An initiative is a single, scoped change to an environment: standardize authentication, isolate a legacy server, stand up a new site, retire a NAS. A roadmap is what you get when you've written enough of them, tied each to a real business driver, and put them in the right order. The discipline isn't in the ordering. It's in refusing to put anything on the roadmap that you haven't actually thought through to the bill of materials.
Every initiative I scope gets the same nine-part structure. The newer format runs close to ten pages. The point of the structure isn't length for its own sake; it's that each section forces a question that's expensive to answer later if you skipped it now.
The nine sections, and what each one is really for
Business Purpose
Why this is worth doing in business terms, not technical ones. What it unblocks, what risk it retires, what it costs the business to keep living with the current state. If I can't write this section without resorting to "because it's old," the initiative isn't ready. This is also the section an executive actually reads.
Current State
An honest, specific inventory of what exists today: counts, versions, authentication models, dependencies, the awkward parts. On a recent identity project this section spelled out that 158 of 373 workstations authenticated through Azure AD Domain Services while the other 215 authenticated natively through Entra ID. You don't get to design the fix until you've documented the mess at that level of precision.
Desired Outcome
The target state, broken into the dimensions that matter: identity and authentication, device management and security, infrastructure, user experience. "All endpoints authenticate natively through Entra ID; Azure AD Domain Services is decommissioned; one Conditional Access policy set applies to every device." Specific enough that you can later prove you hit it.
Dependencies & Preconditions
What has to be true before this initiative can even start. Licensing in place. Intune configured. MFA baselines established. This is where initiatives reveal their hidden ordering: a dependency here is a sequencing constraint on the whole roadmap.
Risks & Considerations
Every way this can go sideways, grouped by category (user impact, application and resource access, migration and cutover, infrastructure), each paired with a mitigation. "Profile migration carries corruption risk if not sequenced carefully; pilot 20 to 30 devices first and validate before each wave." A risk without a mitigation is just an excuse you're pre-writing.
Unknowns / Validation Required
The questions I can't answer yet, ranked by whether they block planning or just block scoping. This is the most underrated section. Naming what you don't know is how you avoid quoting a project on assumptions that turn out to be wrong. Things like device OS distribution, current MFA adoption, or whether every device is already enrolled in Intune.
Scope of Work
The actual phased plan (discovery, planning, configuration, enablement, migration, cleanup, validation and handover) with an explicit out of scope list beside it. The out-of-scope list prevents more disputes than the in-scope list does. This is the section that becomes the statement of work.
Assumptions
Everything the plan takes for granted, written down so it's auditable. "Microsoft 365 licensing is in place." "All workstations can natively Entra-join with no legacy-OS constraints." If an assumption turns out false, this section is the paper trail explaining why the scope changed.
Bill of Materials
Every hardware and licensing line item, with the reason it's on the list. Not "a firewall" but the specific model, the licensing mode, why it was chosen for this throughput and interface count. The BoM is where a vague plan finally becomes a real number, and where a lot of half-baked initiatives quietly fall apart.
What separates a good write-up from a lazy one
A lazy initiative is a finding in a costume. "The firewall is end of life" is a ticket, not an initiative. The tell is that the lazy version has a thin current state, no real unknowns section (because nobody looked hard enough to find what they didn't know), and a bill of materials that's really just "replace it with a newer one." It survives right up until someone asks a second question.
A good write-up is one where the risks section made you change the plan, the unknowns section sent you back to the client for answers, and the bill of materials reflects a decision you can defend on throughput, licensing, and lifecycle, not just brand familiarity. The hardest section to get right is consistently the unknowns. It's the only one that requires admitting the limits of what you currently know, and it's the one that saves the project.
From initiatives to an 18-month roadmap
Once each client has a set of fully scoped initiatives (usually three to ten of them, each tied to a specific technical need, a business goal, and a risk worth eliminating), the roadmap is the act of sequencing them. That sequencing isn't done on technical preference. It's shaped by a roughly 60-point business-context index I build per client: their goals, workflows, bottlenecks, budgeting cycles, and seasonality.
Dependencies set the hard constraints (you can't standardize Conditional Access before the licensing and Intune baselines exist), and the business context sets everything else. A change that touches the production floor doesn't land in the client's busy season. A no-cost fix that removes real risk jumps the line ahead of an expensive one that doesn't. The first eighteen months get scoped to BoM depth; years two through five get a deliberate line of sight rather than false precision, because pretending to know year-four pricing is just another assumption you'll have to walk back.
Then it gets governed: reviewed on a cadence and adjusted before things break, documented deeply enough that the plan holds its value whether the client acts on it this quarter or next year. That's the whole point of writing the initiatives this thoroughly. The roadmap isn't a sales artifact you present once. It's an operating document that survives budget pauses, staff turnover, and the eighteen months it's actually meant to cover.