In the corporate world, we build a business case before each project. We build a business case for each of our Web projects. When we implement our Web projects, we can justify them on the basis of the business cases. But how many of those business cases are really sound in business terms? And how many of them are truthful?

Here is a real example of a business case for a new Web-based project.

• The major cost reduction will be in staff.
• The new Web facilities will lighten the workload of five people by four hours each week.
• Given that the total costs of employing these people are $80 per hour, the new facilities will save $1100% per week, or about $80,000 per year.
• Over three years, the savings will be $240,000, thus justifying the project costs of $150,000.

There are three levels of reality that apply to business cases: mathematical, practical and historical. Let's apply them here:

Mathematical reality

The arithmetic just does not add up in this business case.

Project costs rarely include the full costs of implementation. In this particular project, the new facilities, when they were available over the Web, needed to be communicated to external users. The project costs did not include any allowance for advertising or mailing. This is typical of a project that is totally oriented towards technical solutions, rather than taking into account the impacts on people, on business systems and on the organization itself.

The total cost of employing someone can be difficult to calculate. In this instance, I found that the figure of $80 was an estimate, which was passed from project to project. No one was able to tell me how the original calculation had been made.

Practical reality

In practice, of course, there will be no real staff savings. The five people who will each work four hours per week less are full-time employees. They will be paid for simply being at work, regardless of what they are doing. They are not going to work a 36-hour week instead of a 40-hour week.

There is often an assumption that all new applications on the Web are implemented with a "big bang". At a given time on a given day the function will switch to the new application from the five people who have done it previously. This was the expectation with this business case. As soon as the application was implemented, the involvement of the five people would stop. In fact, the five people continued to provide support to users of the new application.

Historical reality

Historically, there are several uncomfortable facts about all previous computer applications.

They are rarely more effective. In fact, mainstream applications have become less effective over the past few years. Much of this has to do with the artificial "bundling" of applications, so that stand-alone payroll applications were replaced by full "human resources" applications and these in turn were replaced by "enterprise resource planning" ("ERP") systems. Each time, the user purchased more functionality that it did not use.

They are hardly ever more convenient. From the days when systems analysts designed applications with hardly any reference to end-users, through the days of the impressive but dysfunctional project steering committee, to today's situation where the user appears to direct any new implementation, we have actually increased the constraints on user choice. Today, with ERPs, users have little choice at all. Many Web applications follow this pattern, with users having to select from drop-down lists or radio buttons; these choices are often close to what they want rather than being precisely what they want.

They are never cheaper. Despite figures showing that the prices of hardware and software have fallen, the cost of keeping a PC on a person's desk has risen. There is now a regiment of network support, security, application support, contract management, helpdesk and operations people supporting that PC. Even if they're outsourced, they still exist, and they still need to be paid.

Given all of this, many companies are stuck in a paradigm of less effective, less convenient, more expensive applications that are justified by increasingly erroneous, superfluous and illogical business cases.

The way forward

What can we do about this?

The first thing we can do is to look at the real reason for this project. In our example, the idea for moving to a Web-based application came from the head of the division. He thought it would be good if his customers could get the information they wanted from the Web rather than by telephone. It wasn't something that was essential to the business. The real reason for having it was that it would look good.

Actually, that's fine.

If the head of the division thinks that the Web-based application would look good, and if he wants to have it, and if he's got $150,000 that he can't put to better use, then that's the way forward. Let him go ahead and have the application installed.

If, on the other hand, he needs to justify his spending in terms of added efficiencies, in order to get his share of a limited number of slices of the budget pie, then he needs to build a business case. Provided that no one looks too closely at the figures in that business case, then he stands a good chance of getting his application.

In some companies no one will look too closely at the figures, because they need to build the same kind of business cases for their projects, and they don't want anyone else looking too closely at their figures. In other words, the whole procedure for spending (rather than investing) the company's money on e-business is dependent upon business cases that just don't add up.

So here are my recommendations.

If you're in charge, stop this situation.

• If your company can afford sponsorships of art exhibitions and symphony orchestras, then it can afford to give heads of divisions some budget that they can play with and spend on their favourite projects.
• If your company can't afford all this, then start getting control over the business cases that are presented to you. Turn back the rubbish and make sure that nothing gets approved unless it has realistic costs and benefits in its business case.

If you're not in charge, and you have real, valuable projects that need a budget allocation to get them started, then your only responsible action is to build proper business cases. But bear in mind that you will still have to "sell" them.

• Research other people's business cases to discover the nonsense that they put in as justification. As you discover a fresh item of nonsense, make a note of it and add your arguments against it.
• When you are preparing a business case, check through your notes and find all the erroneous "justifications" that you could use in it. Include them in a separate section of the business case, with an explanation of why you have omitted them. They're still in there, so that people who believe that you can save four hours of five people's time can still see them.
• Be careful of the project that has no real business case. Go back to the people who want it and get them to give you their justifications. If there's still no real business case, then include the justifications as benefits that may be achieved and attribute them. Don't say "Mr McGregor states that he will save ..." Use "Mr McGregor will be able to save …"

Once you've taken the first step of building realistic business cases, you're on a track that should lead to implementations that bring real rewards and benefits. Eventually, you will only launch new e-business projects that will increase profits rather than drain them.