Program Strategy: Scope Change Process

In today's nugget, I want to talk about the scope change process. I think we can all agree that having no scope change would be great, but it's not likely reality in most large technology projects. From a FastTrack perspective, your solution architect will be checking to make sure that you have a clear process in place for introducing scope changes that are understood and agreed to by all parties. Although there's not a slide that specifically asks you for your scope change process, it ties in with your overall solution scope which is covered on slide 13 in the solution blueprint review template. Your architect will likely want to see a statement of work, project charter, or a business process catalog that outlines in detail what the scope is and what happens when the scope changes.

When describing your scope change process there are three key elements that we're going to be looking at. The first is a notification process, the second is a mitigation process, and the third is your approval process. If one or more of these key elements is missing from your description of the artifacts that you provide us or you're unable to describe this process then it is likely to be called out as a risk. If you provide these details in your solution blueprint template or as an additional artifact for your solution architecture review then this topic may not even be brought up. 

So what are the risks of not having a clearly defined scope change process? First is the lack of visibility to potential changes in scope to your decision-makers that may delay or even prevent go live. When there is not a clearly defined process at the onset of your project you might find that when a change order is needed you wind up with a delayed resolution because the project team does not have a clear process to get the change approved, doesn't know who to contact, or who can approve and there's not a mechanism in place to figure out possible workarounds.

Module 8 in the implementation guide success by design book dives into program strategy and offers a lot of great advice for a well-defined program strategy pages 172 and 173 specifically are great to learn about how you can implement a design review and change board in your project to help manage the overall design and change in your project to help avoid change orders in the first place. So the moral of the story is to define a clear process that's documented and put in place for introducing changes to the scope that's understood and agreed to by all the parties at the beginning of your project.

For the complete 📖 Implementation Guide: Success by Design book click here to download: https://aka.ms/D365ImplementationGuide

To learn about Success by Design, check out this eLearning 🖥: https://docs.microsoft.com/en-us/learn/modules/success-by-design/