Radical Transparency: How We Deal With Scope Creep

Scope creep is the bane of any software project, big or small. Anyone who has worked in the software field for any length of time has experienced it, and most of us will cringe at past memories just hearing the term.

Here's an example of how it works: first, a client goes to a consultancy with a business need. Let's say that the client is a small maintenance company and they want a new mobile app for their field personnel to track site visits. They go over the requirements, agree on a cost and completion date, and sign a contract. The consultancy gets to work, starts showing the client prototypes, and all seems to be going well. As the launch date approaches, the client's workers are excited to start using the app. Then, a month before launch, the client realizes that their back office personnel also need a web application to track the site visits and see reports about employee performance metrics like average visit duration. The client goes to the consultancy and tells them about the new requirements. What should the consultancy do?

The Pitfalls of Yes

It might seem like an obvious next step in the above story to be transparent about the impact of delivering that additional functionality, but many consulting firms don't do that. I have personally worked in some very frustrating environments where the policy is to say "yes, anything you need, no extra cost, same delivery date" to clients when scope creep happens. It's well-intentioned -- "the customer is always right" -- but counterintuitively, it just ends up making everyone unhappy.

For starters, the engineers doing the work obviously don't appreciate having to put in 60- or 80-hour weeks at the last minute to complete a project whose scope expanded beyond the initial specifications. That matters a lot to us, since we insist on a high level of quality in our work. Quality engineers are a scarce resource, and they will leave if they are not treated well.

But in my experience, clients actually do not appreciate this approach, either.

Overworked engineers don’t do their best work, so overspec'd or crunch-time apps are more likely to have bugs or design flaws. Those bugs lead to cost and schedule overruns. And when the client is left in the dark about the reason for those overruns, it's just another frustration for them. This is how making sacrifices for a client can actually lead to a situation where the client is unhappy, not grateful!

When the client is not a partner in the creation of their software, they are left with a frustrating lack of understanding behind the process and the outcome. By covering up the impact of scope creep and trying to make the client happy at all costs, these yes-to-anything consultancies are paradoxically not treating their clients with the respect and dignity they deserve.

The Benefits of Transparency

We find that a policy of honesty is the best way to handle situations where additional functionality is required. If, halfway through a project, we hear a client telling us that they need a piece of software to do more than we initially discussed, we quickly re-assess and provide them with an updated project proposal, including an updated cost estimate and delivery timeline.

All of our project proposals have line-item details on cost and hours, so when we have to add additional functionality (e.g., three new screens in a mobile app), that helps our clients understand exactly how much the increased scope will affect the cost of the project, in terms of both dollars and calendar time. Providing our clients with information about the result of scope change requests then allows them to make an informed decision about whether they do need that extra feature, whether it can wait for Phase Two, or whether the extra cost just isn't worth it to them.

In practice, we see all of these outcomes, which highlights the importance of giving the client the choice. Sometimes, after seeing how much work is necessary to complete an extra feature, a client will tell us that it's not worth that much to them and to just continue with the original scope. Other times, they will decide that the feature can wait until Phase Two and set their business expectations correctly, for example by going to the personnel who will use the new feature and letting them know about the Phase Two completion date. Most often, though, our clients simply agree to the new scope (it will take what it will take, after all) and update their time and cost expectations accordingly. Then, we deliver the software as agreed and everyone is happy!