Level of detail

[pmkb]

How do you determine the proper level of detail for planning your projects? What considerations do you use?

[Anil]

How do you determine the proper level of detail for planning your projects? What considerations do you use?

One basic requirement is that the activity at the lowest level should be clearly
identifiable,
measurable and
resoursable.

[pmkb]

Hi Anil, welcome the forum!

Yes, I agree. These days, it is possible to have multiple levels to a schedule where detailed tasks can be rolled/summarized for reporting, but should the underlying foundation (ie. the lowest level of detail) ever be compromised for practicality of information processing?

[harrywaldron]

Good "old fashioned" planning is something that is too often skipped in a hurry to move to the execution phase at the macro level, or to move onto the next task at the detailed level. Planning is an iterative and continuous improvement process, where you formulate ideas and refine them until you have a optimal solution. Often times, your 1st thoughts are indeed on the right track, but with some tweeking they can be made even better.

Planning needs to be as detailed as possible, as it pays dividends in the future of the project. For example in the system life cycle for IT projects, an error in design is 10X less costly than in programming and in programming errors are 10X less than those found in the testing phase. An old axiom of mine is that "Planning is your friend"

[Bernard]

Activities must be clearly defined, and should be measurable. This means anyone should be able to determine if a particular activity (as defined) is in progress, or completed.

Activities must be defined every time there is a break or change in work content, and/or by changes in the work crew. Activities that are overly broad in scope are difficult to estimate, schedule and measure/report progress against.

That's from the Turnaround Project Planning Primer.

[Mark V. Smith]

How do you determine the proper level of detail for planning your projects? What considerations do you use?

... but should the underlying foundation (ie. the lowest level of detail) ever be compromised for practicality of information processing?

with the members above.

I would submit that practicality of information processing IS the basis for level of detail. You need detail fine enough to generate practical estimates, and be measured in performance aginst those estimates. You need detail fine enough to determine when a piece of work begins and ends. You need detail fine enough to determine, assign and track resources. You need detail fine enough to determine traceability back to requirements.

Since the effort of project management is somewhat proportional to the granularity of detail, and project management is not the work at hand but only the overhead to keep the work IN hand, too much detail means too much nonproductive information to process. The PM is generally a limited resource too, therefore too much PM effort expended nonproductively would be a hazard to the successful outcome of the project because it detracts from the PM's ability to protect the integrity of the project.

If by "compromised for practicality of information processing" you meant not breaking it down as much as desired because your tool can't handle it, then I misunderstood. Sorry. Get a better tool.

One popular rule is the 8-80 hour rule: break work down into trackable units no smaller than 8 nor bigger than 80 hours. Any further breakdown is the resource's own task list and the PM shouldn't have to be concerned with it. PMBOK(2000) 5.3.2.4 gives a few guidelines to determine "are we there yet?" Are lower level items:
a. necessary and sufficient for completion;
b. clearly and completely defined;
c. able to be appropriately scheduled, budgeted and assigned?
I like the qualifier on assigned: "to a specific organizational unit (person) who will accept responsibility for satisfactory completion of the item." I guess that means the breakdown depends on how responsible and competent your people are.

[cdevera]

Dear Colleagues

Since Programme detailing is the topic I would like to know any of your perspective on any of these:

a) Procurement
b) Testings and/or commissionings
c) As-builts drawings or documentation

If we are to make a programme and detail it, is it necessary to detail these activities? if so then up to what extent?

Kind regards,

Christian

[jjf_1975]

...[sic]
a) Procurement
b) Testings and/or commissionings
c) As-builts drawings or documentation
...[sic]Christian

Procurement, for minor items or of-the-shelf/small lead time I generally just enter in a delivery milestone, but for major procurements or those items with long lead times I enter in the following:
1 - Order Product X (Milestone)
2 - Product X Lead Time (note: entered as an activity NOT lag)
3 - Product X Received (milestone)
4 - Product X Testing (activity)
5 - Product X Accepted (milestone)

Now, in defence we sometimes have separate delivery (received) and acceptance. Some procurement (ie those going on aircraft/submarines etc, require traceability for every part or componet contained within it back to the supplier/manufacturing and some require some testing before it can be accepted and be available for the project to use.

Testing in fully detailed as per any other part of the schedule, testing planning, writing up the test procedures, conducting the test, writing up the report etc etc Generally to the level of the 'product' being testing. In these terms 'product' may be a Configured Item of the software development, or an item to be test. Because defence also used "product-based" WBS, it means we have Integration and Test activities as the MIssion System, Subsystem, Product, CSCI level.

In defence for some reason the drawings always seem to take twice as long as you think...generally we break them down by Level 0, Level 1, Level 2 & Level 3 drawings for each 'product'.

Note, that defence typically has a lot more paperwork and requirements then some other industries, because of the types of equipment/assets/systems that are built. If you stuff up...people can die...so I guess that is why every man and his dog has to review everything, test everything and tick the final box that says it's ok.

Hope that makes sense
J