Order from chaos

Reposted, original on the “IT Governance, the Kapteyn’s view” blog on Computerworld UK in March 2010

When you listen to organizational, process or governance experts or to IT architects for that matter, you hear statements like “We need to design the process”, “We need to implement control” or “We need to organize governance”. The common undertone is that they need to create order from chaos. An important deliverable to achieve this goal is formalization. In turn this implies that informal equals chaos. We describe how the organization, process and/ or control is supposed to work. And too often you will find that people think that if you commit something to paper that will make it so.

The more advanced students in change management know that the design of the target situation is only step one. Actually changing the organization so the day-to-day practices are aligned with the (paper) design is a whole different ball game. Indeed implementation of organizational changes is an expert discipline in itself. At one time I walked into an organization that supposedly had adopted ITIL a couple of years before. When I spend some time as a passive observer of the practices on the work floor it was all but impossible for me to recognize the ITIL best practices in their daily activities. So I checked with somebody who was clearly doing very useful things but in an organizational manner that was definitely not advocated by ITIL (I will leave it to your imagination to think of an example of what was happening). When I asked him about the ITIL adoption he recollected the project involving busloads of external consultants who kept themselves and everybody else busy for a while. But that project was finished a couple of years ago, they were now an ITIL based organization. When I asked him for the deliverables of the project he showed me a bookshelf and immediately I felt at home. Documentation with familiar process names like Incident Management, Change Management were nicely printed in color. Per process the documentation was at least 50 pages covering each and every possible detail of a possible ITIL implementation. And no, these were not the ITIL books! The documentation contained company logo’s every other page to proof they were company specific. Furthermore when I read the documents every now and then I could find references to the actual company culture and adjustments to fit the specific user organization. But by all means, not too much, this was a vanilla implementation of ITIL. What disturbed me though was the layer of dust covering the bookshelf and all of these pearls of wisdom they contained. When I decided to turn on the thumbscrews a little with my conversation partner he admitted that it could easily be that these documents had never left the bookshelf after the last project consultant put it there. This example shows you what is likely to happen if you forget to implement what you design. You probably think this is highly exaggerated to make a point. This extreme could not happen in real live, could it? The thing is, if you spend more than one and a half decade looking in company kitchens because you are asked to help them improve you get to see things, some of those hard to believe. Believe it or not, I hope the underpinning message is clear for you.

Having learned from this experience we improved the situation. Internal employees got involved with the design of the operational model, they got trained on the outcome became familiar with the documentation content and felt at ease with it. The project however not only had implementation as the primary driver. No, we wanted to integrate control into the operational model. So the CobiT books came on the table and after extensive discussion with stakeholders we decided what the relevant controls were and how they integrated into the process framework. Business-IT Alignment, control design and/or how we decided what the relevant controls were are not the topic of this article but it is fair to say that it was not as easy as this one sentence suggests. The point is that we decided, designed, agreed, described, implemented and all those other nice things we as consultants do. Furthermore we created our deliverables got them accepted by both management and those who should work with the deliverables we finished the project. And while the internal employees waived on the parking lot with tears in their eyes (It could happen could it not?) we drove into the sun-set feeling real good about ourselves. We delivered! The bookshelf was now a documentation room containing a company specific operating model integrating the best of both ITIL and CobiT, covering both process and control. The detail level approximated the level you would expect for an airplane maintenance manual. No aspect was left un-described! Since the success of an organizational consultancy project is supposedly described in the number of pages delivered by the project this project was a huge success: On average more than 150 pages of documentation per process, as mentioned, all discussed, accepted and implemented by the clients IT organization!

Fast-forward, a couple of months , the phone rang. The customer organization had a problem; they were failing control audits left and right. A lot of disagreement of what was done, how it should be done and overall complete inefficiency of the IT Department. On arrival the first observation was that the operational process/ control handbooks had somehow turned into law-books. The world had changed since the project had ended. However since the content of the handbooks had not magically adjusted to fit the new requirements the described operational model and organization were less than perfect for the new environment. Besides since the end of the project those on the work floor had found things that could be improved and even flaws in the designs. Till date I cannot understand how that is possible, external consultants make perfect assessments of the situation and design perfect solutions that are impossible to improve based on real live experience and that are 100% change and future proof, right? Maybe it was because I did not have as much experience then as I have today; that might be why I did not reach that level of perfection in the deliverables. Since those days however I got certified as the wizard of Oz so today…… Anyway, back to the story. IT management had suggested that there was this thing called continues improvement so maybe it was OK to improve the models based on experience and changes in the environment. This suggestion had been met with disbelieve by both audit and the business. After so much time had been spend designing the operational and control model to fit the business requirements they had found this offered an excellent measuring stick to measure actual performance of the IT department against desired performance. Trying to change the model was like trying to change the metric system, you don’t do that! The metric system offers one of a few constants in an ever changing world. Change it and people will lose their last life-line and drown. That agility had been replaced by bureaucracy in the process was initially overlooked. After much debate all involved eventually agreed that continues improvement was a good concept and that higher-level maturity thinking suggests that you pro-actively improve your processes over time to ensure alignment with an ever changing environment. Somebody even managed to argue that the organization was ISO 9000 certified and that one of the core ideas of this standard is that you try to improve quality over time by fine-tuning your operating model based on experience (a concept so out of this world that it can only work on the Starship Enterprise, according to some). Still at the end of all this debate there you have it, the goal of my new project: Create an organization that manages the operating model over time to ensure continues alignment with the ever changing environment and that is capable of learning and improving based on real-live experiences.

This brings us to the first point of this article: If you formally describe something not only do you need to ensure that it is implemented but also that it is actively managed and maintained during operational use. Things change over time, words on paper don’t! The second point for consideration is that the more you formally describe the more you have to manage. Management costs resources. Actively reading the formal description, managing suggestions for change, adjusting the system based on accepted changes, all of this is time and resource consuming. Think of 20+ processes documented with an average of 150 pages per process just reading all that stuff takes days. Managing something like that is not something you do in between, at least not if you take agility and continues improvement serious.

The reason to formally describe is to mitigate all kinds of risks. The risk of confusion because of differences in interpretation, the risk of inefficiency because lessons learned are not universally applied. Compliance Risks because the organization cannot proof they operate in a compliant manner. Business Continuity Risks because vital knowledge is not formally managed but informally kept in the minds of individual employees. Almost all of the negative (and positive) reasons for having an informal organization can be translated in the form of risks. The nice thing about risk is that once identified you normally think about the possible impacts (good or bad) for the organization. As we have seen there is a cost tag attached to formalization not just one time project cost to describe and implement but also continues running cost for operational management. The more detail you want the higher the cost! When we think in terms of risks and organizational risk appetite we can identify were we want to mitigate and how to balance cost of mitigation against the risk reduction achieved. Very often the end-result is that people realize that there is something to be said for a (more) informal organization and that informal is not always equivalent to chaos.