For those of you that have waited for too long, I am truly sorry, but an eagerly awaited family holiday prevented me from continuing the ITSM passage through the Dante 9 circles of hell. However, as they say, he who waits lingers. Besides, my sons are the biggest inspiration I got so I am pretty sure this, in the end, will mean a much better post. You see, everyone benefits.
Again, just as Dante in the classic 14th-centry poem “Divine Comedy” go through a lot passing the 9 circles of hell, we too have to find our way past many difficulties reaching our objectives when developing our organization. In the first post, we suffered our way through limbo, lust and gluttony. Right now we are going to have to deal with:
- Greed – The 4th circle
- Anger – The 5th circle
- Heresy – The 6th circle
Please let me be your guide through the next three circles of organizational development hell, sit tight, you are in for a rough ride!
One of the key areas for getting ahead in most of your ITSM based processes is sharing knowledge and other forms of collaboration. This means that we have to foster an unselfish strive to always consider the greater good (our client/the users). I do not know about you but I see problems with exactly this in many places. The classical IT hero-culture involves making yourself irreplaceable, important, a key stakeholder just because you know things, if you are not involved in a project or any other endeavor for that matter, it will fail because you have the key information. You are keeping the wealth of your knowledge for yourself, the riches of your experiences, because it means power. The greed for power, for being an important key player is a very serious threat to an efficient ITSM process powered organization. People not sharing, not participating and secretly even trying to make themselves even more irreplaceable are a menace to your ITSM. But this is all very natural, since many seem to think that efficient processes replaces people, makes us like robots, only following instructions, there are no need for skill, experience or personal qualities anymore. People are simply afraid of being unimportant, losing their jobs or turning their jobs into something they would not like.
To battle this knowledge greed, this selfish lack of sharing and unwillingness to collaborate you need to raise awareness of what process really do, and make sure that people understand that even though you have an instruction you still need to be an ace to really nail the task. The processes calibrates us, gives us structure, order and “managebleness” but we still really need good people. Award skill, make personal KPIs and make people really understand that great ITSM delivery is done by people, powered by great process and useful tools.
In many cases, anger involves blame, great frustration and lack/unwillingness to understand things from other perspectives, such as someone else. Anger makes people stupid, make them irrational and steal energy. Sometimes anger needs to be part of the process, the way we change, but it needs to be managed. In early stages of your organizational change journey your organization will actually lower your production, make more errors and in general, things will get worse for a while. Because you are new to something, much like buying a new car always will mean those first bumpy rides before you have mastered this new thing. These initial problems will mean negative attention, blame between units, a lot of frustration and a lot of “us and them”. This whole mess is very contra-productive, causes a lot of stress and steals energy from the change work you are currently doing.
Making sure that everyone involved, including the organization outside the unit changing, for example the business organization outside IT, understand the change process. In short, you need to align the expectations. To gain time you must invest time, this is a universal rule, just make sure that everyone understand and support this, it is really a win-win.
Organizational change takes time. Implementing and/or improving ITSM based processes simply cannot be made over night, it is really a matter of sticking to the plan, doing the slight adjustments, what we ITSM nerds called continuous improvements, but keeping our focus on the plan, what we are trying to achieve. It the beginning of a change journey everyone is aligned, focused and truly believes this is the way to go. However, this will change very soon. Someone will start to talk about that other method framework that seems cool, the new things they heard about and you have a debate on your hands that is not about changing the objectives but rather change the plan or why not switch the tools. A very popular example about this is the rather mindless debate about different types of theoretical frameworks, I see these every day, especially ITIL vs DevOps. I will not even get into how absurd the comparison is and the fact that ITIL is a set of books. People are always looking for shortcuts, if there are simpler ways of reaching their goals. I am a big fan of common sense and of things that works, and of things that are pragmatical – works in reality. I have seen so many frameworks, methods, concepts and other come and go, become popular than fade away, being a buzzword and then forgotten. This steals huge amounts of energy that you should use on making your changes stick, really work. These things are almost like religious debates, which method god to worship and puts way too much effort on things that will not mean attacking your main challenges.
I firmly believe in doing a good plan, make a choice, going for that in short iterations and then simply improve over time. This means doing what I normally call “steal with pride”. Stick with your plan, for example in my case ITSM, but take the things that adds value and include them in your processes. But be true to your choice, trying to break apart your ITSM processes in specialized teams to gain speed in your transition work, to be more agile, is stupid and shortsighted, what you need to do is improve your transition processes and tune you process mechanisms to the demands of the outside world. Nevertheless, you stick with ITSM. Therefore, a short sidetrack, I am sorry but I do not believe DevOps is here to stay, potentially giving us some valuable input to our transition processes.
The third, and final, part in this series will be published later this week, and as always, I really enjoy the discussions, chats, emails and interaction with everyone reading my posts. Please visit my blog on valorizeit.com or follow my tweets @valorizeit.