IT Strategy: How to Write One the Business Will Actually Use

A practical method for writing an IT strategy that starts from business decisions, makes real trade-offs, and stays alive after the launch meeting.

My CIO Coach · Last reviewed October 23, 2026 · 6 min read

Most IT strategies fail quietly. They get written, presented, praised and filed, and six months later the budget, the project list and the hiring plan look exactly as they would have without them. The document was not wrong. It simply was not built to make decisions.

An IT strategy the business actually uses does three things. It explains what the organization is trying to achieve and where technology helps or gets in the way. It makes choices, including saying no to things. And it connects those choices to the mechanisms that really move money and people: the budget cycle, the investment review and the operating plan.

This guide walks through a method for writing that kind of strategy, whether you are a new CIO, an IT director stepping into a broader role, or a manager asked to "put together the IT plan" for the first time.

Start with the business, not the technology

Begin with the organization's own goals, in its own words. Read the strategic plan, the budget narrative and recent board materials. Then interview the people who own revenue, operations, customer experience, finance and risk. Ask what they are trying to achieve over the next two to three years, what is slowing them down, and what would worry them most if it failed.

Governance standards point the same way. The NIST Cybersecurity Framework 2.0, for example, opens its Govern function with outcomes about understanding the organizational mission and stakeholder expectations before anything else. The same logic applies to IT strategy as a whole: context first, solutions second.

A useful test is whether a business executive would recognize their own priorities in your first few pages. If the opening talks about cloud platforms, data lakes and zero trust before it talks about customers, costs or growth, you have started in the wrong place.

Write a diagnosis before a plan

The most valuable page in a strategy is usually the honest description of the current situation. Name the few problems that matter most. For example, imagine a hypothetical regional distributor whose diagnosis reads: "Order data lives in three systems that do not agree, so sales, warehouse and finance each spend hours reconciling, and customers get inconsistent delivery dates."

That sentence is more useful than ten pages of capability maps because it points directly at what to fix and why the business should care. Good diagnoses are specific, are written in business language, and are agreed to by the people who live with the problem.

Cover the uncomfortable areas too: aging systems, skills gaps, security exposure, vendor lock-in and work the IT team is doing that nobody values. Leaving them out does not make them go away; it just makes the strategy less credible.

Make choices and name the trade-offs

A strategy is a set of choices about where to focus limited money, people and attention. If everything on the list is a priority, nothing is.

For each major problem in your diagnosis, describe the approach you will take and the alternatives you rejected. "We will standardize on one order management system and retire the other two, rather than building integrations between all three" is a choice. "We will improve data integration" is not.

Be explicit about what you will stop doing or defer. A short "not now" list often earns more trust from executives than the priority list, because it shows you understand that capacity is finite.

Connect the strategy to investment decisions

A strategy that never touches the budget is a wish list. Tie each priority to how it will be funded and governed.

The U.S. Government Accountability Office's IT investment management framework (GAO-04-394G, 2004) describes a select, control and evaluate cycle built on the Clinger-Cohen Act: choose investments as a portfolio, oversee them while they run, and assess whether they delivered. It places an investment board at the center of those decisions. You do not need a federal-style process, but you do need a regular forum where business and IT leaders decide together what gets funded, what continues and what stops.

In practice, that means your strategy should:

Group work into a small number of themes that map to business goals.
Show the rough cost, effort and timing for each theme, including run costs, not just project costs.
State how success will be judged, in measures the business already tracks where possible.
Name the decision forum, its members and how often it meets.

Keep it short and give it owners

Aim for a core document that an executive can read in under half an hour, with detail in appendices. A common structure:

Purpose and business context (one page)
Diagnosis: the few problems that matter (one to two pages)
Strategic choices and what you will not do (two pages)
Roadmap by theme and quarter (one page)
Funding, governance and measures (one to two pages)
Risks and dependencies (one page)

Every theme needs a named business sponsor as well as an IT lead. If no executive is willing to sponsor a theme, treat that as information: either the business does not value it, or you have not explained it well.

If you need the detailed sequencing, see our guide to leading digital transformation without the buzzwords for an incremental way to deliver change once the strategy is agreed.

Build in a review rhythm

Treat the strategy as a living management tool rather than an annual artifact. A quarterly review against the measures you set, held in the same forum that makes investment decisions, keeps it connected to reality. An annual refresh can revisit the diagnosis and the big choices.

The UK Government Digital Service's guidance on the discovery phase offers a useful mindset here: it is "not a failure" to stop work if research shows that is the best thing to do. A strategy that never kills or reshapes anything is probably not being used.

Governance frameworks can support this rhythm. ISO/IEC 38500:2024 is written for members of governing bodies and covers the governance of an organization's current and future use of IT, and ISACA's COBIT includes a domain (Align, Plan and Organize) that deals with strategic planning. Our guide to IT governance frameworks explains how they fit together.

Common ways IT strategies go wrong

Written by IT alone and presented to the business as finished.
A technology shopping list dressed up as a strategy.
No diagnosis, or a diagnosis too polite to be useful.
Every initiative is "high priority."
No link to budget, staffing or the investment process.
Measures that only IT understands, such as server uptime, with nothing on business outcomes.
No review date, so it quietly expires.

Key takeaways

Start from the organization's goals and the problems its leaders actually feel, in their language.
Write an honest diagnosis of a few critical problems before proposing solutions.
Make explicit choices, including what you will stop or defer.
Tie every priority to funding, a decision forum, owners and business measures.
Review the strategy quarterly where investment decisions are made, and be willing to change course.

Sources

Spotted something out of date? Let us know.