First, "the system" will measure a project's success by how closely it meets the original schedule. This is true regardless of how thoughtful, complete, or realistic the schedule. You would think then a wise manager would develop a schedule that provides some slack for uncertainty, risks and inefficiencies. Guess what, this is often more difficult than it would seem.

Just as it is unreasonable to expect a draft horse to compete in the Kentucky Derby, so too is it unreasonable to expect a plodder to meet an ambitious schedule.

Typically, the project manager is under enormous pressure to be optimistic about the schedule. The pressure can stem from a variety of things: higher management (i.e., by way of mandated schedules or reduced cycle time imperatives), fiscal constraints, contractor promises, or simply from the need to "sell" the project. It's easy, albeit wrong, to succumb to these pressures and come up with an optimistic, "success-oriented" schedule as a starting point or baseline. The project manager must resist these pressures and write a schedule that is relatively conservative. I have found that viewing the schedule as a personal commitment or a contract, as opposed to merely an estimate, serves as a bulwark against the pressure to adhere to someone else's notion of what the schedule should be.

Second, the amount of work needed to complete a project will always expand to fill the time allotted to the project. This is especially true when engineers are involved. This seems to argue against a conservative schedule, but here I must distinguish between the "public" schedule and the "work-to" schedule.

The schedule I described above is the public schedule -- the one that the project manager commits to on paper. The actual schedule that the team works toward should be more challenging than that -- one that requires stretching, innovation and some luck to achieve. We have to be careful not to stretch too much, of course, and must remain focused on what we can realistically accomplish. But very often when the team challenges itself this way, the project finishes earlier than the public schedule mandates. Having two schedules may complicate things, but I have found the benefits far outweigh the problems.

Schedule and Cost Risk Analysis Modeling (SCRAM) System developed for NASA under a 1994 SBIR contract at Kennedy Space Center.

Third, I have found that you cannot separate how long work will take from who is doing the work. This seems obvious, but seldom finds its way into scheduling. Many project managers approach scheduling by considering technical risks, work scope and complexity, yet they ignore execution risk. Some persons, teams and/or companies work quickly, while others are more methodical, plodding or mistake prone. Just as it is unreasonable to expect a draft horse to compete in the Kentucky Derby, so too is it unreasonable to expect a plodder to meet an ambitious schedule. Because of this, I use the past performance of whoever is involved on the project as a major factor in putting together a schedule. This is what I consider as the execution risk, and why I am uneasy relying on so-called independent schedule estimates that ignore who is doing the work.

I have found it useful -- and this doesn't come easy to me -- to create a very bureaucratic process for changing requirements.

Finally, one of the major reasons for schedule slippages is uncontrolled requirements growth. In some cases, requirements growth is a fact of life. The manager may have to just accept growth, but, other things being equal, added work should equal a longer schedule. Too often I see managers who willingly agree to adding work without either increasing the time or money to do the work. In effect, this makes adding requirements seem "free." It is bad business and can turn a realistic schedule into wishful thinking.

I have found it useful -- and this doesn't come easy to me -- to create a very bureaucratic process for changing requirements. Basically, I say there will be no changes in requirements until (1) decision makers understand the cost and schedule implications of the change, and (2) decision makers explicitly agree to those implications. It is quite amazing to see how a process that simply establishes accountability for requirements growth promotes better discipline and yields more realistic schedules.

Many project managers succeed or fail depending on how well they deal with scheduling. The champion or master project manager understands that creating a realistic schedule is one of the most crucial challenges he or she will face.

Terry Little is currently the Director of the Kinetic Energy Boost Office of the Missile Defense Agency. Before that he was the head of the Air Force's Center for Acquisition Excellence. He is one of the Air Force's most seasoned program managers. He entered the Air Force in 1967 and served on active duty until 1975. In 1997 he was promoted to the grade of SES.