What is Business Value Engineering?

I made a post in AgileBusiness (yahoo group). That I thought I would repeat here:

QUOTE
I have been asked to start a conversation about BV Engineering. So, here's a
start...

What is it?

It is a framework for looking at the delivery of business value. It is called BV Engineering for two reasons. First, instead of hand-waving, we believe that BV Engineering should include qantitative measures (although not be dominated by metrics), and, second, it is called that so that it is approached like other engineering practices in Scrum, as something that is not prescribed, except to say one must always have them, identify them, and improve them. And BV Engineering becomes one of those engineering practices.

Where do we start?

We start with a grossly simplistic franework that says: we have
* a box of customers (external and internal typically),
* a box of Business (customer facing people, internal groups like legal and compliance, and perhaps others), and
* a Team (eg, the Scrum team that will produce or improve one product for those customers).

We also start with an assumption that BV Engineering is a round-trip set of experiments that are continuously trying to prove whether our hypotheses related to BV Engineering are useful. Or, more accurately, it is a feedback loop that continuously shows us how far off our hypotheses are. (And since stuff is happening all the time, we are always at least somewhat off.)

And what do we do next?

Next, based on that simple framework, one does a simple drawing, as with Value Stream Mapping, and describes what BV Engineering is in your specific context.

The flow between all the people is diagrammed. The assumptions and hypotheses are described. The business value model is described. We lay out the current state.

Why?

So that, being visible, we can all see it, and make suggestions, little tests, for improving it. Constantly. That is, so we can continuously move toward a future state.

So, what kinds of things are you including?

Well, anything that helps or hinders us from delivering stellar business value to our customers instantly, at a lower price, solving exactly their problem (or fulfilling their need) with no adverse side-effects. And fulfills all our constraints (eg, a good return to capital, etc, etc).

The approach also works if you make the simplifying assumption that "we only want to make money". As Drucker would say, not the correct basis for doing business, but one that some adhere to.

Back to the things. These things include, or might include: communication (who, what, how, when, etc), gathering requirements, the BV model and its assumptions, frequency of release, feedback from the release, how much we do the telephone game, who needs to understand the customer, the role of tacit and explicit knowledge (about what?), how and where we do knowledge creation, how we balance customer needs with legal/regulatory needs, how we do portfolio management, how we start and kill efforts, the Kano model, prioritizing across multiple customers (or customer sets), priority poker, value stream mapping, personas, use cases, etc, etc, etc.

For example, the use of any one of these things has one or more assumptions tied to it. One hypothesis is that these assumptions have often never been articulated, much less challenged, and even less have they been confirmed as accurate for our specific situation.

Two more observations, each fundamental. As soon as one sees this as a feedback loop (or PDCA cycle) that is trying to prove whether our theories and practices are on target, one immediately asks about the frequency of feedback. And almost always it is not fast enough (GM anyone?). And, second, one then looks at this not as a static model, but as a dynamic model that is always adapting to change. So, one asks "how are we building into our BV Engineering appropriate mechanisms for it to be continuously adjusting in a useful way?"

Lastly, let me add a "personal bias" (which I find empirically true), namely:
virtually every team member needs to understand how we do BV Engineering in our specific situation, and where they fit in on the process.

Well, that's a start.
Comments or questions?
UNQUOTE

Your comments, here or on AgileBusiness, would be welcome.