Scope creep rarely arrives as one dramatic decision. It arrives as a dozen reasonable-sounding “can we also just” requests, each small enough that saying no feels petty, and each one quietly moving the delivery date without anyone officially changing it.
It is also one of the most common ways projects go wrong. PMI’s research has tracked it for years, and the public record has some expensive examples of where it leads. This guide covers what scope creep really is, three documented cases, the early warning signs, and a change-control habit simple enough that teams actually use it.
of projects had scope creep (PMI, 2018)
five years earlier (PMI)
Healthcare.gov FFM cost growth (GAO)
Denver airport opening delay (GAO)
What scope creep is, and what it isn’t
PMI’s PMBOK Guide defines scope creep as the uncontrolled expansion of product or project scope without adjustments to time, cost and resources. That last part is the whole problem. Scope is allowed to change; projects learn things. What makes it creep is that the work grows while the plan stays the same.
So a change that is requested, assessed, approved and reflected in a new date or budget is not scope creep. It is change management working. The same change slipped in through a hallway conversation, with the original deadline still on the slide, is.
Why it is so hard to see
Each request is small, reasonable and comes from someone the team wants to help. No single one is worth a fight, so nobody tallies them.
The cost lands later and somewhere else: a test cycle squeezed, a weekend worked, a date that “suddenly” slips. By then the project has lost its original success criteria. Nobody can say whether it is on track, because “on track” was defined against a scope that no longer exists, and teams default to working harder instead of renegotiating the plan.
How small requests add up
Here is how it typically accumulates on a mid-sized internal system build. The requests are illustrative, but the pattern will look familiar to anyone who has run a delivery team.
Three projects, one pattern
The public record has plenty of projects where changing requirements, not bad engineering alone, drove the overrun. Three well-documented ones, each from an official audit or a detailed investigation:
| Project | What kept changing | Measured impact |
|---|---|---|
| Denver International Airport (1990s) | Airport scope and design changes, plus an automated baggage system that was not ready | Opening delayed four times, October 1993 to February 1995; delay cost about $360M (GAO) |
| FBI Virtual Case File (2001–2005) | Requirements: an 800-page requirements document and about 400 change requests in one year | About $170M spent; system abandoned in 2005 (IEEE Spectrum, DOJ Inspector General) |
| Healthcare.gov (2011–2014) | Requirements and decisions, with key technical requirements unknown when work began | Marketplace system obligations grew from $56M to more than $209M (GAO) |
Case 1: Denver International Airport
Denver’s new airport was scheduled to open in October 1993. The US Government Accountability Office (GAO) reported that the opening was delayed four times “because of airport scope and design changes and automated baggage handling system problems”. It finally opened in February 1995, 16 months late.
The baggage system started as a $193 million contract. While it struggled, the city had to fund a conventional backup system, estimated at about $51 million, and GAO put the total cost of the delay at about $360 million.
The lesson: changes made while a complex system is being built are far more expensive than the same changes made on paper. Lock the design before construction, and treat anything after that as a priced change.
Case 2: the FBI’s Virtual Case File
The Virtual Case File was meant to replace the FBI’s paper-based case management. IEEE Spectrum’s investigation found a requirements document of more than 800 pages and about 400 change requests logged between December 2002 and December 2003.
The Department of Justice Inspector General’s 2005 audit named “poorly defined and slowly evolving design requirements” among the causes of failure. The FBI spent about $170 million before abandoning the system in 2005.
The lesson: a steady stream of changes means the target never stands still long enough to hit. If change requests outnumber delivered features, stop and re-baseline.
Case 3: Healthcare.gov
GAO’s 2014 review found that the Centers for Medicare & Medicaid Services (CMS) started building the federal marketplace (FFM) and its data hub “when key technical requirements were unknown”, and that cost increases, schedule slips and delayed functionality were “due primarily to changing requirements that were exacerbated by oversight gaps”.
The lesson: starting before the requirements are known guarantees changes later. If you must start early, say so in the plan, budget a contingency for it, and put every new requirement through the same visible decision.
Early warning signs
Scope creep shows up in the project’s habits long before it shows up in the schedule. Watch for these in status meetings:
- Work items appear on the board that nobody remembers approving.
- “While you’re in there, can you also” is a regular phrase.
- The team is busy and behind, but nothing on the plan has changed.
- Status stays green while the forecast end date keeps drifting.
- Requirements are discussed in chat and meetings, not in the backlog or change log.
- Acceptance criteria get vaguer, not sharper, as delivery gets closer.
Ask these three questions
For any new request, before anyone says yes:
- Is it in the baseline? If not, it is a change, however small.
- What does it move? Date, budget, another feature, or quality.
- Who can approve that trade-off? If the answer is “nobody in this room”, it waits.
The fix: make the trade-off visible
The answer isn’t a stricter change-control form that nobody reads. It’s a short, consistent path that every request takes, so the trade-off is visible at the moment the request is made:
Log itthen
Size the impactthen
Name the trade-offthen
Decidethen
Update the baseline
Most of the value is in the fourth step. Say it out loud, in the room:
“We can add this. Here’s what moves: the date goes out by a week, or we drop the export feature, or we add budget for a contractor. Which would you like?”
Most scope creep resolves itself at that point, because the requester usually didn’t realize there was a trade-off at all. The requests that survive the conversation were worth adding, and now they are in the plan with a date that reflects them.
A worked example
Two weeks before user testing, a department head asks for a mobile layout “for the site leads”. The project manager logs it, and the lead developer sizes it at five days.
In the weekly review the project manager offers three options: move testing by a week, drop the second-language labels to make room, or deliver mobile in a follow-up release. The sponsor chooses the follow-up release. It goes in the change log with a date, and the plan stays honest.
Keep it lightweight
None of this needs a heavy process. A baseline (what was agreed), a change log (what was asked and decided), and a weekly look at both are enough for most projects.
Our Advanced Project Planner keeps the project list, tasks, budget and a RAID log in one Google Sheets workspace, so decisions and their impact sit next to the plan instead of in someone’s inbox. For a quick health check, the free Project Health Command Center scores a project across 10 dimensions.
Sources
- PMI, Scope Patrol (Pulse of the Profession 2018: 52% of projects completed in the prior 12 months experienced scope creep, up from 43% five years earlier).
- US GAO, New Denver Airport: Impact of the Delayed Baggage System (GAO/RCED-95-35BR, October 1994) and testimony T-RCED/AIMD-95-184 (May 1995).
- IEEE Spectrum, Who Killed the Virtual Case File? (Harry Goldstein, September 2005), and the US Department of Justice Office of the Inspector General’s 2005 audit of the FBI’s Trilogy project.
- US GAO, Healthcare.gov: Ineffective Planning and Oversight Practices Underscore the Need for Improved Contract Management (GAO-14-694, July 2014).
- PMI, A Guide to the Project Management Body of Knowledge (PMBOK Guide), glossary definition of scope creep.
The request examples and the worked example are illustrative, not drawn from a specific client project.