Dependency-sequenced IT roadmap

I wrote a topic-per-document IT roadmap: nine single-topic strategy documents plus a README that sequences them by dependency. Each entry states why it matters, what it depends on, and what it blocks, so leadership can see which decisions gate which projects rather than reading one long undifferentiated plan and guessing at the order.

It is the strategy layer sitting on top of an annual State of IT assessment. The roadmap documents are what came out of reconciling the original asks against what actually happened over the following year.

Why the format

A conventional roadmap is a flat priority list, which quietly assumes every item is independent. Most are not. When priority two cannot start until priority six resolves, a flat list produces stalled work and a leadership team that cannot tell whether the delay is execution or sequencing.

Splitting one topic per document and making the dependency edges explicit fixes that. It also makes the plan maintainable: a single topic can be revised without reopening the whole document, and the sequencing README is the only thing that has to understand the graph.

How each document is built

• Current state, evidenced. Each document cites live data (inventories, license seat counts, ticket history, support ratios) rather than assertion. A roadmap argued from evidence survives questioning; one argued from opinion does not.
• The decision or the gap, stated plainly as the thing that actually needs resolving.
• Open items, so the unresolved parts are visible rather than smoothed over.
• Explicit dependency links to the other documents: what this blocks, what it waits on, or an explicit note that it is independent and parallelizable.

The sequencing layer

The README orders topics by what blocks what. Some items gate nearly everything downstream and are called out as such. Others are genuinely independent and can run in parallel, which is worth stating explicitly so they don't get queued behind a blocking chain for no reason. Items carrying a real external clock, a compliance or insurance deadline that will not move for internal convenience, are flagged so they don't get lost behind higher-visibility work.

Topics covered

The nine documents span vendor and organizational questions alongside the technical ones:

• Managed-service scope restructuring, splitting the engagement by function and deciding each part on its merits rather than making an all-or-nothing call.
• IT staffing and organizational design, re-costed against user growth. The internally supported footprint runs at roughly one support engineer per 283 users across 850 users and 51 offices.
• Network hardware standardization: addressing, segmentation, and SSID consolidation across the office estate.
• ISP standardization, paired deliberately with network standardization because a circuit install is the cheapest possible moment to re-address and segment a site.
• Laptop fleet lifecycle compliance, verifying that an on-paper standard is actually followed under decentralized regional purchasing.
• Multifunction printer fleet strategy, sharpening what "standardize" means once vendor consolidation is already done.
• Field-device management and ownership for a device category deployed through informal channels.
• SaaS backup coverage analysis, framed around what native retention does and does not cover.
• Shadow-IT containment as a standing access-review practice.

Honest reconciliation

The annual review reconciles the prior year's asks against outcomes, and names what didn't move as clearly as what did. It also accounts for work that appeared during the year without being in the original plan at all, which for the most recent cycle was an entire AI and automation program.

Recording the misses is the part that makes the exercise worth repeating. A roadmap that only reports its wins stops being a planning instrument and becomes a status report.

Docs-as-code, applied to strategy

The same practice behind the IT documentation library applied at the planning layer: git-versioned, single-topic Markdown files, cross-linked, with revision history. Strategy documents get the same treatment as operational documentation because they have the same failure mode, going stale silently and being quoted long after they stopped being true.