A Request For Change…To Change

I’ve spent the holiday period going over the Change Management process in the 2011 ITIL® Service Transition book. I know! It’s fun isn’t it?! Anyway, I remarked on Twitter that the definitions for the types of change requests (4.2.4.3) is rather confusing. Here’s the excerpt in question (from page 65 of the digital edition):

There are three different types of service change:

  • Standard change A pre-authorised change that is low risk, relatively common, and follows a procedure or work instruction.
  • Emergency change A change that must be implemented as soon as possible, for example to resolve a major incident, or implement a security patch.
  • Normal change Any service change that is not a standard change or an emergency change.

It’s also worth noting that a standard change would not require a change request form to be filled out, as the term “pre-authorised” alludes to.

In the English language, the words standard and normal are often used interchangeably. Indeed, the Merriam-Webster thesaurus displays normal as a synonym for standard. Those who are unfamiliar with ITIL®, and there are many, are unlikely to understand the nuance. This could lead to confusion at the time of requesting change and skewed results in change management reporting. After hashing it out with a peer over Facebook I replied to Stuart Rance, a Service Transition author, that I prefer using “routine task” in place of “standard change”. It avoids confusion and still makes sense within the context of ITIL® and IT service management.

He suggested I log a change request with the Cabinet Office. So, I did.

I have logged a change request to change the label of standard change. I’ll keep you posted on the response.

  • This is an interesting subject and as you point out one that easily confuses engineers and other instigators of changes. this confusion often causes resentment in the process and result in a lot of "under the radar" activity.

    In my organisation we have taken the ITIL methodology as the frame work that it is and modified for our own use, to make it more palatable to our internal work cultures in an attempt to maximise its uptake and ultimatley adehrance.

    Due to this approach we have 4 kinds of change, below is each type with a short description

    Major – Major Changes require senior management approval. The implementation of the change represents a very high risk to the services offered to <org>. Major change must be approved by the CAB, business owner, and GM IS.

    Significant – Significant Changes may require a large coordination of effort from IS; represent a reasonable risk to the business when the change is implemented. Significant change must be approved by the CAB, business owner, and <IT Management team> member.

    Minor Change Minor Changes are low risk changes that require a degree of planning, building, testing and coordination to implement. Approval for Minor Changes is by Line Manager and Change Manager.

    Standard – Standard changes are low risk, repeatable and documented changes that have been pre approved by the CAB. They require Line Management and Service Delivery Management approval for implementation.

    As we are starting from a low maturity point there is still a requirement to complete a form for a standard change, using workflow with the request tool we can make this a few painless exercise and it mean we have log of all changes no matter how routine it also removes the excuse of "i thought it was standard so i just did it" as these changes tend to cause the most damage. As the process, the culture and attitude towards change matures it will probably be possible to change this in the future.

    as an example of this we currently have a problem whereby people log everything as standard without doing a proper assessment of the change just to get it done faster but a few high profile screw ups is waking people up to how much of a bad idea this is and as they are all logged we can educate and "discuss" with the relevant people.

    we're about 6 months into this process and after much influencing managed to get a dedicated change manager, which makes a huge difference. Having someone with a single focus has enable the process to be fined tuned, spending time with each technical manage to ensure feedback and buy in is established and also to generate useful reporting, demonstrating the benefit to the business of a proper change management process and more importantly for exec buy in, how much cost we have avoided by having a change process in place

    anyway, i'm waffling now, to your original points…

    i agree that standard and normal or confusing and one of them needs to be reworked or removed.

    I think that not have a change form for pre-approved changes is dangerous, every change should be logged somehow and this is where a good tool-set comes into play using automation to heavily streamline the request and remove any delays.

    Ian

  • aprillallen

    Hi Ian,

    Thanks for your comment. I like to hear what people are doing in their respective orgs.

    I had a to-and-fro with @ITILzealot on twitter about standard changes, yesterday. I agree that they should be documented, but I see them more inline with how the service request process works. Standard changes are, pretty much, business-as-usual in an operational sense–things that occur on a daily basis, so they are kind of like a back-office service request and seem more appropriate for the Service Operations book than the Service Transition Book. The definition of standard change alludes to not being service impacting, not adding or deleting a service, or even changing how a service is delivered.

    I think the way your org is classifying changes is a good and workable solution, and having an enforcer to ensure all requirements are met should make operations much smoother.

  • What your saying makes perfect sence, 95% of our standard changes are of an operational nature, using ITIL terminology they are making changes the resource of a service not the service itself and when I think about it they do follow a carbon copy of the request process. New project and services use the other 3 types of change. The only time operational changes use the other 3 is for major hardware upgrades or version upgrades. I.e exchange 2003 to exchange 2010 is a high risk change but from a user point of view email is email and they see little or no difference to the service as a whole.

    Ian

    Ian

  • @bcullen76

    We also have adapted the ITIL framework to fit our environment. We currently use the change types SIGNIFICANT (which we are about to drop), MAJOR, MINOR and EMERGENCY standard RFC's for example repatching a network port or moving a PC are actioned under the Request Fulfilment process.

    SIGNIFICANT we put in place to highlight changes to services which are linked / depend on other systems, the trigger coming out of our integration testing but we have found that we can drop this and just log these under a MAJOR change.

    MAJOR Changes are HIGH risk i.e Will have impact on a very high percentage of users or a business-critical system. The change may be new technology or a configuration change and would likely involve downtime of the network or a service.

    MINOR changes affect a small percentage of users and risk is less because of ITs experience level with the proposed change and only requires approval from the Change Manager.

    EMERGENCY changes are raised if it is in response to a Priority 1 or 2 incident / problem or has been deemed 'urgent' by the CAB

  • Thanks, Brendan. It sounds like your standard RFCs are working in the manner I expect they should.

    You both classify changes in a similar way, and I can see different groups/roles require sign-off depending on the classification. Does the classification also impact the amount of notification your customers get?

  • Jv

    Hi,

    What is the update of the change request raised to axelos??
    Did they change it??

    Thanks,
    Jvalin

Archives