Tasleemat Forms Guide

Project Artifact: Value Realization Register

Document Reference: PMO-01.03

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

1. What?

A register that records, for each benefit the business case authorised, what the measure was before the project, what it was expected to be, what it has been measured at, and when. It carries the measurement method for each benefit, the owner accountable for it, the signed variance, and what is being done about any variance. It is a record of movement, not a plan, and it is expected to remain open well after the project has closed.

2. Why?

Because a value with no date and no baseline is not evidence of anything. A figure on its own can be anything: measured at the wrong moment, on a changed definition, against a baseline chosen afterwards. The register is what makes the claim checkable by someone who was not there, and it is the only artifact that still exists when the project team that could explain the numbers has dispersed.

3. When?

This artifact is primarily prepared, utilized, and updated during the BUSINESS AND VALUE DELIVERY Process Group of the project lifecycle. It opens with the benefits and runs until the last benefit is realised or formally withdrawn, which is usually beyond project closure and belongs to the business owner rather than the project team.

4. Who?

Responsibilities: Owned by the business owner, with the finance contributor accountable for the method by which value is measured. The project manager maintains the entries but does not own the benefits, and signing the register is an acceptance that the figures in it are the organisation's figures, not the project's.

Tailoring Tips

One register may cover a whole programme, in which case entries should be grouped by component or initiative and a programme-level total shown separately, since a single blended variance across benefits of different size and certainty is not a meaningful number.
Where benefits are tracked at different frequencies, the register may be issued more than one version in a period, but each version should carry the date of measurement, since a figure without one cannot be compared with anything.
Benefits realised by a third party may be entered with the third party as the data source, but the method should still be stated, since the availability of a number is not the same as its reliability.
A benefit that will no longer be pursued should be withdrawn with a stated reason rather than left at its last reported value, since a withdrawn benefit and a stalled one are otherwise indistinguishable.
The register may be handed to the operating function at closure, but the measurement method and the escalation trigger should be agreed with that function first, since neither can be imposed once the project has gone.

Alignment & Dependencies

1. Pre-requisites & Inputs (Upstream Dependencies)

Mandatory:
- Benefits Management Plan (PMO-01.02)
- Business Case (PMO-01.01)
Optional / Contextual:
- Project Status Report (PMO-06.01)
- Product Acceptance Form (PMO-06.08)

2. Downstream Dependents

Mandatory:
- Lessons Learned Summary (PMO-07.01)
- Project or Phase Closeout (PMO-07.03)
Optional / Contextual:
- Post-Project Benefit Reviews (External)
- Operational KPI Dashboards (External)

5. How?

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

Register Purpose: What this register is tracking and which benefits it covers. State the scope, because a register that silently omits a benefit reads as a benefit that was never claimed, and the two are indistinguishable to a later reader.
Reporting Period: The period the entries cover and the date the register was last updated. Without a date a register of moving values is indistinguishable from one that was abandoned, and the two look identical on the page.
Source Documents: The business case and benefits management plan the entries derive from. The register does not create benefits; it tracks benefits defined elsewhere, and the source is what lets a reader check a target against the case that authorised it.
Entry Rules: What qualifies for an entry, and what does not. A register that accumulates everything makes no claim on anyone's attention, and the entries that get reviewed are then the ones that were easiest to write.
Benefit ID: The identifier for the benefit, matching the benefits management plan. Without a shared identifier the register cannot be reconciled against the plan, and a benefit can be tracked in one and dropped from the other without anyone deciding to drop it.
Benefit Description: The benefit as a measurable change, restated in the form it will be measured. The register is where a benefit written in prose has to become a number, so the description must be the one the measure actually refers to.
Benefit Owner: The role accountable for realising the benefit, which is normally not the project manager. The project manager can report the value; only the operating role can change the practice the value depends on.
Measurement Method: How the value is calculated, stated so two people would compute it the same way. Most disputes about a realised value turn on method rather than on the outcome, and an unstated method invites whichever reading suits the reader.
Baseline Value: The value the measure stood at before the project. Without it the actual figure has nothing to be compared against, and the register becomes a list of numbers rather than evidence of change.
Target Value and Date: The value expected and the date it is expected by. A target without a date cannot be late, and an undated target is met every day it goes unexamined.
Actual Value and Date: The value measured and the date it was measured. The date of measurement matters as much as the figure, because a value measured early in the year and reported as final is the most common way a shortfall is reported as success.
Variance: The difference between actual and target, signed. This is the column the register exists to produce, and a register that records only the actuals has omitted the only figure anyone reads.
Status: Where the benefit stands against its plan. The status should follow a stated rule rather than a judgement, since a status chosen to match the reporting is a status that reports nothing.
Variance Explanation: Why the actual differs from the target, recorded as a cause rather than as a gap. A variance with no cause cannot be acted on, and a benefit that is off plan for a reason nobody has established will stay off plan for a reason nobody has established.
Corrective Action: What is being done, by whom, and by when. An action without an owner is a note, and notes appear in the next version of the register as unresolved.
Escalation Trigger: The event that requires the benefit to be escalated rather than adjusted. Without a trigger the variance is absorbed at each review until it is no longer a variance but the plan, and the plan has quietly become the record of what happened.
Benefit Withdrawal: The grounds for removing a benefit from the register. Without them benefits are never withdrawn, only left at their last reported value, and a withdrawn benefit and a stalled one look the same forever.

📥 Associated Templates

6. Reference Example

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

📖 Completed Example: 01_03_Value_Realization_Register_Example.md