One of the most commonly asked questions is what to look out for when reviewing Change Requests. I use the below list when assessing Changes to make sure that my review is as comprehensive as possible.
Title – is it clear and easy to understand?
Description – does it clearly set out what the Change is for?
Reason for the change – could include impact of not doing the Change
Impacted service(s)
Locations impacted by the change
User base impacted by the Change
Change requester details
Change implementer details
Pre implementation testing
Implementation plan
Post implementation verification
Priority
Risk analysis – based on impact & probability – may be useful to have a matrix for this.
Risk mitigation – notes on any activities that could be carried out to reduce risk
Back out plan
Will change impact other environments?
Will the change be mirrored automatically to your Disaster Recovery environment?
Authorisation
Communication – will it be invisible to the user community? If not, will a communication be issued via the Service Desk?
Change closure
I will provide guidance on how to create a risk matrix, implementation plans and communications in my later posts.
Subscribe to:
Posts (Atom)
Microsoft Teams 101
One of the things I've been asked about most this week has been how to use Teams for meetings. Teams is basically Microsoft's replac...
-
Following on from my previous post on things to look at when reviewing a Change, it is important to investigate risk to ensure that stakehol...
-
As promised, here is my take on the Release note (and yes, of course it’s pink!!) It includes the title of the release, the audience, any...
-
So here's the thing. No one likes major incidents; by their very definition they are the serious stuff. But there is something that’s...