(^148) 97 Things Every Project Manager Should Know
Scope Change Happens; Get Used to It
Pavel Simsa, PMP
Bellevue, Washington, U.S.
IF ThERE IS onE ThIng that distinguishes a software development project
from other project types, it is how, inevitably, scope changes occur. Not that it
never happens in other places, but I can’t think of another industry with such
a constantly fluctuating scope.
You know projects are governed by the triple constraint: cost, time, and scope:
• Cost. If your project is in trouble, throwing in extra money or resources
rarely helps. If you double the number of diggers, you’ll probably get your
trench dug in just slightly more than half the time. But if you double the
number of software developers, hoping to get the project back on track,
it will probably do more harm than good. You will create huge confusion
over who owns what code and how things need to be done. So cost needs
to stay the same.
• Time. There’s always “The Date.” It is not the delivery date indicated in
your original schedule. Nobody officially mentions it out loud, but if
you are developing a big security product that is scheduled to release in
November, there is a likely chance you will get to keep your job even if
your delivery slips until January. Secretly, the team knows “The Date” is
February, for example, “at the time of the international Black Hat secu-
rity conference where new releases are announced.” You have some flex-
ibility surrounding your delivery time, but only a small amount. Time
is constrained.
• Scope. What remains to change is the scope. Oddly enough, scope is one
of the most flexible constraints, especially when developing commercial
software, rather than software built and customized for a specific customer.
The reason is simple. Every new software product has “must have” and
“nice to have” features and functionality. The “nice to have” features typi-
cally outnumber the “must have” features several times over.