| Most managers I know think
that constructing a schedule is primarily a technical
activity. I have found over the years that creating a
realistic schedule for a complex project is mostly an
art -- one requiring lots of intuition, judgment and guesswork.
I don't profess to know all there is to know about scheduling,
but I have a few thoughts that might be useful.
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.
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.
|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.
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.
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.
Cost Risk Analysis Modeling (SCRAM) System developed
for NASA under a 1994 SBIR contract at Kennedy Space
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
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.
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