Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Estimating, Information Technology, New Practitioners, PMO, Work Breakdown Structures (WBS)
How granular is your project plan?
Originally I had posted this question in the Microsoft forum for Project & Portfolio Managers in LinkedIn but I did not receive any response.

The question was that I constantly face the dilemma when creating a project plan. How granular do you want your project plan to be? Although I like the idea of a governing structure that would provide direction for the project (aka the project plan) its quite another thing to track all tasks on a project plan. One of our senior executives once told me - he has project managers who won’t have a sip of coffee without visiting their project plan daily - he was referring to PMs that think that all tasks on a project should be on the project plan. Do you guys agree ? Let me know your suggestions. I'm using MS Project for tracking the project.
Sort By:
Page: 1 2 next>
Mahesh

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.
...
1 reply by Mahesh Pachhapurkar
Oct 15, 2017 9:16 AM
Mahesh Pachhapurkar
...
Hi Anton,

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.
Mahesh

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.
...
1 reply by Mahesh Pachhapurkar
Oct 15, 2017 9:18 AM
Mahesh Pachhapurkar
...
Peter - Thanks for the inputs. Although I agree with your time based view, I always find this difficult to manage using MS project. Do you have any examples of how you implement this especially using MS Project?
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 )
Oct 15, 2017 2:13 AM
Replying to Anton Oosthuizen
...
Mahesh

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.
Hi Anton,

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.
Oct 15, 2017 5:16 AM
Replying to Peter Ambrosy
...
Mahesh

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.
Peter - Thanks for the inputs. Although I agree with your time based view, I always find this difficult to manage using MS project. Do you have any examples of how you implement this especially using MS Project?
Mahesh -

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.

Kiron
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.
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Maybe this world is another planet's hell."

- Aldous Huxley