5 Ways to Combat Scope Creep
Scope creep, also commonly referred to as gold plating, occurs when requirements that weren't previously taken into consideration during the planning phase start to get rolled into a project after development has already started. As these additional requirements pile up, projects and project teams will start to fall apart under the weight of the additional work. While there are legitimate requirements that may pop that will need to be rolled into the project plan during development, the responsibility rests on the shoulders of the project manager to drive conversations and implement processes that will prevent the scope of work from expanding beyond what is deemed critical after the initial scope is already agreed to. The following article presents five tools project managers can use to keep scope creep in check.
Gather Clear Requirements
The first part of good requirements gathering is making sure that you have all of the key players plugged into the project from the beginning. After you're confident you have all of the key players involved, a good way to start gathering requirements is to have an initial conversation with the project's executive sponsor to get her thoughts around what the requirements are, and let her guide you around who to talk with next. During those conversations, document the functional versus the non-functional requirements, and also which requirements are required versus which requirements would be nice to have. After you reach a point where you're comfortable you have a solid start at building the requirements, schedule sessions with the larger team to review the requirements and make sure everything is accounted for. Additionally, to ensure that everything is accounted for at the outset of the project, maybe try conducting a brainstorming session or mapping the process flow at a high level to make sure everything is accounted for. Continue socializing the requirements until you are confident they have been fleshed out properly, giving the scope of your project a solid foundation.
After you've fully fleshed out a project's requirements, another good way to prevent scope creep is to have all of the project stakeholders sign off on those requirements. If you've never had stakeholders do this before, you may be surprised at the number of requirements that get added or modified when you start asking them to put their signature on them and validate that they feel like everything has been captured. This can add significant time to the project at the beginning, but it will save you a lot of pain further down the line, as cleaner requirements will reduce the risk of scope creep. An added benefit of having stakeholders sign off on the requirements is that if they come to you while the project is in the development phase and try to expand the project's scope by adding requirements, you can remind them of the document they signed off on previously, and reminding them that they can't change the project's scope without impacting the timeline and the cost of the project.
Change Control Process
A good change control process puts the responsibility on the team leading the project to approve all changes to the initial scope of the project as a group. One benefit of a change control process is that it serves as a check and balance that the project manager is not operating in a vacuum. Another benefit of a change control process is that the responsibility for decision-making is shared, as all requests to deviate from the initial scope of the project have a detailed request submitted that is vetted by the project's senior leadership. As part of the vetting, the project's leadership should not just review the core ask, but also the risks, cost, and resources associated with doing that work.
How to Perform Integrated Change Control in a Project
Don't be afraid to negotiate with stakeholders who want to make change to the agreed-upon scope of a project. This will require some creativity on your part. A good tactic to use can be saying that you'd be happy include that requirement in the project scope, but only if other elements of the existing scope are trimmed to free up resources, money, and time to accommodate the change. Alternatively, if the requester feels strongly about rolling in a specific requirement, then they can write up the change control request and present it to the committee. Alternatively, another option is to explore alternative ways to build in what the requester is looking for in a way that wouldn't have a dramatic impact on the existing scope.
Another tactic is to work with the individual looking to expand the scope of a project and see if there's an opportunity to do that work as part of a future phase. This is an especially easy sell if the requester has a lot of work that they would like to see done. Perhaps the biggest benefit of this approach is that it gives you more time to analyze the requests appropriately and develop the best plan to execute on adding that functionality.
© 2016 Max Dalton