www.rudeandersen.com   •   lars@rudeandersen.com   •   +45 5070 0070




Lars R. Andersen


Freelance CIO/CTO  •  Management consultant  •  Project manager  •  IT architect


  • Flexible, hands-on, experienced and cost-effictive support.
  • Specific competences within IT management and mobile networks
  • Selected experience available in free white papers


Please note that the information here contains my personal viewpoints and not those of any present or previous employer



IT strategy


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:

  • Overview of all systems – including those that are procured outside the IT department.
  • An application architecture, mapping the systems to a functional support. Preferably, the map should be a recognized structure for the business at hand – like TAM for Telecommunications.
  • Overview of functional abilities: how well does the current systems support the business at hand, identifying any obvious opportunities for improvement etc. This can verify, invalidate or augment the key pain points identified previously.
  • Operations: how are the systems operated, how well does it function, how is it sourced.
  • Financials: what are the costs directly associated with IT, preferable including costs of systems procured outside the IT department. If possible, a benchmark of the costs against similar business if such is available.
  • Overview of how sourcing is done and why.


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.




Process supportProvide assistance on methodology, data collection templates, staffing, duration etc.
Project managementEnsure progress of the process.
ArchitectApplication and enterprise architecture experience.
PresentationManagement level presentation of findings, progress, issues, challenges and choices.


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.