In a world of constant change in every aspect of life, it might be reasonable to expect that deciding on changes and processing them would be a widely held skill, familiar to us all.
It’s so innate and essential that in IT service management (ITSM), for example, you’d expect perfect, polished, and pervasive change management to be the norm. Perhaps changes at work are more complicated than in our everyday lives and have broader, and more expensive, consequences? Probably more people will be involved, and we might be less likely to be the decision makers; but the underlying stages shouldn’t really be that different.
In practice however, the change management process still seems to be difficult, and is an ongoing source of discussion and debate across social media for ITSM professionals. Some of the reason for this, I believe is that IT spends too much effort on the wrong parts of the change process, trying to control too tightly or argue over things that cannot be changed.
The full change management process has three phases:
For an organization to make best use of their limited resources, and yet also maximize potential improvements, all three phases of change management need to be there and functioning well.
Understandably, technically-oriented IT departments seem happiest dealing with the last phase, i.e. actually building, testing, and implementing the technological consequences. But all three parts truly matter. Without an appropriate request process the best ideas might never see the light of day. And, unless the thinking and deciding phase is properly done, organizations will most likely end up spending their time and resources doing the wrong things.
Organizations are full of potential change; having lots of people involved in making decisions about each and every change is going to be impossible. Anyone who tries is going to disappear into a bureaucratic mess that will see changes blocked and slowed down by administration, or more likely, they will find changes taking place without going through the approved process.
The successful route is to focus the right resources on the right kinds of decisions; those situations where an IT decision actually needs to be made, where there are benefits, costs, and risks to be considered and balanced. The first step in allowing that focus is to identify two areas where IT should not spend time considering, discussing, and deciding.
Some changes are inevitable, so time spent considering whether to do them is time wasted. For these, ITSM (and other service areas of the organization too) just need to accept it and get on with it, like it or not. Examples include:
No matter how much anyone in IT might disagree, think carefully before deciding to challenge these; you were being told, not asked.
Of course, it should still be open to decide how best to handle the change. It is vital to establish the actual purpose of the change. Sometimes it can be hard to see this because the change might be presented with an assumption of how it should be done rather than what it is supposed to achieve. For example, the response to a supplier withdrawing support is often a request to upgrade to that supplier’s latest version. Alternative options exist though, like moving to a different supplier, building an in-house alternative, taking the risk to run the software unsupported (i.e., not to upgrade), and more.
In our everyday lives, we are all used to changes being decided at different levels of authority. Take a look at this example and see if it fits with your family experience.
|Kind of Change||Authority Mechanism||Caveats and Rules|
|Moving to a new city||Family meeting||All adults have to agree, all children consulted|
|Decorate the house||Parents||Veto rights for own bedrooms|
|Choosing dinner||Delegated to whoever does the shopping||Known list of unacceptable solutions|
|Inviting friends over||Anyone can do this||Inform early if extra meals are involved|
Obviously holding a family meeting to discuss minor issues isn’t sensible, nor is imposing major life changes on the whole family without some consultation. The same mechanism that makes the house run effectively – delegating changes and authorizing people to decide on minor or already agreed issues – works just the same in the work environment.
ITIL® calls these standard changes. For the most part, these are the kinds of changes that have happened before and therefore already have established rules. People are trusted to ‘just do it’.
Think like a parent – the first time your child invites a friend to sleep over, you would expect to be asked, discuss, and approve the occasion before it happens. Once you meet the friend and know things are fine, you trust your child to decide for himself/herself the next time. You may have caveats to that authority – not on Thursdays, or while you have relatives visiting, or you may require that they pay for consequential additional costs (like movies and popcorn). But the rules are set before, everyone knows where they stand and things progress smoothly. If they abuse this delegated authority, it can be removed (no friends allowed over whilst grounded).
All these techniques can apply in work-based standard changes too, along with all their benefits. The first person who wants a new project management software package will need to justify it. By the time the 30th person needs it, it will be everyday routine.
In the extreme case, some changes might be actioned and recorded with no human involvement at all. For example, employees may be allowed to download free software onto their work PCs, and then auto-detection software will find the new programs, establish they are not on any blacklist, and record them. In case of future issues the information is there, but for the most part everyone is able to just get on with doing the stuff that actually does require a human thinking about.
So…if you can see how your human-sized attitudes work at home, maybe apply the same approach at work with your standard changes – it will surely simplify the process.