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

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!