Value Realization Register

سجل تحقيق القيمة

tasleemat asset PMO-01.03 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.03 ./completed_data.json

Template Markdown (Bilingual)

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

Section Instructions:

**1. Register Control**
*   **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.

**2. Value Realization Register**
*   **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.

**3. Realization Actions**
*   **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.
-->

<h3 dir="ltr" align="right">{{Company_Name}}</h3>
<h2 dir="ltr" align="right">{{Program_or_Initiative_Name}} - {{Benefits_Plan_ID}}</h2>
<h1 dir="ltr" align="center">VALUE REALIZATION REGISTER</h1>

| **Date Prepared:** {{Current_Date}} | **Benefits Owner:** {{Benefits_Owner_Name}} | **Prepared By:** {{Prepared_By}} |
| :--- | :--- | :--- |  

---

## 1. Register Control
<!-- What the register covers, the period it spans, where the entries come from, and what qualifies for an entry. -->

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

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

**Source Documents:** [ Add details... ]

**Entry Rules:** [ Add details... ]

---

## 2. Value Realization Register
<!-- One row per benefit: what it is, who owns it, how it is measured, and where it stands against its target. -->

| Benefit ID | Benefit Description | Benefit Owner | Measurement Method | Baseline Value | Target Value and Date | Actual Value and Date | Variance | 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... ] |

---

## 3. Realization Actions
<!-- What is causing the variance, what is being done about it, and when a benefit is escalated or withdrawn. -->

| Benefit ID | Variance Explanation | Corrective Action | Action Owner | Action Date | Escalation Trigger | Benefit Withdrawal |
| :---: | :--- | :--- | :--- | :---: | :--- | :--- |
| [ 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... ] |

**Variance Explanation:** [ Add details... ]

**Corrective Action:** [ Add details... ]

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

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

---

### Sign-off and Approvals

| Role | Name | Signature | Date |
| :--- | :--- | :---: | :---: |
| **Benefit Owner** | {{Benefit_Owner_Name}} | _______________________ | [ .... - .... - .... ] |
| **Finance Controller** | {{Finance_Controller_Name}} | _______________________ | [ .... - .... - .... ] |
| **PMO Lead** | {{PMO_Lead_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> Value Realization Register | <strong>Ref:</strong> PMO-01.03 <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: 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 Reports (PMO-06.01)
- Product Acceptance Form (PMO-06.08)

2. Downstream Dependents

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

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

LLM Generation Prompt & Agent Instructions

VALUE REALIZATION REGISTER - LLM GENERATION GUIDE

System Prompt / Instructions: This document serves as the detailed instruction set for generating the VALUE REALIZATION REGISTER. 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 value realization register is the running record of whether the things the business case promised are actually happening. It is not the plan of the benefits, which is the benefits management plan, and it is not the project's own record of what it delivered. It is the document that survives the project, because the project team that could testify to what was supposed to happen will have dispersed by the time the benefits are due.

The register exists to make one movement visible: the difference between what a measure was, what it was expected to be, and what it is. That requires a baseline, a signed variance and a date of measurement, none of which can be reconstructed later. A value measured early in the period and reported as final is the ordinary way a shortfall is presented as success, and it is only the date that distinguishes the two cases.

A register also needs rules for what happens to a benefit that does not arrive. Without a stated trigger for escalation, a variance is absorbed at each review until it stops being a variance and becomes the plan, and the plan has quietly become the record of what happened.

Alignment & Dependencies: * Pre-requisites (Inputs): * Mandatory: Benefits Management Plan (PMO-01.02), Business Case (PMO-01.01) * Optional: Project Status Reports (PMO-06.01), Product Acceptance Form (PMO-06.08) * Downstream Dependents: * Mandatory: Lessons Learned Summary (PMO-07.01), Project / Phase Closeout (PMO-07.03) * Optional: Post-Project Benefit Reviews, Operational KPI Dashboards

1. Register Control

Register Purpose

Instruction: 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.