Every company that plans anything plans the business three to five years out. Where it wants to be, what it wants to earn, which markets it wants to open, how many people it will hire. That is written down, reviewed every year, and someone answers for it.

Ask about IT over the same horizon and the temperature of the conversation changes. There is a budget for next year — sometimes for next quarter. There is a list of approved projects. But a three-to-five-year plan, with the same discipline as the business plan, almost never exists.

It is a strange asymmetry, because IT is what executes the business plan. And it is that asymmetry that turns the function into permanent reaction.

The symptom everyone recognises

The symptom is not a lack of work. It is the kind of work.

The function lives on demand that arrives fully formed: sales closed with a client who requires an integration; legal needs an answer to a new regulation; the board bought a company and now there are two ERPs. Each of those is legitimate. The problem is that all of them arrive as accomplished fact, on a deadline set by someone else.

When that is the routine, three things follow in sequence. The function loses the ability to say no, because it has no plan to weigh the request against. It starts always choosing the fastest solution, which is almost never the cheapest overall. And it accumulates a debt nobody contracted, but everybody pays for later.

The name of that debt varies — a system nobody knows how to maintain, a rushed integration that became a dependency, a server that cannot be switched off because nobody knows what runs on it. The origin is always the same: a decision taken on someone else’s deadline, with no place in a plan.

Why IT is not planned over the same horizon

It is not negligence. There are reasons, and they are worth understanding before proposing anything.

Technology seems to move too fast to plan for. That is the most common argument, and it is half true. Tools move fast; capabilities move slowly. “Close exposure on a short clock” and “have data you can trust to decide with” will still hold five years from now, whatever product happens to be fashionable.

The budget is annual, so the thinking becomes annual. The financial cycle shapes the mental horizon. Except the business plan also lives with an annual budget and is multi-year all the same.

There is no shared language. A business plan talks about market, revenue and margin. An IT plan tends to arrive as product names and version numbers. A board cannot prioritise between two things it does not understand, and what does not get prioritised becomes a queue in order of arrival.

Nobody asks for it. There is no board asking for the five-year IT plan. Until it is missed, it does not appear.

The question that organises everything

Before methodology, a question. When someone asks for a system, the useful answer is not which system — it is what for.

“I need a CRM.” What for? “To improve sales.” Improve them how — sell to more people, sell more to existing customers, or lose fewer of them mid-funnel? Each of those answers leads to a different technical decision, and two of them may not need a CRM at all.

It sounds obvious and it is almost never done, because it requires admitting the request arrived without a stated objective. But it is that question that connects the technical to the business — and without that connection there is no plan, there is a shopping list.

The plan in four questions

A multi-year IT plan does not need to be a hundred-page document. It needs to answer four things, and be revised when the business changes.

1. What will the business demand? This comes from the business plan, not from IT. Opening in another country? Then there will be tax and latency requirements. Buying companies? Then there will be integration and consolidation, more than once. Selling into a regulated sector? Then there will be audits and evidence. Every business move has a predictable technical consequence — and predictable means plannable.

2. What already exists, and in what state? An honest inventory: what runs, who maintains it, what is out of support, what nobody can explain. This is the part that usually hurts, because it exposes what accumulated. It is also the part that saves the most later — a good share of what gets planned as new construction already exists, badly built or forgotten.

3. What must be born, and what must die? IT plans love the first half and ignore the second. Decommissioning has a cost, a risk and an owner — and if it is not in the plan, it does not happen. The environment that never dies is what makes cost climb without anyone understanding why.

4. In what order, and why? The order is not technical: it is dependency and risk. What blocks other things comes first. What carries a regulatory deadline comes first. What is desirable but isolated can wait — and it needs to be written down that it will wait, or it comes back as an emergency.

How to write it so the board understands

The rule is simple: a plan is written in capabilities, not in products.

“Migrate to version X” is not an objective — it is a means. “Close the month in three days instead of ten” is an objective, and it survives a change of vendor. “Implement tool Y” says nothing to whoever decides; “cut to 48 hours the time between discovering an exploitable vulnerability and fixing it” does, and it can be measured.

That translation has a valuable side effect: it forces IT to know why it is doing what it does. A project that does not survive translation into business language usually should not be on the list.

What changes once the plan exists

Three things change, and none of them is delivery speed.

The conversation moves. When a new request arrives, the question stops being “can we do it?” and becomes “what does this replace?”. Prioritising stops being an IT opinion and becomes a business decision, with the cost visible.

Debt becomes a choice. There will still be emergencies, and it will still be right to serve some of them badly and fast. The difference is that this becomes a recorded decision, with a deadline to fix — not an accident nobody remembers causing.

The budget becomes defensible. Asking for funds to “modernise the infrastructure” is hard. Asking to “sustain the three branch openings in the business plan” is a different conversation — and it is the same money.

The honest limit: no plan eliminates the unforeseen, and IT will keep putting out fires. What it changes is the proportion — from a function that only reacts to one that reacts and builds. And that difference shows up precisely at the three-to-five-year horizon, which is where it does not look today.

Where to start, if nothing exists

Do not start with the document. Start with an inventory of what exists and a reading of the business plan — the two inputs an IT plan needs, and which usually sit in different drawers. It is the same survey we run in an IT diagnostic, and it answers the first two questions before any purchasing decision.

After that, one page. Four questions answered, an order justified, an owner on the board and a revision date. If it does not fit on one page, it is not yet clear enough to be a plan.

And it is worth saying where this observation comes from: not from methodology, but from repetition. Across years of visiting companies, the question “what is your IT plan for the next three years?” almost always meets the same silence — and it is the same silence, six months later, when someone asks why nobody saw it coming.

Frequently asked questions