Preface
In a world with an ever increasing numbers of frameworks being rewritten almost on a daily basis I think it’s time to put the “s” back in simplicity. Personally I’m getting sick and tired of all these “know-it-all-a-lot-better” individuals who rewrite something that isn’t broken, has always been and will always be best practice, and for which the language doesn’t need to be changed just because we’ve got the power to do so and as a side-effect it’s going to create more revenue for some greedy companies and individuals. What idiot came up with the idea of talking about a purpose, goal and objectives for a process? I have issues enough just agreeing on the goal, so I’m really not waiting for added complexity we don’t need (sorry ITIL v3) and isn’t going to help, or provide additional value to anyone or anything in our tiny Universe. Take that in with a teaspoon (or should that be a sledgehammer?)!
Maybe it doesn’t matter whether we call something “reviewing changes” or “filtering changes”, but I think it really does the moment “reviewing changes” is used twice in the same process description (sorry ITIL v3), but with a completely different connotation. I’m not even sure if I’m describing the following “simplified” change management process for you – my dearest readers – out there, or just to convince myself it’s possible to explain process-theory in a language we can all follow. This is my attempt to put the KISS back in change management. I believe that anyone not fully schooled in quantum mechanics and membrane theory should follow this golden law: “Keep it #$&* simple stupid!” I feel like putting some swear-words in, but won’t for the sake of my respected readers.
On a slightly different note – somehow it sounds better in French: "sur un autre sujet" – I absolutely positively most definitely ‘hate’ all these silly acronyms and that’s a huge understatement. I’ll try avoiding them in the remainder of this article, BNPM. (Oh sorry, BNPM = But No Promises Made)
Introduction
Change – it’s a curious thing! The certainties that come with live are death, taxes and never-ending change. Ever gone back to your home city after 30 years? Chances are pretty big that you didn’t recognise the place anymore. I compare the physical environment to playing SimCity (still one of my favourite games, especially when Godzilla is on the loose). So, what about IT? Well, go back thirty years – even better just go back five, and see the amount of astronomical change that’s happened in the wonderful world we call IT. I grew up with a Belgium produced DAI INDATA home computer running a whopping 8-bits 8080a processor, and amazing graphics of 512x244 pixels. Sure, I can still buy that computer today, but only from a museum. Gosh how that makes me feel prehistoric!
Some people believe that strategy, vision and mission drive everything, I tend to disagree with them, as in the end it is change – and the changes going on in our minds – that’s fuelling the decisions and ultimately the changes we make. In this article I would like to give you some deeper insight into the world of change, its definitions, its process, its rules, and its peculiarities. I don’t claim to be complete or 100% accurate, but I have all intention to present change to you on a plate called “plain and simple”, and hope some of you will actually read this article compared to most management bibles that people only seem to buy as paperweights. Come on – be honest with me – who has really read all those ITIL volumes back to front? People always give me the phrase “watching paint dry” when referring to ITIL – I guess ITIL’s authors may never learn, but then again, never say never.
The 10 commandments of change management
I’ve always enjoyed throwing people in the deep end of the pool - makes them learn to swim really fast! So, rather than giving you lots of process theory and all this other nonsense and gibberish to start with, I’ll start with the 10 commandments of change management.
- Thou shalt adhere to the rules and guidance of the change management policy
- Thou shalt provide the organisation with enough time to properly assess and plan each change (this time will be agreed for each change category)
- Thou shalt record all change (from miniscule to mega-sized)
- Thou shalt assess each change on added business value (monetary, but also soft factors), on complete lifecycle costs (implementation, maintenance/support, removal/disposal) and on risks (threats and opportunities)
- Thou shalt ask for change authorisation from the appropriate stakeholders and/or committees (the stakeholders/committees stamp)
- Thou shalt approve each change to continue/discontinue in the change management process (the change management process stamp)
- Thou shalt have a remediation/back-out plan in place for each change
- Thou shalt test each change
- Thou shalt review each change against success criteria
- Thou shalt communicate with all applicable stakeholders on the progress of change
Well, there you have it! Stick to these rules and you’ll end up with a more reliable, stable and trustworthy environment, be it IT or any other environment delivering products and/or services. There’s one thing I’ll need to clarify though, and that’s the subtle difference between authorising and approving, something that most change management descriptions don’t seem to talk about.
The change manager – managing the change management process – isn’t God, Allah, Om or Buddha! He or she can’t possible know all the ins and outs of every single change, and can’t possible implement all changes him or herself. In other words: “the change manager (process) doesn’t know anything (or needs to know a lot) and the change manager (process) doesn’t do anything (or needs to do a lot) “, the change manager (process) merely controls and coordinates all change, but if the change manager doesn’t know anything (specific details of a change) then who does? The answer is obvious: The change manager invites those that have enough knowledge on whether or not the change should be implemented or rejected. Those invited will authorise the change on things like financial impact, business impact, technical impact, and will literally be asked to sign their lives away. When the appropriate amount of authorisations from the various areas of business, IT, and suppliers are collected the change manager has only one thing left to do: either approve or reject the change (stamp it, seal it, and mail it). If the change manager can’t approve the change then escalation to more senior management levels needs to kick in, but ultimately the change manager should be able to hold back (defer) changes if he/she feels that the appropriate amount of authorisations and/or information is not yet available or clear.
So, although the change manager (process) doesn’t need to know a lot, and doesn’t seem to do a lot (not physically implements changes – that’s the job of release management), the process is absolutely 100% critical to business and IT success, as it either approves or rejects change, and guarantees (well, at least it’s supposed to) a level of stability within the organisation.
So what is the important message that you should be able to distil from the above text? Well, it’s two things:
- The change manager role is critical to the success of the process.
- The change management process needs to be clear, understood and followed by all involved.
Let’s discuss these two points in the next paragraphs, and hopefully we’ll end up with a better understanding of change management. Get yourself another cup of something stronger than tea, as you’ll probably need it.
Heil our Change Nazi!
It’s always about policies, processes and procedures... Bull, it’s as much about people as it’s about aforementioned documents, and I didn’t even bring up the technology, information, and suppliers part of the equation. Believe it or not, it’s your choice in the end, but the role of the change manager can make or break your business (correct, I didn’t write IT, I wrote business). The power the person that steps into the role of change manager has is enough to start at least 5 Big Bangs, and crunch another 7 Universes. Well, at least, I think that’s how much empowered this person should be.
The change manager is the ultimate gatekeeper of the live, controlled environment (be it an IT infrastructure environment or otherwise (e.g. nuclear power-plant)). If a change doesn’t look kosher in the eyes of the change manager then it simply should not go in! Of course there will be quite a number of rules to decide (read approve, not authorise) whether or not something is actually kosher, and no I’m not Jewish, but it’s such a cool word, just like mazel tov. If I ever find the time, then I’m going to study some etymology, as I keep wondering where all these words originate from.
So, what are the traits of a good (blah-blah efficient, blah-blah effective) change manager? I’ll start a list here, and have all intention to add more to it based on feedback I hope to receive from some of you – the readers. All my articles are actually darticles (dynamic articles) and hence they may change at any time, as new information becomes available. Sorry, I went slightly off track there (a mere 5.21 astronomical units) and we were talking, or at least starting on the topic of traits. Rather than just talking traits let’s become a bit more sophisticated and talk skills, knowledge, and attitude, as really that’s what you’re looking for when trying to fill a certain role. Fasten your seatbelt, take a deep breath, and relax:
Skills:
- Facilitation / hosting meetings
- Documenting / reporting
- Negotiation / conflict resolution
- Interpersonal / communication
- Resource / time management
- Organisation behaviour / leadership
- Administrative / industry specific (high-level)
- Program / project management
- Assessing / distilling information
- Listening / observing
Knowledge:
- Business processes / functions / roles
- IT processes / functions / roles
- IT Service Management processes / functions / roles (high level)
- IT Service Management change management, configuration management and release management (detailed)
- Knowledge management
- Industry specific (e.g. IT) (high level)
- Generic management (including organisational behaviour and cultural change)
- Program /project management
- Logistics and dynamics of hosting meetings
- Politics and power-plays
Attitude:
- Ability / confidence to say no
- Able to separate business and friends
- Objective and unbiased
- Team-player (even better a likable team-player)
- Charismatic, energetic and influential
- Perfectionist and improver
- Chaser of win-win situations
- Honest, reliable and trustworthy
- Motivated to do whatever it takes to keep change under control
- Someone that quickly earns respect within the business and IT
Well, there you have it, a list of 30 skills, knowledge and attitudinal traits you may be looking for when selecting your next change manager. Do you think it’s easy to find a person with all these traits? No way, my friend! By the time you find someone with all these features embedded in their personality they’re likely already president in a country somewhere, or enjoying a tequila at Sunset Boulevard. The only keynote I would like to make here is that it’s probably going to pay off big-time when focussing on those attitudinal factors, rather than skills and knowledge. Skills and knowledge are relatively easy to obtain (test) compared to changing someone’s attitude (observe), which may take more than a lifetime.
Uhm... I only have 350 words left before I hit my own limit for this article, so I guess I may have to chop it into bits. So, let’s hit the accelerator pedal and go turbo-mode. Does anyone remember those old PCs which actually had a turbo-button (I used to have one called a Pony)? Why would you run it in non-turbo mode anyway? Ah well, it looked pretty cool in those days. I would still like a Porsche 911 with “turbo” engine – anyone got a spare one for me?
Goal
A process without goal is like Cher without Sonny, Mickey without Minnie or night without day. I guess the last comparison probably works best. Basically a process is like a big black box, something goes in, and something goes out. Whatever you’re doing in that box, well hopefully, you’re doing it for a good reason, and you should be able to link that reason back to the process goal, otherwise you’re likely wasting your time, your life, and God/Allah/Om/Buddha knows what else! Yeah, I know, I’m only trying to stay fair to all religions (sorry for those I’ve missed).
I believe the goal for the change management process should be something like this:
“To manage all (product and service related) change as to ensure maximum business value, optimised costs, minimized risks, and a level of agreed stability.”
I really don’t know why organisations and people are all clinging, like baby-monkeys cling to the backs/bellies of their mothers, to the goals as defined by ITIL and other frameworks. These goals are not necessarily 100% aligned with your business, and although they are a good start, you should rewrite them until they fit your business, you all understand them, and more importantly, you all believe they are attainable, hence my statement “should be something like this”. Whatever the goal may look like, I sincerely think that “stability” is one of the key reasons why change management has validity for existence in the first place!
“Without a level of change management the world is likely to end up in complete and utter chaos, with change management we get a level of order, visibility and stability.”
Anyway, time to move on, as I’m pretty sure you get the message by now.
Please note that as the author I don’t believe in “pure” stable/static environments, as they stifle innovation, creativity and the very essence of our human imagination.
To be continued...
Live long and prosper
Nanoo... Nanoo...
IsleBeeBach
No comments:
Post a Comment