Project plan updates for a very dynamic project

Question

I am currently managing a complex development project, comprising of 17 engineers, due to the nature of the project there are many uncertainties and also the development approach frequently changes

I have created a detailed project plan, which I try and update at the end of every week once activities are completed or milestones are met, tried using clocked hours from Jira to manage planned versus earned but since the activities keep changing this was proving to be an impossible task

My question is, how do we manage the project plan when the plan is frequently changing, I am not looking for how to control changes, I am trying to understand how to manage the project plan and effectively undertake EVM, also do you think EVM can be considered for a project of this nature, or a basic variance analysis should be undertaken

I have a baseline, if I perform tracking on the set baseline, the project plan looks pretty skewed The development work packages vary from firmware dev, software dev, mechanical design and dev, electronics design and dev, I am following a hybrid approach where the software is run through sprints whereas I am forced to follow waterfall where hardware design and dev is involved I'm using an incremental approach wherever possible, but going full agile seems impossible. Also, the project has strict deadlines and associated LD's, so driven top down

Answer 1

It sounds like you're trying to develop a single project plan when you should be trying to develop a program plan with several project plans.

It sounds like you're developing a complex system if you have software, firmware, electrical, and mechanical components. Depending on the exact nature of the system, you may want to group them differently. Perhaps you have an electromechanical team and a software team. Maybe you split the firmware team out from the software team. In some cases, treat the electrical team separate from the mechanical team. Regardless of how you do it, each team becomes a project team that would roll up into a single program.

Each project can choose their method based on their needs, considering factors like requirements stability, team knowledge and capabilities, and desired visibility. If your hardware teams feel that the requirements allocated to the hardware are more stable, they can create plans and schedules using approaches that tend toward plan-driven methods. The software teams probably have more unstable requirements - it's common for hardware issues to require software changes due to schedule and budget constraints, for example - so they may opt toward more adaptive or agile methods.

Your overall program plan will guide the teams in choosing their approaches along with how teams communicate and coordinate as schedules change. Even if your hardware teams are following plan-driven methods, things may come up that would allow the software teams to reprioritize their work to maximize integration.

I'd also recommend separating the plan from the schedule and work tracking. The plan should give information about how you schedule and track work. But unforeseen events shouldn't require changing the whole plan. By isolating the right pieces and putting the right levels of change control on each one, you are going to reduce the burden when it comes to updating and releasing a revision to some artifact, whether it's the plan itself or some aspect like a schedule, roadmap, or budget.