Change Categories

Discuss and debate ITIL Change Management issues
Post Reply
User avatar
swal87
Itiler
Itiler
Posts: 21
Joined: Tue Sep 02, 2008 8:00 pm

Mon Mar 24, 2014 7:23 am

I realise this is a difficult question to answer and differs from business to business, however I’m giving it an airing for feedback anyway.

We are looking to drive change approvals based on the V3 change types and categories.

So for a Normal Change i am looking at;

Major 20d lead time- Multiple business departments affected, introduction of a new service, decommissioning current live service.

Significant 10d lead time - Downtime required, Service degradation required, No back out available only forward fix.

Minor 5 d lead time - Build of a new single server (non-standard), Configuration Change no negative impact.

Both Major and Significant changes will require a pre review via CAB Agenda and possible a detailed walkthrough from the requestor / sponsor.

The Minor Change will be represented on the CAB day and potentially approved in the meeting.

The other thing to understand is that we are restricted to Tin and String changes and will occur at some point. The approval to proceed with a build from project (financial, strategy and resourcing) is controlled via a different project process. The Project manager interacts with change when actual environmental changes are required.

Basically, does this seem sensible? have we missed the point and can you think of criteria i can put into Minor.


User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3639
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Tue Mar 25, 2014 4:48 am

My first comments are

why are you not basing your CM policy and categorisation on the realities of the corporate IT environment ?

That would be a better way to classify your CM Policy, process

ITIL is just a guide and the classification model is there - in part as an example

It boils down to this

1 - You have an time driven CM categorisation - Emergency, Fast Track for example - where the time criticality and impact to production are the critical factors

2 - You have a process driven CM Categorisation model - Significant, Major, Normal, Standard, for example - where the change has to be done in an orderly fashion.

You need to look at what the scope is -
Application
Server
Network
Data Centre
etc

and whether the complimentary processes - Release & Configuration - are in place - as Release will definitely have an influence on Change.

As you can see in my signature, I have been doing Change Management for a few years
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
User avatar
swal87
Itiler
Itiler
Posts: 21
Joined: Tue Sep 02, 2008 8:00 pm

Fri Mar 28, 2014 9:51 am

Thank you for your time UKVIKING

Im not sure I get the first point about the realities of the corporate environment? My idea of the time frames is to offer some protection to the business and to put an end once and for all to engineers and project managers requesting changes at the last minute and expecting approval before CAB.

This will also give us some time to undertake assurances, peer reviews, security sign offs etc.... whilst still allowing an avenue for true fast track changes. Not where someone forgot and now needs a favour.

Configuration management is primitive within the organisation, but does exist for application deployments, however Change and Release Management are combined into the same team.

RFC forms we use have the scope for the full implementation instructions.

All the areas you have mentioned are in scope

Applications: - Rollout - patching -
Servers
Network - Although more difficult for me to
Data Centres

I suppose what I am asking what else could be put into the minor category. I feel saying all changes that have "no impact" and "low Risk" to production services is a big catch all that could bite us when we try to apply categorisation.
User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3639
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Fri Mar 28, 2014 9:57 am

OK

To my first point. The defintion of how you differentiate the types of changes should be based on the IT environment at hand

So for example: The CM scope is only networks so there is a fast turn around and very little testing as the majority of the work is either enable or disable F/W ports / IP.

So there would only need to be - Emergency (Fault fix), Normal Change

These are speedily approved (almost presumed)

However, there are a few changes that involves other work than F/W disable enable port /IP so you have Major

So you have 3 Change Classifications - Emergency and Major and Normal
Emergency for Fault fixes only
Major and Normal for everything else. The CAB only discusses the Major but the CM merely tracks the normal for statistical purposes
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3639
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Fri Mar 28, 2014 10:00 am

As for lead time etc. I would not even bother

I would have the following disclaimer

if the Change Request meets the criteria to be included in the next CAB Meeting, the CM will inform the requestor of the date / time their change would be added to the agenda

Another point. There is NO guarentee a change will be approved nor deployed when the customer wants.

This is because if there is a fault - critical - that occurs as the same time the change will be scheduled, which should be dealt with first ?

The fault of course.

The CAB when approving the change would schedule in accordance with the next window

Manage expectations
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
User avatar
ChangingMan
Itiler
Itiler
Posts: 27
Joined: Sun Apr 27, 2014 8:00 pm

Mon Apr 28, 2014 4:38 am

I think it's entirely specific to your business needs but we use fairly standard catagories.

This is ripped out of our change management policy which I wrote.

Standard Change
A standard change is a change to a service or infrastructure for which the approach is preauthorized by change management. A standard change has an accepted and established procedure to provide a specific change requirement. The crucial elements of a standard change are that:
• The change is in the Standard Change list documented by Change Management
• The tasks are well known, documented, and proven
• Authority is effectively given in advance and authorisation is not required from CAB or Change Manager
• The impact is low and always well understood
• The risk is low and always well understood

Minor Change
A minor change is any change which is not a standard change, a major change or an emergency change. All minor changes must be submitted to the Change Manager for approval once the change has secured resource and availability from the Change Implementer to be completed. Once approved, the Change Implementer can carry out the change.

Major Change
A major change is any change which is considered to be of high risk, high impact or may be significantly visible both internally and externally (such as the deployment of a new customer service capability). Release as defined in the companies Release Management policy are also considered Major changes. All Major Changes must be submitted to the CAB for review, should further discussions be required an emergency CAB meeting may be convened.

Emergency Change
Emergency changes are usually initiated in response to a critical IT situation, often an incident or problem requiring immediate action to restore service or prevent service disruption.
The emergency change category is reserved for changes intended to repair an error in a service that is negatively impacting the business to a high degree.
Effectively, the emergency change procedure will follow the normal change procedure except that:
• Approval by Change or Incident Manager if neither can be contacted and sufficient business justification exists the change may be carried out with retrospective authorisation sought.
• Testing may be reduced, or in extreme cases forgone completely, if considered a necessary risk to deliver the change immediately.
• Documentation, such as updating the change record and configuration data, may be deferred, typically until normal working hours.
The number of emergency changes proposed should be kept to an absolute minimum, because they are generally more disruptive and prone to failure with corresponding negative impacts to service availability.
Post Reply