How to Build a Three Year IT Plan

A plan built from technology asks which platforms to buy. A plan built from the business asks what the company intends to do over the next three years, and what would have to be true technically for that to be possible.

The inputs are the things the board already argues about. Where growth is expected to come from. Which sites or countries are opening or closing. What you might buy. Which rules are changing. How many people you expect to employ, and what they will be doing.

Each of those has consequences that are cheap to plan for and expensive to bolt on later. If you intend to buy companies, you need a repeatable way to merge logins and email. If you are moving into a regulated market, you need the evidence and the retention in place before the auditor arrives rather than after.

Every setup carries commitments that exist whether or not anybody has planned for them. Software and operating systems about to lose support. Hardware past its sensible life. Licences renewing on terms that no longer suit you. Certificates and contracts with dates attached to them.

Add the debt that is not technical. Systems only one person understands. A process that depends on a script nobody has read. Access granted for a project that finished three years ago. Those carry real risk and appear on no asset report.

Put all of it on one timeline with the dates that are genuinely fixed. Much of what feels like a free choice about next year turns out to be spoken for already, and knowing that early is what makes the rest of the plan realistic.

Keeping things running, paying down debt and building something new are three different kinds of spend with three different justifications. Put them in one budget line and the third one loses every time.

It loses because running the place is urgent and changing it is merely important. Without a protected share, every quarter the change money gets eaten by something that could not wait, and after two years you have spent a great deal and changed nothing.

Set the split on purpose and review it once a year. If paying down debt keeps crowding out new work, the debt is growing faster than you are clearing it. That is a strategy problem, not an operations one.

Some work makes everything after it cheaper. An accurate list of what you own and what it talks to makes every later project easier to price. One sensible login platform makes every new application faster to connect and every access review shorter. Monitoring that works turns future incidents into questions that have answers.

Other work stands on its own and can happen in almost any order, which makes it good material for a quarter when you are not sure how much capacity you will have.

Put the compounding work first, even though it is the harder half to sell. Projects launched onto weak foundations do not fail immediately. They land, then cost more to run than anyone forecast, and nobody ever traces that back to the order the work was done in.

A three year plan is not three years of committed detail. Year one should be specific enough to fund and staff. Year two is a direction with rough sizing. Year three is a statement of intent, and treating it as a promise is how plans turn into fiction that nobody updates.

Re-baseline once a year and review quarterly against what actually happened. The point of the review is not to defend the plan. It is to notice which assumptions have stopped being true and to move the work accordingly.

Keep something back for the unplanned, because there will be an acquisition nobody mentioned, an incident, or a supplier decision that forces your hand. A plan with no slack breaks on first contact and then gets abandoned rather than adjusted.

A plan only the technology team can read gets funded only as far as the technology team is trusted. That is a fragile basis for three years of work.

Write each item as an outcome and as the consequence of not doing it, in business words. Not migrate the file estate, but something closer to this: staff can reach documents from any site and we can get them back within minutes, which is at risk because the storage platform loses support in June.

One page carrying the fixed dates, the order and the money will do more for the plan than a hundred slides. If you cannot explain it in a few minutes to somebody with no technical background, it is not finished yet.