Page 250 -

the project from delivering at that time. In fact, simply agreeing to the deadline is actually
being inflexible, in that it ignores the reality of the situation and fails to present alterna-
tives that might actually help the team meet the deadline (or, at least, satisfy the organiza-
tion’s needs that motivated the decision to impose the deadline).
Creating transparency and gathering consensus are the most effective ways to address this.
When a project slips, the project manager needs to diagnose where the planning went
wrong or what risk was not previously considered. Hopefully, she has done enough plan-
ning (see Chapter 2) that she has real evidence that the project will not meet the deadline.
In this case, true flexibility would involve presenting the senior manager with options, such
as doing a phased release, scaling back the features to be developed, or adding resources.

Change your approach when necessary

Sometimes a project manager is faced with a project that is coming in early. The schedule
was the result of a difficult negotiation, and moving the date earlier means giving up the
hard-won project time. It seems counterintuitive to move the deadline up and give up the
extra padding. But there are cases when this is necessary.

One of the most common situations that results in decreasing the schedule is when a pro-
grammer discovers a shortcut. For example, a project may have gone through a solid esti-
mation process, and a project plan was created when one of the assumptions for the
estimates was that a certain component would have to be built from the ground up. For
example, if a programmer discovers that this component can be replaced with one pur-
chased off the shelf, this reduces the effort required to build the software.

Many project managers would happily sweep this under the rug and keep that extra
schedule time as a buffer against future schedule slips. This feels like “flexibility” to the
project manager, because it keeps her options open in the future.
The temptation to keep the buffer in the schedule must be resisted. Just as the overly
aggressive deadline had to be resisted with transparency and honesty, the project plan
must be kept honest in this case as well. The reason this is the truly flexible option is that
the extra effort can then be reused by the organization, either to extend the current

project or to apply it to a future one. Keeping that effort on the current project schedule
denies it to the organization and limits its ability to develop other projects.

Don’t confuse “easy to describe” with “easy to implement”
Many changes are very easy to describe in words. Yet most programmers can tell horror sto-
ries about being asked for a “tiny change” that turned out to require an enormous amount
of effort. A manager asking for an easy-to-describe change will often assume that any
project manager who balks at immediately implementing the change is being inflexible.
It is a common myth that having a software process—that is, deciding on how you are going
to build the software before you actually build it—is inflexible. The feeling is that requiring
that the software be planned and designed before it is built will prevent programmers from

242 CHAPTER TEN