+64 4 499 1701
Mon - Fri: 07:00 am - 05:00 pm
Follow
BRAND NEW AGILE TECH!
Psoda is bridging the gap between physical and electronic kanban boards
Learn More
>
BRAND NEW AGILE TECH!
Psoda is bridging the gap between physical and electronic kanban boardsLearn More
>
Title Image

Project business cases: 5 things you need to know

Project Business Case: Ideas with people high fiving each other

Written by Rhona Aylward


Rhona is Deputy Everything Officer at Psoda, where she does everything except code. After starting life as a microbiologist she moved into PMO leadership roles around the world before settling in New Zealand with her family.

If you’re a project manager, chances are that at some point in your career you’ll be expected to write a project business case. This can be a daunting exercise, especially if you’ve never written one before.

I remember the very first business case I ever wrote. I can honestly say it was the biggest bunch of drivel I have ever written. It was even worse than some of my university assignments and that’s saying something! Thankfully, I had a great mentor who took the time to explain exactly where I went wrong and how I could make things better.

What is a business case?

Regardless of the project’s size, the business case’s job is to provide justification for the project, as well as give options on how to proceed. There should be enough information in the document to ensure that the steering committee can decide if the project is viable.

Unfortunately, I’ve seen some really horrendous project business cases over the years. A couple of stand-out examples are:

    • A one page business case for a multi-million dollar revamp of an IT system. To make matters worse, there wasn’t even any options – just a quote from a supplier (who turned out to be a friend of the project manager)
    • The business case that bore absolutely no resemblance to the project whatsoever. When questioned, the business case team said that they thought their idea was better than the organisation’s idea for the project, so they wrote that instead.

Needless to say, both business cases had to be completely rewritten putting the projects behind time and over budget before they’d even started!

So how do you avoid the rubbish business case trap?

First take into account is the size of your project. The amount of work and information that you’ll need to provide in the business case will depend on that. There’s no point writing a one page summary if you’re trying to get funding for a multi-million dollar project. The same is true in reverse. Presenting a 40 page in-depth document for funding for a $50,000 project will make you look stupid.

Team

The project executive is ultimately responsible for delivering the project’s business case but they typically delegate the writing to the project manager or a business analyst.

If you’re running a small project, and by that I mean something with a budget less than $500,000 and which will take a few months to complete, then it’s perfectly possible for you to write a one page business case on your own.

However, if the project is large, it is wise to put together a team to write the business case. That way you can make sure you have experts on hand to help. A typical business case writing team will include:

    • The project manager
    • Business analysts
    • A finance expert
    • Subject matter experts

Stakeholder engagement

Stakeholders tend to be overlooked when developing a business case for large and complicated projects.  It’s not uncommon for a business case to be approved without any stakeholder input and then be rejected when people kick up a fuss about the lack of consultation.

To avoid this from happening, make sure you develop a stakeholder engagement plan specifically for the business case and follow it. This should include a plan on how to influence senior decision makers so that they will support your proposal.

Contents of the business case

When you write the business case, you need to make sure it has enough information in it so the key stakeholders can make a decision.

Before you start, check if your organisation has a template. Most organisations will and they’ll likely have examples that you can work with (copy from). If they do have a standard format, then it is a simple process of filling in the blanks.

If you find yourself having to write a business case from scratch, here’s a good structure to follow:

    • Table of contents
    • Executive summary
    • Proposal
      • Background and current situation
      • Purpose
      • Urgency
      • Relationship to other projects and strategy
      • High level organisational impact
    • Expected benefits
    • Options
      • Option one
      • Option two
      • Option three
      • Options analysis
    • Project approach
      • Expected project timing
      • Project organisation
      • Costs
      • Expected risks
      • Key relationships
    • Other expectations

What to make sure you include in your business case

When you’re writing the project business case, there are some key things to make sure you include. Always provide three options in the options section. I make the first one the do nothing, or status quo option. The second one is the preferred option and the third one is a compromise or completely out-there solution.

Make sure you include any downsides as well as benefits.

Highlight any impacts on the business, both positive and negative.

Things to avoid

Sending a document that isn’t fit-for purpose will see your business case rejected on the spot.

Avoid ambiguity. On more than one occasion I’ve seen project managers held to account in the delivery phase of the project for something that was badly written in the business case.

I hope these tips are useful and will help you the next time you have to write a project business case, whether large or small.

Psoda Plug

If you’re looking for a tool to help you deliver outstanding projects – from the business case right through to delivery, then look no further than Psoda. Sign up for a free trial today!

Post a comment