Project Management Knowledge Base

Go Back   Project Management Knowledge Base > Project Management Knowledge Base > Planning

Reply
 
LinkBack Thread Tools Display Modes
  #1  
Old 09-06-2005, 02:31 PM
pmkb's Avatar
Administrator
 
Join Date: Aug 2005
Location: Cyberspace
Posts: 326
Level of detail

How do you determine the proper level of detail for planning your projects? What considerations do you use?
Reply With Quote
  #2  
Old 09-07-2005, 12:54 AM
Forum Newbie
 
Join Date: Sep 2005
Posts: 1
Quote from pmkb :
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.
Reply With Quote
  #3  
Old 09-07-2005, 06:54 AM
pmkb's Avatar
Administrator
 
Join Date: Aug 2005
Location: Cyberspace
Posts: 326
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?
Reply With Quote
  #4  
Old 09-13-2005, 02:20 PM
harrywaldron's Avatar
Forum Newbie
 
Join Date: Sep 2005
Location: Roanoke, VA
Posts: 25
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"
Reply With Quote
  #5  
Old 09-26-2005, 10:31 PM
Bernard's Avatar
Forum Newbie
 
Join Date: Sep 2005
Location: Friendswood, TX
Posts: 29
Quote :
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 [url=http://www.interplansystems.com/turnaround-project-planning-primer/defining-activities.html]Turnaround Project Planning Primer[/url].
__________________
Bernard
- [url=http://www.interplansystems.com/project-planning-software/etaskmaker.html]eTaskMaker Project Planning Software[/url]
- [url=http://www.interplansystems.com/project-management-software/atc.html]ATC Professional Turnaround Management Software[/url]
Reply With Quote
  #6  
Old 10-03-2005, 06:14 PM
Mark V. Smith's Avatar
Forum Newbie
 
Join Date: Oct 2005
Location: Sacramento, CA, USA
Posts: 16
How practical is YOUR practicality?

Quote from pmkb :
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.
__________________
Mark V. Smith, PMP
Princeton Solutions Group
Sacramento, Ca
Reply With Quote
  #7  
Old 02-15-2006, 11:20 PM
Project Hobbyist
 
Join Date: Dec 2005
Location: Muscat
Posts: 71
Send a message via Yahoo to cdevera
Post

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
Reply With Quote
  #8  
Old 02-24-2006, 05:18 AM
jjf_1975's Avatar
Forum Newbie
 
Join Date: Sep 2005
Location: Adelaide, SA
Posts: 11
Quote from cdevera :
...[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
Reply With Quote
  #9  
Old 10-30-2010, 08:22 AM
Project Hobbyist
 
Join Date: Oct 2010
Posts: 75
Quote from Anil View Post:
One basic requirement is that the activity at the lowest level should be clearly
identifiable,
measurable and
resoursable.
Anil brings up very good points and I couldn't have said it better myself.
__________________
How I am Earning my PDU's
[url]http://www.pmguide.net/pducast1.php[/url]

How I Success In The PMP Certification!
Easy and Cost Less Than $100
[url]http://www.pmguide.net/Recommended/F4/PMPrepcast.php[/url]
Reply With Quote
  #10  
Old 11-13-2010, 02:34 PM
Project Hobbyist
 
Join Date: Oct 2010
Posts: 75
Quote from Anil View Post:
One basic requirement is that the activity at the lowest level should be clearly
identifiable,
measurable and
resoursable.
I go by the same principal
__________________
How I am Earning my PDU's
[url]http://www.pmguide.net/pducast1.php[/url]

How I Success In The PMP Certification!
Easy and Cost Less Than $100
[url]http://www.pmguide.net/Recommended/F4/PMPrepcast.php[/url]
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT -5. The time now is 09:01 AM.


Powered by: vBulletin - Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2009, Crawlability, Inc.
Copyright (c) 2005 Measuring Up. All rights reserved.