Catalogue › Programme Management › programme-charter

Programme charter

Charters an AI adoption, delivery or transformation programme - mandate, the outcomes it serves, scope and exclusions, workstreams, governance and decision rights, tolerances, funding envelope, roles and closure criteria - so the sponsor signs one agreed basis for running it. Use when an agreed pack or roadmap needs mobilising, when AI initiatives run without a common mandate, or when a sponsor asks what the programme is committing to.

Department

Programme Management

Lifecycle

Mobilise

Maturity

explorer, adopter, builder, scaler, ai-enterprise

Risk tiers

0, 1, 2, 3, 4

Platforms

platform-neutral

Editions

starter, scale, enterprise

Reviewers

none

Status

draft

Copilot Cowork

Programme Management plugin for Copilot Cowork, or this skill on its own: Download SKILL.md

Licence

CC BY 4.0, by Simon Foote

Purpose

A Microsoft AI programme touches licences, platforms, knowledge, people, governance and suppliers at once, and without a single mandate each workstream optimises for itself. This skill writes the programme charter: why the programme exists, which strategic outcomes it serves, what is in and out of scope, how it is organised and governed, what tolerances the programme manager may work within, and how it will end. Charters go wrong when they restate the strategy, when they promise outcomes the programme cannot deliver alone, or when they are signed and never consulted again.

When to use

• A transformation pack or AI roadmap has been agreed and someone must now run it as a programme.
• Several AI initiatives (a Copilot rollout, an agent build route, a CoE launch) are running without a common mandate.
• A sponsor asks what the programme is committing to, by when, and with what money and people.
• A programme has drifted and needs re-chartering after a change in scope, sponsor or funding.

When not to use

• Agreeing the strategic outcomes and principles the programme serves - use ai-strategy:strategic-outcomes.
• Writing the charter of the AI Centre of Excellence, which outlives the programme - use ai-centre-of-excellence:coe-charter.
• Producing the tailored set of transformation artefacts - use organisation-tailoring:transformation-pack.
• Building the funding case before the programme is approved - use ai-strategy:investment-case.
• Planning milestones and dependencies across workstreams in detail - use programme-management:integrated-roadmap.
• Defining the evidence each programme gate needs - use programme-management:stage-gates.

Questions to ask first

1. Which agreed strategic outcomes does this programme serve, and which of them can it influence directly rather than only contribute to?
2. Who is the accountable sponsor, and what decisions are they reserving for themselves rather than delegating to a programme board?
3. What is explicitly out of scope, including platforms, business units and solution types the organisation has decided not to pursue yet?
4. What funding envelope and people capacity have been committed, and for how long?
5. What would make the sponsor stop or re-scope the programme early?

Required inputs

• Agreed strategic outcomes from ai-strategy:strategic-outcomes, or the outcomes section of the transformation pack.
• The AI roadmap or pack index showing the initiatives and artefacts the programme will deliver.
• The confirmed edition and assurance overlay from organisation-tailoring:edition-and-archetype, which set the weight of governance.
• The ownership map from organisation-tailoring:ownership-map, showing declared roles and vacancies.
• Any approved funding decision or investment case.

Where an input is missing, write [To confirm: ...] in the charter and list it as a condition of sign-off. Never invent a budget, a date or an owner to make the charter look complete; a charter with visible gaps is more useful than one that hides them.

Decision framework

Decide the shape of the charter from the programme type and edition. The programme manager runs within tolerances; any forecast breach goes to the board, and any breach of the sponsor's reserved limits goes to the sponsor.

Every outcome the charter names must pass one test: can the programme show its contribution with a measure and a baseline? If not, the outcome belongs to the strategy, and the charter names the programme's contribution instead.

Practitioner approach

Start from the outcomes, not the activities. Write one sentence for each strategic outcome the programme serves and, beside it, what the programme will deliver that moves it. "Reduce time spent on case summaries" becomes "deliver role scenarios and a governed summarisation agent for case handlers, with a measured baseline". This separates what the programme controls from what the business must do with it, which is where most disputes about AI programme success start.

Next, write scope as decisions. Name the platforms in scope, the business units and personas, the solution types and the risk tiers the programme will deliver. Then write the exclusions with equal care: tier 3 and 4 solutions deferred until responsible AI review capacity exists, for example, or Foundry work excluded from the first tranche. Exclusions prevent the programme quietly absorbing every AI request in the organisation.

Organise the work into a small number of workstreams, each with an accountable role from the ownership map. Use the programme type table as a starting point and merge workstreams where one role leads several. A programme with more workstreams than accountable people will not hold together.

Agree governance and tolerances with the sponsor before writing them down. The sponsor reserves some decisions (risk acceptance above an agreed tier, changes to outcomes, funding beyond the envelope); the board takes others; the programme manager acts within tolerance. Keep the CoE's standing governance separate from the programme's: the programme delivers change, the CoE runs what remains afterwards, and the charter should say when responsibilities pass from one to the other.

Record the funding envelope and committed capacity as they have been approved, not as hoped. Licence and consumption costs are often the least certain lines; mark them [To confirm: ...] and route licensing questions to the Microsoft licensing guide or a licensing partner rather than estimating them in the charter.

Write closure criteria at the start. A programme closes when its outcomes have measured contributions, its products have owners, support routes and review dates, and its remaining work has been handed to the CoE or business units. Without these criteria AI programmes either never close or close when the money runs out.

Finally, take the charter to the sponsor for signature with the open items listed. Store it with the programme's records, review it at each stage gate, and re-charter rather than drift if scope, sponsor or funding changes materially.

Outputs

• A programme charter on the programme-charter template: mandate, outcomes served and the programme's contribution, scope and exclusions, workstreams with accountable roles, governance and decision rights, tolerances, funding envelope and capacity, key assumptions, closure criteria and sign-off.
• A list of open items and conditions of sign-off, each with the role who will resolve it.
• A record of the sponsor's approval and the date of the first charter review.

Microsoft platform considerations

Name the Microsoft platforms in scope as patterns of work (individual Copilot use, shared agents, delegated Cowork tasks, engineered Foundry solutions, Power Platform automation) rather than relying on product names, which change. Where scope depends on a capability being available or licensed, mark it as an assumption and check it against the source records in references/sources.md before the charter is signed.

Adoption considerations

An adoption programme's charter must name the business roles accountable for adoption in their areas; an IT-led charter for Copilot rollout tends to end at licence assignment. Include Champions and line managers as contributors, not as accountable owners.

Knowledge considerations

Where agents or knowledge-grounded scenarios are in scope, list knowledge readiness as a named workstream or dependency with an accountable role. Programmes that assume content is ready discover otherwise during testing.

Security and privacy considerations

The charter should state that solutions at risk tier 2 and above pass the security-privacy gate before release, and that the programme does not decide data protection questions; those route to the DPO or legal adviser. Store the charter in the organisation's own location with access limited to the programme team and board.

Responsible AI considerations

State whether tier 3 and 4 uses are in scope. If they are, the charter names the accountable executive for risk acceptance and the responsible-ai review route; if not, it says so plainly so requests can be redirected.

Evaluation requirements

Not applicable to the charter itself, which is a governance document; it should commit the programme to the evaluation gates its solutions need, held by evaluation-quality from risk tier 2.

Value measures

The charter names, for each outcome, the measure, the baseline or the plan to establish it, and the business owner, drawing on value-realisation:benefit-realisation-plan where it exists. Programme measures are reported at team or role level, never for individuals.

Scale notes

Starter

A two-page charter: three outcomes, scope and exclusions, the sponsor's decisions, a funding note, and a review date. Often agreed at the AI working group and kept with its terms of reference.

Scale

A full charter with a programme board, three to six workstreams with accountable roles, tolerances for time, money, scope and risk, and closure criteria that hand ownership to the CoE.

Enterprise

A programme charter with business-unit annexes, tranches with their own closure criteria, and an explicit link to the portfolio or executive board that sits above the programme.

Hand-offs

• To programme-management:integrated-roadmap to plan milestones and dependencies within the chartered scope.
• To programme-management:programme-board-cadence to set up the forums the charter describes.
• To programme-management:stage-gates to define the gates and evidence the charter commits to.
• To programme-management:budget-and-capacity to track the funding envelope and capacity.
• To programme-management:programme-risk-log with the assumptions recorded in the charter.

Reviewer gates

Not applicable, because the charter releases no solution; it must still name security-privacy from risk tier 2 and, where in scope, responsible-ai, evaluation-quality and design-authority as gates the programme's solutions pass.

Failure modes

• The charter promises business outcomes the programme cannot deliver alone, and the programme is later judged a failure for things it never controlled.
• Scope has no exclusions, so every AI request in the organisation lands on the programme.
• Workstreams outnumber accountable people, and the programme manager quietly becomes owner of everything.
• Licence and consumption costs are estimated from memory and the envelope proves wrong within months.
• The charter is signed once and never reviewed, so scope drifts without a decision.

Sources

references/sources.md in this skill lists the source records behind this skill, what each is authoritative for, how volatile it is and what you may do with it. Product availability, licensing, limits and preview status change often, so check the current source before stating them, and cite what you used.

Never

• Invent budgets, dates, owners or licence positions to complete the charter.
• Charter a programme without a named accountable sponsor role.
• Merge the programme's temporary governance with the CoE's standing governance without saying when one hands over to the other.
• State a licensing conclusion; route it to the Microsoft licensing guide or a licensing partner.