Jun
17

More about Business Value

Liz Keogh comments on the Business Value estimation blog entry.

Thanks for the model; I’ll remember it for when a team needs to actually come up with some numbers (so far we’ve managed to avoid this!).

A business value model is useful without numbers, when prioritising by relative business value.

The most important thing we can do is to make the “value drivers”, the reasons we do this project, clear. Then we can evaluate any decision against these drivers.

“Increasing domain knowledge is one of the top value drivers for this project. Thus, I’d prefer to see feature A in this release, because it will give us more information than feature B, even though A is more expensive than B.”

“Feature C is going to give us a lot more visibility in the market than the other features and visibility is what this project is about.”

The reason I prefer “want” to “need” is for the same reason that we use “should” instead of “will” in BDD – it allows the goals to be questioned.

Yes, we need to question the goals — and everything else. How many questions are raised by “TO achieve this goal AS a stakeholder I NEED a capability”? A seemingly infinite number if I’m the analyst 🙂

  • Is that a valid stakeholder of our system? If we’ve built a context model, we already know which stakeholders we should consider. Or maybe we’ve discovered a new stakeholder we should include in our context model?
  • Is this a real stakeholder or are they representing a real stakeholder? For example, which is the most powerful user story: “TO sell more AS A salesperson I NEED <some differentiating capability>” or “TO improve my life or work in some meaningful way AS A user I NEED <some differentiating capability>”?
  • Is that a valid goal of our project?
  • How does this stakeholder goal get us closer to the project goal?
  • Is this goal there to support some other goal? If we derive stories from project goals, we will only create stories that achieve a goal or enable another story that brings us closer to the goal.
  • Do we really need that capability to reach that goal? Is there no other way?
  • Is that capability sufficient to reach that goal? Do we need something more?

The “Logical Thinking Processes” book taught me an interesting technique: use “strong” language to encourage questioning. For example:

  • “The only way we can ever reach that goal is to have that capability!” Well no, we could also…
  • “The only thing we need to satisfy that goal is this capability!” Well no, we also need…
  • “If that stakeholder’s goal is satisfied they’ll never want anything else again!”. Well no, they’ll also need…
  • “If we don’t satisfy that stakeholder, this project is doomed!” Well no, they could temporarily….

I like “need”. It’s strong and helps me to derive the minimum number of capabilities to achieve goals. I would ask “Do we need this differentiator? Why? What would happen if we didn’t have it? How will it change the lives of our stakeholders?”

“Want” or “Need”? It doesn’t make much difference. The process and the questions make a difference. People who ask questions make a difference.