What is Business Value Engineering?

I made a post about Business Value Engineering in AgileBusiness (Yahoo group) that I thought I would edit and then repeat here:

QUOTE

I have been asked to start a conversation about Business Value Engineering. So, here’s a start:

What is it?

It is a framework for continuously improving the delivery of Business Value to the customer.

It is called BV Engineering for two reasons. First, instead of hand-waving, I believe we should use numbers. To me, the word engineering implies that.

Second, BV Engineering should be approached like other engineering practices in Scrum, as something that is not prescribed. More importantly, if we do an engineering practice, we should do it professionally and always be improving it. I think BV Engineering becomes one of those practices.

Where do we start?

We start with a very simplistic way of looking at things. (Soon, we will make this picture richer.)

We visually start to think of our situation. The basic elements are:

• 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 (e.g., the Scrum team that will produce or improve one product for those customers)

Then we assume that we can learn in a PDCA cycle how to get better. We assume that BV Engineering can be a round-trip set of experiments that are continuously trying to prove whether our hypotheses related to BV Engineering are useful or working effectively.

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.)

What do we do next?

Next, based on that simple framework, we create a simple picture, as with Value Stream Mapping, and describe what BV Engineering is in our specific context.  Instead of three boxes, we perhaps identify 30 stickies instead that represent the current situation.

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 mostly agree on it, and make suggestions. Suggestions for improving it, constantly.  And for constant changes with little tests.  We can continuously move toward a future state.

So, what kinds of things are we including?

Well, anything that helps or hinders us from delivering more and more Business Value to our customers quickly, at a lower price — solving exactly their problem (or fulfilling their need) with no adverse side-effects — and fulfills all our constraints (e.g., a good return to capital, 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 list

These include, or might include: Communication (who, what, when, how, where, 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, portfolio management, start and kill efforts, the Kano model, prioritizing across multiple customers (or customer sets), Priority Poker, value stream mapping, use of personas, use cases, etc., etc.

For example, the use of any one of these things has one or more assumptions tied to it.

One guess is that these assumptions have usually 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. Almost always it is not fast enough.

Second, one then looks at this not as a static model, but as a dynamic model that is always adapting to change. 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 Business Value Engineering in their specific situation (their project) and where they fit in the process.

Well, that’s a start.

Comments or questions?

UNQUOTE

Your comments are welcome.

 

 

« « Poppendiecks: Designing a Lean Development Process || Breaking the world record » »