Parkinson’s Law for Schedules

Parkinson’s Law states that “Work expands so as to fill the time available for its completion.”

To plan the development of a product, we create a schedule. This schedule is a model of how we hope to proceed with the project. We use it to determine what we need to do, the best order in which to do it, what people and resources we will need and how long it might take. A good schedule is an invaluable tool for planning a project.

During planning, we can’t know exactly how long each task will take. Especially if it is something we haven’t done before. The times we allocate for each task in the schedule are estimates. Some will be too high and others will be too low. We make the assumption that the errors will balance out to give a fairly accurate prediction of how long the project will take.

During development, managers are tempted to tell the engineer assigned to the task that it must be done within the time specified by the schedule. (Note that since the schedule is a model that predicts reality, the manager is actually asking the engineer to make reality conform to the model.) But if they do this, Parkinson’s Law takes effect. The task will never take less time than allocated. Our assumption that some tasks will take less time than estimated and other tasks will take more time than estimated is no longer valid. No tasks take less time than allocated. The project always takes longer than scheduled.

Aggressive schedules

If work expands so as to fill the time available for its completion, it stands to reason that work should shrink if there is less time available for its completion. Therefore, a project might get done sooner if you assign optimistic (or, in management jargon, “aggressive”) completion times for each task.

This works up to a point: an aggressive deadline does encourage focus and discourage digressions. Unfortunately, scheduling no time at all for a task doesn’t mean it will be accomplished instantly! If your schedule is too aggressive, even a well-trained, well-focused and well-equipped engineer will not complete the tasks on time.

If you decide to use an aggressive schedule, you are acknowledging that many tasks may take longer than scheduled. But you hope that you can motivate your team, by fair means or foul, to meet aggressive deadlines. And even taking into account the inevitable overruns inherent in aggressive scheduling, you reason that the project will still get done faster than it would have had you used a more realistic schedule.

However, by deliberately distorting your schedule, you have reduced its usefulness as a model for planning product development.

Attributes of Useful Schedules

A schedule is far more valuable as a planning tool than it is as a motivational tool. And while nothing can take the place of a schedule for modeling your understanding of the development process, there are many other ways to ensure that your development team works productively. Therefore, you want to make your schedule as useful as possible for planning a project. A useful schedule has three major attributes, listed in order of usefulness:

1. A complete lists of tasks

A useful schedule defines all of the tasks that need to be done. A schedule that does not define all of the tasks that must be done will underestimate the cost and duration of a project. Tasks that are discovered during development will usually take longer than if they had been thought about and included in the original schedule.

2. Accurate task dependencies

A useful schedule also defines which tasks depend upon the completion of other tasks. This in turn determines the order in which the tasks should be done. Tasks that are done out of order will always create re-work. And tasks that could have been done in parallel but weren’t, will result in a development effort that takes longer than it might have.

3. Estimated time to complete each task

And finally, a useful schedule estimates how long each task will take. However, even if you are careful to make time estimates based on past experience and good judgement your estimates won’t be perfect. Actual completion time will depend on many factors, including the level of skill and experience of the engineer assigned to do the task. But for planning purposes, over-estimates and under-estimates balance out and the schedule you have planned will be reasonably accurate.

Making a useful schedule

Note that the first two attributes of a useful schedule can be specified exactly but the third attribute can only be estimated. If a task must be done, it must be put in the schedule. If a task depends upon other tasks, the other tasks must be done before it is started. But the time to complete a task can only be estimated.

Note also that a schedule that omits a task that ends up taking 3 weeks is less accurate than a schedule that underestimates the time to complete a task by 1 week. A schedule that misses a dependency of task A on task B, resulting in a delay of 3 weeks waiting for task B to be completed and another 2 weeks redoing task A, is a lot less accurate than a schedule that underestimates the time to complete task B by 2 weeks.

So make your time estimates good enough, but don’t put extra effort into making them perfect. Focus your effort into making your task list complete and identifying all of the dependencies. You will end up with a schedule that is more accurate and therefore more useful.

An anti-pattern emerges!

Trying to manage a project by asking everyone on the team to complete each task according to the schedule is an anti-pattern. If you attempt to manage a project this way, Parkinson’s Law ensures that your project will actually take more time and money than scheduled.

Awakened Systems Engineering