A couple of recent client engagements have had me wondering about this question. If Change Management is done properly, do we really need final approval by a CAB during a meeting when most tools have robust automated approvals, conflict checkers and risk assessments?
The answer is likely no, we can replace the CAB with review and approval processes supported by the tools, but there’s some ground to cover in order to achieve this and it may look more time consuming, but in fact replacing meetings with on-line approvals makes responsibilities clear and will take small bites of time, rather than lengthy meetings.
Essentially the CAB can be replaced with on-line approvals at three critical stages in a proposed change’s life cycle:
1. Initial Business Approval
Many organizations don’t really engage the business in approving all, and formally chartering large changes. All changes should be approved by a business sponsor before work begins and again to approve the scheduled deployment date. For infrastructure refresh and maintenance changes, the business sponsor could be an IT Director or VP, but better to gain approval from any/all business owners of applications or services that rely upon that infrastructure.
What? Business approval at the beginning? Yes! Remember Service Strategy: the business needs to ensure the change is strategically aligned and then budget and charter the resources needed to achieve the change. Many organizations do this outside of the Change Management process, but it can begin with a request in the Service Request Catalog that opens a Change record when the request is approved and chartered. At this point the change may move forward into design.
2. Design Review
At this point, final requirements can be signed off, based on any changes required for budgetary needs and final infrastructure design can be completed. This is where “the juice” is: the design approval is the most important aspect of Change Management (IMHO) and the most ignored. This is the time when a cross-functional group of IT Managers/Directors can review the design and be asked to approve moving the change to the build and test stage. If a meeting is needed to review and finalize the design, it should be held and then folks can approve the change’s movement to the next stage on-line. This meeting would not be as lengthy as a CAB meeting, should be the exception rather than the rule (the documentation should provide all that’s needed) and can even be a 15-minute conference call.
3. Build and Test / Final Deployment
Next the change is built and tested according to design. This is a good time for the business to approve the earliest deployment date acceptable and for the change owner to actually schedule the change. At this point, any conflict checks and a full risk assessment should be performed for making the change at the scheduled time. Risk may be mitigated and adjusted. When ready, the change is submitted for final approval to deploy at a specific date/time.
This final approval is often where the CAB traditionally comes in, approving members consisting of appropriate authorities based on the type of change, it’s scale and risk. This can also be automated utilizing the risk to submit the change to the proper authorities as follows (for example):
High Risk:
- Business Sponsor sign off on the risk
- Implementers’ managers approvals
- Change Manager approval
Medium Risk:
- Change Manager
This may sound a lot like a CAB, except that it varies by services or applications impacted: business sponsors will vary as will the implementation team participants’ managers. Thus, instead of every group in IT sending a representative to a weekly CAB meeting, the appropriate personnel review and approve the change on-line.
Benefits
One of the main benefits of this is that there is no longer any need to expedite changes through an e-CAB. Emergency approvals for repairs can occur in a similar fashion, speeding up approvals needed to restore service. Expedited changes no longer cause issues because the change owner simply needs to move a change through the gates more quickly. There’s no waiting for the CAB meeting, no meeting deadlines and so forth. Dev Ops changes can be moved from release and approved by the business sponsor only (low risk) then go. This is a scalable, flexible CAB structure that meets the needs of the business without adding risk. In fact, it may lower risk by adding tracked approval gates throughout the process, rather than approval occurring during a meeting everyone hates to attend.
Before you start
A well-built CMDB is critical for this as it becomes a source for approvals. Each Service and Application should have a business approver and be added to the list of CI’s affected by a change. As welll the infrastructure support teams‘ information is typically stored in infrastructure CI’s. Without the ability to identify the correct business approvers and the ability to track this information in a well-built CMDB managing automated approvals would be a nightmare. Avoid using ad-hoc approvals to automate this, the aspect of audit/control may be threatened unless you are able to show documentation that the approvers of a particular change match the documented approvers for that service or application.
OK, so maybe the CAB and eCAB aren’t dead: perhaps they’ve just gone virtual.
I’d love comments on this Tweet MSITSM your thoughts. Let’s modernize the process!
