Archive for February 2011

 
 

Projects, Deadlines, Agile, and Schedules

All projects have deadlines. These include the day on which the money or patience of whoever is funding a project is exhausted, the competition releases something that captures a market, or a technology becomes obsolete. The scary difference between real deadlines and the artificial ones usually imposed on projects is that real deadlines may not be recognized until after they have been missed. Agile practices, such as Scrum, do not eliminate these deadlines.

Since the real deadlines are often unknown, completing projects expeditiously is a wise practice. Good scheduling helps to do this.

A schedule should be an iterative and evolving plan. It is a model of an expected future that can be examined, critiqued and hopefully improved. A schedule is not a prophesy, a prediction or a promise. People who set out to do something usually have at least some idea of how they will get that done. When those ideas are collected, organized and written down, they form the basis of a schedule.

Schedules have been used to lie, terrorize project teams and create completely unrealistic expectations. These are abuses of scheduling and are not inherent in scheduling itself. Bad or abusive schedules are tied to bad or abusive management practices. Agile sometimes seems to view scheduling as a bad or abusive management practice. This is a mistake.

The Agile practice of doing the most important things first is a good one. The expectation this means projects can release whatever they have on hand at any time ignores the impact of competition. In a noncompetitive environment, such as internal IT projects, any improvement is valuable and a partial release can be useful. In a highly competitive environment, such as online games, incomplete or noncompetitive releases serve no useful purpose.

Good schedules help to clarify what the most important things are. This includes the things which take a long time to do, so that they can be started sooner, and the seemingly unimportant things on which more important things depend. Good schedules provide a benchmark against which progress can be measured and illuminate where more resources should be applied or expectations changed.

When setting out to accomplish something, it is a good idea to identify what is needed to accomplish it. Scheduling is not a perfect way to do this, but it is a better way than sprinting from point to point in the hope of reaching the final destination before the money runs out or someone else gets there first.

It is argued that setting and meeting deadlines can force the premature release of poor quality products. While it is certainly a bad idea to release a poor quality product, there have been too many instances of poor quality in late releases to believe that delays translate into good quality. They do translate into higher costs and missed opportunities. A good schedule is a valuable aid in meeting deadlines with quality releases.

Two things are required to deliver a project on schedule: realistic deadlines and a team determined to meet them.