business case writing tips

Business Case Writing Tips

Content that must be covered in a business case

There is key content that must be covered in a business case.  And yes, some of these are likely to be things you are familiar with.  The best way to complete each section is to understand what needs to be included in it.  This is different to what you could put there.  A lot of business cases read like marketing proposals.  In my opinion they are a waste of time, especially for the people attempting to sign the business case off.

The key content to include is:

  • Background
  • What’s the problem
  • What are the options
  • Cost estimates for the options
  • Your recommendation

Here are some further tips on writing good business case content.

Follow these 5 tips to get your business case approved

There are five key things you need to consider to have your business case approved.  They are:

  1. Don’t copy and paste pieces of information from other sources
  2. Have at least a high level set of business requirements captured before you start writing your business case
  3. Don’t be afraid to ‘Do Nothing’ or take a stepped approach to reach your outcome
  4. Consider the option of buying a ready made tool that is off the shelf
  5. Understand how to get your business case over the line

These things are important in their own way. Your business case is likely to be more successful if you consider them.  Why do I think this is the case?  If you do nothing else read the details of these five tips. Then consider for yourself why I feel they are important.

The importance of having business requirements

I know Project Managers that consider detailed business requirements aren’t necessary for a project, especially an IT build.  ‘Requirements’ are developed very differently when an Agile project method is used. Use cases are developed with each iteration. This can create gaps in business requirement gathering.

Business requirements lock in project scope. That is why I see them as very necessary for setting a project up for success.  There is a lot of  debate whether business requirements come first, or the business case does.  Business requirements must be fully completed before the final business case is prepared and signed off.  They therefore need to be developed in parallel.

The value of strong cost estimates

Cost estimates is the area I see most PM’s struggle.  Hidden costs can blow a project budget out of the water.  One of the keys to project failure for sure.  You might want to consider some of these hidden costs related to planning.

  • Reputation cost
  • The cost of stress on team members
  • BAU complacency
  • Additional resource costs

They may make the difference between a blown out budget and one that comes in on track.

Why documenting options is important

Are you comfortable that you understand the way to document options?  I find that if I have done all of the other preparation for the business case in the ‘right’ way, then the options naturally fall on the table and make writing this part of the business case easy.

Here are examples of four options for an IT software project:

  1. Do Nothing
  2. Re-engineering manual processes
  3. Partial automation of the process
  4. Full automation of the process

Writing up these different options is easy when you know how.

When the business case doesn’t stack up, stop the project

Senior stakeholders signing off the business case won’t say ‘stop the project before it gets started.’  A Project Managers needs to provide the evidence in the business case to show that it’s the most obvious way to go.  Do that by preparing your business case with rigour.  The steps that I outline in the ebook ‘A simple guide to writing a business case‘ help you to do that. The book  provides a step through process with instructions on what to include in each section of the business case, what to look out for during writing each area and how to validate that it stacks up.

How are you going to present your business case?

Have you thought about how you will present your business case? Project Managers often go into too much detail when they ‘present‘.  If you’ve followed my tips you will already have the full support and buy-in of each of your signatories; those people approving the business case.  Your presentation will only need to contain the high level details in order to gain the formal ‘sign-off’ for it and to allow you to answer any last minute questions. You should have no surprises at the presentation if you’ve done your job well.

Reasons why your business case might get turned down

There are a number of reasons why a business case gets turned down, not least of which is that the ‘business’ case for why the project should be undertaken is not clear.  I have seen numerous business cases that are very long and yet really do not paint a clear picture of what this project is going to achieve for the business and why the money, time and resources should be allocated for it. The other key area that is usually critical in gaining the approval is how realistic the financials are.  Strongly consider the need to do some ground work to provide more realistic rather than ‘pie in the sky’ financials in your business case.

Why your business case is the foundation for your project

Projects that are not set up with a strong and valid business case fail.  The business case is the foundation for any project.  You wouldn’t agree to a builder building your house without solid foundations, so why set a project up without them?  If you have written your business case well then project failure isn’t an option.

Has the right person written your business case?

One key aspect of writing a strong business case is having the right person writing it.  What do I mean when I say that?  For me the right person is the person who knows the business and what it is that they want to achieve with the project.  Often someone far removed from the actual business writes the business case. In being ‘too removed’ from it, or having an ulterior motive, the business case is not written with the right premise.  In my mind there are people who shouldn’t write a business case.  If they do then the chances of it delivering for the business fails.

What to do when there’s no business case

Don’t panic if you’re given responsibility for delivering a project and you find there is no business case. There are key things you can do to get a handle on what the expectations are, in terms of delivery.  I suggest that you take this list of four key questions and ensure you have the answers to them documented, and signed off.  Doing this creates clarity for both you and the business.  It will make both yours, and the project sponsors job easier in the long run.

Key things to look for when writing business cases for specific purposes

You might need to write a business case for a specific system implementation, or based on the method of project delivery that you are using.

I’ve put together some specific tips for some of these:

I hope that with all of these tips and tricks you will find that you look forward to writing a business case. As you will see, it as a task that you will enjoy doing if you have the right knowledge.

I know when I got to that point the business case contributed to successful project delivery.

My experience of writing a strong business case

I had the fortune of being the business PM on a project to build a new system for a key part of the business, one area that bought in a lot of revenue.  On the project I was working with a very experienced IT PM.

I have read many business cases that didn’t help me understand why the project was required.  I would watch the project start up and then fail, not delivering what the business really needed. This made sense to me based on my reading of the business case. These business cases were missing the compelling clarity of what they were going to deliver to the business.

I decided that we were going to put together a quality business case for our project so that it was sure to be a success.  This was my aim. I understood that if the business case was built the right way then it would give us, or set out, the foundation and parameters by which to run our project. So, we did.

Why it was successful

We put together a very succinct and very strong business case.  It became the benchmark for all other business cases in this organisation moving forward.  Why? Our business case was succinct. It clearly showed why the project was needed, what the value of doing it was, and the options that were considered. The recommendation for the option to take was clear AND the cost estimates were realistic.  Ten percent contingency was built it, only as a standard requirement.  We also had a clearly defined set of business requirements to support the business case.

With documented business requirements the scope was clear.  The team worked to the requirements and delivered two weeks ahead of schedule. We came in on budget, with no use of the contingency because the cost estimates were realistic. The business gained some process improvements in the process as we tweaked our scope during the system build by working closely with the business.  It was a winner.  The business got more than it wanted. It was a great outcome. A successful project.  I learned the value and importance of a strong well written business case.  It is possible to do and it makes a big difference to project success.