This page contains a number of different business case writing tips. Each one is based on my own experience with writing a business case, or reviewing other people’s business cases.

6 Basic Business Case Writing Tips

  1. Be clear on what the business change is that you want to implement with the project
  2. Work closely with the business to understand how things currently operate and what will need to change to give them the outcome they want
  3. Know who you are writing your Business Case for (who will be signing off on it)
  4. Don’t skimp on time to prepare your financial estimates
  5. Be very clear and detailed around your scope.  Lock it in
  6. Remember your aim is to put a strong case for change together, not write a marketing or sales document

And here are 5 more tips for writing a strong business case.

You Must Include This Content In a Business Case

Key content that must be covered in a business case is listed below.  And yes, some of these are likely to be things you are familiar with. First understand what needs to be included in each section.  This is different to what you could put there.  A lot of business cases read like marketing proposals, or even work sales documents.

In my opinion, they are a waste of time, especially for the people attempting to approve them.

The key content to include when you are writing your business case is:

  • Background
  • What’s the problem
  • What are the options
  • Cost estimates for the options
  • Key risks that you identify
  • List your assumptions
  • Your recommendation

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

5 Tips to Get Business Case Approval

We often think that once we write the document, that’s it, approval should automatically be given.  And yet that is often not the case.

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. These are options.
  4. Consider the option to buy 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?  Read about each of these five tips. While writing your business case think about each of these things.

In order to have your business case approved what do your PCB need to see? Don’t assume approval will automatically be given.

Go and ask the people who will sign-off on your business case what they want to see included in your business case. You might find they have specific areas that are more important to them.  Knowing this will help you to focus and provided the right level of information, to ensure sign-off or approval.

The Importance of Having Documented Business Requirements

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

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 about whether business requirements come first, or the business case does.  Prepare business requirements before the final business case is written and signed off.  Develop them in parallel with you writing your business case.

The best thing you can do to ensure project success is to develop a set of detailed Business Requirements and have them approved, I would almost say before you get too far into the development of your business case.

Because, what is contained in your requirements, will drive the options available for inclusion in your business case.

The Value of Strong Cost Estimates

Cost estimates are the area I see most PM’s struggle with.  One area that often causes problems is hidden costs. They 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 your project, for starters.

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

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

We often want to put our financials together in the easiest and quickest way.  This doesn’t always work.  I would highly recommend having a brainstorming session with people from both the business, and support to fully document their ideas on what costs need to be factored into your cost estimates. Especially look at the cost of running your project outcome in a Business As Usual state.

It is only through engaging with people who will support the project once it becomes ‘Business As Usual’ or fully operationalized that you will get a full handle on the true costs of implementing the change.

Strong cost estimates will drive your ability to monitor and control your project delivery.

Without them this job will be harder.

If your scope is locked down, through detailed requirements, and the option chosen is one that is practical, AND your cost estimates have been realistic, you will be able to manage project delivery simply by monitoring adherence to these key things – scope and budget.

Without either of these your project will be much harder to manage and most likely to fail.

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

Notice here that there is no talking about specific systems.  That’s the job of the IT Architects. Our job is only to propose the sort of solution that would best work to deliver the desired project outcome.

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 Manager needs to provide the evidence in the business case to show that it’s the most obvious way to go.

You do that by preparing your business case with rigour.

business case writingThe steps that I outline in the eBook ‘How To Write a Strong 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.

What do I mean when I say ‘stacks up’?

A Business Case should clearly show why undertaking a project will deliver the desired business change for the business.  If it doesn’t then it is not ‘stacking up.’  All of the pieces to make the change a viable option aren’t in place.

When you read a business case you should have no questions or concerns about it delivering what the business wants.  If you do, then your business case is not strong enough.  There is not enough of the right information contained in it to support it going ahead.

That’s what I mean when I say ‘it should stack up.’ And this is why it gets turned down.

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‘.  They do this because they think they need to convince the people signing off on the ‘Project’ that it should go ahead.

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 therefore 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 in the formulation of your business case.

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 did not paint a clear picture of what the project was 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 estimates are.

Strongly consider the need to do the ground work to provide realistic rather than ‘pie in the sky’ financials in your business case.  As I explained earlier, this is a very key area of your business case and so time needs to be given to developing it.

There are eight reasons why your business case sucks and I’ve listed them out so that you can check through how each of these items in order to determine BEFORE you present it, whether it is likely to be turned down or not.

Why Your Business Case is the Foundation Of Your Project

Projects that are not set up with a strong and valid business case fail. I don’t know how many times, when a project does fail I hear that one of the main reasons was the business case wasn’t strong.

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 up a project without them?  If you have written your business case well then project failure isn’t an option.

Consider as you are writing your business case that it IS the foundation for your project. Will it stand up to issues that might arise during the delivery phase?  If not, then you should go back and make the necessary changes BEFORE you begin your project to make things stronger.

Be clear on your scope, your budget, and your time frame for delivery.  Know the key risks that might topple what you are doing.

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 to write a business case is the person who knows the business and what it is that they want to achieve by undertaking 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 view there are people who shouldn’t write a business case.  If they do then the chances of it delivering for the business fails.

This probably seems a little crazy to you, especially if you have been given the job of writing the business case and you are not involved in the business.  It happens.

So my advice to you is, go and work with those in the business, as much as possible, in order to develop the business case.  Don’t work with vendors.  Don’t work with others not directly involved in the business area taking ownership of the change when the project is finished.

These people won’t provide you with the right information to support the writing of your business case from the right perspective.

What To Do When There Is No Business Case

You might have just begun your role as a Project Manager on a ‘project’ only to find that there is no business case.

Don’t panic! There are key things you can do to get a handle on what the expectations are, in terms of delivery.

Firstly, I suggest that you take this list of four key questions and you find the right people in the business to answer them, and have them answered.

Then ensure you have the answers to them documented, and get that document signed off by your Project Sponsor or Business Owner.

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 the Value 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. Anarea 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 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 up, the foundation and parameters by which to run our project.

So with that in mind, we did what was required to write a business case that ‘stacked up.’  It provided a very solid foundation for the project that it was written to set up.

Why business case writing this way is successful

In writing the business case we put together a very succinct and very strong case for why the change should happen.

This business case became the benchmark for all other business cases in the 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.

This mean the delivery team worked to the requirements and delivered two weeks ahead of schedule.

We came in on the 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.

From this 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 if this foundation is set up front.


If you want an easy to follow guide on how to write your business case you might like ‘How to Write a Strong Business Case’:

The Bookbusiness case writing

  • provides guidance and advice on how to gather the information needed for each area within the business case
  • explains why the particular information is required in the business case
  • explains how it connects to decision-making about whether the project that the business case is solving should proceed or not
  • allows you to clearly see if your business case ‘stacks-up’ or is valid
  • explains how to gain the buy-in from your decision makers
  • talks about why to not use previously written business cases for the same project.

The book also contains 12 tips as useful reminders of the key things to cover or watch out for in developing each area of your business case