Scope creep is rarely one big decision
Projects almost never lose control of scope through a single dramatic decision. They lose control through a dozen small, individually reasonable requests that nobody tracked against the original business case. By the time a steering committee notices the project is behind, the scope has already grown well past what the budget and timeline were built for, and the conversation becomes defensive instead of productive.
I managed this exact pattern on an ERP replacement in the public sector, where finance, HR, and operations each had a legitimate stake in the new system and each had a steady stream of small requests once they saw what the platform could do. The goal was never to refuse every new request. Some new requirements genuinely belonged in the project, particularly around payroll compliance rules that had not surfaced during initial requirements gathering. The goal was to make every addition visible and deliberate, instead of letting it slide in quietly through a side conversation with a developer.
1. Write the scope boundary down in plain language
A scope document full of technical specifications is not useful for catching creep, because the people requesting changes rarely read it that closely. I write a short, plain language summary of what is in scope and, just as importantly, what is explicitly out of scope, and I keep it visible to the steering committee throughout the project. On the ERP project, that summary explicitly excluded a legacy reporting tool that three different departments later asked to have migrated as part of the same phase. Pointing back to the written boundary turned what could have been a political fight into a two line email.
2. Give every new request a visible cost, not a quiet yes
The fastest way to lose control of a timeline is to accept small requests verbally without logging the time and budget impact. I require every scope addition, no matter how small it seems, to go through a brief change log that states what it costs in time and money. Most requesters are reasonable once they see a specific cost attached to what sounded like a minor ask, and on more than one occasion a department withdrew its own request once it saw that a seemingly small reporting tweak would actually touch the data conversion scripts and add a full testing cycle.
3. Separate must have from nice to have before the project starts
Projects that enter execution with every requirement treated as equally critical have no basis for trading off scope later without a painful renegotiation. I push stakeholders to rank requirements before the project starts, even if that conversation is uncomfortable. When a true must have request appeared mid-project on the ERP work, a late-arriving federal payroll remittance change that genuinely could not wait for a later phase, having an agreed list of lower priority items to trade against meant the conversation was about which deferred report to push to phase two, not about who was to blame for the schedule impact.
4. Protect the team from informal requests outside the change process
A common pattern is a business stakeholder approaching a developer directly, outside any formal process, with a request that sounds small. The developer, wanting to be helpful, quietly builds it. Multiply this by several team members over several months and the project has absorbed significant undocumented scope. I ask the team to route every request, however small, through the same change log, and I back them up when they do. On the ERP project, that meant telling a finance director directly, in a short one-on-one, that a request she had already made informally to a report-writing developer needed to go through the log before any work started, even though the developer had been happy to help. It was an uncomfortable five minutes. It also meant that request, once logged, was correctly identified as touching a regulated payroll field and routed through a compliance review the hallway version would have skipped entirely.
5. Revisit the business case when scope moves, not just at the end
Scope additions often make sense individually but, in aggregate, undermine the original return on investment that justified the project. I periodically total up the approved changes and check them against the original business case rather than waiting until the project closes. On the ERP project, a mid-project review of the accumulated change log showed the business case was still intact, but it was close enough to the line that the sponsor deliberately deferred two lower priority requests to a later phase rather than discovering the shortfall at go live.
Visibility, not refusal, is the discipline
None of these practices are about saying no to legitimate change. They are about making sure every change is seen, costed, and chosen deliberately, rather than absorbed quietly until the project is both late and over budget with no clear explanation of how it got there. The change log from that ERP project ran to over sixty entries by go live. What mattered was not the number. It was that every one of them had a cost attached and a name attached to the decision to accept it.
Leave a Reply