Project Scope creep (sometimes known as “requirement creep” or even “feature creep”) refers to how a project’s requirements tend to increase over a project lifecycle, e.g. what once started out as a single deliverable becomes five. Or a product that began with three essential features, now must have ten. Or midway through a project, the needs of customers change, prompting a reassessment of the project requirements. Scope creep is typically caused by key project stakeholders changing requirements, or sometimes from internal miscommunication and disagreements. This post tackles several ways it creeps up on projects along with tips on how to nip it in the bud. While it might result in project delays, roadblocks, or going over budget, scope creep is not necessarily a bad thing. Remember that change is inevitable. Customer needs do change over time and delivering a project that answers their needs often means altering the scope. Scope creep is therefore a reality that every good project manager expects and plans for.
In order to avoid project scope creep, it’s important to consider some concrete project scope creep examples.
Consider a company that is launching a new type of phone case next month. The company has meticulously planned the product launch from start to finish. However, over the course of development, the CEO and exec team decide they want to add a ring light, battery pack and other elements to the case. This requires the project team to spend considerable additional time on this product, which in turn affects the product’s final launch date and the attendant revenue.
In a particularly famous real world example of scope creep, we look to Denver International Airport (DIA) and its experience with attempting to create a fully automated baggage handling system, which was plagued by scope creep that involved over 2,000 design changes. These design changes were, in part, a result of not including relevant parties in the planning stages and ignoring fundamental project concerns. The scope creep during the DIA baggage automation project meant the project finished 16 months late and more than 250% over budget.
But while DIA’s attempt at automating baggage ultimately failed, there are key lessons to be learned from one of the most well-known project creep examples.
From this example, future project managers will hopefully be reminded of the importance of communicating with all stakeholders from the initial phases, heeding expert warnings about potential obstacles that could impact timeline and budget, and breaking projects into smaller chunks using achievable project milestones.