Thursday, November 25, 2010

Toolkit: Results Chains and Benefits Registers

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).


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).

Object Name

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.


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".


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.


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.


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.


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.


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.


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!

Monday, November 8, 2010

Ideas on Designing Products for the 21st Century

As of November 5, 2010, the world population is over 6.8 billion.  The population of the United States is estimated at 310 million or 4.5% of the world population.  And yet with under 5 percent of the global population, the U.S. consumes 30 percent of the planet's resources and churns out 30 percent of its wastes (the U.S. is the #1 trash-producing country in the world at 1,609 pounds per person per year.)  In addition, the U.S. consumes more gasoline per day than 20 other large countries combined.

I have often thought on my trips abroad what the world would be like if every country was similar to the U.S. in its consumption and trash production.  As I visited China in 2005 and Vietnam in 2009 with their bustling economies and large populations, I wondered if there is enough raw material on the planet to support similar consumption habits.  If you include India, which is forecasted to become the world’s fifth-largest consumer economy by 2025 (up from 12th now) and the most populous country by 2030, it is easy to foresee much higher consumption and waste production on the planet.  Waste, raw material supply, and pollution issues already exist today and will only be magnified in the next two decades.

This posting recommends the world needs new design principles to be able to handle the increases in consumer demand in the 21st century and suggests a few design principle ideas.  These design principles should be implemented now all around the world to successfully manage the issues confronting us today.


All design considerations should strive to maintain or improve quality of life.  The current standard of living in developed countries is the baseline.

This does not mean that designs have to keep the same consumer behavior of today's developed countries.  Consumers have adapted to new designs in the past, and adjustments to lifestyles may be needed.  Marketing of products with these new design principles will play a major role in helping the necessary behavior changes take hold.

There are usually trade-offs in design.  And there are practical design decisions, too, which may override "better" designs.  Making a product to last 5000 washes when it typically will be washed 10 times in its lifetime may make it prohibitively expensive.  These should all be taken into account with preference given to 21st century design and the broader issues we face.

Here are some design ideas I recommend.

Design for compactness.  Benefits:  Smaller products use less raw material, require less inventory and shipping space, and reduce shipping costs because they usually weigh less.

In the past, many products were made large by design to give an appearance of opulence and prestige or to appeal to the "big is better" perception.  A combination of good design and marketing can help compact designs take on these attributes.

New designs leveraging new technologies can reduce the size of products with similar or better features.  Take televisions as an example.  The move from tradition television technology to flat screen televisions has reduced the weight and physical size in the last fifteen years.  For example, compare the Sony Trinitron 40-inch TV with the flat screen Samsung 40-inch HDTV in the table below.  This difference is a significant decrease in both weight and size and translates to all of the advantages of a more compact design.  Multiply these advantages to millions of consumers around the world to compute the tremendous benefits these new designs offer.

Television Model
Shipping Weight (lbs)
Dimensions (inches)
Sony FD Trinitron WEGA KV-40XBR800 40 inch 325 26.2 x 43.2 x 33.2
Samsung LN40C630 40-Inch 1080p 120 Hz LCD HDTV 46 10 x 38.5 x 26
Optoma HD20 High Definition 1080p DLP Home Theater Projector 12 19.4 x 13.1 x 7.3

The next step is to reduce the footprint further through additional compact designs and through new technology.  For example, projectors such as the Optoma Home Theater Projector is only 6.4 pounds out of the box and you can fit 20 of these projectors in the same space as the Sony Trinitron.

There are reasons not to miniaturize certain products too much, and these factors must be taken into account as well.  Poor eyesight can prevent the reading of any visual output on a product if too small.  The size of hands, fingers, other body parts, and other input mechanisms also set practical limits to certain designs.

Another example in line with the compact design principle is to move to higher concentrated products. Proctor and Gamble has begun selling many of their detergents in concentrates.  The same number of ounces of detergent cleans two or three times the loads of clothes.  The compact design results in less inventory and shipping space and costs.

Design for easy assembly.  Benefits:  Assembly of large products close to or at the final destination (rather than at the origination) often saves inventory and shipping costs.

Ikea's products are a classic example of this design principle.  Ikea furniture is sold in compact packages and assembled at the final destination.

Many people avoid buying products that require assembly because of the difficulty in assembling the product.  Some of the reasons are due to the difficulty in understanding the instructions provided, but often it is due to poor design that does not consider the assembly process early on in the design process.

A corollary to this design principle is design for easy non-destructive disassembly. If a product is easy to disassemble and reassemble elsewhere, it is more likely to be reused, which reduces waste.

Design for durability.  Benefits:  Durable products last longer, use less raw material over a longer period of time, and reduce waste.

Some companies design products for failure so they will be replaced and new sales can be made.  That makes business sense, but it does not make 21st century design sense.  The markets in emerging countries are large enough to sell products that last a lifetime.

Convenience has taken a priority in the design of many products, often creating a throw-away culture with one-time use products and little need for durability.  While the use of recyclable materials can help reduce its impact somewhat, the convenience through throw-away design principle must become secondary in the 21st century.

Design for minimum waste in manufacturing.  Benefits: Minimizing manufacturing waste has always made business sense to keep cost of goods low.  But it does require extra design work that is sometimes not on the priority list of designers and even for some businesses where the cost of raw materials are low.

The waste can occur in raw materials for the product itself and in materials used during the manufacturing process.  For example, water is used not only as a raw material in a soft drink beverage itself, it is also used in the manufacturing process, such as rinsing bottles and cans, cleaning equipment, heating, and cooling.  A conscientious effort is needed to make improvements.  As an example, Coca-Cola Enterprises Inc. reduced its water use ratio to 1.67 liters of water used to make one liter of product using water-saving technologies and monitoring and targeting systems, which is an improvement of more than 3.5 percent from 2008.

Design for easy replacement of parts.  Benefits: Fixing existing products reduces the likelihood of a perfectly-good product being thrown away because one part broke that is too expensive or difficult to repair or replace.

Easy replacement of parts requires careful design.  Some businesses count on repair services for income or new sales as parts break down.  These need to be called out by consumer groups and reviews as part of the total cost of ownership.

Design for easy removal of hazardous materials during disposal.  Benefits: Reclaiming or proper disposal of hazardous materials reduce toxic waste.

The most desirable situation is to eliminate the use of toxic materials altogether from products.  Apple has been example of a company looking at replacing hazardous materials from their products.  In 2010, Apple stated that that their entire product line is free of lead, brominated flame retardants (BFRs), polyvinyl chloride (PVC), mercury, and arsenic.

If the current state of technology does not allow for a comparable replacement, easy extraction and proper disposal of hazardous materials should be part of the design.

Design for recyclability.  Benefits:  Recycling reduces waste, allows reuse of raw materials so less mining/drilling/logging is needed, and conserves energy in making new products compared to new sources of the raw material.

If a product contains both recyclable and non-recyclable components, it should be designed for easy separation so the proper materials can be recycled.

Design for easy upgrades.  Benefits: A product that is easy to upgrade is more likely to be used longer, reducing waste and use of raw materials.

One of the best ways to upgrade an electronic product is through software.  This typically does not require any additional material resources to improve an existing product.  It also allows fixes and refinements to be made to existing products without requiring replacement and extending their life.

Design for minimal energy usage.  Benefits:  No or low power consumption reduces the need for non-renewable energy sources and reduces pollution generated from the production or use of energy.

Designs prior to the industrial age worked on designs focused on human, animal, water, and wind-powered devices and gaining efficiencies from these energy sources.  The introduction of electricity, gasoline, and battery power shifted designs to new uses; efficiencies were secondary as the energy costs were low enough.  Focus should now be put on designing "no power" products (for example, the perfectly useful flushing toilet uses no batteries and leverages gravity), lower-powered products, more power-efficient products (for example, more efficient motors, software that prolongs battery life), and differently-powered products (for example, hand cranks that store power in flywheels, products powered by light, products powered by movement such as walking.)


As the world population, disposable income, and consumption increases around the world, these and other design recommendations can help address some of the issues confronting us.

But another trend should be started.  While there is a human desire for material goods, we need to encourage less unnecessary consumption and encourage spending on more services and experiences that require less use of our planet's natural resources.  Challenging and positive experiences are what are important to happiness, not the temporary pleasure of much of our material goods.  More on this in another posting at a future date.

Happy designing!
Toolkit: Results Chains and Benefits RegistersIdeas on Designing Products for the 21st Century ~ DANIEL SKLAR