Skip to main content

Ways to Manage The Fear of Scope Creep

This paper is designed to provide a framework on ways to manage the fear of scope creep in a project.


Scope Creep, as the term sounds tends to give the “creeps” to the project manager if it is to happen in a project. It is treated as a threat to any given project as it will cause the “project triangle” which consists of cost, schedule and scope to be affected and which will also indirectly affect the quality and profitability of a project.

What is Scope Creep

Scope creep is defined as an additional workload or changes from the originally agreed project scope and normally happens when the project scope tends to give way for ad-hoc processes to happen during the mid-way of the project without anyone noticing. This will eventually lead to extra stress to the resource and timeline of the project. On some projects there are scope changes every week, or even several times a week.

Different types of Scope Creeps

There are several types of scope creep that can happen in a given project and below are a few keys issues:

  1. Changing the original requirements
  2. New requirements being added and removing existing requirements
  3. Change in technology
  4. Changing and adding of new stakeholder

1. Changing The Original Requirements

A major reason for change in the original requirements is due to a poorly defined or ignored requirement development process. This happens when a client doesn’t know what they want until they see the GUI Interface. Another reason for the change is due to some key stakeholders was left out at the beginning of the project and when joining mid-way of the project, they tend to put their requirement or change the existing requirements.

2. New Requirements Being Added and Removing Existing Requirements

Stakeholder’s expectations change over time if not managed properly. This will lead to requirements being added or remove from time to time. If we are not going to set the mindset of the stakeholders on what to expect from the original requirements, other people could be influencing them and changing their expectations.

3. Change in Technology

Another reason for scope creep is the rapid technology updates and improvement. With this rapid change, every project stakeholder wants to be up to date with latest technology. If a project is in a long development time, a change in technology (hardware/ software) tend to happened which directly will affect the project triangle.

4. Changing and Adding of New Stakeholders

Not all stakeholders will be joining in the beginning of a requirement process. Some even might be replaced or leave mid-way of the discussion. This will bring different views of understanding of certain requirements which will directly impact the scope of the project.

We can’t conclude that all the changes above comes from the customer only rather, scope creep is often a sign of poor initial requirement analysis of needs or simply misunderstanding on the part of the client.

Ways to Manage Scope Creep

There are several ways which a project manager can deal with scope creep:

1. Use the prioritization technique rather than numbering technique.

Example of a prioritization technique that can be used is MoSCoW technique.

This technique is a “know how” for most project managers out there. Always remember that the prioritization is from the client perspective. The definition of MoSCoW theory is as below:

[widget id=”custom_html-68″]

  • Must Have – this requirement is critical and must be included to achieve project success. Project Managers also need to be aware that not including at least one Must Have requirement will be considered a failure of the project.
  • Should Have – this is a high priority requirement but not critical to be developed but it is considered important and of high value to users.
  • Could Have – this requirement is nice to have but not a critical for a project success. This kind of requirements will be normally removed first from the scope if the project timeline’s are at risk.
  • Won’t Have – this requirement doesn’t need to be implemented for now but may be included in future development stages. This kind of requirements normally does not affect the project success.

The below diagram illustrates the MosCow Prioritization Technique:

Ramalingam 112017 a

2. Have a strong Change Control Process such as:

  1. Any new changes must go through a change request form (CR) and analyzed properly on the impact the change will have on the wider side of the project.
  2. Do not entertain any ad-hoc changes from the customer without going through the proper channel of authority
  3. Not all changes can be accepted. Some would need to be rejected or amended depending on the required priority
  4. All changes that have been accepted need to be added as addendum to the original project scope documentation

3. Scope of Work should be clearly defined in the early stage or even better before the project initiation.

Have regular workshop before the project kick- off to finalize all requirements. Once this is done, this will reduce the “leg room” for a change to happen and causing a scope creep.

4. Stop using “Gold Plating” technique in any project as it is a bad practice.

What it means that any team members of a project would go an extra mile just to please the customer by adding some features which are not originally in the agreed scope. If the customer turns down the feature, all the efforts of the team member will be futile. It is a waste of resource and time.


To avoid all the unnecessary implication caused by scope creep, it is advisable to well manage a project scope from the start to avoid any unauthorized changes happening to the original scope. Implementing scope management processes which include a change control process will ensure all changes are properly raised and documented. This will help ensure the project is delivered on time and within budget, with no unwanted surprises.

Comments (6)