What Is A Business Case?

The objective

One of the key areas of focus of Prince2 2009 is the Business Case. Senior managers will always want to ascertain if the project meets particular requirements and remains in that state. The key points are whether the project is desirable (a balance of benefit, risk and costs), viable (will the project actually produce the product) and achievable (will the product supply the benefits desired). They will need this information so as to make the correct decisions on their investment. Simply expressed, is the project good value for money.

Minus the business justification a project can’t go on. Not just this, but it is the rationale for a project which should not begin without one. For this reason, if the business situation alters in the course of the project, and this is detrimental, it is very likely to be modified or even terminated. It is never fixed. It controls the ultimate viability of a project. When writing a Business Case it may prove useful to use a set format or look at one from an earlier job.

It may be tempting to use it to help initiate the project then put it on the rear shelf. Within PRINCE2 2009 this would be a heresy. It must be taken account of at the appropriate milestones of any project. Projects should always be reviewed to show how they will contribute to the corporate objectives. Thus, the organization can compare projects to maximize their financial commitment. The person who asks ‘what is a Business Case’ is probably not running the project as well as can be expected.

This business reason is noted in the Business Case document. The rationales for the project will be based upon projections of costs, project risks and the expected gains. These reasons will thus drive the project decision making. The Executive will want to know the level of benefit (from a specific level of financial commitment) and when it will materialise given a specific set of risks.

It is beneficial to remember that any project has an objective and the project is certainly not an end in itself. Therefore, anything that influences the project should be evaluated by consulting the Business Case. So, it sits in the background of each project decision making.

Within PRINCE2 2009 the Senior User (s), who will also sit on the Project Board, will stipulate the benefits and guarantee that they are realized by the product.

The Executive has the responsibility for verifying that the benefits provided by the Senior User are in agreement with the objectives of the corporation, could be attained and are good value for money.

The PRINCE2 Business Case is put together at the start of a project and is managed and referred to for the duration of the project. It is formally ratified by the Project Board at decisive points in the project, for example, end stage analyses. Benefits are confirmed as they materialise. It is not just the Project Board that must put their trust in the project but likewise all the stakeholders.

If one currently exists, for instance, from program or corporate management, it should be changed to meet the current project demands.

So You Can Speak Geek – Big Deal, Can You Speak Business?

If you ask your VP of marketing what you need to look for in your next firewall purchase, what will he say? It needs to work? It needs to keep us safe? It needs to not interfere with our sending and receiving legitimate attachments? That hardly amounts to a technical specification.

On the other hand, if you ask your network engineer what to look for, what will he say? High throughput? Configurable Bayesian content filtering? Better SMTP relay protection? That hardly amount to a business justification.

So who do we ask, and what do we ask?

Often, technology purchases either start with management saying “fix this problem” or they start with the tech guys saying “hey, this thing isn’t working well anymore, we need to replace it”. In either case, there is likely to be a gap between what the suits (management) and the glasses (techies) think are important.

The suits will look at the ROI, the depreciation level of the existing equipment, the cap-ex or op-ex ramifications, and will want to know what this new expenditure will “do” for the business. The glasses are more likely to look at the technical specs, reliability, and bells and whistles. In the end, we often end up with the glasses not getting the budget they wanted (meaning they cut back on features they thought were important) and the suits feeling like they just spent money on who-knows-what-or-why.

Real-world (made up) example

To illustrate the conundrum, let’s talk about Jake. Jake is the IT Manager for Awesome Stuff LTD. Jake reports to the CFO, Ritchey (the financial guy is named Ritchey, like RICH-ee – see what I did there) who knows almost nothing about technology, but handles the department’s budget. Jake notices the company’s firewall needs to be replaced. It locks up and has to be bounced a few times a month, it’s throughput is barely keeping up with the load during peak times, and he gets constant complaints about the email content filtering “not working properly”. Further, he sees the need to upgrade the company’s bandwidth in the near future, but knows the firewall will be a bottleneck. So, he goes to Ritchey and says, “we need a new firewall”. Ritchey says, “why?”. Jake says, “because the flibbity-boppity multiplex protocol initiator is in a constant state of routing flux, and if we don’t replace it soon, we could easily have COBOL RAM application OSI malware” (that’s not actually what Jake said, but that’s what it sounded like to Ritchey).

Jake puts together a proposal to spend a modest $20,000 on a new, high-end, loaded with bells and whistles, firewall. That price tag comes with 5 years of 24×7 support, next day replacement, free software updates, content filtering, email spam filtering, and has consistently gotten A+ reviews for quality and reliability. He knows that this will solve problems for his department, save lost time for employees, improve the network’s reliability, and simply make things better at work.

Ritchey gets the proposal and sees 20 grand to replace a whatchamathingy that’s not even broken, won’t increase sales, won’t decrease costs, and doesn’t improve our business at all? The budget gets cut. Jake drops the service agreement, the ongoing support, the content filtering and spam filtering subscriptions, and downgrades by a few models.

The company has just missed out on an opportunity to solve a business problem, reduce costs, and improve efficiency and productivity just because Jake and Ritchey weren’t speaking the same language.

What’s the solution?

I think we have to get the suits and the glasses to speak the same language. So, we either teach our MBA-educated business people the ins and outs of software development, network engineering, systems design, and data security (not likely), or we start teaching our tech guys how business works.

How would the conversation have been different if Jake had made this proposal to Ritchey:

Look, our firewall is getting to the point of being unreliable. I’m concerned that we’re quickly heading for a hardware failure, which would mean an expensive quick-fix plus crazy-expensive downtime. The existing firewall is fully depreciated anyway, so it’s time to look at replacement. I’ve evaluated a new product that will meet our technical requirements. It will also give us the risk protection we need with a service contract and free software upgrades to make sure we get the most out of our investment. The purchase will cut my departments time spent managing the existing firewall by 40 man-hours per month. That’s 2,400 hours over the expected life of the product which means a $72,000 opportunity code reduction. We also get complaints from users who spend a lot of time fighting with improperly blocked email attachments, filtering through SPAM email, and fighting with the content filter. We expect $46,000 in improved employee productivity over 5 years by eliminating those issues. We also get better protection for our data, and we know from our recent risk assessment that exposure of our intellectual property would be disastrous – this purchase will help mitigate that risk.

Now, we can make the purchase up-front out of Capital or we can use their managed firewall service and keep it in Operating expense – which do you prefer?

Conclusion

My point here is, if you’re a techy, learn how business decisions are made. Learn what things are important to the suits. You might not like it, but you’ll be able to do your job much more effectively.

What do you think?