Seven deadly sins of scheduling

 

Something I’ve taken for granted is a project manager’s ability to create and maintain a project schedule.  The reality is that most accidental project managers spend at least as much time struggling with their schedules as they do getting real value out of them.

No project scheduling tool is inherently bad, but there are a few cardinal sins that will reduce the value you achieve by using these indispensable aids.

1. Use a scheduling tool to help you define the scope for your project. Most scheduling tools are good for entry of tasks with durations and dependencies but are lousy as brainstorming or iterative definition aids.  Spend the time to create a Work Breakdown Structure (WBS).  Then using traditional Post-It notes or a similar visual approach, sequence the activities that will deliver the scope of your project.  Once you’ve got the skeleton ready, you are ready to transition this information to a scheduling tool.  Otherwise, get ready for spaghetti-like dependencies that are impossible to trace…

2. Use scheduling constraints excessively. Too often, I’ve reviewed project schedules that are saturated with constraints – these have been used as a cheap way of getting tasks to start and end on specific dates.  While this may help to get a quick & dirty view of a project’s time-line, it effectively neuters a critical path methodology-based scheduling engine and eliminates the ability to optimize schedules through appropriate use of slack.  Constraints should be used to capture real world situations only (e.g. we can’t start this task until the next Saturday as that happens to be the first available maintenance window).

3. Use automated resource leveling and effort-driven tasks. Automated resource leveling is a great concept but is poorly used – unless you are 100% certain about the relative priority of individual tasks (most organizations can’t even figure out the relative priority of their individual projects!), this feature can effectively shred your schedule.  Effort-driven tasks work well for projects where there is a true linear relationship between resource allocation and task duration – however, on most knowledge-based projects, Brooks’ Law and the old cliché about nine women being unable to have a baby in one month come into play.

4. Capture too many (or too few) tasks. Remember that a schedule is just a model of what you expect to happen that serves the dual purpose of being a forecasting and tracking tool as well as a communication medium to team members and project stakeholders.  There is equally as much pain of having a schedule that is at too high a level of detail (it is too easy to lose track of schedule progress) as there is of attempting to define and track every minuscule activity that occurs on the project (you’ll spend all your time maintaining the schedule).

5. The schedule is out of date the moment it is updated, so why bother updating it? Of course, this is a relative state, and yet many PMs seem to feel that keeping a schedule current is a waste of time.  Unfortunately, this reduces the value of a schedule to purely being a task list.

6. Outline levels and milestones are GREAT! Outline levels and milestones are a good way to present schedule information in a fashion that will satisfy multiple levels of detail for status reporting.  Having said that, too much of a good thing is also not a great idea – just because your scheduling tool supports hundreds of outline levels or milestones per schedule does not mean you have to push the boundaries of these limits!

7. We can’t start over… The worst sin of scheduling is to work with a schedule that has reached such a level of chaos that no one derives any value from its continued existence.  Many project teams take that undesirable journey to Abilene without someone stepping back and saying “let’s start over” – not only can that reduce administrative effort but it can create the perception of a clean slate for the project team.  To quote Kenny Rogers, “You got to know when to hold ’em, know when to fold ’em…”

(Note: this article was originally written and published by me in September 2009 on my personal blog, kbondale.wordpress.com)