Here’s how you define change.

I just read an article on an ITSM blog I stumbled across where the author briefly discusses the confusion that can arise when people talk about different types of change.

The author raises a valid point about operational change versus standard change etc. and this is a problem I’ve run into in the past.

So let me give you the way I solve it.

There are two things we need to define here:

  • Attribute = how you describe a change in terms of priority, impact, type, category etc
  • Process / Route To Production (R2P) = how you deal with a change which can be described by a combination of one or more attributes – eg. Normal change, operational change, standard change, emergency change, service request….

Basic matrix showing Change attributes and processes
Basic matrix showing Change attributes and processes

Many books on service transition confuse these, and whilst ITIL covers it, it doesn’t really spell it out. You can have an ’emergency’ priority, and an ‘Emergency’ Process. You could very easily have a password reset which is emergency in priority but you’d just use the service request process for it…you wouldn’t convene an eCAB with senior stakeholders just because you’d forgotten your password… (unless you wanted to be really unpopular).

The key here is to be granular and descriptive enough to make meaningful sense without having to do every permutation. Remember, most Change Policies (and this is one of the first things that should go into your change policy) can iterate. If someone comes up with a new combination of attributes which they raise a lot of requests for and you don’t have an appropriate definition of process for, then make one up and add it to the policy.

I start with the following category attribute:

  • Tech/Infrastructure = Servers, Comms, OS patching
  • Functional Enhancements = Business-driven changes such as “give me a new CRM workflow”
  • Functional Fix = Incident, problem and defect fixes requiring some kind of code change
  • Data = pretty self explanatory

You can grow this list to suit your common change types – I’ve used heading such as ‘Project’, ‘Comm/DeCom’, ‘Service’ in the past. If all your change is focused in one of these areas eg. infrastructure, then abandon this as a type and break it down into Server, Router, LoadBalancer, Virtual, Physical etc or whatever makes sense for you.

After category comes Priority. I usually keep it as either High/Medium/Low or Normal/Urgent/Emergency. The use of the word ‘Emergency’ here might constrain you if you also use it later as a Process name, but it depends on your organisation and change portfolio. If all you do are monthly bundled releases or emergency ad hoc “chuck ’em over the fence” deployments then it makes sense to have ’emergency’ as a priority attribute to save time and keep it simple, but if you’re a larger organisation with multiple pathways even for faster paced change, then stay away from using process names here and stick with low, medium and high etc.

Impact. I break this down into ‘invasiveness of change’ and ‘how difficult is it to deploy’: I-Impact and D-Impact respectively. Invasiveness is usually related to how big or complex the change is, how many system or service components are being touched by the change. Deployment risk at its simplest is usually answered by the question ‘does it need an outage?’ but can expand from there to how well it was tested, does it have a backout plan etc – these factors are often combined into scores or other weighting factors that tell you if it’s a high or low impact.

Finally, I’ll identify whether the change is pre-defined or not. Typically these will be service requests or operational standard changes eg. password reset, set up new user, clean up logfiles etc

Once you’ve identified these attributes, identify your processes. Most organisations will have a ‘normal’ process which covers most of the stuff that needs assessment, scheduling, authorisation etc

Many organisations will also have ‘standard’ changes to cover repeatable, low risk changes and stuff which doesn’t need lots of governance.

You always need an exception process for stuff which needs doing RIGHT NOW and which doesn’t fit any other label, so I use my emergency change process for this.

After that, it’s up to you. If you start with those 3, normal/standard/emergency and build processes for those, monitor the requests for a few weeks. You might find there’s a lot of changes being pushed down one route which isnt’ competely appropriate for them, and that might be a trigger to create a new process. It may also be a trigger to create a new attribute so that you can identify them easily.