Benefits Realization Model: A Practical Application of Metrics and Key Performance Indicators

By C. Dennis Allen, Senior Business Analyst, Novell, Inc.

The intent and purpose of the Benefits Realization Model (BRM) is to ensure that the valuable benefits of a project are delivered to the business.

But it’s tricky. The project implements the technical solution and the processes needed to realize those benefits, but the impacts of the project might not be visible to the business for months after the project’s completion.  In fact, by the time the benefits can be verified and validated, the project team has likely been disbanded and its members allocated to other projects.

When I first learned I needed to create a BRM, I was intrigued and motivated because I saw it as a powerful tool to improve business performance. However, as I worked to focus the team on defining it, I was puzzled by their passive disinterest.  It turned out that the team members understood that the end of the project signified the end of their involvement and that that their interest and focus would shift to their next project, not the impacts of this one. 

As I discussed this conundrum with my manager, Mike Sandberg, he asked me to upgrade our BRM process and project deliverables to address this problem.

As I worked through defining the process and related project deliverables, I had an epiphany regarding stated project benefits. A business organization manages what it cares about.

This has led me to ask, when interviewing the business about benefits, “How do you currently manage that benefit?” They typically respond with one of four revealing answers:
  1. Here’s how we do it.
  2. We don’t, and we want to.
  3. We don’t, and we don’t want to.
  4. What do you mean?
If they answer “Here’s how we do it,” then they are committed to this benefit and are more likely to have a mature understanding of the dependencies relative to creating and improving the benefit. When we review how they manage the benefit, there is the potential of discovering systems and processes that impact the scope definition. This answer significantly increases my confidence that the project can achieve the desired benefit impact.

When they answer #2, “We don’t, and we want to,” then one can surmise that they are likely serious about creating the benefit for the business and discussing how to manage it. It basically invites the BA into a management discussion regarding metrics, process, roles, responsibilities, etc., all of which are relevant to the scope and requirements of the business case under discussion.

When they answer #3, “We don’t, and we don’t want to” this signifies that this benefit is a “nice to have.”  Although it should not be dismissed out of hand, this probably means that this benefit is out of scope for this project. However, before reprioritizing, it is important to probe why the benefit was requested. This discussion might reveal an unarticulated benefit that is important to the business when it is clearly articulated.

I dread answer #4, “What do you mean?” because it suggests that the business owner might not understand the cause and effect relationship between project deliverables and resultant positive and negative business impacts. It can also indicate there might be tremendous organizational distance between the project’s impacts and the desired business benefits.

For example, suppose the web team says the benefit is “increased sales.” One must then verify whether the web team can attribute sales volume fluctuation to the currency and accuracy of relevant web marketing content. For some businesses, there is a strong attribution, but for others, the attribution may be quite tenuous.

Ultimately, for the BA to feel confident in a BRM, the business must commit resources to manage the realization of desired benefits on an ongoing basis after the conclusion of the project and understand the process of doing so. Lacking either, it seems reasonable to question the benefit’s viability.