One reason for “Business Value Engineering” – 2nd pass

Let’s say some smart people have given you some great ideas about “business value engineering.”

Let’s say those ideas include:

  • More customer demos
  • Having the implementers visit the customers as they “do work” or “live” (depending on your product)
  • A better BV Model
  • Don’t talk to customers (they don’t know they want an iPad)
  • Taking BV metrics after each release, or every X months
  • Using the Pareto rule more to skinny down how many stories go in a release
  • Better PMO governance, to assure that problem teams are helped sooner (so that deliveries happen faster)
  • Improving the creativity of the Product Owners
  • Better brainstorming by the Business Stakeholders (or whatever you call them…the people who ‘assist’ the Product Owner)
  • Priority Poker (wide band delphi to estimate business value, using Fibonacci cards)
  • Enabling Specs
  • Rely less on documentation and more on conversation to assure the Implementers understand the story
  • Story Boards
  • User Story Mapping
  • More wireframes
  • Focus on “bang for the buck”
  • A story breakdown structure, to use to manage with senior Business Stakeholders
  • Completing more projects “early”, eg, when we see that the benefit-cost ratio of the project has deteriorated to below alternate projects (and other criteria are met).
  • Light use cases
  • Etc, etc, etc

Note: I personally like some of these ideas a lot.  On the other hand, some I tend to shy away from.

First thing to observe (and the above is a short list from all the ideas out there): Too many ideas to implement all at once.

Second: Some of these ideas are contradictory.

Third: “Many seem very good ideas for us, but how do I prioritize?”

Yesterday I explained how we can use “BV mapping” to enable us to see enough to prioritize the improvement we want to make first.  (This really includes more than mapping, but let’s over-simplify and call it just “BV engineering process mapping.”)

As a minor benefit, BV mapping enables you to hear ideas, and identify which part of the BV engineering process the person is making a suggestion about. In other words, you can put others’ ideas in a context that, hopefully, makes the ideas more useful or at least, more actionable. They can be prioritized.


« « One reason for “Business Value Engineering” || Better distributed Scrum » »

Leave a Reply