What to do when the client keeps adding scope

So you come out of discovery, and you have a great plan for what to expect for the release. You understand the problem, you have a proposed solution and clear success criteria to qualify the success of this phase. The team are aligned, they have a clear workflow (similar to the one outlined here) and understand the user flow and tech stack. The client has even given verbal AND written confirmation on the scope, budget and timeline — but more importantly, everyone throughout the organisation is aligned on the business benefit that the project will bring. The tools are in place to get started, you have the right team composition and so you get the project underway.

Two weeks pass by and you are now wrapping up your first sprint showcase. It went very well. The work package for the sprint included the most complex and most important stories, everyone finished their work with minimal time to spare, and enough testing was even done to catch some early bugs — and fix them! What more could the client ask for? Surely they are happy with the early progress? Well yes, in fact. They are. And more than that they have some “ideas” they would like to share.

“I was actually thinking that…”

“I wonder if we could…”

Or even worse when it is phrased as an assumption

“We assume that this will also include [insert something that is definitely not in scope]” and my personal favourite… “I know we didn’t ask for this but it’s obvious, right?”

However it comes about, the client adding scope to a project seriously derails the timeline which also affects the budget and ultimately the delivery of the project outcomes. In an enterprise organisation, it is also likely that other parts of the business will be affected as well, especially if the project is a strategic one.

Photo by Brad Starkey on Unsplash

Before we move on, I have to be clear on two things: 1. We are not talking about progressive elaboration and 2. It isn’t the client’s responsibility to contain the scope, it’s the project leader’s.

Progressive elaboration is a healthy feature of complex projects where, as we get into the implementation of the project we find out more about the features we are implementing, the problem we are solving, the customers we are serving etc. The workflow linked above encourages a degree of progressive elaboration, which contains it within the constructs of BA sessions. It is part of the continuous discovery and treats any product requirements documentation as a living, breathing thing. However, progressive elaboration respects the boundaries of each story, which should have the success criteria as the final guard rails. Through progressive elaboration, we will learn things we didn’t know already. Some of those things will be important to achieving the success criteria. Find a way to put them in. If necessary, use a prioritisation matrix like this one and work out what can be traded out so these stories can be traded in. Some stories will fall below that threshold and can be postponed until a later release. Some stories will be so tangential that you can immediately relegate them to “won’t do” and not focus on them at all. This is a natural part of working on complex projects. You should inform your client at the beginning of the project that there is a limit to how much we can learn before the project starts and that discovery isn’t designed to uncover everything. Embrace “progressive elaboration”.

We aren’t talking about that here. We are talking about “I have a new idea” or “I know we didn’t talk about it but…” scope.

Here is what I recommend:

1. Set a precedent — don’t let it slide the first time just because it’s “only” going to take an hour and won’t affect the timeline. The first time it happens, stick with the plan, be strict and let the client know their options. That doesn’t include just absorbing it into the current scope. Be strong, and they will respect you for it.
2. Create a process for assessing scope changes — Is it purely progressive elaboration? Then run it through the priority matrix. Is it something that has come from actual users? If so, how many, how impactful is it to the success criteria and what is the effort required? Is it something that the client forgot to mention or a new idea they have had? Push back and refer back to the prioritisation matrix AND the success criteria. If they forgot to mention it before, it is unlikely to be as important as most of the things that came out of the discovery. Make sure they know the hierarchy of additional scope and always apply the process.
3. If they insist, be firm on repercussions— One thing I say to insistent clients is “You can have anything you want, but not everything”. If they insist on adding the new scope, make sure they know that by doing so there will be consequences in other areas. For example, the timeline may increase, the cost may go up and there may need to be rework if the new scope affects something that was already built with the original scope in mind.
4. Make it formal and in writing — if the client ends up accepting all of the additional conditions that accompany changing the scope, make sure they know the formal process of doing so. You want to protect yourself and the client from any miscommunication down the line so create a formal change order and have them sign it. The change order should show:

• Date and Sprint Number that the change order has been requested
• The new scope
• Old scope removed (if applicable)
• Estimated effort/time for new scope (with contingency)
• Change in timeline (if applicable)
• Change in cost (if applicable)
• Additional expected benefit (monetised if possible)

The last one is especially important. Having gone through the steps to push back on additional scope, you should encourage the client one last time to confirm that this new scope is worth it. Having seen the extra time and cost required to implement the change, the client should be able to do some cost-benefit analysis and confirm that they are happy that the benefit will be enough to warrant the change. The change order should be signed and filed with other project documentation.

If this keeps happening, don’t hesitate to present the previous change orders to demonstrate that this is becoming frequent and you may be deviating too far from the initial scope — which was an agreed work package to reach the intended goals. Going through a “re-discovery” might be the best option, where you and the client can re-align on the desired outcomes.

Conclusion

Part of the role of the project leader is to coach the client into making best-practice decisions. One of those decisions is about managing the scope throughout the project. A key part of that is understanding which scope is natural progressive elaboration (which should be embraced) and which is scope creep (which should be pushed back upon). Guiding the client through these decisions should always be based on the success criteria and business outcomes from the project. If the client has particularly strong feelings about a change in scope, process the request systematically. If it becomes too frequent, re-align with the client at the highest level and work your way back through the backlog.