0

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

3
  • 1
    Why is the development approach changing? If there is so much uncertainty, why are you not using an adaptive or agile method to handle this uncertainty? Such methods can be described at a level of detail to guide the team through an iterative and incremental process of discovery and delivery without needing significant changes to the project plan documents.
    – Thomas Owens
    Jun 28 at 10:52
  • 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
    – NinjaPM
    Jun 28 at 11:47
  • I hate this question, because I've lived this question.... One of my partner teams filed (IIRC) 244 baseline changes a month. 1) Please move your comment into the question - it adds critical details and is much more likely to get you an answer. 2) Insufficient evidence for an answer, but I suspect the problem is the hybrid model, where we use the language of scrum (sprint), but religiously avoid self organizing teams. (waterfall) and the solution might be to change the level of granularity of your deliverables.
    – MCW
    Jun 29 at 15:19

1 Answer 1

0

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.

1
  • Thanks Thomas. I'll now split the project plan into individual components, I agree, this is help with better management of the PP
    – NinjaPM
    Jul 5 at 0:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.