Please login or join to subscribe to this thread
The reason why this is such a dilemma is that there is not a right or wrong answer. The level of detail would depend on (amongst others)
a) Project complexity and/or size
If you have a very complex/big project you might have to control execution on a much more detailed level. You might also treat it like a program where you have an overarching high-level schedule with more detailed schedules per component that plugs in. If you determine your project complexity it will also indicate to you where the biggest exposure to risk lies, and this is where you might flesh out the schedule a bit more for better control.
b) Stakeholder needs
I've worked on projects where a schedule as rejected on both grounds, not enough detail or too much detail. While not all requests make sense it is important that you understand your stakeholder needs and come to some agreement on what level of detail will be most efficient. Too little or too much can hurt equally as bad.
as stated by Anton instead of having the "one and only" plan with all granularity, a rolling wave approach with different planning horizons on strategic, tactical and daily level is more appropriate. To apply the principle of subsidiary functions makes also sense: No central authority should do what a subordinate entity can best plan for itself.
As previously mentioned here, the level of detail will depend on stakeholder requirements and project complexity. Other factors which may influence the level of detail include reporting requirements, quality assurance, regulatory compliance etc.
It should contain what is necessary to ensure successful delivery of all deliverables. For some that may be more detailed than others, both from PM and stakeholder perspective. Experience will help identify what level of detail is necessary.
That said, once a planned schedule is completed and baselined, it should indeed be visited often.
There is a big mistake in your post: a project plan is a document, not the project schedule. And, if I understood well, you are talking about schedule, not project plan. That is a big mistake that you have to avoid. Taking into account the project schedule, the deep or level or detail you can manage is 5+-2 levels (it means a range of 3 to 7 levels). That is empirical but have been proved by the psicology. And if you ask me, it has no sense to have an schedule with more level of detail because it has no sense to try to control a project schedule at minimum detail. Why? Because including the fact you have a dedicated team things will not happens as estimated in the more atomic level.
As mentioned above , I also agree that granularity of project plan depend on the type of project , stakeholders and team. If project is complex then it is essential to have detailed plan with proper well defined milestone , if stakeholders are interested the WBS are also mentioned in details in plan and finally it depend on type of team ( if team is experienced and smart then detailed WBS are not needed but if team don't take initiative and work only on basis then WBS is important )
I agree there would not be a binary answer to my question. In my case I always see a push from the business in terms of final deliverables rather than the emphasis on the process. I will try to use the modular approach that you mentioned for the complex projects that I manage. Also a need based stakeholder-centric approach is something very useful and I will try to use this in my future projects.
As others have stated "it depends". This is why while the PMBOK Guide defines what a work package and a control account are in your WBS, they do not indicate the specific level of granularity for each.
Factors to consider include:
- Degree of control you wish to have over the work being done
- Level of experience and empowerment of the team members delivering the work
- Level of uncertainty and complexity of the project
- Whether the project fits a deterministic/predictive model better than an adaptive one
Ideally, a PM can focus on milestones and variances affecting those and let their team members self-manage their individual tasks. Methods such as CCM provide a means of doing this but only work when the organizational and team culture is supportive.
The granularity of project plans vary from project to project. Small projects usually don't require that much granularity. Large projects should have as much granularity to give you a comfort level that you have everything covered. Keep in mind the skill level of your teams also dictate how granular you have to be. You can never assume anything.
Please login or join to reply