Every IT initiative — whether it came from a carefully maintained Roadmap or landed on a Monday morning as a board-level urgent request — eventually needs to be designed, funded, and built. Initiative Alignment is the process that handles this.
It has two inherent steps, separated by a funding gate.
Step One: Initiation
Initiation answers the question: what are we going to build, roughly how, and why is it worth funding? It produces a Business Outline — specifically, a Solution Overview.
A Solution Overview is not a requirements document. It is not a technical architecture document. It is an investment case. It needs to be intelligible to the senior business executives who will decide whether to fund it, and it needs to give architects and technical leads enough information to assess feasibility. Both things. In one document. Typically fifteen to thirty pages.
The ten sections of a useful Solution Overview:
- Business context — why does this need doing now?
- Current state — what does the current landscape look like in the relevant area, in business terms?
- Proposed solution — what will be built, at a conceptual level accessible to non-technical readers?
- Future state — what will the business environment look like after delivery?
- Business benefits — what specific outcomes will the organisation achieve? Quantified where possible.
- Cost and timeline — indicative, not committed. Enough precision to support a funding decision.
- Risks — the top three to five risks, with mitigating factors.
- Strategic alignment — which Principles does this comply with? Which Roadmap entries does it address?
- Technical concept — a brief explanation of the proposed approach for a technically literate reader. One page maximum.
- Sourcing recommendation — buy, build, or outsource, with rationale.
The over-specification failure mode: If a Solution Overview contains detailed requirements or system architecture diagrams with integration patterns, it has over-specified. The test is simple: does this section help the Investment Forum decide whether to fund? If not, remove it.
Step Two: Realisation
Once the Solution Overview is approved and funding is committed, Realisation begins. It answers: exactly how will we build this? The output is an IT Design — the document the project team actually builds from. It covers application architecture, data model and data flows, integration specifications, infrastructure requirements, and security architecture.
The key principle for IT Designs is the boundary rule: specify every decision that, if made incorrectly, creates a costly landscape consequence. Delegate every decision that has no landscape consequence. IT Designs that over-specify become obstacles. IT Designs that under-specify leave the architecture to chance.
The five initiative types
Not all initiatives are strategic. AMBIT identifies five types:
- Fundamental — major transformations that reshape the organisation’s capability landscape.
- Strategic — initiatives drawn from the Roadmap, implementing agreed Business Visions.
- Local — business-unit-initiated initiatives serving a specific area’s needs.
- Urgent — reactive initiatives responding to immediate business problems or compliance requirements.
- Technical — IT-internal initiatives: infrastructure refresh, platform consolidation, architecture debt remediation.
The diagnostic signal: A portfolio dominated by Urgent and Technical initiatives means Strategic Alignment is not working. Business needs are arriving as fire-fighting rather than planned investment. No amount of better Initiative Alignment process fixes a Strategic Alignment problem — but consistently good Initiative Alignment builds the track record that makes Strategic Alignment possible.