Toward a general theory of Business Value

The title of this post is a little highfalutin, but it gets the idea across I hope.

After many discussions with people about this subject, I find that the words “Business Value” tend to mean something very narrow to most individuals.

For example, the words often mean, mostly: “the numbers we put on the story cards,” “the  NPV estimate someone made to get this project approved,” “how the company benefits from this team’s project,” “something that only the business guys care about…probably they just want to boast that they have the project with the biggest one,” etc.

It is important to note immediately that Business Value ties in with our highest values. To satisfying the basic human needs of those in difficult circumstances, obtaining our highest aspirations, or leading a good life (in whatever way you define that). When I was young, I was taught two main rules: (a) Love God, and (b) love your neighbor as yourself. Without ignoring (a), let us say that in my opinion, Business Value is really about expressing caritas (love) to specific individuals. Peter Drucker famously defined the purpose of the firm: To satisfy customers. I think it is essentially the same thing.

To me, when you use the words Business Value, you imply and/or are really talking about a whole bunch of things:

• a definition of what value means; and one or more specific operational definitions of BV for the effort (project) at hand
• a bunch of ideas that surround and pervade BV, that are key to the way we use it
• a recognition that communication and motivation are key
• a very practical down-to-earth subject, that is at the same time difficult and slippery
• a bunch of practices that make BV useful. I want to call these the BV engineering practices (although again that may sound too highfalutin to some)
• change and learning, since the subject is as much about adapting to change and learning about it faster, as about any hard and fast dicta on BV itself — BV is not something that exists ‘objectively’ and continues to exist unchanged

And other things as well.

So, I wanted to back up on the subject. At least compared to some who want to rush to consensus on one definition of Business Value (e.g., reduction in process cycle time, to pick one of my favorites from Lean).

So as not to lose you, please define in your own head what Business Value means to you. For example, the Business Value of a project. How would you define it? (I assure you there are many different definitions out there.) Now, think about that as I talk about why we care about Business Value.

I am searching for the general ideas that pervade all views of Business Value. Perhaps by examining them, we may discover more about what BV really is, or at least how to use it better.

Why do we care about Business Value?

“You have to be very careful if you don’t know where you’re going, because you might not get there.” This was Yogi Berra’s wacky and wise way of saying it.

I have been on too many projects where there was no clear definition of what we were trying to accomplish. In several cases, one guessed that we were at the personal and daily whim of some project “leader.”

Let me state this a different way.

In the world, my hypothesis is that there are an infinite number of good things to do. The problem is not finding a set of good things to do, but in deciding which are the most important things to do.

So one reason we care about BV is to, in this short lifetime, accomplish something truly meaningful. In fact, the most meaningful things we could do, within our own capabilities.

Another reason is that we work in small teams. We want everyone to be working toward a common goal. So, we need to agree what that common goal is. It can be expressed in many ways, but at one level it must be called Business Value. Or, more specifically, the operational definition of Business Value for this project that motivates the team to do only (and just) what is needed as defined by Business Value.

Put another way, Business Value draws upon our natural motivations, and gives us a basis for putting a natural order into all the arrangements involved with a team’s work (e.g., who does what, the architecture of the system, etc., etc.).

Another reason is based on my hypothesis that change is incessant. This means that people forget, customers change, customers’ needs change, past estimates (if they were fairly accurate) are no longer accurate, etc. To the degree we understand BV appropriately, it can act as a guidepost in this swirl of change. We do not build new products for mere technical success. We do it to provide Business Value to specific people, so we must adapt to this change.

My hypothesis is that BV itself is also changing. This is alluded to below, but more a subject for later.

Some people use BV to make us practical. Some of us maybe are ambivalent about money.  Or we forget that the firm needs to pay its providers of capital.  Or we forget that we must make a payroll date each week or so.  For those people, the monetary definitions of BV are relevant and helpful sometimes.

Four related ideas

Let me mention now four ideas that are key to understanding Business Value (that weren’t already said earlier).

Cost-Benefit Analysis: No buyer buys a thing in isolation. He is always comparing an apple to an orange to a box of Cheerios. He only has some much money (or time), so which gives him the most satisfaction for the buck? It is my hypothesis that we must use this kind of thinking (or should) for each project, and we should do this at a more granular level also.

Pareto’s 80-20 Rule: Pareto posited that in any population, there were “the vital few.” This is translated into saying: “20% of the work provides 80% of the value.” And this is true for any size of the population (or at any level of population, if you prefer). So, it is probably true of projects, of themes within a project, of nitty tasks within a story. I guess it is necessary to say that Pareto did not say it is always exactly an 80-20 ratio. For example, it might be 90-10 or 70-30.

My hypothesis is that, in any set of stories for a project, there are at least one or two orders of magnitude difference (given probably the same size story) between the BV on one story versus another. This is of course implied by what Pareto said. This information is very valuable. This is a very common (although not universal, I think) situation for Product Backlogs.

Knowledge-creation: There is a whole set of ideas around knowledge creation. We will greatly simplify them here. First, that a team is better at learning/discovering new things than an individual. Second, that knowledge goes through cycles of conversion from tacit to explicit (and perhaps back again). Third, that knowledge creation is energized by putting people together in a place and providing a context (meaning). (See article titled “The Concept of ‘Ba.'”) Fourth, that knowledge can be said to self-organize into a product (solution). There is increasing evidence that knowledge-creation is our core competency. Our hypothesis is that applies to Business Value in many ways.

Learning Methods: We think BV should be used in the context of (to pick one instance) Deming’s PDCA model. This is Plan-Do-Check-Act. (Basically the scientific method.) We think short, time-boxed iterations are key. That some data is a key learning device (comparing expected results to actual results), and that general indicators are more important than slowing down for more precision and more “accurate” numbers. In the end, though, it’s about people, not the numbers. The numbers are only a rough guide to the people, or to the world. In many cases, out-of-the-box intuition may be a better guide (cf. Steve Jobs).

A full BV engineering approach

Let’s give a rough first definition of what we think a minimal BV approach would be (the fancier term would be a full BV engineering practice).

• a well-communicated high-level definition of Business Value (this might have multiple dimensions)
• a well-communicated operational definition of BV for the specific effort (this probably should include or imply multiple measurements)
• a clear way to measure whether that hypothesis (as embodied in the operational definition(s)) was correct; or how incorrect it was (probably a likelier outcome)
• a confirmation that this definition actually energized behavior (e.g., the programmers wanted to see success in that way) and that it was used in a way that allowed small adjustments toward a better outcome
• a clear set of practices for using this definition throughout the course of the project
• a clear way to modify those practices, so that better practices could emerge over time
• a common understanding about the time-boxes around the practices, and a continual questioning about whether those time-boxes (possibly at different frequencies, depending on the practice) were the most effective in guiding a better delivery of Business Value in this specific case
• a set-out way to develop the people to perform these engineering practices (training and the like)

There should also be some discussion about the dimensions of the word “better” in the next-to-last bullet. That might mean faster, more, higher quality (perhaps more reliably hitting the target), cheaper, etc., or some combination of those, depending on the context. My personal bias would be, first, to optimize faster delivery.

It is probably necessary to say (just as we still have to say that agility requires greater discipline of a sort) that the overview of the BV engineering approach above does not imply something like BDUF, endless documentation, long meetings of high ceremony, etc.

I would greatly appreciate your comments on this discussion and on later related discussions. More to come.

« « Suggested Resources for CSM Course NYC Feb 28-29 || “How to Tap IT’s Hidden Potential” » »