Tasleemat Forms Guide

Project Artifact: Program Charter

Document Reference: PMO-00.02

This document provides a comprehensive, professional reference to understand the purpose and effective usage of the Program Charter in alignment with the Tasleemat framework.

1. What?

A formal Tasleemat-aligned project document known as the Program Charter, the document that authorises a program: why it exists, what it is accountable for delivering, and what authority and resources have been given to the program manager in order to deliver it.

It records the purpose and the business driver, the objectives with their measures and target dates, the component projects and which objectives they serve, the benefits and how they will actually be realised, the authority granted and the authority retained, the program-level risks and assumptions, and what happens when an objective is not met.

2. Why?

Because it is the point at which a group of individually sensible projects becomes a program with a single accountable owner and a single set of objectives. The separation of components from objectives is the part that matters: a program whose component list could be pasted into its objectives section has inherited its scope without choosing it, and a charter with no stated response to failure leaves that decision to whoever is in the room when it arises.

3. When?

This artifact is prepared at the PROGRAM AND PORTFOLIO MANAGEMENT Process Group, at the point the program is initiated and before any component project is funded against it.

4. Who?

Responsibilities: Sponsored by the executive who holds the funding and approves the charter. Owned by the Program Manager, who is accountable for delivering the objectives rather than for the components, since the components have their own owners. Reviewed by the PMO for consistency with the portfolio, and signed by the finance business partner who can confirm the funding position is real.

Tailoring Tips

A program charter may be combined with a business case where the organisation treats them as one approval artefact. If they are combined, keep both sets of content: the business case answers whether the program is worth doing, the charter answers who is accountable for doing it.
The components section may be a portfolio extract rather than a maintained list, where components change faster than the charter is revised. The form should say which, so a reader does not treat an extract as authoritative.
Add or remove sections as the program's own governance requires. A program with a formal benefits mandate carries a benefits section that a program without one does not need.
Where the program is small enough that one person holds all the authority, say so explicitly rather than leaving the authority section blank, and record which authority is being retained elsewhere.
The authority table can be replaced by a delegation of authority policy reference where the organisation issues one centrally, provided the charter records which policy version applies.

Alignment & Dependencies

1. Pre-requisites & Inputs (Upstream Dependencies)

Mandatory:
- Portfolio Roadmap (PMO-00.01)
- Business Case (PMO-01.01)
- Strategic Plan (External)
Optional / Contextual:
- Interdependency Register (PMO-00.03)
- Benefits Management Plan (PMO-01.02)

2. Downstream Dependents

Mandatory:
- Benefits Management Plan (PMO-01.02)
- Project Charter (PMO-03.01)
- Interdependency Register (PMO-00.03)
Optional / Contextual:
- Resource Capacity Matrix (PMO-00.04)
- Program Governance Plan (External)

5. How?

To accurately and professionally complete the PROGRAM CHARTER, the responsible party must populate the following sections based on the project context (ensure parameters.md is referenced for global project variables):

Program Purpose: The change the program exists to bring about, not a description of the work it will do. "Replace the billing platform" describes work; "so that month-end billing closes in three days rather than ten" describes a change, and only the second can be judged complete or not.
Business Driver and Strategic Alignment: The portfolio or strategy entry this program serves, named so the program can be traced back to the objective that funded it. A charter that cannot name its driver has no way to answer whether it is still worth doing once the strategy has moved on.
Problem or Opportunity Statement: The specific problem being solved or the specific opportunity being taken, stated so that someone who disagreed with it could say why. An opportunity described only in positive terms is indistinguishable from a wish, because nothing in the statement can fail.
Consequence of Not Proceeding: What happens if the program is not undertaken, including what is lost rather than only what is missed. This is the test every charter is eventually measured against, usually several years later by someone who was not present when it was written, and it is almost never recorded at the time.
Program Vision Statement: A short statement of the future state the program exists to create, in the organisation's own words. Keep it to a single sentence that someone outside the program could understand, since a vision statement read only by the program team is a statement to itself.
ID: The identifier for the objective, used in the components, benefits and reporting sections so that progress against it can be traced to the work that was meant to deliver it.
Objective: What must be true when the program succeeds, stated so that a reasonable person could disagree with it. Where the components were funded before the charter was written, check the direction of the fit: an objective written to fit a component has inherited that component's scope without choosing it.
Measure: How achievement will be established, naming the source of the figure rather than the sentiment behind it. A measure with no source cannot be reproduced by anyone checking the claim, and an objective whose evidence cannot be reproduced is an opinion with a number attached.
Target Date: When the objective must be met, which is what makes it a target rather than a direction. Where the date is inherited from a component's own plan rather than from the benefit it serves, record the date the benefit is actually expected rather than the date the work finishes.
Owner: The single role accountable for the objective, which is normally not the program manager for every objective. An objective owned by a team cannot be chased, because a team is never available when the answer is needed.
Status: Where the objective currently stands, from a fixed set agreed for the program. A free-text status cannot be rolled up, and a program whose objectives cannot be rolled up cannot be reported to the sponsor as anything other than a list.
Component ID: The stable identifier of the component project, matching the identifier used in the portfolio roadmap so the two can be joined and the same component is not tracked under two names.
Component Name: The name of the project or operation within the program, taken from its own charter. Where a component serves more than one program, record that here, because a component reported to two owners is reported to neither once they disagree.
Objective Linkage: Which program objectives this component serves, by identifier. A component linked to no objective is a candidate for removal, and the charter is the last point at which that is visible before the money is committed.
Status: Where the component currently stands, from the fixed set used across the program, so components are read against each other rather than each in the terms its own project used.
Owner: Who is accountable for the component, which will usually not be the program manager. The program manager remains accountable for the component's contribution to the objective, which is a different accountability and is worth stating as such.
Benefit ID: The identifier for the benefit, used in the benefits management plan and the value realization register so the same benefit is not counted twice under two names.
Benefit: The benefit the program expects to produce, preferably stating benefits the components would not produce individually, since those are the reason for having a program rather than a list of projects. A benefit that any one component would have delivered anyway is not a program benefit.
Category: Whether the benefit is financial or non-financial. The two are governed differently and are counted differently, and a benefit recorded without a category is usually valued at whichever the writer found more convenient.
Beneficiary: Who receives the benefit, named rather than described. A benefit with no identifiable recipient cannot be realised, because realisation requires someone to change their behaviour or take a decision they would not otherwise have taken.
Realization Mechanism: How the benefit will actually be captured, which is where most assumed benefits turn out not to be. The mechanism is what distinguishes a benefit the program will deliver from one the business hopes will occur, and without it the benefit is an aspiration with a number attached.
Realization Date: When the benefit is expected to be realised. For a financial benefit this is commonly well after the component that created it has closed, and recording the earlier date is the most common way a program's benefits appear to land on time when they have not.
Program Manager Authority Statement: What the program manager is authorised to decide and to commit, in the terms the organisation recognises. Record it as a grant rather than as a description of the role, so that a decision taken under it is defensible afterwards.
Authority Retained by the Sponsor: What the sponsor keeps, which is usually the larger share. A charter that grants everything appears to grant everything, and the first real escalation then has no precedent to follow because there was no line drawn to escalate across.
Program Governance Forum: The forum that governs the program, its membership, and what it decides rather than merely discusses. Record the distinction, because a forum that only discusses produces minutes about decisions taken elsewhere.
Reporting Cadence and Audience: How often the program reports, to whom, and in what form. Reporting to a body that cannot act on it is a reporting obligation rather than a control, and the difference is visible only when the report is examined.
Escalation Path: Who decides when the authority level is exceeded, named so the escalation does not have to be negotiated at the moment it is needed. Where the path is a role rather than a person, record how the person is identified, since roles go vacant.
Funding Position: What is approved, what is requested, and what is not yet decided, stated honestly. A charter that treats unapproved funding as available sets the program up to discover the shortfall after it has already committed the component projects to spend against it.
Decision Type: What kind of decision this row concerns, such as scope, budget, procurement, or personnel. Naming the kinds separately is what makes the authority levels below meaningful, since a single level cannot apply uniformly to all of them.
Authority Level: The level at which the program manager may decide this kind of decision, such as team, department, or business unit. Where the answer is the same for every row, consider whether the row is doing any work.
Escalation Path: Who decides when this authority level is exceeded, named for this decision type rather than in general, since the escalation for a budget decision is often not the escalation for a scope one.
Limits or Conditions: What this authority does not extend to, which is the half of the row that prevents the dispute later. A row recording only what is permitted invites the reading that everything not forbidden is also permitted.
ID: The identifier for the risk or assumption, so it can be referred to from the objectives and from reporting without ambiguity.
Type: Whether the row is a Risk or an Assumption. A risk may occur or not; an assumption is either true or false and can be tested. Recording both under one heading loses the distinction exactly where it decides whether the item needs watching or checking.
Description: What is at stake, or what is being taken for granted, stated so the assumption could be shown to have failed. An assumption phrased as a sentiment cannot be tested, and an untestable assumption is a hope with a risk rating attached.
Impact on Program: What happens to the program if the risk occurs or the assumption proves false, in objective, funding or schedule terms. An item recorded without an impact cannot be prioritised, because nothing distinguishes the consequential from the trivial.
Owner: Who watches this. A risk with no owner is not being watched, and the program's exposure grows silently while the register still appears complete.
Review Date: When this will next be checked. An assumption nobody revisits becomes a fact by default, which is precisely when the conditions that made it true have changed.
Defined Response: What happens when an objective is not met: whether the response is to replan, reduce scope, extend the date, or close the objective. A charter with no stated response to failure leaves that decision to whoever happens to be in the room when it arises, which is usually the person least able to afford the time.
Decision Authority: Who takes that decision, and whether the sponsor must be consulted first. Where the answer is that the program manager decides alone, record what they may not commit without the sponsor, since that is the part that is assumed rather than agreed.
Trigger for Reassessment: What specifically triggers the response: a date, a measure falling short by a stated margin, or an event. A trigger expressed as "if the objective is not met" is the same as the failure itself and gives no warning that the decision is coming.

📥 Associated Templates

6. Reference Example

A fully completed, gold-standard reference example illustrating this artifact in practice is available:

📖 Completed Example: 00_02_Program_Charter_Example.md