Quantifying Value - Is it Really Possible?

A critical skill for organizations wanting to become more efficient, flexible and adaptive is the ability to prioritize their backlog(s) of future work. Successful organizations learn to apply smart prioritization at every level of their future work backlogs. These backlogs range from the portfolio of products to launch and initiatives to fund all the way down to the specific application backlogs containing features to add and bugs to fix.

 Prioritization - Just Ask the Boss

We know that the best way to prioritize these backlogs is based on economic value (e.g. ROI, Return Value, etc.). But in so many cases it seems frustratingly hard to determine the economic value of backlog work items. So, these organizations default to subjective opinion in analyzing and prioritizing their backlogs. This subjective view usually devolves to the "Ask the Boss" approach. Sometimes this is known as prioritization by Highest Paid Person's Opinion (HiPPO).

 I have a lot of sympathy for the folks in these organizations. Their experience tells them that their backlog work items either are part of some larger initiative or "impossible" to determine the value. In many cases, their management chain and their organizational culture also assume that prioritization is inherently a "subjective opinion" activity. Folks in these organizations often joke, "That is why you are paid the BIG BUCKS!".

 I coach and mentor organizations adopting Lean and Agile principles and methods. In this role, I often get to work with folks from the business side responsible for these backlogs ranging from executives to product managers to business analysts. I know that sometimes I sound like a broken record as I repeatedly encourage them to analyze and prioritize their backlogs based on economic value. 

Finding the economic value of work items is HARD

I get it… in many cases, it appears that subjective opinion is only practical option for prioritizing. And since it comes down to a subjective opinion then, just like with other governance controls, the level of the decision maker will likely mirror the scope of the decision. Hence, the "Ask the Boss" pattern emerges. Some examples of work items that are difficult to quantify in economic terms include:

• The request backlog for a Shared Services group (e.g. Infrastructure, UX, Common Platform, Database infrastructure, Engineering, Operations support, etc.)
• Features and support for an application that is used internally by a captive audience.
• Features and support for a legacy product - where the new features are not likely to appreciably improve market penetration or realized revenue
• Support for legacy products that is primarily addressing product "dissatisfiers"

But, it can be done!

I have worked with some brilliant business leaders and together we have figured out ways to understand the economic value for many backlog work types. We have identified the key measure of progress that the organization is looking to achieve with their backlog of work. Then we begin to quantify how each backlog item is expected to impact that measure and then use that expected impact as a proxy for the economic value.  Of course, to close the loop we want to measure how the actual impact compares with the expected impact.

The first hurdle is the WILL to do it.

That describes at a high level the approach we have used to drive towards economic valuation of backlogs. However, we have found that the most important hurdle to cross is making the decision that "we will prioritize based on economic value". This decision is pivotal and after this decision is made, the solution for understanding the economic value of backlog items can be found quickly.

 What about your organization?

1. Is your organization ready to move past subjective opinion and move on to economic valuation? 
2. What are you doing to move your organization in that direction?