Avoiding project death by ROI

I had an unusual experience recently: a client demanded an exhaustive ROI calculation for a project, and the client approved the investment.

How to kill a project

Why is that unusual? First, some background. Over the years, my consulting firm, Strativa, has developed a methodology for building the business case for enterprise IT projects (or, any initiative for that matter). We identify the perceived benefits of the new system (for example), trace them back to features/capabilities of the new system, then quantify the direct financial impact. We also identify the time-phased project costs so we can calculate the ROI, whether by a simple break-even calculation or a more sophisticated internal rate of return. The whole methodology is implemented in an elaborate Excel workbook.

Although we are quite proud of this tool, I have noticed a pattern in cases where we use it. Often, when a client demands an exhaustive ROI calculation ("show me the money"), the project does not get approved. This is true even in cases where our calculations show a strong ROI.

Although I am a great believer in the need to demonstrate financial return, I have come to the conclusion that, in practice, too many executives ask for the business case not to determine whether they should make the investment, but to find an excuse for why they should not.

Now, having said that, there are some cases where an organization's capital expenditure processes require a formal business case. Here, the project sponsor requests the business case not as a means to kill the project but merely to get funding for a project that he or she already wants to do. But apart from these cases, what explains the correlation between client demands to see an ROI and projects being killed?

The "ROI Trap"

My hypothesis is that, due to a reluctance to say "no" directly, ROI calculations are often a convenient way to refuse projects that management simply doesn't want to do.

This "ROI trap" can take several forms:

• Management argues the project budget is underestimated
• Management argues the benefits are overly optimistic
  
• Management argues the benefits cannot be connected to the proposed initiative

That final point is the most subtle. For example, benefits involving increased sales are the most difficult to get by management review. A new sales force automation (SFA) system, for example, might be justified in part by increased revenue from new sales. The rationale would be that sales people today only spend about 50% of their time selling. The rest of their time is spent looking for information, administrative activities, and reporting to management. By providing faster access to information and automating much of this administrative overhead, sales people can spend more time selling, which should result in increased revenue per salesperson.

The problem, however, is that the organization is planning to do all sorts of things to increase sales, such as any number of marketing programs and new product introductions. If sales do increase after the new system is implemented, how will management know that the improvement is due to the new system and not to other things that the organization is doing? Therefore, when presented with a SFA business case that relies in part on increased sales, the easiest thing for management to do is to say, we don't see the connection.

Who owns the business case?

Is there a way out of this trap? We have found that there is one important key to having a business case approved: management ownership of the benefits statement.

Here is how we now prepare the business case for a new system or business initiative. We hold a series of workshops to collaborate with the client's project team and stakeholders around five questions:

1. What the objectives for the proposed investment?
2. How will the project meet those objectives?
3. What financial metrics would improve if those objectives were met?
4. What are the baseline measurements for those metrics today?
   
5. What percentage improvement would be achieved in those metrics if the project is approved?

We often find, however, that even among the project sponsor, project team, and key stakeholders there can be significant disagreement, especially in answering the fifth question. The reason is simple: stakeholders are going on record that they believe the project will yield certain benefits, and if the project is approved they are in effect taking responsibility for meeting those improvements in performance.

A success story

Now, back to our recent client project, which involved selection and approval of a new customer relationship management (CRM) system.

Early in the project, the client made it clear that a strong business case would be needed for a new CRM system to be approved. Based on my past experience, alarm bells went off in my head. What were the chances that this selection would end in "no decision," to the disappointment of the project team and the vendors asked to bid on the project?

Knowing about "the ROI trap," our consultants took a collaborative approach to the business case. Instead of going off in a corner and coming back with the proposed business case, they brought the client's team into the room and asked the five questions outlined above. The CFO was particularly strong in telling the team: if you say these things are benefits, you can expect your sales quotas and budgets to reflect what you say. Translation: they would be held accountable. The CFO even went so far as to ask us to break down the benefits by region, so that the regional sales managers could be held accountable.

The result? A business case that, perhaps, was understated (due to the desire not to set too high a bar) but one that was still quite positive, and most importantly, one that had the ownership of the stakeholders who would be responsible for implementation.

In the end, the project was approved, and contracts have been signed.

Lessons learned

No one likes to be held accountable, and if the business case for a new initiative is the consultant's work only it becomes an easy excuse for stakeholders to escape responsibility. Collaboration is the key: combining the consultant's methodology and industry knowledge with the client's ownership of the goals and metrics. Then, when it comes time to present the business case, it is not the consultant's presentation but the project team and stakeholders arguing in favor of the investment.

Footnote: way back in 2004, I explored the psychological dynamics of the ROI trap, based on the work of Max Bazerman. These are still quite relevant today. See the related posts below for more discussion.

Related posts

Escaping the ROI trap
Escaping the ROI trap, Part 2

*Image courtesy of Ramberg Media Group.