Seeking Best Practices for Handling Emergency Changes

Lance Waldrop August 9, 2024

We are implementing change management in our environment and seek insights on handling emergency changes. In ITIL, the Emergency Change Advisory Board (ECAB) addresses these requests as a subset of the CAB. Do you prioritize verbal approval before submitting the change request, or is the request submitted first and then handled by the ECAB? Alternatively, do you follow a different process? We are interested in learning about others' practices and experiences.

2 answers

1 accepted

0 votes
Answer accepted
Mark Higgins
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
August 9, 2024

Hi @Lance Waldrop 

We have an ECAB group, or 'Emergency Approval' group.

The change is raised as an Emergency, and an automation rule, takes the ticket straight to Emergency Approval.

One of the ECAB group, are required to Approve the request, which then goes straight to Implementation.

I would recommend that a ticket does need to be raised, which takes minutes, and does need to be approved, before the fix is applied. Auditors tend to see it that way as well . :-) 

REgards

Mark

Lance Waldrop August 13, 2024

Hey @Mark Higgins thanks for your input! In your automation rule do you send a notification to your Emergency Approval group via Teams/Slack or some other type of incident management tool? We were discussing establishing a private chat group with our ECAB members who with receive a private message when then emergency RFC was submitted.

Mark Higgins
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
August 15, 2024

hi @Lance Waldrop 

We don't do anything other than move to Emergency Approval status, and set the Approvers as the Emergency Approver group, which then sends them a notification via email for them to approve.

We do tend to seperate CAB people from Emergency people, as the Emergency people are normally Heads of IT, or Business, and not the same that sit within the CAB.

You can also state in the approval step, if you need 1 person to approve, or all.

These 'people' are normally trusted, senior IT, do hitting the 'Approval' and moving to 'Implementation' may require discussion, or may be not.

Cheers

Mark

 

 

 

Like Lance Waldrop likes this
Lance Waldrop August 26, 2024

Thanks for your suggestion!

0 votes
Jim Knepley - ReleaseTEAM
Atlassian Partner
August 9, 2024

In my experience, a CAB is most effective when you emphasize the "advisory" part, and don't let it slip to an "approval" board.

For example, if systems are out of bounds for changes because of quarter-end financial reporting, the CAB should be the clearinghouse for that communication and coordination. Teams should want to coordinate their changes with other teams, particularly operations, which the CAB facilitates.

The same goes for ECAB.

So, to your exact question: it depends. IMO, teams should have a good enough grasp on a change that documenting it isn't a burden, but it's fine to backfill the documentation after the incident has passed.

Lance Waldrop August 13, 2024

Is that recommendation for all situations or just for teams with a mature setup? We are currently in a growth phase, dealing with a lot of monolithic legacy code and lacking formal pipelines. While we're using a similar strategy, our team's focus on resolving issues quickly makes it challenging to ensure complete documentation.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events