Page 138 -

To many people, this is all just a fact of life: it’s the reality of how software is developed.
They feel that changes happen, and that there’s really nothing that can be done about
them. But it doesn’t have to be that way. As with iteration abuse, if more of these changes
can be identified on paper during requirements elicitation and reviews, by the time the
programming team starts building the software they are much closer to the goal and will
have to deal with far fewer changes.
However, there will still be requests for changes, and those changes should be controlled
using a change control process. One reason changes are easy to sneak through is because
it’s often easy to describe a difficult change using simple language. It’s human nature to be
accommodating, so the programmers are willing to incorporate that change because it
seems like it would be easy to implement. The change control process requires that a
description of the change be written down, and that engineering team members take the
time to estimate how much effort the change would require. This forces the project’s deci-
sion-makers to decide if the change is worth the effort. If it is, the schedule is updated. But
many changes that seem “simple” turn out to be much more involved than the person
asking for them realizes, and many changes turn out not to be worth the extra effort. If
the changes are starting to make it harder to develop the software, this will cause each
additional change to have a greater impact, which in turn will make it less likely to be
approved. Even if the changes are all approved, the team does not have to fight against an
unrealistic deadline to get them done—instead, the project plan is updated, and it remains
realistic.

130 CHAPTER SIX