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 (External)

2. Downstream Dependents

Mandatory:
- Value Realization Register (PMO-01.03)
- Project Management Plan (PMO-04.01.01)
- Project or 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