What’s the right level of detail in a project plan; I mean how deep a project plan should go in tracking activities/deliverables/resources.
Should it be one big consolidated plan with 100's or lines of activities?
Or should it be multiple interconnected plans with relevant local details reporting to each other?
Or just an overview plan with tracking and reporting happening offline?
I have seen very detailed project plans with immense and useful details but completely ignored by teams and plans that track on a very higher level but have no control on the project.
Let’s talk about a mid-size to large project because I think for small projects the details are limited by design and simple measures are more effective specially to strike cost/value balance.
Personally, I have always favored connected plans with communication protocol that track activities and relevant dependencies like product roadmap -> Project Plan -> Release Plan -> Stream Plans (Implementation/Infrastructure/Test/Training/PMO)
That way every plan has the right amount of manageable details and more importantly understood and followed by the team.
I would love to know your approach and thoughts!
Saving Changes...
PMBOK Guide is very clear on the subject. Nowhere does it advocate a very detailed plan at all times for all kinds of projects. It also does not recommend a very sketchy outline of a plan. PMI does not suggest "one size fits all" but provides us with guidelines and standards to customize to project environment.
The three cases you have suggested, for complex and large projects, I would go for the "multiple interconnected plans" but the first and last approaches cannot be considered applicable to all projects all the times.
As a project manager you will have to decide the level f detail you need to go for a specific project, having considered the importance of project, its priority, team competence and skills and especially business and stakeholders' "needs and expectations".
I can pose a project which needs almost no documentation where all the plan is in the head of project manager and still it goes well. On the other hand I can quote a project which was extremely detailed and could not have been done with any lesser details. The final decision lies with the project manager and the approval of project initiator/sponsor. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
You have to take this from the quality perspective. Mainly quality assurance. What determines the amount of deliverable you have to create and the format of each deliverable is your governance process (and your project management process itself). Project means investment and people who give you the money will request from you to demonstrate you are in control. That is because you need a governance process. It does not matter if you have a "one page" document or not. What matters is you will be able to demostrate that with this "one page" document you are in control of all related project component. Saving Changes...
The level of detail vary from across projects. The only way is to know how far could a deliverable be broken down into using WBS technique where it can be managed or estimated. Saving Changes...
Similar to Maxson for the last 15 years or so I have been successfully using a multiple plan approach at different granularities for medium to large business process/technology projects.
The initial plans are for resource and timing estimation purposes, created with the deliverable stakeholders and constructed in 2 hour blocks as the lowest level of granularity. From these plans, I derive what I call the Master Work Plan, which is deliverable/milestone focused and is used to manage the schedule and sometimes the budget. It is from this plan that deliverable resource assignments are made.
Then it is a question of context/method whether the Master Work Plan is used to derive a Product Backlog in the case of Scrum or can be used as a standalone artifact. Regardless, when things are late we can reference back to the detail to determine where the estimates were faulty and see if the same error is repeated downstream and whether adjustments can be made.
Saving Changes...
James PorterSr. Project Planner| Hitachi Rail STS USAGlenshaw, Pa, United States
Some other factors that I feel are relevant to the topic are:
- Personality of the project team. Some teams thrive on detailed schedules while others ignore them. I like to adapt the level of detail to what the team does best with.
- Handoff points. Where you have points where you interface across subcontractors/departments, be as detailed as necessary to make sure everyone knows what needs to happen. If Department A needs to perform a 2-day activity in order to progress work from Subcontractor X to the Customer, put that activity in the schedule even if your typical activity is much longer.
- If a Work Package Leader wants to have far more detailed activities than necessary (perhaps they think it will impress someone to show how many things must be done), encourage that WPL to maintain his/her own detailed list while the project schedule is at a higher level. Just make sure it's possible to accurately capture physical progress. Saving Changes...
David KnutsonProduction planning and project controls professional| Between gigsArvada, Co, United States
If the string is still active: IMHO, the project plan level of detail is what can be objectively and routinely reported. Necessary and sufficient. Similar to Sergio's reply, the WBS needs to be coupled to systems supporting that breakdown. Otherwise, the results are schedule activities precisely defined and progressed, but completely devoid of accuracy when audited, such as build documentation database dates that don't align with project activities, concept / prototype / demo deliveries when final / production / beta release expressed and implied, cost tracking numbers that don't align with progress, and the ubiquitous 1-page dashboards coupled with the almost ubiquitous 10-page explanation. Saving Changes...
