Developing an IT strategy

One of the first considerations when deciding the contents of a document is, what is it for and who will read it? An IT strategy will be read by people at several different levels in the company, and will serve several purposes. It is a challenge to be able to pitch a strategy at different levels with the right detail at each level. Another challenge is to align the strategy with the Business. An IT strategy should not be about technology but about business enabling technology and this is a two-way street. The business strategy will drive your IT strategy, but IT can also use technology to drive the business strategy.

This sounds like a contradiction, but it is not really. When you see a new technology emerging, think, how can this be used by my business? For example, now that GPS systems are cheap and readily available can these be used to streamline delivery management? Be alert to new technological opportunities by understanding where the bottlenecks are in your business and what slows you down. What can be used as a differentiator to give you an advantage over the competition? What are your customer's problems? Can you use technology to solve them? As part of your communication with the business, consider providing 'Technical Opportunity' documents that describe new technology and how it can be used to drive innovative business strategy.

The other side of the coin is that your business plans will affect your strategy. For example, if your business is planning for a 50% year-on-year growth through acquisition for the next three years, then your IT infrastructure must be flexible enough to cope with that growth. The problem is that if you are a large organisation and request business strategy information from each department you will be inundated with data. The trick is to be able to identify the key business drivers and then determine how they will affect your infrastructure.

The process below was developed when I worked for a large, multi-national finance company. It would make no sense at all to try a process like this if your company is quite small, but it should be easily possible to simplify the process as the basic ideas should work for any company.
Of course, many smaller organisations operate without an IT strategy. However this means that investment decisions about IT are made piecemeal and just for one part of the company. This will be expensive in the long run. IT should be a powerful resource to ensure a company meets its aspirations, whatever its size. A clear IT strategy will help enables an organisation to do just that.

Business input

One way to do involve the business directly is to develop a questionnaire that asks each business unit the right questions that can be used to forecast infrastructure growth. However the questionnaire needs to be couched in business terms, not IT terms. This means you avoid questions like 'How many Gigabytes of storage do you expect to use next year?' ' or 'What average IO response time do you expect from your disk subsystems, to the nearest millisecond?' Questions like 'Your department currently uses the ten applications listed below, do you expect your usage to remain constant, increase by x% or ..?'.
If your organisation has Service Managers, people who liaise between IT and different business departments, then they will be ideally placed to get this information for you.

Operation Control Areas (OCAs)

An IT strategy will be complex, and a rule I learned years ago for dealing with complexity is

  • When faced with a large monolith, break it down into smaller, more manageable entities
  • When faced with lots of small entities, look for common factors and combine them into fewer, larger entities.

The point here is that an IT strategy should consist of a number of areas that I will call ' 'Operational Control Areas' or OCAs and these will typically describe a major service delivery item. How many OCAs should you have and what should they be? I suggest between ten and fifteen as this breaks down the single IT strategy monolith and yet is not too many to be overly complex. I offer the following list of twelve as a suggestion. When building your own list, bear in mind that each OCA must have an owner.

Application Development / Application Support / Network / Voice / Desktop / Mobility / Server / Storage / Database / Security / Collaboration / Help Desk

Developing the Strategy

In the Business Input section I suggested a directed questionnaire. The responses from the questionnaires should be analysed to determine the impact of business directions on each OCA. Based on this feedback, each OCA Owner (FSO) should prepare a prototype strategy document which describes the current position, any problems with that position, how business drivers and technology trends will affect that OCA, and a roadmap that describes how that OCA will move forward over the next three years. This document should be at a high enough level that it can fit onto one page of A4 paper (or US letter size in North America) as shown in the example below.

Company Name OCA title Author / owner
Current position Technology trends Future vision
The status of this OCA right now, with an outline of supported technologies and infrastructure. These outline statements will link to more detailed statements for those who need more data A description of current and emerging technologies, along with how they can be used to provide business differentiation, gap resolution or support business plans. This is an overview of the end vision, where you expect this OCA to be in three-five years time. The overview should be linked to detailed supporting information.
Known issues Business opportunities Three year plan
A description of any problems and capability gaps or areas that could be improved A summary of the key business plans and directions as they apply to this OCA. Typical examples would be cost efficiency or planned growth activity. An itemised list of the activities that need to happen over the next three years to achieve the vision above.

The FSOs should then get together and validate these prototypes against each other, to ensure that they fit together into a single coherent IT strategy and to ensure that the road maps make sense in terms of interdependencies between OCAs. The result will be a coherent, high level IT strategy and road map. This coherent 12-15 page document ensures that the business get a consistent view of the long-term IT strategy at a high level, not at the individual technology silo level. This document, though still in a prototype state, will start to flesh out an IT wide programme of work, and will be high visibility, used for IT/business discussion for prioritisation of work and budgets.

The next stage is to carry out a Stakeholder review, where business representatives can suggest revisions to policy and accept or reject technology opportunities. This could be an executive level planning meeting, or the review could be carried out electronically. Note that this is a deviation from a standard business planning process, as technology opportunities are being introduced at the early stages of strategic business planning.

Once the high-level strategy has been reviewed, amended, prioritised and authorised a programme of work can be fleshed out. If an innovative technology idea has been accepted, you may want to form a separate, multi-disciplinary programme team for that implementation, to allow the right mix between business market awareness and technical knowledge to combine to seek the optimum solution.

Now the outline strategies are finalised, it will be possible to expand them out for each OCA to the level of detail required by the functional areas. If you maintain a Service Catalogue that includes pricing for each service, this is the time to update it with new services and new prices. This is the part that meets the first challenge described above, where we need different levels of detail for different audiences. The documents should be hierarchical, with the ability to drill down to lower levels as more detail is required. One way to present this, is to write the documents using MS-WORD, but save them in HTML format. This puts the presentation in read-only format, and makes it easy to link between documents.

Review Cycle

Traditionally, strategies are updated and communicated annually, usually to meet budget cycles. This should be considered the minimum review period. If an emerging technology surfaces that has the potential to enhance the business, it should be investigated and communicated to the business quickly, as we live in times of rapid change and a one-year cycle can be too late. The business that comes in first with a new idea will make the most money.