The question I have often been asked is why bother writing an IT strategy as the industry moves too fast, it is difficult to plan beyond three years and the document is normally out of date before it is printed off for proof reading.

I normally start by asking a similar question back, why bother writing a business strategy as the problems are very similar. At this point people normally start to make their arguments for the case of the business plan and to be honest the arguments are almost always valid and poignant. Once they have finished I will then say the same or similar arguments can be made for the IT Strategy.

I have worked at organisations where the business strategy has teams of people working on it or updating and ensuring that the business is underpinning the goals and objectives, yet they have no IT Strategy at all.

Conversely I have worked at organisation where there is a well-documented IT strategy but it does not reflect or underpin the business goals and objectives, leaving it isolated and inept. Even where there is a business and IT strategy that has been written to reflect the business goals and objectives it has often been created for other purposes, for example: to get additional funding or to float the company, to appease a corporate auditor or to show to the board of directors as a tick in the box.

Deriving business benefit

Rarely is it used to derive business benefits and to ensure that IT is underpinning the business goals and objectives in line with the business strategy.

So why is there such problem and why is this document so undervalued? I don’t think there is one simple answer to this question; I think it is a combination of issues. IT People normally appreciate the need for documentation but are often not aligned with the business and possibly don’t understand or acknowledge the business drivers.

I have often heard the IT strategy, referred to as a pointless exercise that has little value and is out of date as soon as it is written by both the business and IT people involved. Yet it does not need to be this way. The IT strategy has as much to offer the business, as the business strategy and if written in conjunction with and underpinning the business strategy it can be a business enabler, ensuring that the IT deliverables are in line with the business requirements and expectations.

Defining the requirements

As an IT manager I have fairly simple requirements: let me know what you want and when you want it. Let me know the budget and any other requirements and I will go away and make it work. Sounds simple and I think I am fairly typical in IT, tell me what you want give me the tools and I will try to deliver.

Unfortunately, often it becomes far more complex and both expectations and deliverables are not in touch with reality or with each other. I have been in to many organisations to assist and the first thing I do is sit down separately with the IT management and the business management to try and see what their requirements are and to try to gauge how joined up and in tune both parties really are.

The results do not make good reading. There is often a miss match or disjointed view on both sides. So what can be done to change this and to make the IT strategy really reflect the business needs.

Well as always there is no golden rule or easy fix. It very much depends on the willingness of both the business and IT to embrace and work together towards the goals. This is not something the business can simply say is an IT issue, equally IT cannot say leave it to us we will create one that works.

Create a living document

Once there is an agreed desire to create this document the first tip I would give is make it a living document. Historically we have used a single document that is almost a list starting out at what we want now and moving on to fill in the three or five year plan.

I take a very different approach, the first thing we do, is look at the business strategy and the business requirements. We use this to work backwards ensuring that the requirements and budget are clearly defined at each stage of the strategy.

Once this is defined, we start to create the documentation, unlike other strategy documents I use a core set of agreed locked in stone requirements. To this I add all the peripheral information like the executive summary, the introduction and all the scene setting components.

Once these are in place I start to build the details into the strategy but we keep this flexible by the use of place holders in the main document. Each of the placeholders will have an introduction and a link to the document that underpins the particular element covered.

Depending how the business strategy is defined – time or requirements – will dictate how the rest of the IT strategy is structured. If this is a five year strategy based on five years business requirements, each year will have its’ own section which is built up to show how it underpins and reflects the business goals and objectives.

Flexibility

Each year will start by clearly setting the agenda for the year; it will lay out the principles and the limits. This will be more clearly defined in the first years, becoming more abstract as the years go on, a good tip: IT changes quickly by year three, it is unlikely that the requirements agreed today will still all be valid. To get around this issue we set loosely agreed targets that work in conjunction with the business goals and this is reviewed and changed year on year.

I have even had occasions where the first year, has needed to change due to changing business requirements that were not originally known or defined and it is for this very reason why we keep the strategy flexible. It needs to be a living, developing document that really does meet and underpin the organisations goals and objectives.

At its heart it needs to enable the business to understand the time it will take to deliver on the business goals and objectives along with the costs. It needs to clearly show the risks and issues associated so that an informed decision can be made and most of all it needs to look at the impact of the change.

The impact of change is more often than not over looked or not even considered. Yet it is a fact that people on a whole are naturally change adverse, if the effect of any change is not correctly communicated the impact could have profound consequences.

Using linkage

Whilst the business is only really interested in the cost, the impact, the time and disruption of the changes; as a strategy we need to layer on the detail. It is here where the document uses the process of linking detail.

Linking detail is a term I use on a regular basis and all this means in real terms is that we use a mechanism – in the old days hyperlinks to other documents, but more and more often we are changing to WIKI or SharePoint type document repositories that allow version control and links – to control and link detail to the main document.

Using linking means that as the requirements change or the goals and objectives become clearer, the strategy can be easily updated to reflect the new or refined requirements. The strategy grows and evolves and I have had customers who have effectively created a five year rolling process that develops and changes in line with the business.

Define checkpoints

My last tip in this article is to have clearly defined checkpoints, using the yearly approach it is quite easy but using some of the other methodologies clearly defined checkpoints may not as obvious. Ensure that there is a clear mandate for the strategy and that this is communicated to the business and IT, so that people engage and buy into the goals and objectives.

Don’t assume that people will want to embrace something new, just because you can see the benefit doesn’t mean that others will. Once you have the strategy defined and you are happy with the content and layouts, don’t just put it on the shelf to be dusted once a year.

This is a living document that needs to be reviewed and amended as the business and IT changes and adapts, to meet your customers’ needs.