Scope Creep Definition - The uncontrolled and unauthorized growth of the deliverables of a project (product scope) and the work required to complete it (project scope) due to incremental changes in the original scope.
Also known as kitchen sink syndrome or requirement creep, scope creep occurs when more functionality and features are added to a project without accounting for the additional budget, time, and resources or without the approval of the customer.
Scope creep is considered one of the biggest causes of project failure. Note that scope creep is different from feature creep—while feature creep is about the features, scope creep is about the entire project.
While Scope creep is usually viewed as a negative phenomenon, I see some good in it.
One of the reasons why Scope Creep happens is because of the constant need to improve a certain aspect of the project or the project itself.
Constantly trying to improve the project and being a perfectionist can be fruitful.
You add features, ideas, and resources to your project to make sure you deliver the best version of that project.
This is GOOD.
However, this stops being good and moves to “the bad” part when you don’t know when to draw the line between what’s needed to have a successful project and when you’re disregarding the project scope due to changes that would make the project better but not in a timely manner or without going over budget.
This takes me to The Bad.
While change is inevitable in any project, it’s those uncontrolled changes that cause delays in project completion and, in turn, lead to scope creep.
For example, changes that have been requested by the customer and haven't been documented as a part of the project’s updated scope can quickly get out of a product manager's control.
In 2008, BBC initiated the Digital Media Initiative, which aimed to modernize the company’s media production and archiving methods by using connected digital production and media asset management systems.
Spoiler alert, scope creep ended up costing BBC £100M.
The business users decided not to stick to the agreed agile method, which caused the Chief Technology Officer responsible for the project and his team to deliver big chunks of functionality instead of small, incremental ones.
Due to the loose communication between the two teams, the business users were not satisfied.
In addition, the business users initially requested a feature that would allow them to produce a “rough cut” of video output. After it was developed, they changed their minds and decided to use an off-the-shelf product from Adobe.
Even after the IT team integrated that specific Adobe software, the business users decided to use a different Adobe product altogether.
So as you can see, managing scope is of utmost importance as it will be the guideline of what should be achieved and prevent the project from going off course.
So here comes the bad part. Unauthorized changes can lead to cost overrun, operational inefficiencies, and failure to achieve deliverables.
Moreover, scope creep can lead to:
A vague and unclear Project Initiation Document that lacks a clearly-defined Project Scope Statement
Poor communication between stakeholders, customers, project managers, and team members
Undocumented and unapproved changes and conversations between the stakeholders
An inflexible/non-existent change control process
Unrealistic deadlines and time frames
Inexperienced or inefficient project managers
Poor feature prioritization
In 1995, the Denver International Airport devised a project to automate the baggage handling system, integrating all three terminals.
The goal was to reduce the baggage turn-around time for travelers.
The project extended about 16 months beyond the original deadline and cost the City of Denver an extra $560 million over the decided budget.
They couldn’t hit all their targets either - they were able to automate at just one terminal, for one airline, and only for the outbound flights.
The team also had to build an additional manual baggage handling system to make up for the failure of the project.
The project failed due to scope creep, caused by the following reasons:
Failure to address the project scope’s complexity: The city decided to pursue the project in spite of Breier Neidle Patrone Associates (who evaluated the baggage system) blatantly stating that it was too complex. They also tried to cram the project into an unrealistic timeline of about 2 years. When Senior Managers at BAE Systems (the company that undertook the project) were initially skeptical about its complexity and estimated a timeline of 4 years, the city ignored their concerns and stuck to its 2-year deadline.
Failure to address stakeholder’s concerns earlier: The Airlines were not involved in the initial decision-making process. When they were eventually asked for feedback mid-way through the project, they posed additional requests that required substantial redesigns in the already completed portions of the project and it led to a major waste of time and resources.
This is the ugly part about scope creep.
While in a small project like my sock business or my now-defunct hillbilly truck, the damages of scope creep are sometimes minimal, for big companies and products, scope creep has a real impact that affects people and resources deeply.
1. Break down large complex projects into simpler subprojects. Ensure that each subproject has a tight deadline, less room for scope deviations, and specific stakeholders to own its execution.
2. Prepare a detailed and clear Project Scope Statement at the onset of the project. Ensure that the statement includes information like:
Specific goals of the project
Deliverables and their descriptions
Tasks to be completed, their corresponding dependencies, and owners
Deadlines for each deliverable, key project milestones, and checkpoints
The cost associated with each stage of the project and for each deliverable
Points of contact who own the right to request a change in the project
3. Have a solid change management plan in place. It should cover details about how you will monitor, measure, and act on change requests. A change management plan must include:
A consolidated record of all changes requests, who made the requests, the expected effect of the changes, and their real-time status.
The process to evaluate each request’s priority, depending on its urgency, business impact, and stakeholder’s authority.
The process to ascertain the impact of a change on the project’s existing scope, timeline, and budget.
The process to monitor the actions taken on change requests and addressing delays before they blow up into bigger issues.
The process to communicate the status of change requests with the corresponding stakeholders.
The process of regular feedback cycles with the stakeholders right from the start of the project, to avoid eleventh-hour feedback.
Use a dedicated product roadmapping tool that keeps everyone from your team up to date on the product scope, roadmap, and initiatives.
Back to you now.
How did scope creep affect your project? Let us know here @airfocus
Andrei Tiburca