Business Case Critics: De-Clawing the Cat. Newsletter 184

There are some things you don’t want to hear at your business case review.

The case, after all, is supposed to build management confidence that supporting your proposal is a good business decision. At a case review, however, certain kinds of remarks from the critics can undermine that confidence—if you are not prepared for them.

We often hear from participants in our Business Case Seminars about some of the painful comments they've received, such as:

“You left out important cost items.”
“Your case depends on “soft” benefits.”
“The results stand on risky assumptions.”

A year ago we worked with a product manager at a European automobile parts manufacturer who had just had a product proposal turned down by the Management Review Committee. Comments like those above were delivered at the business case review meeting by one especially vocal reviewer, the company’s financial controller.

While other members of the group had simply asked questions and probed, the controller offered judgment. Those words, from that source, no doubt undermined case credibility with the rest of the committee. After a short final discussion, the verdict was delivered by the VP of Engineering who chaired the committee: “The business case does not convince us that we’re really going to see the projected results.”

The product manager asked me: “Where’s the problem? Was it a weak business case? Did I fail to communicate effectively? Or did I get shot down by unfair criticism?

Getting answers was important because his “second chance” presentation was coming three weeks after the first review. In fact, by addressing each of the controller’s comments, we could deal with all three issues at the same time: content, communication, and criticism.

“You left out important cost items”

We met with the controller himself to redesign the cost model for the case. This does not mean going through all the costing analysis: it means agreeing on which cost categories belong in the case, which do not, and how to summarize the rules for including or excluding cost items. The controller asked for several adjustments to the draft cost model we presented him, and then agreed—two weeks before the next review—that the model covered every relevant cost category.

It is always good practice to agree on business case design elements with your reviewers or stake holders before you build the case rather than after. Here, cost model design was agreed and understood by the critic himself. This approach leaves very little room for critical surprises on review day.

“Your case depends on 'soft' benefits.”

Using the term “soft benefits” in a room full of reviewers has a way of softening support for the case. “Soft” implies that benefits are either unlikely or that the no one knows how to assign credible financial value to them. Some people, in fact take the position that only “hard” benefits such as cost savings, avoided costs, and increased cash inflow belong in the financial case. A wiser view, I think, is that any contribution to an important business objective is a benefit and belongs in the business case. Many of the so called "soft" benefits can in fact be valued in cash flow terms that are acceptable to all, if the case builder and reviewers alike understand the strategy and some tactics for doing so.

The product manager's proposed improvements in product design would very likely contribute to improved customer satisfaction, an important objective for the company. The controller had objected especially to the financial value for that benefit in the case. We sat down with him, again, and took him through the logic of the benefits rationale (the strategy):

Yes, the proposal would very likely contribute to improved customer satisfaction.
Yes, improved customer satisfaction is an important objective for the company.
Yes, the action (improved design) and the objective (improved customer satisfaction) are measurable in tangible terms. Evidence for customer satisfaction came from customer surveys, repeat business rates, customer referrals, and customer complaints, for instance.

At this point, the controller found himself affirming that the contribution to customer satisfaction was important and it had value. The only question remaining was the size of the projected cash flow benefit. There is no one-size-fits-all tactic for sizing cash flow benefits, but in this case we assumed that improved customer satisfaction could improve the repeat business rate by at least 10%, and the value of that was easily quantified. There would probably also be improvements in new business sales and lower warranty service costs, but in we took a cautious approach, using only the financial benefit that was more certain, a conservative estimate for improved repeat business.

Like the cost model, the benefits rationale should be understood and agreed well before the case review, in stages, where you establish the benefit's legitimacy first and the financial value second. If you wait until the case review itself, you have a difficult "sell" on your hands. (You can learn more about the strategy and tactics of the benefits rationale in the whitepaper, "Soft Benefits in a Hard Business Case.")

"The results stand on risky assumptions"

The business case predicts the future, after all, and the results will always come with some uncertainty. You cannot eliminate the uncertainty, but you can reduce it to a minimum and you can measure very precisely the uncertainty that is left.

The controller had a much higher comfort level after we "re-positioned" the case analysis for him. Case results should not be presented as though they are predictions that come from a crystal ball, or a sophisticated "black box" forecasting system. Instead, reviewers should see that the case builder has drawn one or more pictures of the way the future might work out (scenarios), and the case results for each scenario stand on a number of assumptions (assumptions about prices, labor requirements, business volume, for instance). If the assumptions hold, then the results that are presented will follow.

If you can identify the least likely and the highest likely value for each assumption, then you have the means to minimize and measure uncertainty in your case results. Yes, you may have assumed that a product development task will require 100 hours of designer time. That is a point estimate and the actual requirement will almost certainly turn out to be something else. But, if you can be very sure that it will be no less than 80 or no more than 120 hours, and if you can make similar estimates for other important assumptions, then you be very certain about how much uncertainty comes with your results.

After looking at the major assumptions behind the product manager's proposal, the controller was ready to accept a confidence interval summary statements for financial metrics such as net cash flow, net present value, ROI, and Payback period, such as: "We don't know precisely what the 5-year return on investment will be, but we are 95% confident that it will be between 143% and 190%." That was an uncertainty he could live with. (Read more on reducing and measuring uncertainty in The Business Case Guide).

De-clawing the cat

Better case design and communication during the case-building process can certainly help prevent damaging criticism at the case review. The most important factor in disarming this product manager's critic, however, was his involvement in case design and agreement—"buy in"—to case methods before the final review. If you don't want nasty critical surprises at your review, then don't surprise your audience.

Take action by learning more in a business case seminar or read The Business Case Guide.

Marty Schmidt
21 April 2009
mschmidt@solutionmatrix.com
www.solutionmatrix.com