google-site-verification: google15fcd3d03d303535.html
top of page

Managing Scope Creep

Top five causes of scope creep ... and what to do about them

Larson, R. & Larson, E. (2009). Top five causes of scope creep ... and what to do about them. Paper presented at PMI® Global Congress 2009—North America, Orlando, FL. Newtown Square, PA: Project Management Institute.


Scope creep is a dreaded thing that can happen on any project, wasting money, decreasing satisfaction, and causing the expected project value to not be met. Most projects seem to suffer from scope creep, and both project teams and stakeholders are consistently frustrated by it. Why does an effective means of controlling scope seem to continually elude us?

This paper covers the five most common causes of scope creep and what project professionals (project managers and business analysts) can do about it. Problems and their symptoms are presented from the standpoint of a project sponsor, and solutions from the project team's perspective. This unique combination provides attendees with new insights and ways of controlling scope that can be applied to any type or size of project.


The PMBOK® Guide describes scope creep as “adding features and functionality (project scope) without addressing the effects on time, costs, and resources, or without customer approval” (PMI, 2008, p 440).

Change on projects is inevitable, so the possibility for scope creep is also inevitable. Perhaps this is the reason why taming scope creep is so challenging.

We don't mean to imply that additional functionality or work is not desirable on projects. We also don't mean that scope creep occurs just because requirements change. The key part is whether changes are authorized or not. If an expansion of scope is approved, then it is not scope creep.

  • Scope: The extent of what a project will produce (product scope) and the work needed to produce it (project scope). A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fourth edition mentions it is the sum of the products, services, and results produced in a project (Project Management Institute, 2008, p. 440). It is often documented using a scope statement and a Work Breakdown Structure (WBS), which are approved by the project sponsor.

  • Scope creep: Adding additional features or functions of a new product, requirements, or work that is not authorized (i.e., beyond the agreed-upon scope).

What is Wrong with Scope Creep?

By working on unapproved features of a product, a project team devotes time to the unauthorized changes. The work to incorporate these changes must usually be done within the original time and budget estimates, leaving less time for approved parts of the scope. That could mean approved features don't get completed, and the end-product is not what was chartered. Or, it can mean that time and cost overruns to finish the authorized parts of the scope will occur.

How Does Scope Creep Occur?

There are many ways scope creep can occur on projects. Executives at the sponsor level frequently don't want to be involved in every decision. So, project teams make them. Some change requests are or appear to be small, so again, project teams act on them instead of following a formal change management process. An inflexible or cumbersome change control process may also contribute to unauthorized scope additions.

For various reasons, the project team may want to exceed expectations and deliver “more value” by adding unrequested functionality.  Managers often fail to negotiate more time and budget when requests for additional functionality are made, and the scope creeps.

LinkedIn colleagues cited reasons for scope creep that include:

  • Lack of clarity and depth to the original requirements specification document.

  • Allowing direct [unmanaged] contact between client and team participants.

  • Customers trying to get extra work “on the cheap.”

  • Beginning design and development of something before a thorough requirements analysis and cost-benefit analysis has been done.

  • Scope creep “where you do it to yourself” because of lack of foresight and planning.

  • Poorly defined initial requirements.

  • “Management promises the sun and the moon, and breaks the backs of the developers to give them just that in impossibly tight time frames.”

  • It is impossible to control scope creep, so always work on the highest-priority features.

(Bleiweiss, A., Bupp, J., Johnson, D., Meister, J., Murphy, B., Temchin, M., & Oldfield, P, 2009)


Scope creep is dreaded in projects, and may occur for a multitude of reasons. Most of these reasons pertain to the fact that projects bring change, an unpredictable occurrence. Scope creep is not inevitable, though. Here is a summary of the top five causes of scope creep and a recap of what to do about each of them.

  1. Ambiguous Scope Definition


    • Sponsors: Develop charters with specific product features

    • Project managers: Create tight scope statements, with features in and out of scope

    • Project managers: Decompose deliverables into work packages, using a WBS

    • Business analysts: Create scope models to align project team's mental models

    • Business analysts: Define detailed and complete requirements

  2. Scope and Requirements Not Managed


    • Project managers: Include a change management process in the scope management plan and follow them both

    • Business analysts: Create a requirements management plan to be included in the overall scope management plan and follow it, including the use of requirements traceability.

    • Both: Formally communicate, review, and get all requirements approved; use traceability to manage the process.

  3. Inconsistent Process for Collecting Product Requirements


    • Both: Define requirements processes related to scope, analysis, prioritization, traceability, and new requests

    • Business analysts: Use context diagrams to clarify scope/stakeholders early (e.g., SIPOCs, Context Diagrams); add detail in layers as appropriate

    • Both: Define scope and requirements iteratively in “layers” throughout requirements analysis

  4. Lack of Sponsorship and Stakeholder Involvement


    • Sponsors: Develop Charters that communicate desired product features, emphasizing project benefits

    • Project managers: Provide project status that engages sponsors, focusing on how deliverables are being realized

    • Both: Use tools like RACI to get commitment for approvals and for providing input, review, testing, etc.

  5. Project Length.

    • Sponsors: Keep projects as short as possible and focused.

    • Project managers: Decompose projects into smaller subprojects

    • Project managers: Close out sub-projects to maintain momentum and show results






Bleiweiss, A., Bupp, J., Johnson, D., Meister, J., Murphy, B., Temchin, M., Oldfield, P., respondents to a discussion on  during May, 2009 from  &askerID=245516

International Institute of Business Analysis. (2009). A Guide to the business analysis body of knowledge (BABOK®), Version 2.0. Retrieved from .

Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK®guide)— Fourth Edition. Newtown Square, PA: Author.

The Standish Group. (2004). Standish Group Chaos Report.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2009, Watermark Learning, Inc.
Originally published as a part of 2009 PMI Global Congress Proceedings – Orlando, Florida, USA

bottom of page