Preventing Scope Creep

Why change management should be (a little) complicated

As project managers, we strive to create and achieve efficiency. We endeavour to make the best use of resources. We work to structure well-organized communication strategies. Even with an agile approach to project management, applying structure to the process helps to create order from chaos and make everything work better. Most of the time, it works. When things run smoother, everything is better – and we come out looking better at our jobs.

But efficiency isn’t always the best path forward. There are some situations where efficiency is counterproductive, even dangerous. Scope change requests are a prime example. Scope creep can be a challenge for managing many types of projects, particularly projects with intangible deliverables such as software, processes, or events. Scope creep can be a project killer. Requested changes and additions to a projects scope are a regular occurrence. Very rarely are such requests accompanied by additional schedule time or financing; at least not at first.

Scope changes can’t be avoided and a good project manager knows better than to try. Often times, especially in fast moving industries, new deliverable requirements will come up that simply can’t be identified in the initial planning stages of a project. Whether it’s because of oversight, changing market conditions, or new regulations, many products and services just won’t be successful without a little bit more than was thought of before. Change can’t be avoided and so the next best thing we can do is to proactively manage it. By making the process of change management just a little bit complicated from that start, we can avoid a lot of bigger issues later on down the road.

The scope of a project is all of the work done to deliver the project output. It’s the sum of the products, services, and results that a project provides. Simply put, it’s what a project does and results in. This can include things like features of a project, aspects of an event, or functionality of a software program. Scope change results when any changes are made to the project scope that differ from the originally detailed scope items.

Scope change itself isn’t the problem. The problem comes when, little by little, additional scope items and deliverables are added to a project over time, resulting in an aggregate increase in the scope beyond what is achievable given the other constraints of time, cost, quality, and resources – a phenomena known as scope creep. When allowed to happen, scope creep results in the uncontrolled expansion of a projects scope without consideration or adjustment to the other project constraints.

Scope creep happens for a number of reasons. Little changes are very easy to ask for. Regardless of how necessary or discretionary they are, most clients and customers don’t think much of asking for small favours or tweaks. They are also very easy to say yes to. We all like to have a happy client and nobody wants to seem rigid or inflexible. Project managers want to demonstrate a ‘can-do’ attitude. Logically, we know that these little things add up over time, but for some reason it is still allowed to happen. The results are predictable – nobody wins.

This is why a little bit of strategic complication can be effective in scope management and preventing scope creep. When done correctly, the goal should be to complicate things just enough to make everyone slow down, pause, and consider the wider implications of all requested changes. The result should be that changes are not so easy to make or grant without thinking about the big picture, while still preserving an avenue for requesting necessary scope adjustments.

Proactive scope management needs to look beyond project scope and consider the wider area of change management and a structured change control system. This is the same type of system that is used to coordinate all changes to a project, including areas such as scheduling and budgeting. Establishing a change control system means putting in place a set of procedures describing how modifications to the project are going to be proposed, considered, managed, and documented. The level of structure and formality is adjustable and should be appropriate for the type of project being managed. At a minimum, a structured, slightly (and intentionally) complicated change management plan should do several things.

1. Set up a change review board
2. Require requests in writing
3. Consider the request carefully
4. Delay decision making

Set Up a Change Review Board

Setting up a change review board is a formal way of saying you will decide in advance on who will make the decision. Members of the change review board are tasked with receiving, evaluating, considering, and deciding on changes. Ideally, the change review board will include a member of the client team, a member of the project team, and an additional member who is most appropriate for the job given the specific circumstances of the project (i.e., subject matter experts, technical experts, etc.). In many cases, the client will still have the final say when it comes to scope items on the project they are paying for. The goal is to have all of the relevant points of view represented in order to bring all of the applicable information up for discussion.

Require the Request in Writing

Any change management plan should include a requirement for written submission of all change requests. Written requests can be as simple as an email or as complex as a change request form detailing all of the specifics of the change (item, reason, results, costs, schedule implications, etc.). Written requests for change help the process in a few ways. For one, it helps with project documentation. Also, it makes the requester take pause and consider the request a little bit more than by simply verbalizing the idea. Again, the requirements can be simple or complex, depending on the needs of the project.

Consider the Request Carefully

Once the change request is received, it should be considered not only based on its impact on the final output result of the project, but also on how it impacts other areas of the project. At a minimum, diligent consideration of any requested scope change should include discussions of impacts on the project schedule, the project budget, and the overall project output quality. Doing so will help to balance the need for the change against the overall effect on the project as a whole.

Delay Decision Making

The change management process should specify when the change review board will meet and consider issuing a decision on any requested scope changes. This might be at each regularly scheduled project meeting, or, if the nature of the project includes a high number of regularly requested changes, at a regularly scheduled meeting of the change review board itself. Requested changes can be considered at any time that is convenient based on the needs of the project. As a matter of practice, they should not be considered on the spot.

This doesn’t mean that a project team needs to sacrifice all flexibility. There will be situations where requested changes are urgent and need immediate consideration. The change review board should consider requested changes immediately when necessary, but this practice should be made the exception rather than the rule.

By implementing a structured change management process for all project scope changes, a project manager is better able to prevent scope creep from happening. The goals of structuring the process is to slow things down to the point where all scope changes, large, medium, and small, receive complete consideration as to how they affect other constraint areas of the project.

When putting together a structured plan to manage scope creep, it’s important to keep the mind set of managing it – NOT fighting against it. It’s a fight that project managers can’t win and all too often it leads to an adversarial view of the relationship between the client and the project team. PM’s can end up seeing clients as demanding more while giving less. The structured process should be collaborative. As project managers, we need to remember that clients are under pressure too.