{"id":23847,"date":"2015-03-24T16:10:00","date_gmt":"2015-03-24T16:10:00","guid":{"rendered":"https:\/\/kepner-tregoe.com\/when-projects-change-or-grow-managing-scope-creep\/"},"modified":"2026-06-05T14:43:11","modified_gmt":"2026-06-05T14:43:11","slug":"when-projects-change-or-grow-managing-scope-creep","status":"publish","type":"post","link":"https:\/\/kepner-tregoe.com\/fr\/blogs\/when-projects-change-or-grow-managing-scope-creep\/","title":{"rendered":"When Projects Change or Grow: Managing Scope Creep"},"content":{"rendered":"

Scope creep is the bane of any project manager\u2019s life and to an extent unavoidable. While best controlled by properly defining a project, sometimes there are good reasons for extending or changing a project. The world moves on, new data is discovered, external demands from customers change, technology advances, or other changes occur. A bad reason for changing a project is, \u201cwe didn\u2019t think it through properly in the first place.\u201d You can avoid or manage a large portion of scope creep using the following ideas:<\/p>\n

1. Involve stakeholders deeply in project planning<\/span><\/h4>\n

Typically we ask questions, draft requirements, and then review with stakeholders. Even though risks are well known; users provide an ill-thought-out wish list and then keep adding to it and changing their minds. It helps to have the stakeholder group participate in producing the work breakdown structure\u2014not in fine detail\u2014but in framing the major deliverables. This provides an appreciation of what is to be done and serves as a useful reality check around what can be done.<\/p>\n

2. Use the Five Whys<\/span><\/h4>\n

One simple technique you can use to check reality and get behind requirements is Toyota\u2019s Five Whys<\/em>. By asking why<\/em> five times in succession you increase understanding. For example:<\/strong><\/p>\n

What\u2019s the issue?<\/em>
\nNeed to delay our new financial system go-live data.
\nWhy?<\/em>
\nWe can\u2019t get new server capacity installed in time.
\nWhy?<\/em>
\nThere are restrictions on the number of machines per rack.
\nWhy?<\/em>
\nHeat generated is high.
\nWhy?<\/em>
\nUsing machine of older design.
\nWhy?<\/em>
\nBecause it provides high stability.<\/p>\n

This example reveals that our challenge is to maintain historic stability, but increase capacity quickly. It moves the focus away from a project to find more space for server farms towards (perhaps) identifying machines that deliver the same uptime with less heat. If four or five whys are not enough, questioning to the void<\/em> is asking why<\/em> until you\u2019ve exhausted the available information or ideas.<\/p>\n

3. Actively manage risk and opportunity<\/span><\/h4>\n

Too often risk management focuses on obvious risks such as building catches fire<\/em> without exploring specific project challenges. We should aim for a continuous appreciation of how changes around us may impact or enhance a project. For managing scope, our greatest concern is the business environment and the events inside and outside the organization that could affect requirements. This is easily achieved by running brief, weekly issue sessions with stakeholders, using this simple framework:<\/p>\n