Lars R. Andersen
Freelance CIO/CTO • Management consultant • Project manager • IT architect
Note that the information here contains my person viewpoints and not those of any present or previous employer and is not updated with latest employment history
Building an IT strategy is the process of making a direction and plan for the IT applications of a company, division etc. that ensures support for the business strategy. The steps contained in a generic IT strategy process looks as follows:
Briefly, the steps are as follows.
Mobilise sets up the project. The approach, scope, timeline and organisation is agreed. The scope can be all applications or a subset – e.g. operations. Typically, the organisation is a small group of people with anchored in a steering group consisting of the business owners.
In case the strategy works within IT, e.g. operations, the typical steering group would be comprised of IT management and the working group also from IT. In case the strategy comprises business applications, the steering group should contain representatives of the relevant business area as well as IT and the working group be comprised similarly.
The magnitude of the project depends a lot on the scope. Including everything from support of the entire business over sourcing and operations to the procurement of desktops will make the project very large and potentially defocused. If all these areas are pain points, it should be considered sequencing the discussions with the most business oriented first.
Business strategy has the purpose of ensuring alignment with the business strategy. Again, it can be the “business of IT”, e.g. operations, or it can be the business proper, i.e. the application support.
Alignment is ensured by understanding the business purpose. The team should be set up to have this insight already, but articulating the strategy to a point where it is pertinent to the IT strategy is frequently a challenge. For organisations that depend heavily on IT like financial and telecommunication services, the core part of the IT strategy should ideally be developed as an integral part of the business strategy. This will be visible if the IT strategy starts having questions like “if the business wants A then … but if the business wants B then …” and not getting clear answers from its steering group.
Also, understanding the current support of the business and the key pain points, typically the reason for starting the IT strategy work at all, should be clearly understood and validated with the steering group.
Current status ensures that a jointly understood and accepted status on the current situation is document. The information is normally available in the organisation, but normally not in a form where it is directly applicable for the IT strategy work.
The current status comprises at least the following:
Options is the phase where the basis for the strategy is formed. From the input gathered, various options are considered and the implications analysed. The analysis can require revisit to previous phases and this is often where the questions on the intended direction of the business emerges.
Looking for inspiration through “best practices” can be an important part of this phase, depending upon how open the discussion is and how well the team finds it understands the trends in IT technology and business.
With “digitalisation” being a buzzword of the day and therefore one that eludes specific definitions, it is important to understand what it implies in terms of IT strategy. It can range from integrating channels, integrating partners to redefining and simplifying the offerings in a “digital” way. If this is a big open question, the right place to solve it is a business strategy, not an IT strategy.
Other important current topics include use of cloud applications (which have a number of advantages but also challenges; the latter made more difficult by the arrogance of many cloud vendors) and cross-border or cross-business-unit IT (which virtually never works if IT is used as the vehicle for achieving synergies).
There are a large number of practices of what makes sense to do, both generic and (normally) business specific. In spite of this, the phase of options and the subsequent phase of formulating the strategy, there does exist an element of “leap of faith”, in particular when moving outside the beaten track of mainstream applications. The reason is that in some areas, the option space is so wide that a full analysis is not in practice possible. The important thing, of course, is to agree where to put the effort of analysis and where the 80% choice is good enough.
Strategy is the phase of formulating the chosen option into a specific direction in terms of application architecture, financial targets, sourcing direction as well as documenting the likely implications.
An important discussion as part of the option discussion and strategy formulation is to which extend the IT strategy sets a transformational approach, replacing major applications, or a more evolutionary approach with updates and augmentation to existing applications. For further discussion of this see the separate IT Transformation page.
Apart from the application plan, an IT strategy also contains direction and plan for operations and sourcing and, of course, estimated financial implications of the plan.
Plan is the phase of mapping out the IT strategy into a plan for the area at hand: applications, operations, desktops, mobility, whatever. As an IT strategy normally is developed at comparatively high level to agree on overall direction, the plan is correspondingly high-level. It should, however, comprise the main activities required as well as an indication of realistic time frames and realistic level of parallel execution of proposed activities.
Experience and offerings
Through running IT strategy processes a number of times in different businesses, I have extensive experience that can be leveraged with an internal team to provide a cost-efficient, focused process, following the general process outlined above.
I recommend having permanent staff on most key positions, not just in steering or reference groups. A team with strong external bias runs the risk of producing overly optimistic plans.
A team made of mainly of internal staff tends to come up with plans that are realistic in terms of scope or time, and anchored enough to go through the subsequent decision making process. A combination leaning towards the internal staff will, in my experience, provide the best balance.