Controlling Scope at the End of the Project


Joshua Lieb, Product Strategist


Scope can increase at any time in a project.  Sometimes, requirements don't change - the client knows exactly what they want at the inception of the project, the niche it serves is constant, and the client does a good job of managing their stakeholders.  Most of the time this isn't the case, though.  Months - and even years - can elapse between when the project was originally commissioned and when it launches, and in that time a company's economic model can change, elected officials leave office, and new stakeholders and administrators are brought in.  The organization may remain constant, but the users of the system change constantly.  Often times, as time passes it becomes clear to the client that the assumptions that informed the requirements may have changed given new information, rethinking, or outside events.  Scope can, and will, change, and managing these changes is a natural part of any project.

Although new feature requests can come at any time, projects are particularly sensitive to them as the launch date approaches, when there is little wiggle room in either the schedule or the budget.  it happens, though, and you should always assume that it can.  In some cases, there are features and changes that only become obvious once the site is almost built out.

Of course you can and should negotiate with the client over these requests - although you have an interest in producing a solid product that fits your client's needs and makes her happy, you also have a selfish interest in keeping you budget and schedule intact.  But its inevitable that some of what they ask for be done.  So if scope creep at the end of a project is unavoidable, how do you prevent it from affecting killing your budget, torpedoing your launch, and making your developers hate you for dumping an eighty-hour task on them the week before launch?

Establish a baseline

It goes without saying that you need to nail down your requirements and get the client to sign-off, but beyond that you need to make sure that as you develop you relate what you are building to what you've agreed to build.  Get good estimates from your developers and track this over the course of the project, and when it comes time at the end to evaluate last-minute requests you can have a high degree of confidence in the accuracy of their estimates.  This will help quantify the impact that scope changes will have.

Go Agile and be transparent

Using an Agile project management process will allow you to more closely track the progress of the project towards meeting the basic requirements, and giving the client a window into this process helps them understand your development process and lets them see progress. When they make a request for a new feature, they'll have a better understanding of how it will impact development.

Keep an open door

Set up a system to track feature requests.  If your client has access to your ticketing system, set up a bucket for 'Required Features', train them in prioritization and triage, and let them manage the list.  If you can't or won't give your client ticketing access, set up a Google spreadsheet and hook up a webform frontend.  Let them know that if they realize new needs or find things to improve that these needs can be captured and tracked and not forgotten.  If you are running an agile project, some of these can be added into the development cycle at appropriate points, and you can avoid having all of the scope changes come tumbling out at the end when there is no time left to elegantly manage them.

Budget for scope creep

When you set up your development schedule, add a sprint or two at the end for 'remediation', and let the client know that there is time budgeted for fixing bugs, reviewing the product, and making changes.  As the project approaches this phase, get them involved early in planning for testing and QA, and start tracking their existing requests with an eye towards evaluating how many of them will fit into your remediation sprints.  Finally, when it comes time to plan the sprints, get good estimates on logged bugs and feature requests, and let the client participate in prioritizing the tickets.  They will be far more willing to forgo features if it is them making the decision to deprioritize than if they are simply told that there's no way to fit it in.

Help the client plan the future of their site

A web application doesn't have to be a rigid system that, once launched, never changes.  A well-built site is extensible and is able to evolve to meet the client's ongoing needs, and this is not always apparent to a client.  Educating them on the life-cycle of a site and helping them work this into their long-term plans helps control budget and scope because they realize that they don't need to do everything right now - they can launch a first version, see how their users work with it, and then iteratively build in new features.  Even setting up a maintenance plan in advance can help - anything that you can do help them budget in advance for ongoing work will minimize the stress associated with negotiating scope.

Finally, be open to requests but be prepared to say no

If you lay the groundwork, the process of negotiating scope doesn't have to be acrimonious.  Your clients shouldn't be afraid to advocate for their interests, but if they understand that it is in their own interests to help where they can in building their site they will limit their requests to those requests that are truly essential.  Likewise, if you plan accordingly, you will have the leeway to let the client push the scope when it's in the interest of the project.


Joshua Lieb

Product Strategist