I have a client that is requesting that I enter in all work packages no longer than 8 hours. My experience is that 40 hours is standard but they have stated that past experience tells them that 40 hours introduces risk.
My experience tells me that having individual tasks at only the 8 hour max will introduce risk all on its own.
David -- I like your rule #1. Starting with seriou clarity on the product (in terms of objective, deliverables, and succes criteria), and then quickly jumping into the development of the dependency network of tasks needed to deliver and support these end states is what is recommended in the TOC approach to PM. Dependency network building (starting at the end, and sequentially asking "What do I need?" to start each identified task, working back to things that already exist) is far superior, IMHO, to overdoing detail on a WBS. Overemphasis on a WBS has too much opportunity to miss necessary dependencies.
Regarding rule 2, however, in the planning/scheduling phase, how do you know who will be doing the work when it comes around?
Appropriate task granularity is simple, if one defines a task as a chunk of work, that when complete, allows someone else to start their chunk of work necessary to lead to the objectives, deliverables, and success criteria of the project. If that results in 1 day, fine. If if results in 40 days, fine.
I look at this issue from the reporting/CYA perspective. :-)
Whichever maximum increment of time you choose to breakout your tasks will directly impact your ability to track progress and give accurate project status reports to sr mgmt.
By choosing to breakdown tasks longer than 40 hours, you decrease the chance you will be caught with a delay/slip that is longer than a week to resolve and will be better able to give visibility to major slips before they happen.
Maybe I've been in too many scenarios with the SOP mantra of "the beatings will continue until morale improves," but I've been able to use the 40 hour task limit to illustrate potential risks to mgmt and receive the attention required to resolve issues before the entire project gets knocked sideways without any warning.
Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
Roger, you make an excellent point. I found that keeping my max task times to align with progress reporting keeps you ahead of the game politically and functionally. Saving Changes...
John ZacharProduct Dev Manager| Association for Project Management (APM)Brackley,, Northamptonshire, United Kingdom
Lots of interesting discussion - in my humble opinion, work package development / creation or the partitioning of tasks / activities is really dependent on a number of factors; people, resources, complexity, etc.
Being able to track progress is really dependent on what has been / will be delivered - that point has already been made - PBS then the WBS.
Lenght of any work package in my opinion should not exceed about 5 or 6 mandays. I want to be able to ensure that the consumption of my resource is focused on what needs to be done - and isn't running off at some tangent - thereby wasting effort and expending time that I can't get back. Saving Changes...
What I'm hearing is that most of you want to limit work package/tasks in order to assure catching slips or to stay on top of resources. There seems to be an implicit weekly feel to your limits -- 40 hours, 5-6 days. This suggests that you're doing weekly updates.
Why not collect status daily with a simple rolling "days to completion" update?
If you start getting daily reports of 5 days left on day 1, 5 days left on day 2, 5 days left on day 3, then you know that the resource has either run into a problem, or not started it yet and is reporting time to complete from when s/he starts.
Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
Actually I change my update frequency based on days until the project is complete. During the last two months I am usually in the daily update mode. I come from the old school of construction type project management. I find small work packets make it easy to "walk the site" and it helps the team see their progress. Successful PM is a people thing not a technical thing afterall. Saving Changes...
Anonymous
Very late comments, but here goes: 8 hour work packages? Maybe for a week-long project. I'm a PM on IT projects - most of my projects are at least 6 months in duration - I track tasks at the 8-80 hour granularity - work packages are usually much longer in duration. My team members are responsible for billing time and tracking progress against their own tasks via our time tracking tool (it feeds the input back to our project plans). I can't imagine the pushback I'd get from my team on assigning work packages in 8 hour increments - I think the word that would be used is "micro-managed" - that, and of course, mild cuss words muttered under breath. I can very well imagine the negative impact on the cooperation level of my team.
Isn't it part of a PM's job to motivate their team into understanding, accepting and practicing good project management principles? Saving Changes...
I find this a very interesting discussion for how different I manage project tasks. I agree with Michael Woods opinion that breaking the overall work package into smaller chunks (my words) makes it easier to track, because it is done or not done. IT developers are notorious for not providing an accurate estimate for percent complete, and could be at 90% for 50 % of the time (yeah, tell me if that makes sense!) So what I do, is try to break the overall task down into parts that have tangible outcomes. For eaxample, this includes a design document, code, code review, unit test, etc. each would have enough detail for me to ask what is left to do. This way I have a strong feeling for where a 200 hr deliverable status actually is. I have no problem is breaking measurable tasks down to 4 or 8 hrs if the deliverable is only estimated at 40 hrs overall. In general, I do think that trying to determine task progress over 40 hrs can introduce risk unless you are addressing it some other way
Ken Roche, PMP Saving Changes...
Rakesh TrivediSenior Project Manager| IT CompanyIndore, Mp, India
Good Discussion, One point wanted to stress that Work packages can be of any size ranging from 8hrs to xxx hrs but only catch is that one work packages again will consist of sub packages , so for tracking purpose work packages can be shared with Customer but sub packages should be internal to team for low level tracking .Having said that, it will again depend upon Team/Organization to describe period of a work packages which would deviate as per requirement .
Saving Changes...
Sylvie EdwardsProfessor/Program coordinator| Durham College (DC)Whitby, Ontario, Canada
Okay so the standard for work packages is between 40-80 hours. If you need documentation just point your client to the WBS standard published and post with the standards documentation at www.pmi.org. When you start going at the 8 hour level you are not doing WBS work packages any longer you're working on your schedule and a gantt chart.
This is a none problem these days with technology, increases in the need for faster delivery. People want to skip that bit about the BIG PICTURE. That's when you introduce RISKS. Saving Changes...
