ANSWER

Scope creep occurs when additional features are slipped into a project after the project scope is defined and the project has started. The intent is generally good with the hope of making the delivered product better, but these changes can lead to the project running over time and/or over budget. How you manage scope creep depends on the type of project.

There are multiple ways in which additional scope can creep into a project:

• New capabilities are being added to the list of must-do items which were not there at the beginning of the project.

• The complexity of individual capability increases thus requiring more time and resouces to complete them.

• Working on "nice to have" features before completing the must-have features.

Waterfall methodology used to be standard for software projects. Using waterfall, a project is completely designed, documented, and approved before it begins. After this point, if people want to add or significantly change features, it is considered scope creep. Each company should have a change control process, which will help control scope creep. With a formal change control process, the project team must submit a request to add or change features. The change request will include a description of the change, a justification, and a time estimate for the new features or changes. The change request is reviewed by a committee who must sign off on it before the changes are approved to be added to the project. If the change is not approved, the change is not made. Some new or smaller companies may not have implemented a change control process yet.

Agile methodology is more commonly used for software development projects today. Agile projects are less prone to scope creep because the project is planned at a high level at the beginning of the project, but the details are worked out as the project processes. This gives the project team flexibility around the product features. Sometimes people want to add in large chunks or work that aren't accounted for at the high level. This is where scope creep can happen. When this occurs, the new feature/user story is added to the product backlog and prioritized accordingly at sprint planning.

Finally, there are projects that aren't specific to software development such as process improvement projects. These types of projects should have a defined scope with a desired end state prior to the project starting. The desired end state could be things like reducing processing time, removing a team from a workflow, or better review of the work entering a complex process. Scope creep can happen to process projects when people want to incorporate adjacent processes or when they change the desired end state. To prevent scope creep in process projects, start the project by defining the problem and defining the desired end state. If changes are needed to the original plan, the stakeholders must approve the scope change before the project plan is updated.

Since scope creep can be so damaging to a project's success, how can scope creep be reduced or avoided?  Here are some things to consider if you want to avoid scope creep:

• Not just document the requirements but prioritize them.
• Establish a well-defined change control process
• Engage all stakeholders in the project planning process
• Review often the estimated size and complexity of must-have capabilities
• Watch for nice-to-have features being "sneaked" before must-have ones

--
Shawna Burkey
LinkedIn Profile