<!--  
LLM INSTRUCTIONS: Fill in the [ Add details... ] placeholders based on project context.

The program charter is the document that authorises a program. It states why the
program 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 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 intent behind separating the components from the objectives is that the two
are routinely confused: components describe what exists, objectives describe what
must change. A program whose component list could be pasted into the objectives
section has not yet decided what it is for.

Alignment: the program charter should be aligned and consistent with the
following documents: Portfolio roadmap, Business case, Program management plan,
Organizational change management plan.

Writing guidance:

*   State the purpose as the change the program exists to bring about, not as a
    description of the work. "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.

*   Give every objective a measure and a date. An objective that cannot be
    tested cannot be reported against, and an objective reported against only
    by opinion is indistinguishable from an aspiration.

*   Name the authority the program manager holds, and equally what they do not
    hold. A charter that grants everything appears to grant everything, and the
    first real escalation then has no precedent to follow.

*   Record the funding envelope as an assumption where it is not yet approved. A
    charter that treats unapproved funding as available sets the program up to
    discover the shortfall after it has committed the component projects.

*   Record what happens when an objective is not met. A charter with no stated
    response to failure leaves that decision to whoever happens to be in the
    room when it arises.

Tailoring Notes:

*   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.

Column guidance, by column:

Objective rows:

*   **ID:** The identifier for the objective, used in the components, benefits
    and reporting sections so that progress against it can be traced.

*   **Objective:** What must be true when the program succeeds, stated so that
    someone who disagrees with it could say why.

*   **Measure:** How achievement will be established, naming the source of the
    figure rather than the sentiment. A measure with no source is a number
    nobody can reproduce.

*   **Target Date:** When the objective must be met, which is what makes it a
    target rather than a direction.

*   **Owner:** The single role accountable for the objective, which is normally
    not the program manager for every objective.

*   **Status:** Where the objective currently stands, from a fixed set.

Component rows:

*   **Component ID:** The stable identifier of the component project, matching
    the identifier used in the portfolio roadmap.

*   **Component Name:** The name of the project or operation within the program.

*   **Objective Linkage:** Which program objectives this component serves. A
    component linked to no objective is a candidate for removal, and the charter
    is where that becomes visible before the money is committed.

*   **Status:** Where the component currently stands, from the fixed set used
    across the program.

*   **Owner:** Who is accountable for the component, which will usually not be
    the program manager.

Benefit rows:

*   **Benefit ID:** The identifier for the benefit.

*   **Benefit:** The benefit the program expects to produce.

*   **Category:** Whether it is financial or non-financial. The two are
    governed differently, and a benefit recorded without a category is usually
    counted at the value the writer found most convenient.

*   **Beneficiary:** Who receives the benefit, named rather than described,
    because a benefit with no identifiable recipient is not a benefit the
    program can be held to.

*   **Realization Mechanism:** How the benefit will actually be captured, which
    is where most assumed benefits turn out not to be.

*   **Realization Date:** When the benefit is expected to be realised, which for
    a financial benefit is often well after the project that created it ends.

Authority rows:

*   **Decision Type:** What kind of decision this row concerns.

*   **Authority Level:** The level the program manager may decide at, such as
    team, department, or business unit.

*   **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.

*   **Limits or Conditions:** What the authority does not extend to, which is
    the half of the row that prevents the dispute later.

Risk and assumption rows:

*   **ID:** The identifier for the risk or assumption.

*   **Type:** Whether the row is a Risk or an Assumption.

*   **Description:** What is at stake, or what is being taken for granted.

*   **Impact on Program:** What happens to the program if the risk occurs or the
    assumption proves false.

*   **Owner:** Who watches it.

*   **Review Date:** When it will next be checked.
-->

<h3 dir="ltr" align="right">{{Company_Name}}</h3>
<h2 dir="ltr" align="right">{{Program_Name}} - {{Program_ID}}</h2>
<h1 dir="ltr" align="center">PROGRAM CHARTER</h1>

| **Date Prepared:** {{Current_Date}} | **Program Manager:** {{Program_Manager_Name}} | **Prepared By:** {{Prepared_By}} |
| :--- | :--- | :--- |  

---

## 1. Program Purpose and Rationale
<!-- 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. Record the business driver from the
 portfolio roadmap so the program can be traced back to the strategy it serves.
 State what happens if the program is not undertaken, since that is the test
 every charter is eventually measured against, usually several years later. -->

**Program Purpose:** [ Add details... ]

**Business Driver and Strategic Alignment:** [ Add details... ]

**Problem or Opportunity Statement:** [ Add details... ]

**Consequence of Not Proceeding:** [ Add details... ]

**Program Vision Statement:** [ Add details... ]

---

## 2. Program Objectives
<!-- What must be true when the program succeeds. Every objective carries a
 measure and a target date, because an objective that cannot be tested cannot be
 reported against, and one reported only by opinion is indistinguishable from an
 aspiration. Where a component has already been funded against an objective
 before the charter was written, the objective is often written to fit the
 component; check the direction of that fit, because a program whose objectives
 are derived from its components has inherited their scope without choosing it.
 Add or remove rows as needed. -->

| ID | Objective | Measure | Target Date | Owner | Status |
| :---: | :--- | :--- | :---: | :--- | :---: |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

---

## 3. Component Projects and Operations
<!-- What the program is made of, as distinct from what it must achieve. A
 component linked to no objective is a candidate for removal, and the charter is
 where that becomes visible before the money is committed rather than after. Use
 the component identifiers from the portfolio roadmap so the two can be joined.
 Note where a component is shared with another program, because a component
 reported to two owners is reported to neither once they disagree. Add or remove
 rows as needed. -->

| Component ID | Component Name | Objective Linkage | Status | Owner |
| :---: | :--- | :--- | :---: | :--- |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

---

## 4. Program Benefits
<!-- What the program is expected to produce that the components individually
 would not. A benefit recorded without a beneficiary is not one the program can
 be held to, and a benefit without a realization mechanism is usually an
 assumption rather than a plan: the mechanism is what distinguishes a benefit
 the program will capture from a benefit the business hopes will happen. For a
 financial benefit, record when it is realised, which is commonly long after
 the component that created it has closed. Add or remove rows as needed. -->

| Benefit ID | Benefit | Category | Beneficiary | Realization Mechanism | Realization Date |
| :---: | :--- | :--- | :--- | :--- | :---: |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

---

## 5. Program Manager Authority and Governance
<!-- What the program manager may decide, and equally what they may not. A
 charter that grants everything appears to grant everything, and the first real
 escalation then has no precedent to follow. Name the escalation path, so the
 escalation does not have to be negotiated at the moment it is needed. Record
 the funding position honestly, including what is not yet approved: a charter
 that treats unapproved funding as available sets the program up to discover the
 shortfall after it has already committed the components. Add or remove rows as
 needed. -->

**Program Manager Authority Statement:** [ Add details... ]

**Authority Retained by the Sponsor:** [ Add details... ]

**Program Governance Forum:** [ Add details... ]

**Reporting Cadence and Audience:** [ Add details... ]

**Escalation Path:** [ Add details... ]

**Funding Position:** [ Add details... ]

| Decision Type | Authority Level | Escalation Path | Limits or Conditions |
| :--- | :--- | :--- | :--- |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

---

## 6. Risks and Assumptions
<!-- What the charter takes for granted, and what could undermine it. These are
 the program-level items; component-level risks belong in the components' own
 registers and are not duplicated here. A risk recorded without an owner is not
 being watched, and an assumption without a review date becomes a fact by
 default exactly when it should still be in question. Where the program has no
 funded contingency, say so, because a program that expects none has usually
 simply not looked. Add or remove rows as needed. -->

| ID | Type | Description | Impact on Program | Owner | Review Date |
| :---: | :--- | :--- | :--- | :--- | :---: |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

---

## 7. Response to Objective Failure
<!-- What happens when an objective is not met. 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. Record
 whether the response is to replan, to reduce scope, to extend, or to close the
 objective, and who takes that decision. Add or remove rows as the program's
 governance requires. -->

**Defined Response:** [ Add details... ]

**Decision Authority:** [ Add details... ]

**Trigger for Reassessment:** [ Add details... ]

---

## 8. Sign-off and Approvals

| Role | Name | Signature | Date |
| :--- | :--- | :---: | :---: |
| **Program Manager** | {{Program_Manager_Name}} | _______________________ | [ .... - .... - .... ] |
| **Program Sponsor** | {{Program_Sponsor_Name}} | _______________________ | [ .... - .... - .... ] |
| **Business Owner** | {{Business_Owner_Name}} | _______________________ | [ .... - .... - .... ] |
---

<div dir="ltr" align="right" style="margin-top: 20px; font-size: 12px; color: #7f8c8d;">
  <span>Electronic Audit Trail: Hash SHA256: {{Audit_Trail_SHA256_Hash}}</span> <br>
  <strong>Template:</strong> Program Charter | <strong>Ref:</strong> PMO-00.02 <br>
  <i>Generated on: {{Current_Timestamp}}, by <a href="https://github.com/fakhruldeen/Tasleemat/" style="color: #7f8c8d;">Tasleemat</a></i>
</div>

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://tasleemat.pmo/schemas/completed/PMO-00.02.schema.json",
  "title": "Completed Program Charter Data Contract",
  "description": "Additive structural schema validating completed Program Charter artifact data payloads (PMO-00.02).",
  "type": "object",
  "properties": {
    "artifact_id": {
      "type": "string",
      "const": "PMO-00.02"
    },
    "metadata": {
      "type": "object",
      "properties": {
        "project_name": {
          "type": "string",
          "minLength": 1
        },
        "project_code": {
          "type": "string"
        },
        "date_prepared": {
          "type": "string",
          "format": "date"
        },
        "project_manager": {
          "type": "string",
          "minLength": 1
        },
        "prepared_by": {
          "type": "string",
          "minLength": 1
        },
        "version": {
          "type": "string"
        },
        "status": {
          "type": "string",
          "enum": [
            "draft",
            "baselined",
            "in_review",
            "approved"
          ]
        }
      },
      "required": [
        "project_name",
        "date_prepared",
        "project_manager",
        "prepared_by"
      ]
    },
    "program_purpose_and_rationale": {
      "type": "object",
      "properties": {
        "program_purpose": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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."
        }
      },
      "required": [
        "program_purpose",
        "business_driver_and_strategic_alignment",
        "problem_or_opportunity_statement",
        "consequence_of_not_proceeding",
        "program_vision_statement"
      ]
    },
    "program_objectives": {
      "type": "object",
      "properties": {
        "id": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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."
        }
      },
      "required": [
        "id",
        "objective",
        "measure",
        "target_date",
        "owner",
        "status"
      ]
    },
    "component_projects_and_operations": {
      "type": "object",
      "properties": {
        "component_id": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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."
        }
      },
      "required": [
        "component_id",
        "component_name",
        "objective_linkage",
        "status",
        "owner"
      ]
    },
    "program_benefits": {
      "type": "object",
      "properties": {
        "benefit_id": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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."
        }
      },
      "required": [
        "benefit_id",
        "benefit",
        "category",
        "beneficiary",
        "realization_mechanism",
        "realization_date"
      ]
    },
    "program_manager_authority_and_governance": {
      "type": "object",
      "properties": {
        "program_manager_authority_statement": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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."
        },
        "decision_escalation_path": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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."
        }
      },
      "required": [
        "program_manager_authority_statement",
        "authority_retained_by_the_sponsor",
        "program_governance_forum",
        "reporting_cadence_and_audience",
        "escalation_path",
        "funding_position",
        "decision_type",
        "authority_level",
        "decision_escalation_path",
        "limits_or_conditions"
      ]
    },
    "risks_and_assumptions": {
      "type": "object",
      "properties": {
        "id": {
          "type": "string",
          "minLength": 1,
          "description": "The identifier for the risk or assumption, so it can be referred to from the objectives and from reporting without ambiguity."
        },
        "type": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "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": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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."
        }
      },
      "required": [
        "id",
        "type",
        "description",
        "impact_on_program",
        "owner",
        "review_date"
      ]
    },
    "response_to_objective_failure": {
      "type": "object",
      "properties": {
        "defined_response": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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": {
          "type": "string",
          "minLength": 1,
          "description": "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."
        }
      },
      "required": [
        "defined_response",
        "decision_authority",
        "trigger_for_reassessment"
      ]
    }
  },
  "required": [
    "artifact_id",
    "metadata",
    "program_purpose_and_rationale",
    "program_objectives",
    "component_projects_and_operations",
    "program_benefits",
    "program_manager_authority_and_governance",
    "risks_and_assumptions",
    "response_to_objective_failure"
  ]
}

{
  "_llm_instructions": "Fill in the 'project_title' and 'date_prepared' properties, and the 'value' property of each field, based on the provided project context. Reference parameters.md for global project variables.",
  "form_name": "Program Charter",
  "document_reference": "PMO-00.02",
  "project_title": "",
  "date_prepared": "",
  "fields": {
    "f01_Program_Purpose": {
      "section": "Program Purpose and Rationale",
      "label": "Program Purpose",
      "guidance": "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.",
      "value": ""
    },
    "f02_Business_Driver_and_Strategic_Alignment": {
      "section": "Program Purpose and Rationale",
      "label": "Business Driver and Strategic Alignment",
      "guidance": "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.",
      "value": ""
    },
    "f03_Problem_or_Opportunity_Statement": {
      "section": "Program Purpose and Rationale",
      "label": "Problem or Opportunity Statement",
      "guidance": "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.",
      "value": ""
    },
    "f04_Consequence_of_Not_Proceeding": {
      "section": "Program Purpose and Rationale",
      "label": "Consequence of Not Proceeding",
      "guidance": "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.",
      "value": ""
    },
    "f05_Program_Vision_Statement": {
      "section": "Program Purpose and Rationale",
      "label": "Program Vision Statement",
      "guidance": "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.",
      "value": ""
    },
    "f06_ID": {
      "section": "Program Objectives",
      "label": "ID",
      "guidance": "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.",
      "value": ""
    },
    "f07_Objective": {
      "section": "Program Objectives",
      "label": "Objective",
      "guidance": "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.",
      "value": ""
    },
    "f08_Measure": {
      "section": "Program Objectives",
      "label": "Measure",
      "guidance": "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.",
      "value": ""
    },
    "f09_Target_Date": {
      "section": "Program Objectives",
      "label": "Target Date",
      "guidance": "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.",
      "value": ""
    },
    "f10_Owner": {
      "section": "Program Objectives",
      "label": "Owner",
      "guidance": "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.",
      "value": ""
    },
    "f11_Status": {
      "section": "Program Objectives",
      "label": "Status",
      "guidance": "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.",
      "value": ""
    },
    "f12_Component_ID": {
      "section": "Component Projects and Operations",
      "label": "Component ID",
      "guidance": "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.",
      "value": ""
    },
    "f13_Component_Name": {
      "section": "Component Projects and Operations",
      "label": "Component Name",
      "guidance": "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.",
      "value": ""
    },
    "f14_Objective_Linkage": {
      "section": "Component Projects and Operations",
      "label": "Objective Linkage",
      "guidance": "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.",
      "value": ""
    },
    "f15_Status": {
      "section": "Component Projects and Operations",
      "label": "Status",
      "guidance": "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.",
      "value": ""
    },
    "f16_Owner": {
      "section": "Component Projects and Operations",
      "label": "Owner",
      "guidance": "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.",
      "value": ""
    },
    "f17_Benefit_ID": {
      "section": "Program Benefits",
      "label": "Benefit ID",
      "guidance": "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.",
      "value": ""
    },
    "f18_Benefit": {
      "section": "Program Benefits",
      "label": "Benefit",
      "guidance": "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.",
      "value": ""
    },
    "f19_Category": {
      "section": "Program Benefits",
      "label": "Category",
      "guidance": "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.",
      "value": ""
    },
    "f20_Beneficiary": {
      "section": "Program Benefits",
      "label": "Beneficiary",
      "guidance": "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.",
      "value": ""
    },
    "f21_Realization_Mechanism": {
      "section": "Program Benefits",
      "label": "Realization Mechanism",
      "guidance": "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.",
      "value": ""
    },
    "f22_Realization_Date": {
      "section": "Program Benefits",
      "label": "Realization Date",
      "guidance": "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.",
      "value": ""
    },
    "f23_Program_Manager_Authority_Statement": {
      "section": "Program Manager Authority and Governance",
      "label": "Program Manager Authority Statement",
      "guidance": "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.",
      "value": ""
    },
    "f24_Authority_Retained_by_the_Sponsor": {
      "section": "Program Manager Authority and Governance",
      "label": "Authority Retained by the Sponsor",
      "guidance": "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.",
      "value": ""
    },
    "f25_Program_Governance_Forum": {
      "section": "Program Manager Authority and Governance",
      "label": "Program Governance Forum",
      "guidance": "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.",
      "value": ""
    },
    "f26_Reporting_Cadence_and_Audience": {
      "section": "Program Manager Authority and Governance",
      "label": "Reporting Cadence and Audience",
      "guidance": "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.",
      "value": ""
    },
    "f27_Escalation_Path": {
      "section": "Program Manager Authority and Governance",
      "label": "Escalation Path",
      "guidance": "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.",
      "value": ""
    },
    "f28_Funding_Position": {
      "section": "Program Manager Authority and Governance",
      "label": "Funding Position",
      "guidance": "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.",
      "value": ""
    },
    "f29_Decision_Type": {
      "section": "Program Manager Authority and Governance",
      "label": "Decision Type",
      "guidance": "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.",
      "value": ""
    },
    "f30_Authority_Level": {
      "section": "Program Manager Authority and Governance",
      "label": "Authority Level",
      "guidance": "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.",
      "value": ""
    },
    "f31_Escalation_Path": {
      "section": "Program Manager Authority and Governance",
      "label": "Escalation Path",
      "guidance": "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.",
      "value": ""
    },
    "f32_Limits_or_Conditions": {
      "section": "Program Manager Authority and Governance",
      "label": "Limits or Conditions",
      "guidance": "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.",
      "value": ""
    },
    "f33_ID": {
      "section": "Risks and Assumptions",
      "label": "ID",
      "guidance": "The identifier for the risk or assumption, so it can be referred to from the objectives and from reporting without ambiguity.",
      "value": ""
    },
    "f34_Type": {
      "section": "Risks and Assumptions",
      "label": "Type",
      "guidance": "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.",
      "value": ""
    },
    "f35_Description": {
      "section": "Risks and Assumptions",
      "label": "Description",
      "guidance": "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.",
      "value": ""
    },
    "f36_Impact_on_Program": {
      "section": "Risks and Assumptions",
      "label": "Impact on Program",
      "guidance": "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.",
      "value": ""
    },
    "f37_Owner": {
      "section": "Risks and Assumptions",
      "label": "Owner",
      "guidance": "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.",
      "value": ""
    },
    "f38_Review_Date": {
      "section": "Risks and Assumptions",
      "label": "Review Date",
      "guidance": "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.",
      "value": ""
    },
    "f39_Defined_Response": {
      "section": "Response to Objective Failure",
      "label": "Defined Response",
      "guidance": "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.",
      "value": ""
    },
    "f40_Decision_Authority": {
      "section": "Response to Objective Failure",
      "label": "Decision Authority",
      "guidance": "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.",
      "value": ""
    },
    "f41_Trigger_for_Reassessment": {
      "section": "Response to Objective Failure",
      "label": "Trigger for Reassessment",
      "guidance": "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.",
      "value": ""
    }
  }
}