Technology strategy

A technology strategy is a written direction for the company's systems over several years: which stay, which are replaced, in what order, what the company does itself and what it buys. We set the horizon with the board. The starting point is the business goals the board already has: a new market, more orders with the same team, a merger of companies. We translate them into requirements for the systems: what the systems must be able to do by the end of the period for the goal to be achievable.

Against that background every system gets a decision. It stays, because it carries a process the goals do not change. It stays after changes, because the limitation can be removed more cheaply than the system can be replaced. It is replaced, because it blocks a goal or the supplier is ending support. It is retired, because it duplicates another. A review of each system from the inside is a separate scope; the strategy uses its results or a description at the level the board needs.

We put the decisions in order. Replacing a system that feeds others comes before them. A change that needs people from the previous implementation waits until that implementation ends. Contractors call the picture of the systems at the end of the period the target architecture and the order of steps a roadmap; in the strategy we describe both in plain terms. A detailed plan for a single implementation and a feasibility study of a single undertaking, a check of whether it can be done and at what cost, are separate scopes.

The third part is the division of work. With its own people the company does what gives it an edge or concerns data it does not want to take outside. It buys a ready-made subscription service where one exists and is enough. It commissions a build when nothing ready-made exists. This division tells the board whom to hire and what contracts to look for.

The result is a document the board uses to steer the budget: every IT expense either has its place in the strategy or does not, and the lack of a place is a signal to ask questions.

1. We set the goals and the horizon with the board. We discuss where the company wants to be in a few years and what has to change in how it works. Outcome: a list of goals translated into requirements for the systems, for your approval.
2. We describe the systems in the board's language. For each: what process it carries, what it costs a year in licences, maintenance and people, and what limits it with respect to the goals. Outcome: a list of systems with cost and limitation.
3. We take the decisions in a workshop with the board. Every system gets a decision, every change a place in the order, every piece of work an assignment: do it ourselves, buy, commission. Outcome: a draft strategy with justifications for discussion.
4. We write up the strategy and the steering rules. The document is given a form the board can read without the IT department, together with instructions for using it when setting the budget. Outcome: a strategy ready for the board to adopt as the basis of the budget.

1. Which business goal does each decision about a system follow from, and where can we see that in the document?
2. Which systems stay, which do we replace, and what happens if we postpone a replacement by a year?
3. In what order should the changes go, and which of them blocks the others?
4. What should the company do itself, what should it buy and what should it commission, and by what criterion was this divided?
5. How is the board to use this document when setting next year's budget without the IT department at the table?
6. Does the strategy contractor earn from the implementations it recommends, and how does it separate advice from sales?
7. When does the strategy need a review, and who on our side should lead it?

A direction for several years makes sense only against what holds the company back today, so the first step is an analysis of the process and systems, and the strategy grows out of its results.