IT Strategic Plan Template: Sections, Example and 12-Week Process

9 min read ยท 2026-10-25

An IT strategic plan template gives you a fixed structure for a document that links business goals to IT priorities for the next three years. It covers where IT stands today, the few goals it will pursue, the initiatives behind each goal, a roadmap by year, the budget and people needed, the risks, and how progress will be measured. A good one fits the main story in 15 to 20 pages, with detail in appendices.

Below are the ten sections to put in your template, what goes in each, a 12-week process to write and approve the plan, and a filled-in example for a mid-size company. It is written for CIOs, IT directors, heads of IT in smaller firms and the PMO or strategy leads who help them. The hardest part is not the writing. It is getting business leaders to agree on what IT should stop, start and fund, so most of the process below is about those conversations.

The roadmap at a glance

Goal: A three-year IT strategic plan, built with business leaders and approved by the executive team, with a funded first-year roadmap and a quarterly review in place. Duration: 12 weeks

  1. Mandate and setup (Weeks 1-2)

    Agree on why the plan is needed, who decides and when it must be approved.

    • Get a sponsor on the executive team, usually the CEO, COO or CFO, and agree on the approval date.
    • Set up a small steering group with three or four business leaders and two IT leads.
    • Collect the company strategy, budget cycle dates and any board commitments IT must support.
    • Write a one-page charter: scope, time horizon, deliverables, interview list and timeline.

    Milestone: Charter signed by the sponsor, steering group named and the approval meeting in the calendar.

  2. Business needs (Weeks 2-4)

    Understand what each part of the business needs from IT over the next three years.

    • Interview each department head with the same questions: goals, pain points, planned changes, data needs.
    • Run a short survey of staff on the tools and support they rely on.
    • List the business capabilities the company needs, such as quoting, billing or field service, and how well IT supports each.
    • Group what you heard into themes and share them with the steering group.

    Milestone: A business needs summary with five to eight themes, reviewed and corrected by the steering group.

  3. Current state assessment (Weeks 3-6)

    Describe honestly where IT stands today.

    • Build or update the application inventory: owner, users, age, support status and yearly run cost.
    • Review infrastructure, security posture, data quality and the support desk backlog.
    • Map the IT budget into run, grow and transform, and the team into roles and skills.
    • Score each area as strong, adequate or weak, with evidence for each score.

    Milestone: A current state report with an application inventory, budget split and scored assessment, accepted by IT leadership.

  4. Vision, goals and options (Weeks 6-8)

    Choose a small set of goals and the initiatives that will reach them.

    • Write a short IT vision tied to the company strategy.
    • Set three to five goals, each with a measure and a three-year target.
    • List candidate initiatives, then score them on business value, risk reduction, cost and effort.
    • Hold a workshop with the steering group to rank the initiatives and agree what IT will stop doing.

    Milestone: Goals and a ranked initiative list agreed in the steering group workshop, with a stop list.

  5. Roadmap, budget and people (Weeks 8-10)

    Turn priorities into a sequenced, funded plan.

    • Place initiatives on a three-year roadmap, detailed for year one and at theme level for years two and three.
    • Estimate budget and staff needs for each initiative, including run costs after go-live.
    • Plan the people side: hires, training, partners and changes in roles.
    • Write the risks and dependencies with an owner and a response for each.

    Milestone: Full draft plan with roadmap, budget by year and risk log, reviewed by finance.

  6. Approve and launch (Weeks 11-12)

    Get formal approval and set up the routines that keep the plan alive.

    • Present the plan to the executive team with a one-page summary and the budget ask.
    • Update the plan with their decisions and publish the final version.
    • Brief the IT team and department heads on what changes and when.
    • Set up a quarterly review with the steering group and a yearly refresh.

    Milestone: Plan approved by the executive team, year-one initiatives funded, and the first quarterly review booked.

The ten sections of the template

Use these ten sections as the skeleton of your document. Keep each one short and specific to your company. An executive should be able to read sections 1 to 6 in one sitting and know what IT will do and what it costs.

Write the executive summary last, but put it first. It should state the goals, the top initiatives, the three-year budget and the decisions you need, all on one page.

  • 1. Executive summary: one page with goals, top initiatives, budget and decisions needed.
  • 2. Business context: the company strategy and the business goals IT must support.
  • 3. Current state: strengths and weaknesses across applications, infrastructure, security, data, support and people.
  • 4. Vision and guiding principles: where IT is going and rules such as cloud first or buy before build.
  • 5. Goals and measures: three to five goals, each with a baseline and a three-year target.
  • 6. Initiatives and roadmap: the initiatives behind each goal, sequenced by quarter for year one and by half-year after.
  • 7. Budget and resources: run, grow and transform spend by year, staff, partners and hires.
  • 8. Governance: who decides on priorities, how new requests are handled and how often the plan is reviewed.
  • 9. Risks and dependencies: each with an owner and a response.
  • 10. Appendices: application inventory, interview summaries, scoring of initiatives and detailed cost estimates.

Example: a filled-in plan for a 600-person distributor

Picture a wholesale distributor with 600 staff, three warehouses, an ERP system that is close to the end of vendor support, and a growing number of online orders. The CEO wants to grow online sales and open a fourth site. Here is how the plan could look.

Notice how each initiative maps to a goal, and how the plan names what IT will stop doing to make room. Without a stop list, the roadmap becomes a wish list on top of the current workload.

  • Goals: replace the ERP before support ends, give sales and operations one view of stock, reduce security risk, and cut the share of IT time spent on manual fixes.
  • Year 1: ERP selection and design, identity and multifactor authentication for all staff, data warehouse for stock and orders, retire three old reporting tools. Owner: IT director with the COO. Milestone: ERP contract signed and security baseline in place.
  • Year 2: ERP go-live in waves by warehouse, warehouse management integration, self-service reporting for sales. Owner: ERP program manager. Milestone: all sites on the new ERP.
  • Year 3: fourth site opened on the standard setup, customer portal for online orders, automation of routine support tasks. Owner: IT director. Milestone: new site live in the planned window.
  • Stop list: custom reports for single users, new projects on the old ERP, and on-site server rooms at two warehouses.

Who owns what

An IT strategic plan written by IT alone tends to be ignored by the business. Give business leaders real roles in it, from the interviews to the ranking workshop to the approval.

After approval, each initiative needs one business owner and one IT owner. The business owner is accountable for the outcome, such as fewer stock errors. The IT owner is accountable for delivery.

  • Executive sponsor (CEO, COO or CFO): sets the mandate, chairs the approval meeting, settles priority conflicts.
  • CIO or IT director: owns the plan, the roadmap and the budget ask.
  • Steering group of business leaders: gives input, ranks initiatives and reviews progress each quarter.
  • Enterprise architect or senior IT lead: current state assessment, application inventory and principles.
  • Finance partner: checks costs, run costs after go-live and the link to the budget cycle.
  • PMO lead: turns year one into a project portfolio and runs the quarterly review.

How to present it to the executive team

Executives will read the summary and look at the roadmap, so build the meeting around those two pages. Open with the business goals the plan supports, in their words, not IT terms. Then show the three to five IT goals, the year-one initiatives, the three-year budget split into run, grow and transform, and the decisions you need today.

Leave out the full current state assessment, product names and technical diagrams, and keep them in the appendices for questions. Show the stop list. It proves you made choices, and executives tend to trust a plan more when it says no to something. End with the review rhythm, so they know when they will see progress.

Metrics to track

Each goal needs one or two measures with a baseline from the current state assessment. Report them every quarter in the same format, next to the roadmap status.

Mix delivery measures with outcome measures. Delivery shows whether IT did what it said. Outcomes show whether it made a difference to the business.

  • Roadmap delivery: initiatives on track, at risk or late, from the PMO's portfolio report.
  • Spend mix: share of the IT budget on run, grow and transform, from the finance system.
  • Application portfolio: number of applications, and how many are out of vendor support, from the inventory.
  • Security posture: staff covered by multifactor authentication, open critical vulnerabilities, time to patch.
  • Service quality: support tickets per user, resolution time and a short user satisfaction score.
  • Business outcomes: the measures business owners care about, such as order errors or time to close the month.

How to build the template in your tools

Write the plan as a document in Word or Google Docs, using the ten sections as Heading 1 styles so you can generate a table of contents. Keep the application inventory and initiative scoring in Excel or Google Sheets, with one row per item, and paste only summary tables into the document.

Draw the roadmap on one slide or one page: years or quarters across the top, one swimlane per goal down the side, and initiatives as bars inside each lane. Color bars by status, and use the same slide in every quarterly review so changes are easy to spot. If your PMO uses a portfolio tool such as Smartsheet or Jira, keep year one there and link the roadmap slide to it.

How to adapt it

For a small company with a one- or two-person IT team, cut the plan to five sections: business context, current state, goals, roadmap and budget. A short document that leadership reads beats a long one nobody opens. Interviews can be a single workshop with the leadership team.

For a large or regulated organization, such as a public body, a hospital group or a bank, add sections for compliance, architecture standards and portfolio governance, and plan more time for approvals. In the public sector, align the plan with the funding cycle and any required formats from your oversight body. In every case, keep the three-year horizon and the quarterly review.

Common mistakes to avoid

  • Writing the plan inside IT and presenting it at the end gets polite nods and no backing, so involve business leaders in the interviews and the ranking workshop.
  • Listing every project IT could do turns the plan into a wish list, so cap goals at five and publish a stop list.
  • Budgeting only for project costs hides the run costs that follow, so include support and licensing after go-live for every initiative.
  • Planning years two and three in detail creates false precision, so detail year one and keep later years at theme level.
  • Skipping a baseline makes progress impossible to show, so record each goal's starting number during the current state assessment.
  • Filing the plan after approval lets it go stale, so review it every quarter with the steering group and refresh it every year.

Frequently asked questions

What should an IT strategic plan include?

It should include an executive summary, business context, current state, vision and principles, goals with measures, initiatives and a roadmap, budget and resources, governance, risks and appendices. Keep the main body short. Put the detail in appendices.

How long should an IT strategic plan cover?

Many IT strategic plans cover three years, with a detailed first year. Review them every quarter and refresh them every year. Shorter horizons work for fast-changing small companies.

What is the difference between an IT strategy and an IT strategic plan?

The IT strategy sets direction: the vision, goals and principles. The strategic plan adds how you will get there: initiatives, a roadmap, budget, owners and measures. Many organizations combine them in one document.

How long does it take to write an IT strategic plan?

A common timeline is 8 to 12 weeks for a mid-size organization, including interviews, assessment, workshops and approval. Small companies can do it faster. Large or public organizations often need longer because of approval steps.

Who should approve the IT strategic plan?

The executive team, usually with the CEO or CFO as sponsor, should approve it, since it commits budget and changes priorities across the company. Some organizations also take it to the board. Approval should include the year-one budget, not just the document.

Generate this roadmap with AI