Scope Change Happens; Get Used to It

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 security conference where new releases are announced”. You have some flexibility 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 typically outnumber the “must have” features several times over.

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 building, 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.