See the Simple Picture of BV Engineering

Total Page:16

File Type:pdf, Size:1020Kb

See the Simple Picture of BV Engineering

BV Engineering

We first need a simplified view of what BV Engineering encompasses. Like the value stream mapping that Lean does.

[See the simple picture of BV Engineering]

The first ideas are: The requirements flow from external and/or internal customer. These requirements are “gathered” by a customer facing business group(s). One problem that is common with this approach is like the telephone game we play as kids, by the time these requirements are received by the development team, they usually don't represent what the customer asked for. And additional requirements, sometimes way too many, are added by non-customer groups (eg, legal, compliance, etc.)

The development team then creates a software product based on these requirements. The software product is then passed back through the business organizations such as legal, etc. to be delivered to the customer(s).

What is described above is a very generic view of the BV Engineering flow. (Just as the initial ideas about the Value Stream are very simplistic.)

So, one makes the BV Eng picture very specific to your situation. And more detailed. Often, as soon as the “flow” (or lack of flow) is made visible, a 6 year old can identify the weakest parts of the flow.

How does an organization know if their BV Eng is working, providing the right value to the customer(s)?

So, we draw out this BV Eng flow and analyze where problems exists and then determining which fixes will provide the biggest improvement, will result in the biggest increase in value to the customer(s). This is at the heart of Business Value Engineering.

The first problem that exists is that most organizations do not document and measure this BV Engineering flow and so they cannot tell what areas of the steam are working to provide value and which are impacting things negatively.

One way to start measuring BV is to adapt methods for including some relative measure of business value to each story. Like story points, the right “experts” can also assign BV points to each story. Like story points, the business value is a relative value to compare stories. The product backlog could then be sorted by the BV points, by which stories have the most BV points.

Even better, you can also compare the business value points to the story points, get a ratio, to see which stories will deliver the most value with the least effort, or give you the most "bang for the buck".

An organization can use the above principles to evaluate projects to determine which ones should be worked on first or at all. On a project level you can use the total business value and total story points to determine which project will produce the most value with the least effort.

Another application to adding the business value points of the stories completed (eg, done, done) so far, to measure the progress to delivering value.

If a team works to deliver the highest business value stories first, using the Pareto principle, the team can expect that 20% of the stories contains 80% of the business value. Or something close to that (Pareto did not assert that the ratio is always 80-20).

If they have not delivered that (something close to 80-20), then the team should analyze why. Additionally, as the team progresses through the backlog, each story delivers less value and at some point the ratio of the story may be below some cut-off level (eg, below a 2:1 level).

The team and the customers can use this information to gauge when to stop the project.

The participants then brainstormed on what customers consider business value: $$ NPS Coolness Emotion Stickiness of client repeat customers Competitive Comparison converted customers Cheapness Timeliness High Quality Image PCE (Lean “process cycle efficiency”) Simplicity (Usability) Compliance

Once an organization understands and defines what their customers value, understands their BV Engineering flow, and starts applying metrics to the overall flow, they can start to make adjustments to the process and measure the positive or negative impact those adjustments are making to the value they deliver.

Recommended publications