Benefits Management Plan

خطة إدارة الفوائد

tasleemat asset PMO-01.02 template --lang en

Deliverable Summary & Governance Boundaries

Lifecycle Phase Alignment

Phase 01: Business and Value Delivery

Sizing Tier Requirements

Tier 1

Validation Contract

This deliverable conforms to a strict companion Draft 2020-12 JSON Schema for automated structural and semantic validation.

tasleemat validate PMO-01.02 ./completed_data.json

Template Markdown (Bilingual)

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

Section Instructions:

**1. Benefits Baseline**
*   **Benefit Statements:** The benefits the project is expected to deliver, each stated as a measurable change rather than as an activity. "Improve the onboarding process" is an activity; "reduce time from application to first productive day by five working days" is a benefit, and only the second can later be shown to have happened or not.
*   **Benefit Categories:** The category of each benefit, distinguishing financial from non-financial. The split matters because the two are approved, measured and reported by different parties, and a plan that reports one blended number lets each party read it as favouring itself.
*   **Benefit Owners:** The role accountable for each benefit, which is normally not the project manager. The project manager can deliver the output; only someone in the operating role can change the measure the benefit is written against.
*   **Baseline Values:** The value of each measure today. Without a baseline no benefit can later be shown to have arrived, and a baseline written after delivery is a baseline chosen to flatter the delivery.
*   **Attribution Assumption:** Why the project is credited with the benefit rather than a trend that would have happened anyway. This is the assumption most often left unstated, and it is the one that determines whether a realised benefit can actually be claimed.

**2. Benefit Realisation Timeline**
*   **Realisation Date:** When each benefit is expected to be realised, stated as a date. Benefits do not arrive when the project does, and a plan that dates them at handover is a plan that will be found to be wrong in the first month after delivery.
*   **Lead and Lag Indicators:** The leading indicator that will be visible before the benefit itself. Benefits that are only measured at realisation give no warning while they are failing, and by the time the measure moves the intervention that could have helped has passed.
*   **Dis-benefits:** Any harm the project causes, including the disruption of changing a process people are working in. These are the benefits that do not appear in a benefits register because nobody is reporting them, and they are reliably larger than the expected gains.
*   **Dependencies:** What must be in place for each benefit to arrive, such as a policy change, a training programme, or a budget. A benefit dependent on something nobody has committed to is a benefit that will be attributed to nobody.

**3. Measurement and Governance**
*   **Benefit Metrics:** The measure for each benefit, with its source, its collection frequency and who collects it. A metric with no named collector is a metric that is not collected.
*   **Measurement Method:** How the value is calculated, stated so that two people would compute it the same way. Most disputed benefits are disputed over method rather than over outcome.
*   **Review Cadence:** How often the benefits are reviewed, and by whom. A benefits review that is held only at project closure is a retrospective exercise, by which point every decision available to influence the outcome has already passed.
*   **Benefit Status Rules:** What happens when a benefit is not on track: who is told, what action follows, and what would cause a benefit to be withdrawn from the plan. Without a rule the status is adjusted to match reality rather than reality being adjusted, which is the mechanism by which a plan quietly becomes fiction.
*   **Reporting Audience:** Who receives the benefits report, and in what form. The reporting line is what makes the numbers change; a benefits report sent only to the project team is a record rather than a control.

**4. Benefit Risks and Actions**
*   **Benefit Risks:** The risks that would prevent each benefit arriving, stated as the risk to the benefit rather than as a project risk. A schedule risk is not a benefit risk until it is traced to the benefit it threatens.
*   **Risk Owner and Response:** Who owns each risk to the benefit, and what the response is. An action with no owner is a wish, and the wish is repeated at every review until the review becomes routine.
*   **Early Warning Trigger:** The observable event that means the risk is materialising. Risks are usually reviewed after they have occurred, at which point the response is a record of what happened.
-->

<h3 dir="ltr" align="right">{{Company_Name}}</h3>
<h2 dir="ltr" align="right">{{Initiative_Name}} - {{Study_ID}}</h2>
<h1 dir="ltr" align="center">BENEFITS MANAGEMENT PLAN</h1>

| **Date Prepared:** {{Current_Date}} | **Lead Evaluator:** {{Lead_Evaluator_Name}} | **Prepared By:** {{Prepared_By}} |
| :--- | :--- | :--- |  

---

## 1. Benefits Baseline
<!-- The benefits as measurable changes, their owners, today's values, and why this project gets the credit. -->

| Benefit | Category | Owner | Baseline Value | Target Value | Attribution Assumption |
| :--- | :--- | :--- | ---: | ---: | :--- |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

**Benefit Statements:** [ Add details... ]

**Benefit Categories:** [ Add details... ]

**Benefit Owners:** [ Add details... ]

**Baseline Values:** [ Add details... ]

**Attribution Assumption:** [ Add details... ]

---

## 2. Benefit Realisation Timeline
<!-- When each benefit is expected to arrive, what will be visible beforehand, what harm is expected, and what it depends on. -->

| Benefit | Realisation Date | Lead Indicator | Lead and Lag | Dependencies | Dis-benefits |
| :--- | :---: | :--- | :--- | :--- | :--- |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

**Realisation Date:** [ Add details... ]

**Lead and Lag Indicators:** [ Add details... ]

**Dis-benefits:** [ Add details... ]

**Dependencies:** [ Add details... ]

---

## 3. Measurement and Governance
<!-- The measures, the method, the cadence, and what happens when a benefit slips. -->

**Benefit Metrics:** [ Add details... ]

**Measurement Method:** [ Add details... ]

**Review Cadence:** [ Add details... ]

**Benefit Status Rules:** [ Add details... ]

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

---

## 4. Benefit Risks and Actions
<!-- The risks to the benefits themselves, who owns each, and the observable event that means it is happening. -->

| Benefit | Benefit Risk | Owner | Response | Early Warning Trigger |
| :--- | :--- | :--- | :--- | :--- |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

**Benefit Risks:** [ Add details... ]

**Risk Owner and Response:** [ Add details... ]

**Early Warning Trigger:** [ Add details... ]

---

### Sign-off and Approvals

| Role | Name | Signature | Date |
| :--- | :--- | :---: | :---: |
| **Benefit / Business Owner** | {{Benefit_Owner_Name}} | _______________________ | [ .... - .... - .... ] |
| **Project Manager** | {{Project_Manager_Name}} | _______________________ | [ .... - .... - .... ] |
| **Project Sponsor** | {{Project_Sponsor_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> BENEFITS MANAGEMENT PLAN | <strong>Ref:</strong> PMO-01.02 <br>
  <i>Generated on: {{Current_Timestamp}}, by <a href="https://github.com/fakhruldeen/Tasleemat/" style="color: #7f8c8d;">Tasleemat</a></i>
</div>

User Guide & Practitioner Instructions

Tasleemat Forms Guide

Project Artifact: Benefits Management Plan

Document Reference: PMO-01.02

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

1. What?

A plan that defines the benefits a project is expected to deliver, fixes their present value as a baseline, assigns each to an owner, dates when each is expected to be realised, states the measure and method by which it will be checked, and records what happens to the plan when a benefit does not arrive. It is distinct from the value realization register, which tracks individual benefits as they move, where this plan sets the rules those benefits are tracked under.

2. Why?

Because delivery and benefit are different events with different dates, and only one of them happens while the project team is still watching. A project that closes on time is a statement about outputs; whether the measure moved is a separate claim that nobody is accountable for verifying unless it was written down before delivery began, with a baseline and a name against it. Writing it afterwards is not the same act, because the baseline can then only be chosen with knowledge of the outcome.

3. When?

This artifact is primarily prepared, utilized, and updated during the BUSINESS AND VALUE DELIVERY Process Group of the project lifecycle. It is written before delivery, reviewed through delivery and after it, and kept alive until the last benefit is realised, which is usually well beyond project closure.

4. Who?

Responsibilities: Owned by the business owner, not the project manager, because the manager delivers the output while the benefit is realised in the operating role that has to change its practice for the measure to move. It is reviewed by the sponsor, who is accountable for the investment decision the benefits were part of the case for.

Tailoring Tips

Financial and non-financial benefits may be tracked in separate sections with different owners and cadences, which is usually clearer than one blended figure that each interested party reads in its own favour.
Where benefits are realised through a third party, the plan may name the third party as owner, but should still state the measure, since an outsourced benefit cannot be assumed from the fact of the contract.
The dis-benefits field should be retained even where nothing is expected, because an empty field records that the question was asked, and a plan that never asked cannot later be shown to have been complete.
For a small project the plan may be reduced to a single table of benefits with owners and dates, provided the status rule and the measurement method are retained; those two are what turn the table into a control.
The plan may be handed to the operations function at closure, but the review cadence and the status rules should be agreed with that function before handover, since neither can be imposed afterwards.

Alignment & Dependencies

1. Pre-requisites & Inputs (Upstream Dependencies)

Mandatory:
- Business Case (PMO-01.01)
- Project Charter (PMO-03.01)
Optional / Contextual:
- Program Charter (PMO-00.02)
- Enterprise Strategic Goals

2. Downstream Dependents

Mandatory:
- Value Realization Register (PMO-01.03)
- Project Management Plan (PMO-04.01.01)
- Project / Phase Closeout (PMO-07.03)
Optional / Contextual:
- Project Roadmap (PMO-04.01.03)
- Transition to Operations Checklist (PMO-07.04)

5. How?

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

Benefit Statements: The benefits the project is expected to deliver, each stated as a measurable change rather than as an activity. "Improve the onboarding process" is an activity; "reduce time from application to first productive day by five working days" is a benefit, and only the second can later be shown to have happened or not.
Benefit Categories: The category of each benefit, distinguishing financial from non-financial. The split matters because the two are approved, measured and reported by different parties, and a plan that reports one blended number lets each party read it as favouring itself.
Benefit Owners: The role accountable for each benefit, which is normally not the project manager. The project manager can deliver the output; only someone in the operating role can change the measure the benefit is written against.
Baseline Values: The value of each measure today. Without a baseline no benefit can later be shown to have arrived, and a baseline written after delivery is a baseline chosen to flatter the delivery.
Attribution Assumption: Why the project is credited with the benefit rather than a trend that would have happened anyway. This is the assumption most often left unstated, and it is the one that determines whether a realised benefit can actually be claimed.
Realisation Date: When each benefit is expected to be realised, stated as a date. Benefits do not arrive when the project does, and a plan that dates them at handover is a plan that will be found to be wrong in the first month after delivery.
Lead and Lag Indicators: The leading indicator that will be visible before the benefit itself. Benefits that are only measured at realisation give no warning while they are failing, and by the time the measure moves the intervention that could have helped has passed.
Dis-benefits: Any harm the project causes, including the disruption of changing a process people are working in. These are the benefits that do not appear in a benefits register because nobody is reporting them, and they are reliably larger than the expected gains.
Dependencies: What must be in place for each benefit to arrive, such as a policy change, a training programme, or a budget. A benefit dependent on something nobody has committed to is a benefit that will be attributed to nobody.
Benefit Metrics: The measure for each benefit, with its source, its collection frequency and who collects it. A metric with no named collector is a metric that is not collected.
Measurement Method: How the value is calculated, stated so that two people would compute it the same way. Most disputed benefits are disputed over method rather than over outcome.
Review Cadence: How often the benefits are reviewed, and by whom. A benefits review held only at project closure is a retrospective exercise, by which point every decision available to influence the outcome has already passed.
Benefit Status Rules: What happens when a benefit is not on track: who is told, what action follows, and what would cause a benefit to be withdrawn from the plan. Without a rule the status is adjusted to match reality rather than reality being adjusted, which is the mechanism by which a plan quietly becomes fiction.
Reporting Audience: Who receives the benefits report, and in what form. The reporting line is what makes the numbers change; a benefits report sent only to the project team is a record rather than a control.
Benefit Risks: The risks that would prevent each benefit arriving, stated as the risk to the benefit rather than as a project risk. A schedule risk is not a benefit risk until it is traced to the benefit it threatens.
Risk Owner and Response: Who owns each risk to the benefit, and what the response is. An action with no owner is a wish, and the wish is repeated at every review until the review becomes routine.
Early Warning Trigger: The observable event that means the risk is materialising. Risks are usually reviewed after they have occurred, at which point the response is a record of what happened.

📥 Associated Templates

6. Reference Example

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

📖 Completed Example: 01_02_Benefits_Management_Plan_Example.md

LLM Generation Prompt & Agent Instructions

BENEFITS MANAGEMENT PLAN - LLM GENERATION GUIDE

System Prompt / Instructions: This document serves as the detailed instruction set for generating the BENEFITS MANAGEMENT PLAN. When asked to populate this form, use the guidance provided for each section below to accurately generate the required content. Reference parameters.md for global project variables.

Context & Definition: A benefits management plan is the answer to a question the project itself cannot answer: whether the thing that was built is being used. A project that delivers on time, on scope and on budget has still failed if the measure it was supposed to move has not moved, and nothing in the conventional triple constraint would have shown that.

The four sections follow the life of a benefit rather than the life of a project. The baseline fixes what the benefit is worth today and who is accountable for it, because a benefit with no baseline and no owner is a claim rather than a target. The timeline fixes when it is expected to arrive and what will be visible beforehand. The measurement section fixes who collects the number and what happens when it does not move. The risks section traces what would prevent the benefit arriving, as distinct from what would delay the project.

The section that is most often left out is the rule for what happens when a benefit slips. Without it the status is revised to match reality rather than reality being revised, and that is how a plan becomes fiction while still being reported as on track.

Alignment & Dependencies: * Pre-requisites (Inputs): * Mandatory: Business Case (PMO-01.01), Project Charter (PMO-03.01) * Optional: Program Charter (PMO-00.02), Enterprise Strategic Goals * Downstream Dependents: * Mandatory: Value Realization Register (PMO-01.03), Project Management Plan (PMO-04.01.01), Project / Phase Closeout (PMO-07.03) * Optional: Project Roadmap (PMO-04.01.03), Transition to Operations Checklist (PMO-07.04)

1. Benefits Baseline

Benefit Statements

Instruction: The benefits the project is expected to deliver, each stated as a measurable change rather than as an activity. "Improve the onboarding process" is an activity; "reduce time from application to first productive day by five working days" is a benefit, and only the second can later be shown to have happened or not.