Advertise with Project Manager online

Project schedules: the good, the bad, and the pretty

Martin Vaughan
April 26, 2012

What makes for a quality project schedule?

  • Well structured, having the right amount of detail?
  • Following the scheduling rules?
  • Dates that make sense?
  • Float calculations and critical path?
  • Pretty and colourful?

Having spent a lifetime in scheduling, this question has been raised on more than one occasion. I have seen schedules built to rigorous standards, obeying all the rules but clearly unachievable although politically correct. I have seen schedules breaking every scheduling rule but providing dates that people actually believed. I have seen very pretty schedules, colourful with the ‘wow’ factor in terms of presentation but with questionable content.

The answer to the question of what makes a quality schedule is ideally a balance of all the above aspects. Schedules should be built in a consistent manner, they should meet a minimum standard and follow a consistent structure.

The baseline dates should be those which are agreed or approved. The forecast dates should be just that—the latest forecast—not some politically correct set of dates. Float calculations and the critical path(s) should make sense. Printouts should be clear, concise and in a consistent format so readers find them easy to read and interpret.

Thanks to the tool vendors we are led to believe you can be scheduling within an hour. Click and drag the bars, use manual schedule override and planning wizards. They all mask the fundamental issue that people really don’t know how to plan and schedule these days.

The ability to define a WBS, responsibilities, dependencies and durations seems to be a lost art, let alone resource modelling, levelling and float analysis. And don’t get me started on tracking progress, providing revised forecasts for future work.

Above: Schedule updated properly

In terms of standards, there aren’t too many recognised scheduling standards around. PMI has published its Practice Standard for Scheduling in which there are about nine key pages which capture ‘Good practice’: it’s not bad. Many organisations try to define their own standards; many more don’t even bother or aren’t aware that they are necessary. When asked about scheduling training, our first question is ‘to what standard?’. We are often met with a blank look. A defined scheduling standard is fundamental, especially if you are trying to improve schedule quality.

So what do we check for in terms of the health of a schedule? Remember, automated checks can only check against the scheduling rules, it takes a person with analytical skills and insight into the project to check for achievability of a schedule.

Automated checks we carry out on schedules typically include:

  • Summaries with dependencies or resources assigned, specifically with MS Project. The tool may allow these to be added but it is poor practice to do so since they can corrupt the float and resource modelling.
  • Missing predecessor. For a closed network, with the exception of the start milestone or incoming interproject dependencies, every milestone or activity/task should have at least one predecessor.
  • Missing successor. For a closed network, with the exception of the finish milestone or outgoing interproject dependencies, every milestone or activity/task should have at least one successor.
  • Future actual, specifically with MS Project. Thanks to the tool allowing for the percent complete status technique, it is possible to have a milestone or activity/task with completed work after the status date. Our ‘rules’ state that people provide actual dates for completed work with a focus on rescheduling the remaining duration (revised forecast finish date).
  • Unstatused. Following a regular status update, there should be no milestone or activity/task with incomplete work scheduled before the Status date. Our ‘rules’ state that the remaining duration must be scheduled after the status date.
  • Unresourced. Only if there is a requirement that all activities/tasks must be resourced, we check for any item missing an assignment.
  • Resourced non task, specifically with MS Project. Summaries and milestones should not have a resource assigned (unless it is a cost type of resource for milestones).
  • Suspect duration. Shorter or longer than a predefined duration, e.g. no more than 2 x reporting cycles. The only exception being long lead times (for procurement) and level of effort tasks (e.g. admin/management). Never less than one day duration.
  • Suspect constraints. Checks for constraint types other than ‘ASAP’ or ‘No Earlier Than’ are used. For MS Project, also checks for use of ‘deadline’ date too.
  • Uncoded. Checks for where any mandatory reporting codes have not been assigned to milestones or activities/tasks.

Finally, schedule quality is fundamentally tied to using the tools properly. When we learnt to drive, it was all we could do to use the clutch and brake pedal smoothly. Road awareness only came later once our mind wasn’t focused on the mechanics.

Scheduling is similar: users must be good enough with the tools to not have to worry about making the tool work, they can focus on the project they are planning. Each tool is different, just like cars are different, but they all do fundamentally the same thing. And yes, it does take longer than one hour to get good at them!

Martin Vaughan
Martin Vaughan started his career as a specialist planner/scheduler in construction before moving to defence, then into IT. He progressed through project management and program management into consulting and advisory roles. Meanwhile he maintained an interest in tools and technology, on the way building and managing small businesses and squeezing in some lecturing in IT Project Management at the University of Melbourne. He is now a director and senior consultant at Core Consulting Group.
Read more

2 thoughts on “Project schedules: the good, the bad, and the pretty

  1. Basic Schedule drawn right at the beginning must be to the extent realistic & feasible. However, due to various inevitable circumstances during the project execution stage, many a times schedules are redrawn but but on many an occasion over look the ground reality which ultimately leads to jeopardizing the project.

    Needless to mention that while redrawing the schedule, the existing real ground reality need to be vigorously considered taking all aspects into account so that slippages are minimized and resources are optimized / augmented to recover the loss to the most practicable extent. Schedules need not be redrawn just only for the sake of satisfying certain agencies, it will only lead to disaster.

  2. Thanks, Martin.
    I like this article, especially the advocating of the basic set of rules of good practice, which is rarely ever seen anywhere.
    It is just good practice to not assign resources to summaries, nor costs, nor predecessors.
    Why? because they are not tasks or milestones.
    You mention actuals in the future (relative to the status date?).
    How about planned or scheduled duration in the past (relative to the status date?)?
    I see both of these all the time, and when I try to point out that both are impossible I often get a response that they are somehow OK. What!!??

Leave a Reply to A..K.shukla Cancel reply

Your email address will not be published. Required fields are marked *