Collective Wisdom from the Experts 149
Fortunately, the “nice to have” items are also the easiest to eliminate. If you
are building a skyscraper, you can’t announce in the middle of the project, “In
order to get this project back on track, we’ll only build 40 stories on this build-
ing, rather than the 60 stories the architectural plans show. We can add the
other 20 later, when we have the time.”
With software, it’s relatively easy to say, “Change of plans—we’ll support only
two operating systems in Release One. Later, we can add the other two we
originally planned to support.”
It’s not an ideal solution, so what can be done to avoid it? Honestly speaking,
probably nothing. It’s the nature of software development projects. However,
what you can do is to plan your scope concretely. Identify the “nice to have”
features and their dependencies from the beginning. The dependencies are
important. Removing a “nice to have” feature may otherwise also change the
development architectures linked to a “must have.”
If you plan possible scope reductions from the beginning, it will make your
decision about what to cut and how to cut it easier, should it become necessary.