Wednesday, June 5, 2013

Schedule Estimating Threshold

Ten Step Header with Logo and Social Media
Define the Work
Before You Start Project Execution
Have you ever been on a project that experienced difficulties? The chances are you looked back and said "we should have spent more time planning". You need to do a good job defining the work before you start to execute the project.
Spend two hours with us to learn the elements of defining the work of a project. You will learn the following:
 - How to define project objectives and why they are important
- The elements of scope needed for a project
- Alignment of objectives and deliverables
- Differentiating assumptions, risks and constraints
- Identifying project sponsor and other key stakeholders
- Much more
This class is valuable for experienced and inexperienced staff. We describe many of these concepts in a way most have not heard before. 
This distance learning session will feature instructor-lead teaching, exercises to reinforce the concepts, interactive feedback and real-time questions and answers.
Two PDUs will be awarded to all participants.
June 17, 2013
12:00-2:00 PM EST (Atlanta USA)
Cost - $49 per person

Schedule Estimating Threshold
When you create a schedule you generally don’t know enough to enter all of the detailed activities the first time though. Instead, you identify large chunks of work first, and then break the larger chunks into smaller pieces. These smaller pieces are, in turn, broken down into still smaller and more discrete activities. This technique is referred to as creating a Work Breakdown Structure (WBS).
A question people ask is how small the activities should be before they do not need to be broken down further. This is referred to as your “estimating threshold”. Work can be broken down into smaller activities than the estimating threshold, but normally no work would be left at a higher level. The threshold can be different based on the size of your project and how well the work is understood.
You can use the following criteria as a guide. For a typical large project (say 5000 effort hours or more) the activities should be no longer than two weeks. Medium and small projects (say 1000 effort hours or less) should have activities no larger than one week. Remember that this threshold is an upper limit. You can break the activities down further if you want.
Assigning work that is smaller than your threshold allows the work to be more manageable. Think about it. When you assign work to a team member you don’t know for sure how he is progressing until the due date (or the completion date if it comes first). (Yes, you can track progress if the work proceeds linearly - like painting a wall. But many of us work in the knowledge business (IT, Sales, Finance) and it is not easy to know exactly how the work is progressing.)
Let's look at an example. If you assign a team member work that is due in four weeks, you are not going to know for sure whether the work is on time until the four-week deadline. The worker may tell you things are on track, but you don't really know for sure until the due date. If the work is completed you will know you are on track. If the work is late you will know it then as well. However, four weeks (or longer) is too long to wait to know if the work is on track. A better approach is to break the four-week activity into four one-week activities. Then you will know after the first week if the work is on time or not.
If at all possible you want to try to have schedule work completed within two weeks. If you give someone work that takes four weeks or longer there is just too much time before you really know if things are on-track or not. It is much better for you if you can keep the schedule feedback loop to no more than two weeks.  
News from Max Wideman (  
June 2013 - This month in Papers we are starting a new series of book reviews. In this Set #1, we review Kathy Schwalbe's latest updates to her admirable An Introduction to Project Management. This is followed by a look at Pyzdek & Keller's comprehensive description in The Six Sigma Handbook, and we conclude with Jerry Julian's introduction of new concepts Facilitating Project Performance Improvement.

Our Guest Mark Kozak-Holland presents his case study describing how Meddling Stakeholders: the Titanic Project resulted in such a disastrous outcome. With the help of a long LinkedIn exchange, our Musings this month answers the question: How Critical is the WBS to Project Scheduling?