Strategic IT Planning

Strategic planning usually breaks not at the idea stage but at the handover to execution: the goals are written down, yet nobody knows whose quarter this is or which number settles the argument. I take strategy down to the level where every initiative has an owner, a deadline and a measurable result, and into a quarterly rhythm where the plan gets revisited rather than remembered a year later.

What people arrive with

It usually goes like this: in March the board asks for a three-year plan, by May there is a forty-slide deck and it gets approved. In September somebody asks what has been delivered, and there is nobody to answer: the status “in progress” fits every item.

The reverse happens too: no plan is written at all, because an argument about technology eats every attempt. Neither case is short of ideas; what is missing is the step from a wish to an answer: who, by which date, measured by what. That step is what I do. The standing-role version of the same work is described in the guide Fractional CTO in Dubai; this page is about the project.

Diagnostic: where the company actually is

The inventory takes two weeks and starts with a table that every system in the company goes into. The rows with no owner are the ones that explain why the previous strategy failed. Process maturity is scored on the COBIT and ITIL scales, not for a certificate but so that “everything is a mess here” turns into a list: where there is no owner, where there is no procedure, where a procedure exists but nobody follows it. More on that in the article on IT department maturity.

• A register of systems with owner, annual cost and role in the business.
• A dependency map: what stops if a given element fails.
• Gaps between the written strategy and reality.

Target state and architecture

The target state is not “cloud” or “microservices”; it is the answer to what the technical side of the company has to look like in two to three years for the business goals to be reachable. If the goal is to sell the company, the infrastructure has to survive the buyer’s review. For the MENA market a regulator’s requirement to keep data inside the country is added: it narrows the choice of hosting before any argument about technology.

I describe the architecture in the C4 model: diagrams that a developer and a board member read the same way. Where the infrastructure changes, the target configuration is captured as code in Terraform and Ansible. In Monolith Plus the target state was a single line (the platform absorbs multiple-fold growth in load without being rewritten), and that same line became the acceptance criterion.

Portfolio of initiatives: owner, deadline, metric

The gap between the current and the target state is broken into initiatives. Each has three mandatory fields: an owner from among your managers, a deadline, and the metric that settles whether it is done.

Priority is set on two axes: effect on the business goal and the risk of not doing it, assessed under ISO 31000. That is how the first quarter gets not the most interesting work technically, but the most expensive to leave alone. The portfolio lives in your own tracker, whether Jira, Linear or Notion, depending on what is already in use.

Financial model and budget

Every initiative comes with a calculation: what it costs and when its effect becomes measurable. The horizon is three years, and over that horizon the purchase price does not decide it: an expensive licence beats a cheap one if a year later it needs no second administrator.

The model is an ordinary spreadsheet in Excel with open formulas: your CFO unfolds every line of effect down to an assumption and changes it directly. The saving from the move to microservices at MStar was an assumption of exactly that kind first, and a fact only later. An ongoing IT budget control loop is a separate service, financial management.

Strategic planning as a quarterly rhythm

A document filed away is not a strategy. So the project ends with the first quarterly review: owners come with their numbers, some initiatives move their dates, some close early.

Metrics go onto a dashboard (technical metrics in Grafana, business figures in Metabase) so that “how is the plan going” is something you look at rather than ask. Goals are written as OKRs if the company is ready for that format. After the project the rhythm runs on your own or with me as a fractional CTO.

Stack

Layer	Tools
Goals and risk	OKR, ISO 31000
Portfolio and tracking	Jira, Linear, Notion
Quarterly review dashboard	Metabase

What I do not do

• I do not write the strategy behind a closed door: initiative owners take part from the first week.
• I do not plan beyond three years: past that horizon the numbers in an IT plan mean nothing.
• Revenue is not modelled here. The sales plan comes from your commercial director, and the signature under it stays theirs.
• I do not stretch the project: at one company two conversations made it clear that what was needed was not a plan but a mail migration, and the work ended there.

How the engagement runs

A fixed-price project at $50,000 (AED 183,500) over eight to ten weeks for a company of 30–300 people. The first step: a conversation with the CEO and the CFO, plus read access to the systems and invoices. That is enough to tell whether there is full-scope work here; sometimes what is needed is not a plan but a review of one decision, and that is hourly IT consulting instead.

• Weeks 1–2. Diagnostic: system register, dependencies, maturity, interviews with the owners.
• Weeks 3–5. Target state: architecture, data requirements, options with cost of ownership.
• Weeks 6–8. Portfolio of initiatives and financial model: owners, deadlines, metrics, budget.
• Weeks 9–10. Presentation to leadership, transfer into your tracker, first quarterly review.

Related services

If the plan is needed first of all for an investor’s review, see investor readiness and due diligence. Shared passwords and missing logs are closed by a separate information security engagement. The financial side of the plan continues in financial management, and the risk map in risk management.

Frequently Asked Questions

Who runs the quarterly review after the project?

Whoever approved the plan: usually the CEO, sometimes the COO. The review works through the portfolio in the tracker and the metrics dashboard; all of it stays with you in editable form, along with the register and the model.

A strategy already exists, but it is not being executed. Will you write a new one?

Not if the existing one has something to work with. Usually the problem is not the goals but the absence of owners and metrics. Whatever is alive gets an owner and a deadline; the rest is honestly closed.

What do you need from the company to get started?

Read access to the infrastructure and invoices, plus about an hour with each future initiative owner. A plan built from slide decks will not survive the first quarter.

What happens to the plan when the market changes?

That is what the quarterly review is for: initiatives are revisited every three months against their metrics. The two-to-three-year target state changes less often, but it is not carved in stone either.

---

Ready to Get Started?

Show me the plan your board is looking at today, and in one short call I will point out what in it has no owner and no deadline. Talk the plan through on a call.