I’ve certainly experienced this myself and this is my take on the 6 most common reasons that I’ve seen why IT strategies fail:
Technology First
Let’s face it; people generally go into IT because they are interested in technology. There is nothing wrong with that: IT needs good technologists. Also, a good IT strategy is all about how to apply technology to the needs of an organisation. However, the trap here is that sometimes, rather than focussing first on the needs of the organisation, IT strategies start with technology and then look for the problems the technology can solve. With this approach, what you almost inevitably end up with, is solutions looking for problems and a consequent loss of credibility of the strategy with the users of IT.
In my experience, the very best solution to this is for IT to be involved right at the start, in the development of the organisational strategy. That way, technology and the potential value it can bring to the organisation can be fed in when the whole strategy process begins, with the IT strategy then building on that by articulating in more detail how the technology enabled initiatives identified in the overall organisational strategy will be supported. This is not always possible of course; getting a seat at the strategy top table is a deeply political issue in many organisations and IT is often excluded, in which you just has to work with what you have been given. Even in those cases, however, anyone developing an IT strategy should always start with the defined needs of the organisation not with technology.
Ivory Tower
For a strategy to be successful it must have buy in, and to get this, the people issues have to be addressed. Unfortunately, however, people aren’t always logical about these things; they have subjective views, hidden agendas and are very often uncomfortable with change. Also, dealing with soft, people focussed issues, is a notorious black spot for many IT professionals.
Nevertheless, my experience is that it is always better to develop a strategy using, to some extent at least, a collaborative process. Find out who your stakeholders and opinion leaders are. Engage with them. Work with them and let them have their say. This is not to say that you have to agree with them or do what they tell you, but even individuals who don’t entirely agree with what comes of the process are far more likely to at least not actively resist it if they feel that their views have been listened to, acknowledged and understood.
Strategies developed by an “expert” in a so called ivory tower might be perfectly logical to that individual, but getting broad acceptance and buy in from everyone else is always going to be an uphill struggle.
The invisible sponsor
This is a particularly tough one to manage. Strategy is all about leadership and for that reason it is my opinion that strategy should always be very high, if not top, on the priority list of any CIO. The CIO, therefore, should always be the direct sponsor of the IT Strategy, should be actively involved throughout the process of developing the strategy and, in particular, should be highly visible as the owner of the strategy when it is rolled out. The problem is, however, that many CIOs reach that position because of a very strong record in operations or projects and strategy can fall outside their comfort zone. Consequently, whilst many rise to the challenge and CIOs cannot, of course, ignore non-strategy topics, there this always a temptation for CIO’s to over- involve themselves in issues in the areas that they are most comfortable with and distance themselves from the topic of strategy preferring to leave this to the “expert”.
Addressing this is difficult as it involves managing upwards. A good start is to make it clear in the terms on reference for any strategy work that regular and direct access to the CIO throughout the activity of developing the strategy is essential and continually push to ensure that he or she stays engaged. This is not always easy; CIOs are of course inevitably busy people and other topics will always compete for their time, but without that visible engagement and commitment it will be very hard to get the strategy accepted and properly bought into both within the IT organisation and with the senior stakeholders outside of IT.
The never ending project
Whilst one can, in some ways, view the process of creating a strategy as a project, there are some important issues with this. In particular, predicting how long will be needed to complete the work can be very difficult to judge. Asking how long developing a strategy should take is often a bit of a “how long is a piece of string?” question. Naturally one can give a view based on previous experience, but any timetable is likely to be significantly impacted by, firstly, the issues encountered as you go through the process and, secondly, the expectations of the sponsor and the main stakeholders, neither of which can always be clearly predicted at the start. A lot of this comes down to organisational culture: some organisations favour short, high level documents, others expect lots of detail.
The risk here, however, is that one ends up carrying on for ever and ever going into more and more detail and never actually reaching a conclusion. Strategies suffering from weak sponsorship (see previous point) can be particularly prone to this. The truth is that there is always something one can look at in more detail and so at some point you have to make a judgement on whether you have reached the point of diminishing returns and ask the question: will doing more work materially improve the quality of the outcome? For what it’s worth, my recommendation is to spend less time creating an outline of the strategy and more time collaboratively reviewing, refining and selling what you have created. For me, a strategy is far more likely to be successful if the messages coming out of it are concise, clear and relevant and surrounding them in lots of detail only tends to confuse. Keep it short and high level and leave the creation of the detail until the big picture is clear.
All things to all men
Lots of otherwise perfectly good strategies fail on one thing: the “so what?” test. They are clear, concise and well-presented but they fail because they are just too bland. The risk in strategy development is ending up with a strategy that always takes the middle ground, offends no-one and as a result says nothing new. This is once again, very much a judgement call and the situation of the organisation has to be taken in account; for example, an organisation that is still adjusting following a period of radical change is unlikely to benefit from a strategy that recommends more radical change but, to be really compelling and motivating, a strategy should be hotly debated by the main stakeholders and the outcome should be achievable but challenging and thought provoking.
Forgot about implementation
I won’t go into detail on this because I covered it in a previous blog post. Suffice to say that many otherwise perfectly good strategies end up a shelf-ware because, having put a lot of effort into creating them, organisations didn’t put the structures in place to ensure that they were actually implemented.
So, that’s my thoughts on what can go wrong in strategy development, but do you agree? Have you experienced other mistakes and if so what are they. I’d be really interested to learn about your experiences.
