Managing Change Requests

[dwalby]

Hi all,

We've only recently implemented the first iteration of our Change Management process and for the first time are using a tool (Service Manager) to log and track changes. In terms of the usage scenarios around Change Management though I wanted to get a feel for how others approach it in conjunction with Service Manager.

By default Service Manager has 3 change types which can be selected; Standard, Normal & Emergency - all of which are common terms as per ITIL guidance. For the most part though it is suggested that 'Standard' changes do not require a RFC as they are categorised as changes that are low-risk, common and 'standard' practice, such as a password resets for example. Instead, most articles on the matter I've seen suggest that these should be raised as Service Requests, which I'd agree with. With this in mind, what are some usage scenarios and reasons for raising 'Standard' Changes within Service Manager?

Thanks in advance

[Dan Munns]

We use standard changes for things like updating software to be deployed via GPO or patching. 

Basically from the Change Policy I wrote: 

Emergency Change: Changes which require urgent implementation as they are associated with a major disruption, outage or degradation to a live IT service.

Normal Change: Change to a service which may have major impact and risk. May require a large amount of resources and funding and may be run as a project. A change to a service which has not previously been built or tested. May generate a number of smaller changes which will be submitted through Change Management

Standard Change: Low risk and low impact change that is pre-approved by change management and has a documented predefined process (Standard Operating Procedure / SOP). The bulk of the change is considered Business as Usual (BAU) work undertaken by IT teams

Service Request: Changes which are preapproved and can be requested via the IT Service Desk. Follow predefined procedures (SOPs) and are low impact and low risk. IT Service Desk to manage and approve as per Service Request Process

It may not be (is not) 100% as per ITIL guidance but it works for us. We mainly log standard changes as changes rather than service requests so that we have visibility of them on the change calendar. 

There are also sub categories of changes to go with the above: 

Emergency

• Emergency
• Emergency Out of Hours

Normal

• Major/Significant
• Minor

Standard

• Standard
• Service Request

[dwalby]

Thanks @Dan Munns - This makes sense, thank you for clarifying your usage scenarios.

Out of interest how do you approach the authorisation of emergency, normal and standard changes?

[Dan Munns]

Emergency changes require an emergency cab (done via service manager) with only one approval. 

Normal changes go through a cab meeting we hold weekly which needs at least 3 people to approve. 

Standard changes get approved by the change manager (ie me) as and when they are raised. 

[lee mcdermott]

@dwalby

We deal with our emergency changes via email. So when the change is logged it will generate an email to all CAB members - it then requires 2 to approve (via email). When these are received back into the mailbox (in Hornbill) the change is processed.

Normal changes are emailed to CAB on a weekly basis - once approved (via email) the change is processed.

Standard changes - when logged we have a list of pre-approved changes to select from. The change will automatically process through and gets assigned to the actioning team. Some of our standard changes are things like, reboot print server, add dns entries, apply microsoft patches. add mailgate rules etc.

 

lee