Identify your multiple! WHAT?!?!

Let's discuss the last post, from the skeptic's point of view.

Simon (the implementor) 1: "OK, I don't want to get fired. But what this "multiple" got to do with it?"

The multiple is the relationship between the cost of the team and the NPV (net present value) of the benefits the Team delivers. As in: "If I invest $1 million in this team over a year, I expect them to (and they usually do) deliver about $3 million in NPV from that work." If you have been doing any investing in the stock market lately, you will appreciate that that is a powerful statement.

Simon 2: "Great. You're asking me to get something I don't understand. And I know we don't have it around here. Thanks for nothing."

Well, if you are an implementor, you have no real need to understand NPV in detail. How it is calculated. You're right about that. Product Owners (or business sponsors) should do that. But you can appreciate that some BV must be delivered, othewise the firm would not invest in the team (or at least should not). ie, You don't have a job.

You think no one has NPV around your shop? Three comments:
1. Yes, this is all too common. And incompetent. (Did I say that nicely enough?) [more on this below]
2. They might have it and not tell you. At least the initial estimate used to justify approval of the project.
3. To me, it is also incompetent management not to inform the team, at some level and frequency, how much BV they are delivering. (more on this below)

So, go ask your Product Owner: "Show me the money. Now." If she can't show you money, she must at least have something.

Simon 3: "I went and asked the PO. And she said it was too hard to estimate. She said: "It's a very important project, trust me." Too much risk involved. Kinda made sense to me."

Well, at some point you must say: "If these guys manage this badly, I should go work for a better managed firm." But maybe not this week.

Yes, doing our work as professionals is hard. Estimating BV is hard. And predicting the future is difficult. Developing software is difficult too. But of course, that should not stop us from doing what is important.

People also make it seem harder than it is by demanding too much precision. All we need is a decent number, with a reasonable bell curve of probable values, and we have enough to make decent business decisions. (Simon says: "Ok, yeah, I remember that bell curve stuff from that stats course in college.")

So, who knows how to convert risk into dollars. Let's see...umm, I just got a bill from my auto insurance company. Oh yeah, they use "actuarial science" to establish premiums (price/value) for risk. So your firm could hire one of those guys.

Simon 4: "I went back to the PO and she said we have no actuaries around here now. So we're stuck. Your idea is a non-starter for us. And thanks for making me feel bad too."

Wait a minute. Let's try another approach.

Can we get about 5 key senior managers who understand the business side of your industry? And also the business side of your effort (project/product)?

Ask them to play a kind of wide-band delphi. They discuss the assumptions and facts around the project (or set of Product Backlog items) to guess at the total BV. Then each independently guesses (eg, writes a number on a hidden sheet of paper). Then they all show at once. If the two extremes are disparate, then the two people who voted the extremes talk about assumptions. And maybe the team asks more questions to get the info for a better estimate. Maybe they vote again (and maybe another round). At some point you declare "we have enough consensus", and average the numbers given.

In case this "team" may be biased (or someone will complain loudly that they are), I suggest you or the PO have them take the number and explain it to a more senior manager. If it passes his "sniff test", then it is good enough for business decision making.

Simon 4: "Yeah. Tried that. They wouldn't bite. Are you wasting my time yet?"

Ok. This happens. Usually I am not happy with it. Sometimes it makes some sense.

So, we have another approach.

Ask the delphi team what the maximum is they would pay for it (that feature set or "the project"). Go through some reasonable consensus building. Then take the numbers and average them. Now you have a number. It may need "rounding up", given that most people want to make a profit on investments. And this number is the max cost, not the max value.

Simon 5: "OK. That sounds reasonable. But what if they don't bite for that?"

At some point you must persuade them. Or leave. Or wait to be fired (worst option).

Explain to them all the ways that not having a decent estimate of BV known by the Team is hurting them. Often this will work.

For example, telling the Team the Business Value will almost always change their behavior. It will affect their motivation. It will get them thinking about what is most valuable to the customers (or various end users) and to the firm. Your best implementors typically don't do their best work until they see the challenge.

Simon 6: : "I will try. But what if they don't do it?"

Again, if they are really incompetent, you should leave. Alternately, show them why BV is important to you. Make a personal case.

BTW, incompetence can be very easy to fix (or very hard). Some people, with just a little training, can become competent. So, we don't mean these folks are evil, or mean harm, or are completely stupid. Probably no one, yet, has made them see how doing things a different way would be better.

Simon 7: "Wait a minute. That remark could apply to me. Are you insulting me?"

Well, the usual case is....we all could be more competent at our jobs. It is more useful to think of this as...not a problem, but an opportunity.

Simon 8: "OK. Let's imagine they give us an estimate of BV. How do I know they didn't just pick it out of [bleep bleep]? I mean, you know what these [bleep] are like!"

Simon, come on. This is the public airways. Please.

Still, very good question. Make them get real numbers that show, after-the-release, whether the estimate was decent or not.

Usually the estimate will be somewhat wrong (high or low). Tease them a little, but don't make them chicken to guess (uh, estimate) the next time. As you know, stuff happens between the time you estimate and the time the software goes live. And insist that they learn how to do it better (and maybe more frequently).

By learning about this, we each can have more successful work. More satisfied customers. This makes for more successful firms. Pretty soon, we might have the economy back on track. And then my neighbor will have a job again, and quit talking to me endlessly about ACC basketball.

This Bus Value stuff is not as much fun as watching somebody make a fool of themselves on American Idol. But it might be more important. To you.