“Why have you rejected this Change!?” questioned the Application Team manager of the IT Change Manager, after waiting patiently in a Change Advisory Board (CAB) meeting for the last two hours. “This Change delivers crucial functionality for our commercial platform and will place us a step ahead of our competitors”, they continued.
The Change Manager’s response? Take any, or a combination of, the following:
- You didn’t complete the Request for Change (RfC) form correctly.
- I wasn’t comfortable with the completeness of the implementation plan and backout plan.
- I feel it’s too risky at this time.
- The required stakeholders haven’t been engaged.
- You didn’t provide sufficient time for the Change Advisory Board (CAB) to review.
Some of you reading this have likely been in this position at least once before, with frustrations boiling over at the time. Most of the rejection reasons given were no doubt based on sound judgement. But how did you get to that point in the first place? How did a Change go out for approval ‘not ready’ or ‘too late’? And why do a cast of thousands need to approve a Change that your agile team are the experts in?
We regularly work with clients to help their IT Change Management activities transition from Change prevention to a more flexible, lighter, customer focused, Change enablement practice that drives accountability, and objectively balances risk with reward. This article provides an insight into our recommended approach.
Read the full insight on the Mason Advisory website