Many programs and projects undertaken in organizations fail to get their intended benefits. In one survey from 2005, only 2% of organizations achieved targeted benefits all the time and 86% of organizations lost up to 25% of target benefits across their entire project portfolio (
KPMG Global IT Project Management Survey - clicking this link downloads a pdf of survey).
My experience suggests the actual situation is much worse because business cases are often a one-time document (used to get funding and not updated) and many businesses do not track benefits during or after the project. The same survey makes a similar observation, noting: “A remarkably high 59% of organizations have no, or only an informal benefits-management process. Only 18% of those who have a formal process stringently enforce it. An interesting implication of this is that with benefits so poorly defined and/or measured, how can the 86% of survey participants claim they only lost up to 25% of their targeted benefits? The loss may be far higher.”
Two techniques I have leveraged over the past decade to clarify and track program and project benefits are
Results Chains (a benefits modeling technique) and
Benefits Registers (a benefits tracking technique). Both techniques are related and should be used together as part of a benefits realization or value management discipline. They can be used by both profit and non-profit organizations. And they can be used by IT and non-IT programs and projects.
This post introduces you to Results Chains and Benefits Registers by:
- Presenting an introduction to the concepts of the two techniques.
- Providing a real-life example of both techniques.
- Sharing some practical tips when using the techniques.
- Listing additional resources if you are interested in learning more.
Note: The remainder of this post will use the term
project to refer to either a
program or a
project. Technically, a
project is "a temporary endeavor undertaken to create a unique product, service, or result" and a
program is "a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually" (both definitions from the Project Management Institute).
CONCEPTS OF THE RESULTS CHAIN
The Results Chain modeling technique for benefits realization was formally introduced in the book
The Information Paradox: Realizing the Business Benefits of Information Technology by John Thorp and DMR’s Center for Strategic Leadership in 1998. A key premise of the book is that benefits must be proactively managed if you want to achieve them; completing a program or project as intended does not automatically result in achieving the desired benefits.
A Results Chain shows the connections (linkages) between activities (work) and outcomes (results) and any assumptions. The process of building a Results Chain can help you define the activities to be done, clarify the outcomes to be achieved, and manage the realization of the benefits. Below is a simple example:
 |
| (Click to view) |
There are four objects used in a Results Chain model (plus a fifth as a connector object).
Graphic
|
Object Name
|
Description
|
|
| Activity | The work that contributes to an outcome. This can be a program, project, or activity, depending on the level of detail being modeled. |
| Outcome | The result of an activity and/or other outcome. This can be an intermediate outcome or an ultimate outcome of the project. |
|
| Connection | The linkage between one object and another. The arrow shows the direction of the connection. |
| Assumption | Any consideration not in control of the project that is required to achieve an outcome. |
| Connector | A symbol to represent a continuation of the connection from one page of a Results Chain to another (or on the same page to prevent connections from crossing). |
Activities should be worded to start with a imperative verb, such as
Identify,
Document,
Configure, or
Test. The wording should clearly state what the activity is, but it should not be too wordy. Additional documentation can specify more details about each activity. Each activity should be assigned a reference number.
Outcomes should be worded with a verb in past tense to refer to the achievement of the outcome, such as
created,
reduced,
increased, and
eliminated. Some practitioners have a set list of words they use. These outcomes should be measurable and will appear on a Benefits Register. Each outcome should be assigned a reference number.
Each activity should have a connection originating from it and terminating in an outcome. There should not be an activity-to-activity direct connection as each activity should produce an outcome. Outcomes may generate other outcomes (for example, as a newly implemented process matures and participants get more comfortable with it) or a combination of an outcome and another activity may generate an outcome.
The model is not a timeline and does not depict the elapsed time to perform an activity or to achieve an outcome. It does show dependencies through the connections so there is some relative order. However, it will not always be clear as to when an activity is performed or outcome is achieved relative to other activities or outcomes that are not directly connected. Some outcomes may be achieved immediately after the completion of an activity. Other outcomes may require some time before they are fully achieved.
The model should flow left to right. The ultimate outcomes (the primary benefits of a project) are depicted on the far right of the model. Other outcomes that come before them are sometimes referred to as intermediate outcomes.
REAL EXAMPLE OF A RESULTS CHAIN
The Results Chain shown below was created to help plan and document the outcomes of a segregation of duties project. Segregation of duties (SoD) is a primary internal control intended to prevent or decrease the risk of errors or fraud by assigning conflicting duties to different personnel in an organization. This project was designed to document SoD rules for the organization, automate the detection of SoD violations, and remediate them.
 |
| (Click image to view) |
The activities are represented by the rectangles. Each activity has a unique reference number, such as T-100 or T-108. Each activity starts with a verb and is written to be descriptive, such as "Test SoD rules and eliminate rule violations". Each of the activities has a connection that links it to an outcome.
The outcomes are represented by the large circles and have unique reference numbers. Each outcome is written to end in a verb, such as "SoD rules documented".
The connections are represented by the lines and show the linkage in the direction of the arrow. In this example, the completion of activity "T-100 Identify risks" results in the outcome "O-101 Business risks identified". This is an intermediate outcome that is necessary to achieve other outcomes. In this example, the outcome of business risks identified and the activity "T-102 Define SoD rules" both contribute to the outcome "O-103 SoD rules documented".
The ultimate outcome in this example is "O-125 SoD and sensitive access risks reduced" which is achieved through two other immediate predecessor outcomes "O-119 SoD violations reduced" and "O-121 Timely visibility to inappropriate sensitive access increased".
One assumption is depicted in the upper right part of the model: "A-11 Monitoring and remediation of SoD violations (operational)". The monitoring and remediation of SoD violations is outside the scope of the project. However, it is critical activity to achieve the outcome "O-119 SoD violations reduced" that it has been highlighted in the model.
There are several connectors represented by the small circles. The S-3 connector was created to avoid the crossing over of connection lines (which can make diagrams difficult to read). The S-3 connector connects outcome O-111 to O-119. The other connectors show connection of outcomes with other Results Chains. In this example, an outcome "P-1 Accountabilities established" depicted on a different Results Chain is linked to "O-117 SoD processes established".
BENEFITS OF RESULTS CHAINS
The benefits of Results Chains include:
- Confirmation of project benefits. The Results Chain should clearly identify and display the ultimate outcomes on the far right of a Results Chain model. These benefits should match the expectations of the sponsor and stakeholders.
- Sanity check of business cases. The Results Chain can be used to validate the benefits and to identify cost areas of the project. Cost areas include each of the activities and any of the intermediate outcomes that have costs to sustain them.
- Agreement of project scope. The Results Chain highlights the major activities of the project. These activities are the "what" needs to be done, and they should match the expectations of the sponsor and stakeholders.
- Input to project planning. The activities in the Results Chains can serve as a starting point in preparing project plans.
- Exposure of key assumptions. The Results Chain can highlight key assumptions so you can communicate and monitor those throughout the project.
- Analysis of impacts if changes occur. If an assumption changes (e.g., the operational processes are not put in place), an activity is curtailed (e.g., the testing was done but the identified violations were not remediated), or if an related external event was delayed or canceled (e.g., the automated tool was not implemented), you can immediately see the impact to the project and its benefits (e.g., we will not be able to reduce SoD violations to the extent expected).
- Communication of benefits. The Results Chain can be a good tool to communicate to certain audiences the high level activities, outcomes, and relative sequencing.
TIPS FOR CREATING AND USING RESULTS CHAINS
If you get two different groups to create a Results Chain for the same project, I guarantee the two Results Chains will look different. Even two experienced practitioners will come up with different models. Do not worry about it. The important aspect is to get key stakeholders involved in creating, approving, and using the Results Chain.
Involve your key project participants in creating the Results Chain. It is the process of creating the model where you can get agreement on the activities, outcomes, ultimate benefits, assumptions, and linkages.
Keep it simple. Do not make it overly complex. It is input to project planning. It is not intended to contain all project tasks.
Create the Results Chain using both left-to-right and right-to-left approaches. Some practitioners use the left-to-right approach, focusing on the key activities to determine the outcomes. Others prefer to start on the right side with the ultimate benefits or goals of the project and work back to the activities. Do both as they give different perspectives.
Know your audience before communicating with a Results Chain. Many audiences may be overwhelmed by the information contained in a Results Chain. One approach is to simplify the Results Chain by raising it up a level or two to highlight the key activities, outcomes, connections, and assumptions you want to communicate. If your audience wants to drill into the details, you can then pull out the more detailed version.
Recognize that many outcomes, particularly the ultimate outcomes, are achieved after the project has been completed and is in operational mode. For example, if a goal is to have improved efficiencies of 10% by implementing a new computer system, this efficiency improvement will not be achieved on the day the system goes live. It takes a period of time before the users become comfortable with the new system and the efficiencies are achieved.
Keep it live. Revise the model when changes occur. Show progress against it by coloring or shading activities completed and outcomes achieved and by highlighting those activities in progress.
Track the progress of the outcomes on the Benefits Register. While the Results Chain can highlight outcomes achieved, the Benefits Register can show the details.
CONCEPTS OF A BENEFITS REGISTER
A Benefits Register is a listing of all outcomes of a project with details of how to measure the achievement of the outcome. The outcomes are taken from the Results Chain for the project.
The following fields are contained in a Benefits Register.
| Field | Description |
| Measurement # | A unique number given to the measurement. |
| Project | The name of the project. This is useful for a program with multiple projects being planned and tracked. |
| Outcome | The name of the outcome on the Results Chain. |
| Outcome # | The reference number of the outcome on the Results Chain. |
| Measurement | A clear and specific description of what will be measured for the outcome. |
| Metric Value | The standard of measurement to be used. Examples include: number, percentage, yes/no. |
| Frequency | The frequency the measurement will be taken. Many will be one-time and others will be measured periodically. |
| Measurement Method | A clear and specific description of how the measurement will be taken. |
| Baseline Value | An actual value measured before the outcome was achieved. This is the baseline that can be compared to a target value expected to be achieved by the outcome. For example, if the outcome is "Sales increased by 10% over last year", the baseline value should be last year's sales. |
| Baseline Date | The date the baseline value was taken. |
| Target Value | The value of the result expected for the outcome to be achieved. If the outcome is "Sales increased by 10% over last year", the target value should be 110% of the baseline value. |
| Target Date | The date by which the target value should be measured. |
| Tolerance Limit | If applicable, an acceptable range around the target value that will consider the outcome achieved. For example, if the outcome is "Errors eliminated" and the target value is zero, it may be agreed that if there were five errors or less measured, then the outcome was achieved. |
| Accountability | A person assigned responsibility for achieving the outcome. |
The listing of outcomes should be ordered in the general sequence the outcomes are achieved. This makes it easier to update the Benefits Register.
A Benefits Register typically contains one row per outcome. You can easily turn it into a Benefits Register for tracking purposes by adding columns or rows and using the grouping/outlining feature of Microsoft Office to hide and expand the tracking detail.
EXAMPLE OF A BENEFITS REGISTER
The portion of the Benefits Register shown below is related to the Results Chain shown earlier. I have expanded the detail for the first outcome to show how it was used for tracking purposes as well.
 |
| (Click image to view) |
Intermediate outcomes in a Results Chains may often be simple measurements. In this example, the first outcome "Business risks identified" is measured by the existence of a Risk Analysis Document. The measurement is a yes or no and measured one-time. The measurement is taken by viewing a Risk Analysis Document signed off by the Business Process Owner, which is considered proof that the Risk Analysis Document exists and the business risks have been identified. A baseline measurement was taken on March 1 and no Risk Analysis Document was found. The target value is "yes" (a signed-off Risk Analysis Document). The date the outcome should be achieved is documented in the project plan. There is no tolerance limit; it must be a "yes" for the outcome to be achieved. The Rulebook Owner is accountable for achieving the outcome.
The outcome in this project example is unique in that the measurement is performed per process area, that is, there are several process areas to be tracked. The green columns allow detailed baseline and target information to be tracked multiple times, one row per process area.
Here is another outcome on the Benefits Register from the project. It is closer to an ultimate outcome where stronger benefits to the organization come in to play.
 |
| (Click image to view) |
This this example, the frequency of measurement is monthly. One row is used per month to track the baseline and target values. Notes can be captured to provide more detail on the results of the measurements.
TIPS FOR CREATING AND USING A BENEFITS REGISTER
Create the Benefits Register after the Results Chain has been created but before the Results Chain has been finalized. The process of determining how the outcomes will be measured can help clarify the wording of the outcomes and ensure it can be measured.
Keep the accountable parties informed of the measurements, the target dates, and the status. And keep the Benefits Register updated. These are two of the management activities needed to realize the benefits.
Celebrate benefit successes. My experience has shown organizations celebrate key project milestones (like go-lives or project completions). Milestones are nice, but they are rarely the benefits of the project which are the real reason to celebrate. In fairness, most projects are completed and project teams disbanded before the ultimate outcomes are achieved (and as noted in the KPMG survey, most projects do not achieve the intended benefits or do not track them.) With Results Chains and Benefits Registers, you can finally celebrate what should be celebrated.
ADDITIONAL RESOURCES
The book
The Information Paradox by John Thorp contains the original description of the Results Chain modeling technique. It is a good read.
Here is the link in Amazon for more information.
Here is a link to a Results Chain and Benefits Register created by the Treasury Board of Canada. This gives you another real example.
Happy chaining!
