Five Prerequisites for Eliminating Scope Creep

Many project managers out there are very concerned with managing scope creep in their projects. For many, the ideal project is one that doesn’t change once it’s planned. For others, it’s one with tight change controls a.k.a. contracts that legally limit change. The problem is these mechanisms and methodologies strangle agility — the organization’s ability to adapt to changing, customer needs or exploit emerging opportunities in their market. It achieves stability at the expense of customer collaboration and favors following a plan rather than responding to change.  It locks them in to decisions made at the point of least understanding i.e. at the beginning of a project.

There is no such thing as scope creep. There is only deeper understanding.

This is important. Scope creep is negative while deeper understanding is positive. One is to be avoided while the other is to be sought out.

Such thoughts seem utopian in software development. Some would grumble, “I live in the real world where scope creep is inevitable. I don’t have time or patience for California dreaming.” I don’t normally quote the bard, but one passage from Hamlet presents itself as appropriate:

There are more things in heaven and earth, Horatio,
Than are dreamt of in your philosophy.

Dream with me for a moment. Presume the following:

  1. You and your client trust each other enough to collaborate frequently
  2. If you have fixed delivery, you flex on scope
  3. If scope is fixed, you flex on delivery
  4. You build what you know is valuable for your customers
  5. You don’t ship $#^!

One is required for two and three. Four and five build up number one. It’s a harmonious cycle that is true to the spirit of the Agile Manifesto and one to which Scrum gives form. It’s a pattern you and your organization could follow if you’re willing to put in the hard work.

You may have inherited a world where scope creep seems inevitable, but you don’t have to bequeath it to others.


Jason is a developer, Scrum Master, writer, teacher, coach, husband, father, and community leader out of Tulsa Oklahoma. He's been delivering software since 2007 and absolutely loves the values and principles of agility especially as given form by the Scrum framework.

  • Hebo 63

    If a Project Manager is worried about managing scope creep, then they have already missed the boat. A PM following a traditional/waterfall methodology must focus on managing and controlling scope, not scope creep. If scope is managed effectively through the use of an Integrated Change Control process, there will be little to no creep.

    This requires the PM to collaborate frequently and effectively through the use of a Stakeholder Management process that includes frequent communication and collaboration with the a project Sponsor and Key Stakeholders to discuss/negotiate scope changes when they occur.

    The statement “there is no scope creep, only deeper understanding” is not completely accurate. Creep does exist, even in Agile/Scrum projects if scope changes are not managed, controlled and responded to properly. Deeper understanding is a normal part of any project and referenced many years ago in the PMI PMBOK as Progressive Elaboration.

    Scope Creep is not and never has been inevitable. Fortunately the PMI framework and industry standard best practices provide Project Managers with processes and tools to effectively and efficiently Respond to Change, Collaborate with Customers, and Interact with Individuals to deliver Working Software/Products

    • I’m not used to getting many comments, so I see I’ve completely ignored you for many months. Welcome!

      I confess you have me at a disadvantage. I don’t know anything about what an Integrated Change Control process is.

      It’s time to be careful with words; I love them, but they can get me into trouble. When I say, “There is no scope creep…” I mean essentially that scope creep is a choice not an eventuality. Even if the contract says this or that, it is still a choice to add work to a release date or a product version.

      Some may see this distinction as sophomoric i.e. a choice to break with our biggest client is not a choice at all — it’s suicide. I get that, but I see the distinction as being quite significant. The more we resign ourselves to the inevitable or the eventual we cease to be free, creative human beings.

      Even when features, releases or other buckets of code expand they do so because we have come to _understand_ something more deeply.

      That is my point.