Change Management Approval

Blue · ‎08-26-2024

Hello all, we are interested in how you have approached your Change Management for the enterprise IT.

Who compromises your Change Authority Board (CAB)? Is it all IT Managers or IT Directors or IT VPs or etc.?

Do all of the CAB members need to approve CHGs in ServiceNow to allow it to progress? How have you configured the approval for CAB on a CHG in ServiceNow?

Option 1: One CAB member can approve

Option 2: All CAB Members must approve

Option 3: % of CAB Members must approve (ie. 100%, 75%, 51% etc.)

We are revisiting our approach.

Alan Prochaska · ‎08-26-2024

We have a multi-stage change approval process:

We have defined the manager of the assignment group as the primary approver, who is accountable for the change end-to-end. If the change blows up or disrupts something else, the primary approver is accountable and gets to provide explanations. Primary approval happens during Assess.

After primary approval completes, the change moves to Authorize, where it could have some combination of compliance approval, CAB approval, and additional approvals. If the lead CI of the change is in-scope and onboarded for a compliance regulation, then the workflow stages a compliance approval to the business application owner and their delegate. Once complete, the workflow stages a CAB approval to the CAB assigned for the lead CI (Chg.Configuration Item.Approval Group). Once CAB approval is complete, then if the change request included an Additional Approval, the change workflow stages and collects it.

Compliance approval ensures the change complies with key regulatory controls for change, specifically that a) new content was successfully tested off production before implementation in prod, and b) approval was collected before new content was migrated to prod.

CAB approval ensures that appropriate communication and coordination with key stakeholders has been done, and there are no objections (ie. they agree that the content can be implemented per the defined scope and schedule). This is different from many orgs' expectation of CABs. We no longer make CABs accountable for changes, only responsible for communication and coordination. Accountability lies with the primary approver.

Additional approval is typically a way to include additional CABs for broader oversight and awareness.

Compliance approval may or may not be required. It depends on the CI.

CAB approval is required.

Additional approval may or may not be required. it depends on whether the change manager (Assigned To) specified an Additional Approval on the change request.

CABs are typically not populated with VPs or even Exec Directors. Levels below them are typically the ones reviewing and approving the changes to move forward. VPs or EDs typically are not aware of change and impact specifics.

All approvals are "one must approve". We have found that multiple approvals and shared accountability are not effective. The basic model is "many reviewers, one approver" and "one throat to choke". If a CI or deliverable has many stakeholders, the approver must be accountable for all stakeholders and incorporate their opinions and recommendations into their decision. Trade-offs may be required, and decisions must be made.

Our 0.02

View solution in original post

Mike B_ Fisher · ‎08-27-2024

I worked for a healthcare provider and worked on multiple Change Management evolutions. A few things that helped our approval/CAB process:
1. Delineate voting members vs attendees. Voting members were usually leaders (manager and above). We asked key personnel to attend CABs to provide their input, but they weren't part of the formal approval process. Think the C in RACI.

2. Our CAB approval was done by in-person consensus, not via workflow. Decisions were made by people that showed up to CAB meetings. There's only so much you can put in a Change Request record, often the nuances and concerns had to be fleshed out in a discussion at the CAB meeting. A change was considered approved when no voting members present at a CAB meeting had any concern, then the Change Manager clicked the Approve button on behalf of CAB.

3. Instead of rejection, we asked that any voting member with a concern about a particular change to discuss their concern with the submitter or their leadership. So most times a voting member had concerns about a particular Change Request at a CAB meeting, the voting member would hold their approval (and thus CAB approval), have a sidebar or discussion after the meeting with the submitter and/or their leader, and then communicate with the Change Manager whether to approve or reject the change. The majority of the time, the discussion either led to an approval, a minor modification of the change to address the concern, or a resubmission to the CAB with a significant modification of the change. This approach promotes both efficiency (rejections take time to resubmit) and collaboration (dialogue instead of just clicking Reject).

Blue · ‎08-27-2024

@Mike B_ Fisher ,

1. agree fully. What I am concerned about is delegating down by certain individuals which then loses that leader review.

2 & 3. I find that not having an auditable trail in ServiceNow of CAB members clicking approve makes it a burden on the Change Mgr to keep track of who of the CAB members approved or did not approve. Also, if we have to audit we have no mechanism other than the CAB Mgr clicking approve as the validation that all CAB Members approved.

Blue · ‎08-29-2024

@Alan Prochaska , curious, would your organization approve a CHG record to have 2 month + start and end dates for the Change where multiple infrastrcuture devices are changed to be all lumped into that one change?

Is there a threshold for how long a CHG can be or how many CIs/services/applications can be included within that one CHG?