Anyone working on software development knows the importance of the Triple Constraint triangle: time, cost and scope. One cannot be changed without affecting the others. In the following post I will describe how these constraints can help us keeping a project in line.

One of the hardest parts of software development is keeping the scope of a project clean, avoiding what is called requirement creep. Requirements can change for several reasons:

1. A poor discovery phase
2. Confusing documentation
3. Weak project management
4. Lack of change control

There are tons of books written about each of these issues, but I would like to focus on one in particular: change control.

The ‘Undemanding Change’

There is one kind of change that is very difficult to refuse, the undemanding change. An apparently harmless and effortless change request, often sponsored by statements like “how much time can it take?” and “it would take only five minutes”.

It is common to cave into such demands, arguing a five minute change is not deemed worthy of analysis. That is how the scope of a project starts growing silently and fills up with tangential raw requirements. Unfortunately, it is too easy to fall into that trap and suddenly be buried beneath thousands of trifling change requests.

Lost in Translation: an Example of the ‘Undemanding Change’

I remember one time I was working in a mobile application (before Android or iOS appeared) that was being used in more than 20 countries. We had a clearly defined translation process to localize the application for each country, as it was mostly used in non-English speaking countries. One day our customer manager received a request for a Farsi version of the application, and the answer was “sure, why not? Just another translation”.

Well, Farsi is a right-to-left language, something we didn’t support at the moment, nor the framework the application was built upon. So what initially was estimated just as a “translation effort” to be handled by the translation team, ended up being a complex development and testing effort that took more than a month and involved some obscure voodoo programming to turn the app’s UI right-to-left on every screen.

Don’t All Changes Come with Demands?

That is an extreme example of a poorly analyzed or underestimated requirement, and in software development, miscalculations on estimates happen more often than not. This post is not about estimates and how to get them right, it is about the unhealthy habit of accepting a change request for the sole reason of it being, apparently, a cakewalk.

The question is: is there such thing as an undemanding change?

Have you ever taken the time to analyze how much effort is put in a single change? Regardless of its complexity, there is a series of steps that simply cannot be ignored.

As Eric Lippert stated on his genius blog post How many Microsoft employees does it take to change a lightbulb?, “all changes have similar costs and go through a similar process”. At that time, Lippert was working at Microsoft, and of course not every company has such a rigorous process as theirs, but let’s see how he answered the light bulb question:

• One dev to spend five minutes implementing ChangeLightBulbWindowHandleEx
• One program manager to write the specification
• One localization expert to review the specification for localizability issues
• One usability expert to review the specification for accessibility and usability issues
• At least one dev, tester and PM to brainstorm security vulnerabilities
• One PM to add the security model to the specification
• One tester to write the test plan
• One test lead to update the test schedule
• One tester to write the test cases and add them to the nightly automation
• Three or four testers to participate in an ad hoc bug bash
• One technical writer to write the documentation
• One technical reviewer to proofread the documentation
• One copy editor to proofread the documentation
• One documentation manager to integrate the new documentation into the existing body of text, update tables of contents, indexes, etc
• Twenty-five translators to translate the documentation and error messages into all the languages supported by Windows. The managers for the translators live in Ireland (European languages) and Japan (Asian languages), which are both severely time-shifted from Redmond, so dealing with them can be a fairly complex logistical problem
• A team of senior managers to coordinate all these people, write the cheques, and justify the costs to their Vice President

And there’s always the chance of repeating several steps when a mistake is detected on a later stage. Now multiply it for all the simple change requests added to the backlog of a project during its lifetime and you’ll understand why so many projects fail, exceeding their time and budget.

Advice for Keeping the Project Scope Under Control

Recognizing there is no such thing as an undemanding change is the first step to keep the scope of a project in line. That notion combined with usual constraints, as time and money, will force you to separate wheat from chaff when it comes to accepting or rejecting change requests.

If the change was indeed a great idea, it will make it through that filter. If it doesn’t, you can always bring them back later. As it happens with many different products, good parts are cut down for the greater good. Focusing on the primary components will give you a clean and shiny product, instead of one bloated with secondary features.

Conclusion: Constraints Can Help Keep Project Scope Clean

Constraints are our friends, they guide us through the decision process, stimulating creativity and efficiency. The ultimate way to keep a project scope clean is to welcome constraints and use them as an advantage.

Combined with a clear notion of the effort required in each change, they play a primary role, it is up to us to embrace them as an advantage or ignore them and face the consequences.