What’s The Business Value of … Anything?

By | March 2, 2019

What’s the value of a new software feature, a corporate training or a marketing collateral? Sounds like something we should be able to answer at least because one way or another each of those assets have their cost, so we naturally want to know what is the benefit. And this is where things usually get tricky. The cost is quite easy to figure out; the benefit (or the business value) are not so much so. Here’s why…

A software feature, in and of itself, rarely represents business value. What usually happens is that it may enable some new user capabilities that subsequently create new user value. So, for example, de-duplication of business transactions data (as a feature) enables an analyst do provide a better sales forecast and thus the organization to more effectively plan the manufacturing process. A corporate training, similarly, does not represent direct value, but through instilling new techniques and behaviors in workers, will result in certain business benefits. A marketing collateral represents value only as much as it enables better brand and product awareness. So, here’s the common trait across all our examples:

An asset (like a software feature, a training, a marketing material, …) may itself not represent direct business value at all; it’s utility is in how it enables business value.

Today’s organizations are incredibly complex and often we need to determine value of an asset that is so far down in the long enablement chain that it takes many “transitions” for it to result in something that is ultimately valuable to the business. No wonder that organizations happen to waste precious resources on doing things of little value as the proper understanding of enablement chains is missing.

In a few subsequent blog posts we will make a deeper dive into the specifics of analysis of enablement chains and thus advancing our understanding of the value an asset represents to the organization. But as a little teaser, I’d like to outline an example here. It outlines one specific aspect of enablement, namely understanding the required enabling factors and their connections.

Assume an organization considers buying a training for their sales people. The training delivery will cost the organization $60,000. By dint of astrology and crystals, the organization has figured that they should expect $800,000 increase in sales within 12 months following the training. Let’s ask ourselves a question: is the $60,000 investment going to inevitably turn into an $800,000 payoff? The answer is actually: no, not at all. There is no inevitability in that outcome. The enablement connection contains quite a bit of complexity:

The training has to actually be relevant (i.e. apply to the organization’s environment), the instructor needs to be really good (and that’s never a given), attendees have to be 100% present and engaged (not so easy with sales people)… But even more importantly, the new approaches and behaviors that the training encompasses are going to need to be further adjusted to the organization’s context, some additional software enablement may be required (different functionality of the CRM system, for instance), and over time some additional coaching may be needed to properly adopt the techniques across the diverse customer base. So, all of a sudden, we are talking about a more complex picture.

This example shows how multivariate enablement is and how easy it is to commit organizational resources to something that may, despite the great expectation, produce zero business value. It also shows us that alchemy and crystals have very limited applicability in enterprise context (despite the fact that almost every organization uses their version of “supernatural” means to rationalize desired outcomes).

But there is a better way and we are going to incrementally uncover it in this post series.

Hope you enjoyed this little blurb!

2 thoughts on “What’s The Business Value of … Anything?

  1. Michael Maricevic

    Value is especially difficult when team are setup as component teams that dont deliver value on their own. Once that model is broken you have to identify when value is actually realized, not in the completion of code or the fact that the user not has a new capability. But what behavior/outcome has been improved based on the delivery of the feature/capability.

    1. Aleksandr Kizhner

      Component teams are structured to match technical layers, components or services. Feature teams are structured to match/ deliver BUSIENSS VALUE so that they take end-to-end valuable functionality and deliver within the boundary of a one single team.


Leave a Reply

Your email address will not be published. Required fields are marked *