You have created this beautiful plan. All neat and in order.
Through Manage, we have made sure that we are keeping on track.
But there will be times when somebody changes their mind. And the purpose of Control is to allow you to manage requests to do something different to the plan you agreed in Aim.
Why do we make changes?
You all agreed what you were going to do at the start and you had a plan. But it was based on the best information that we had available at the time.
Changes can occur for a number of reasons.
- Design or scope
- You don’t like what you see, make it purple not pink please ????
- The market/your circumstances/environment has changed since Aim
- Defects or bugs
- You may need to make changes to resolve problems and fix design issues
- Fixes could cost more than you forecast or might take longer to implement if they relate to unplanned product features
- You forgot something when you created your plans in Aim
- Resources have changed along the way or an error occurred
The reality is that things can evolve.
And it’s not always just at the whim of your Sponsor. The Sponsor can do as they wish and change whatever they want. But you wouldn’t be doing your job if you didn’t help them understand what happens if they do something different?
So changes aren’t necessarily bad. But changing something without due consideration or impact assessment is bad. So in theory, all changes are possible, but they just need to be handled properly.
Let’s have a look at the process to make a change request.
- Describe the change: Your goal here is to describe, as fully as possible, the proposed change. Include sketches or pictures if you can. The more detail, the better
- Why change?: Give a detailed overview of the reasons for the change and how it helps achieve the why or the Sponsors mandate
- Intended outcome: Say what it will mean if the change is agreed, how it achieves benefits, meets the critical success factors or list new ones
- Cost: Say how much more or less it will cost to incorporate this change
- Time: Say how much more or less time it will take to incorporate this change
Any change request needs to be justified.
Sometimes you’re being asked to do less, not to do more. So you need to pull all the information together and work out how it’s going to impact your plan overall.
The change might come from your Sponsor, but it doesn’t always. It could be from anyone in the project team. Anything that looks different to what you agreed at the beginning will need your Sponsor’s approval.
Usually you can discuss these changes at your Steering Group meetings. And you can add whether or not you recommend the change request. But remember you are not the decision maker. You provide the information, and will have made an impact assessment which means you have an informed opinion.
You’re on the home straight.
The final bit of Build is getting that approval. You’ve built your product, you’re managing the activities and the plan really well. There’ve been a few hiccups along the way, and some changes that you’ve had to incorporate. You just need to ensure that you have agreement from your Sponsor that you’ve built what they wanted.
- Did your RACI and governance meetings help to make timely decisions?
- Did you create what the sponsor asked for?
- Have you met the Sponsors why?
- Have the Critical Success Factors you agree in Aim been met?
- Did you control the build throughout?
- Are you still on time and within budget?
- What would you do differently next time?
- Why did it happen the way it did?
- What will you do more/less of in future?
If your Sponsor is happy with what you’ve built, and you’ve met their why, then your Sponsor needs to give you that formal approval to move forward. And again, you can do that at your regular slot that you’ve got with them at the Steering Group meeting.
And that’s it!
Well done, you’ve completed Build: the B of the ABCDE way.