Project Management Central
|
Please login or join to subscribe to this thread
Request to reuse this Topics: Estimating, Information Technology, New Practitioners, PMO, Work Breakdown Structures (WBS) |
||||||
|
||||||
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. 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.
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 
Network:2306
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
ADVERTISEMENTS
|
"Maybe this world is another planet's hell." - Aldous Huxley |
