In the world of project management, creating a project plan is a crucial step towards achieving the desired outcome. However, the question arises as to when to create a separate project plan for each section of a larger project. Recently, I came across a project plan that had multiple mini-projects within it. While they all had something in common, such as the same customer or similar functions, I felt many of the sections of that project plan deserved a separate plan by themselves.
When I asked the project manager why he created a single project plan instead of many, he told me that the reason is ease of maintenance. It made sense to me as all of them are managed by him only.
But, I felt it also creates a single point of failure. Such a complex, monolithic project plan works for him because he created it and knows the logic behind how different mini-projects are combined to form a single large project. What if he moves to another team tomorrow and someone else has to pick this project? Won’t it need a tremendous amount of learning/understanding/managing things the way the previous program manager did?
Even now, I doubt whether all his team members understand this complex project plan. This can also cause unnecessary friction and ambiguity, resulting in delays and/or rework.
Considering these, I feel we should keep things simple and create multiple project plans when necessary. We can always link them together to create a master plan if it makes sense.
But, if we extend this logic, we can argue that every line item in every project plan might need another dedicated project plan. Where do we draw the line? How do we know when we can say THIS needs a separate project plan?
Thankfully, we have our programmer friends who have a similar problem and found a solution too: Functions!
There are clear expectations on how functions are defined. Each function should be created to perform a specific task or set of tasks within their code. They should be designed to be reusable and modular, meaning they can be called multiple times throughout their code without having to rewrite the same code over and over again. Hence, a good practice is to keep functions small and focused on a single task. This makes them easier to understand, test, and maintain. It also allows for better code organization and readability.
Of course, all these don’t apply to project plans as is. But we can still use this reasoning and ask some simple questions such as:
- What is the purpose of this project or task?
- What are the inputs and outputs (entry criteria and exit criteria)?
- How complex are the steps in between?
- Who executes these steps? (Same person, multiple people, different teams, etc.)
- How complex are the dependencies between these steps?
Based on the response to these questions, we can say whether this needs a dedicated project plan or it can sit inside its parent project plan.
In conclusion, creating a separate project plan for each section of a larger project depends on various factors such as complexity, dependencies, and execution. By asking simple questions and analyzing the responses, we can determine whether a dedicated project plan is necessary or not. Ultimately, keeping things simple and organized is key to effective project management.
***
Originally Published in my LinkedIn Page
