In this video, learn how to implement a change control system. Additionally, learn some simple steps to prevent stakeholders from introducing scope creep on your projects.
- All projects start with stakeholders' desires, needs, and expectations. These are born from a problem they'd like to solve or an objective they'd like to meet. Assuming you've clarified what's in and out of scope in your baseline, you should have a solid foundation to work from. This being said, even the best plans need to be adaptable. Inevitably, stakeholders will forget to include things or will misinterpret what was originally agreed upon. If you know there's a good likelihood this will occur, why not prepare for it up front? Let me explain how to implement a change control system that takes scope changes into account.
A good change control system will have procedures in place to address questions like how will scope change requests be reviewed? How will scope change requests be approved or denied? How will changes to deliverables, documents, and plans be managed? How will decisions be communicated? How strictly you manage scope change requests will determine how likely scope creep will get a foothold in your project. For example, if you're lackadaisical on what you will and won't run through your change control system, you can expect stakeholders to try to take advantage of your lack of discipline.
Scope creep should never be allowed. It's uncontrolled. And losing control of any of your project constraints, especially scope, is bad project management practice. Here are some simple steps you can take to prevent stakeholders from sneaking something past you. First, only accept change requests in writing, preferably on a change request form. Stakeholders should be required to document why they're requesting the change. Next, review the change request with your team and get their input.
Evaluate and record the potential impact the change request will have on your project's constraints. If you and your team deem the change request acceptable, you can then send it to your Change Control Board. On small projects, you might be the sole decision maker but large projects should include key decision makers and influencers. The Change Control Board will ultimately decide if the change request is accepted or denied. No matter if the change request is accepted or denied, the reason why the decision was made should be documented in the change log.
Approved change requests are then sent back to Planning so the baseline can be revised. Then, once the baseline is updated, your team can execute the approved changes. Keep in mind, there's a difference between negotiating constraint trade-offs and allowing scope creep. The first is within the boundaries of the existing constraints, in other words, control, while the latter is not. Nothing's wrong with improving products or services. The changes just need to be accounted for and the potential impact measured against the other constraints.
Staying in control of scope changes is vital and implementing a change control system can help you proactively manage change.
- What is scope creep?
- Causes of scope creep
- Preventing scope creep
- Learning from a case study