Beware the Sirens of IT transformation

I have been writing a series of posts about implementing an operating model for IT which is based upon services. If you followed the last post you will have already started to engage your key stakeholders and they will already be thinking about their IT needs and their role in making the IT ecosystem work. Now you will be looking for advice on how to map out the value chains for the new IT model.

The next post will go into more detail on how to use value chains and provide some examples but first I thought I should share a few warnings. We are about to enter what is probably the most dangerous part of the journey where unwary CIOs could be lured off course and face disaster. Take a look and let me know what you think.

Concepts and complexity

In any enterprise the IT ecosystem will be large and complex. The chains of value which run through IT will begin in some commodity manufacturer across the other side of the world and extend through the enterprise and on to the customer of the enterprise (and maybe their customers too). It will be impossible to deal with all of the breadth and details of the ecosystem at once. You will not be able to avoid using concepts and models to bridge the gap and help make sure that, when you do get into the details of a particular service, the whole ecosystem will still join up.

Fortunately the IT community are likely to be reasonably well qualified to work with models and concepts - please use them. Models that are used for benefits mapping, process modelling, organisation design and systems engineering are all intended to help manage this kind of complexity. Most will also support a degree of “testing” so that you and your key stakeholders can exercise the concepts and get early insights into how they will work in practice. This ability to “test” is one of the features which distinguishes a “model” from a “diagram” and it is a vital tool during this stage of the IT transformation process.

Labels and language

The IT market place can be a bit like “Alice in Wonderland”. How about this quote?

“When I use a word,” Humpty Dumpty said in rather a scornful tone, “it means just what I choose it to mean - neither more nor less.”

Pick three words from the subject of this post - value, service and IT - and you could fill a book with the different interpretations. This is not just a challenge to communication it is also a barrier to change as our thinking is shaped by language.

To be most effective an IT transformation needs to address the whole IT ecosystem - the complete chain of value from source to consumption - a much wider scope than most people will associate with IT. Stakeholders who commission and consume IT services need to understand that they will feel the impact of the changes and will need to adapt and support them. IT specialists need to be reminded that they cannot retreat into a silo, fine tune internal IT operations and ignore the impact they have on others. Everyone needs to understand that IT is just a convenient label that has evolved along with the enterprise over a number of years. Through the transformation this label may be re-assigned or abandoned.

Don’t be surprised at how durable these labels are and how hard it will be for stakeholders to let go of the assumptions that support them. You will need to provide both challenge and support to help stakeholders as they change their thinking.

Leadership, control and decision making

Mapping out the IT value chain will involve making choices. There will be some cosmetic choices about how to represent the IT value chain but ultimately there will be some fundamental choices about which options are implemented. Who will make these decisions? Since we are discussing IT transformation, most people will assume it will be the CIO. You need to avoid falling into this trap.

The IT ecosystem depends upon the support and cooperation of all parts of the value chain. This is unlikely to be achieved if the CIO attempts to dictate how things will work. This is true even if executive peers encourage the CIO to take control as IT is “not their thing”. Similarly, in certain parts of the IT services market place, suppliers will aggressively qualify opportunities and may not participate if the characteristics are not right - leaving a gaping hole in an otherwise excellent design for IT.

The appraisal of options needs to take account of the willingness of key stakeholders to participate and provide support. Instead of aiming for control, the CIO should strive for good governance and well informed decisions. If you are looking for more detail on this area in particular try Steven Romero’s blog.

Short-term and long-term service

You would have thought that it would be obvious that normal business cannot be put on hold while considering how IT should work in future and, when pressed, most people will accept this. Unfortunately, IT transformation is intellectually and emotionally demanding. It is all too easy for people to become consumed by the challenges of how to optimise IT in the future and neglect the vital work of maintaining current levels of service and fending off daily issues.

There are many articles written about how CIOs should put routine concerns to one side and focus on strategy but don’t be seduced by these. Your executive peers will only allow you to spend effort on IT transformation because the current services are under control and performing reasonably well. They will only tolerate a limited degree of disruption during the transition to a new IT operating model because they trust your ability to deliver better services in future. I am using phrases like “allow” and “tolerate” deliberately. If you think, as a CIO, that you are in complete charge of your own priorities just let day-to-day IT services deteriorate for a while. You will find that your ability to influence the future of IT will rapidly evaporate.

Elegance and execution

Another apparently obvious factor which can get lost in the excitement of developing the IT model is that an elegant conceptual model is useless if it remains on paper.

Translating the model into reality will involve all sorts of compromises and there is no benefit is trying to avoid or postpone these. Using the powerful modelling techniques that we discussed earlier will prove to be a valuable investment as they will provide a strong foundation for making practical trade-offs during the implementation and transition.

Also, don’t neglect basic good practice in project and change management. Break the change up into manageable chunks to front load benefits and reduce risk. It will be much better to successfully implement the key changes that deliver 80% of the benefits than stake everything on achieving the complete, conceptually elegant solution.