How to put a brake on scope creep

What is so insidious about scope creep is that it propagates downward in the system. A small change in one place can have big (often unforeseen) consequences in many other places. If we return to the IT example, a small change in the number of functionalities can affect both the project's completion date, costs and required resources.

What can you do to prevent scope creep from occurring?

Depending on your company, position and the size of the project, there are different things you can do to prevent scope creep. As you can read here, then don't expect the following 3 techniques to completely eliminate scope creep, but they can help you curb the demand for unwanted changes.

• Make a 'scope statement'. Before the project starts, i.e. during the planning phase, you prepare a document that clearly describes what lies within the boundaries of this project. And what doesn't. All of the project's stakeholders sign this paper so that everyone is aware of where the project's boundaries lie.
• Punishment. Some companies accept the requested changes, but in return charge extra payment from the customer (In the following, I use the customer as an example, but the same principles apply to internal projects). Another option is to accept the change, but at the same time make it clear to the customer that it will affect when you can start on the next project. Subsequently, it is up to the customer to assess whether the change is worth the "penalty".
• Make the change later. In some cases, it is possible to carry out the change after the original project is finished. A company can, for example, ask the customer to request a new project at a later date. The price could turn out to be the same, due to the amount of work required to make the change.

What do you do when scope creep can't be avoided?

Even if you implement the above techniques to avoid scope creep, there will be times when you need to make a change in your project plan that shifts your project in one way or another. And what do you do?

Here are three suggestions:

• Move on. If you have been notified that the change is necessary, make the change and move on. Persistent negativity does nothing to help the project reach its goal.
• Document the change and the price. Document the change and get all stakeholders to sign it in a scope change logbook. Make sure your document accurately describes the change. Also remember to document all the implications the change causes. Eg. the time it takes, what it costs and what it means for the end date of the project.
• Make the change something positive. Maybe the change contains a new idea or maybe there is something about it that can be used by other customers. Perhaps the change simply makes good sense.