The Project’s Business Case

It’s a shocking reality that many Project Managers have never sighted their project’s business case.  It’s true that a Business case takes many different shapes and sizes and called by many different names for that matter, however there are some identifying elements which should be present in every business case.

What is a Business Case?

A Business Case generally takes the form of a written document; it is used to convey a commercial solution to a need or opportunity.  The methods by which the action of presenting a solution differ greatly from industry, organisation, department or project to project for that matter.  The abundance of available templates and their inherent differences can be attributed to the confusion of many project managers as to what a business case should look like.

What should be included in a Business Case?

Now this question is a trap. One that many fall into.  A Business case should not be treated as a one size fits all; whilst there are items which I believe every business case should include, another professional may have good grounds to argue otherwise.  As such as Business case’s appearance and contents should be based upon the context in which it is being applied.

The core elements of a Business Case

Current Situation

As a business case is developed to propose a need for action, it makes sense that at its core it includes the current situation.  This should provide an accurate representation of the current issues and within its own right paint a picture that a change is required.

The current situation should focus and detail the problem or opportunity; for example: showing the number of loss of time injuries and associated contributing factors, recorded downtime for machinery or technology, issues with current systems or even the current brand perception or customer satisfaction levels.  Where possible these should be quantified.

The current situation is imperative for the establishment of a baseline to successfully analyse the impact of any future action or project.  Many projects fail to capture and adequately measure the situation prior to commencement and as such are not fully equipped to provide accurate realisation of benefits.

Background

The background is important in the establishment of context; not only with relation to the operating environment but also the previous attempts to remedy the problem or harness the opportunity.  The Background should further include any studies, investigations, reports or reliable data which can be utilised to inform decision making.

Proposal

The business case should provide at least a suggestion in how the issue may be resolved or improved upon.  At this stage this may be at a high-level (conceptual stage) however the solution should be tangible enough for other minds to meet.  The proposal may in fact be to conduct further research, employ a subject matter expert, consult the agency etc.  It is important to note that it isn’t required to fully solve the issue, but more so to provide an avenue to pursue.

Plan

This is where many people become unstuck, generally as they acquire a project planning template and get lost halfway through trying to complete the requirements. At this stage the plan should be a balance of certainty and effort.  The greater certainty the project has of being approved, the greater the effort which can be expended in its development.

The plan should illustrate;

• the proposed methodology, high-level schedule depicting key stages and milestones;
• a rough cost estimate;
• consideration of key risks, including the risks of doing nothing,
• key assumptions and constraints.

Scale the Template to the context

At this point you may be wondering how you could get away with proving such little information for a project to be approved; well as I said at the beginning, business cases need to be fit for purpose.  With that in mind drafting a business case for the installation of MS Project on my project team’s PC’s would probably not need to be covered in any greater depth than:

Current Situation	5 Project team members are not able to provide input into the project’s schedule.  This is causing all updates to be done by the project manager resulting in an additional 5 hours of work per week.
Background	All projects are using MS Project to establish, implement and adapt works schedules.  Currently the software is limited to the Project Manager’s PC, as such updates must be performed by the PM. The Project team have training in Project Management and MS Project as well as having capable PC’s to support the software.
Proposal	To procure and install the latest version of MS Project on 5 computers
Plan	Key Stages: Approve Business case, Procure Software, Install Software Estimates: Time: 1 week, Cost: $5000, Key Risks: Other staff may request software Key assumptions/constraints: Staff in positions do not need specialist training, no IT issues with installation and running of software

 

There it is, a business case in less than 150 words.  Whilst an argument could be made that it’s not complete; it may be all that is required for the Director to consider for approval.

As the project grows; in complexity, risk and cost the Business case will have a tendency to shadow the growth.  It makes sense; small business cases for small simple projects, and as they get bigger so do the business cases.  The key is to start small and get the core elements correct.

What else should be included in a Business Case?

We’ve already established that the above elements can in their own rights complete a business case, so I am happy if you answered nothing.  However let’s take the view of a more complex decision, possible one where rather than a sole party, a panel may be required to reach consensus, as such we may need to provide some additional information.

The following are discretionary and may not apply to all projects, if there is value in their inclusion, by all means adopt them, but if they are just sections inserted in a document to waste time and or confuse/irritate people- please leave them out.

Make your own business case

Title; now this makes it formal.  If it needs to be formal- great, insert a title.  Make it something that will provide a clear indication of the nature of the business case. For example, Request for MS Project Software conveys a lot more than Software Project Business Case or my favourite (sarcasm is so hard to portray in text) Project XXX.

Department/Company; Sure, if the company is large enough that the person approving the business case may not know who has submitted it.  However, for most cases there is a degree of proximity between the party developing the business case and the one approving.

Table of Contents; wow, that makes me feel like I’m writing a book.  A table of contents can be a blessing or a curse. There is no doubting their use in lengthy documents, however I find that those who start by including a table of contents have a tendency to increase the length of their documents to justify the inclusion of the table of contents.  Tip; leave it until last and include it if it will assist the reader.

Executive Summary; I’m going to treat this in a similar light to the table of contents; if it will assist the reader then include it.  I find in many cases the executive summary becomes an area which simply provides duplication of information. It’s real value is in the synthesis of a large document into a quickly read and understood abstract. Think of who will be reading the document; will it be of value to provide a short abstract to a time poor director?  Consider in some cases it may be the only part of the business case that is actually read.

Introduction; boring.  If you have included the background, current situation and proposal this will merely serve as an exercise in duplicity.  I notice that many Business Case templates do include and exc summary, background, current situation, proposal as well as an introduction, so I could be wrong- but I’m not.

Version/Document Control; you know if you need it.  If there is an organisational policy, follow that.  If many people will have access to or providing input into the document, it makes sense.  If you may be sending it for approval only to receive it and make changes, it also makes sense.  I’m not going to shoot this one down as it can dramatically reduce risk.

Acceptance Panel; Somewhere there is the notion that acceptance of contract must take place on a document which houses lots of signatures.  I may be rusty on my contract law, but pretty sure a contract can be formed verbally and unless governed by statute there is no need for a formal instrument. That aside- it helps.  Having a record of acceptance is a useful addition, whilst not essential in contract formation, keeping correct records can prove invaluable in the long run.

Vision; this has become very a very popular term and as such it has crept into many business cases.  Used in the right context, the vision is important it shows the future after the proposal has been adopted. This alongside the current situation can be a very powerful tool.  I wrote an article not too long ago on how a vision poster can be useful in projects, check it out.

Relevant objectives; it may be of use to show how this project aligns with departmental, organisational or strategic objectives.  This works on the notion that if your solution is assisting the organisation meet its objectives it is much more likely to be considered than one that doesn’t.  If relevant show the link- the solution will contribute towards, or in line with objective 1,2,3……. etc.

Assumptions and Constraints; useful inclusion for most Business Cases, however they don’t always need a separate section.  If there are some key assumptions which may be relied upon (or construed as fact) it is important to communicate that they are assumptions.  Items such as exchange rates, the weather, current state of something, the right to own, transfer etc. are common ones.

Purpose of the business case; Seriously this is in many businesses cases and it goes against the notion of a business case- keep it simple.  The purpose of the document is not to educate people on what the document is about.  It is implied that a business case is the proposal of a case; by which if adopted, business (work) will be required.  If your business case aims to do something different to this, which I doubt, then yes have a section which you can fill with the purpose of a business case.

Governance Structure; It is useful to highlight the key roles with relation to the business case, especially in multi-organisational projects or multi-disciplinary internal projects.  Identify the key roles, who is the sponsor, the client, the project manager.

Key Stakeholders; as with the governance structure it may assist to provide the parties which may be impacted or the capability to impact the decision as well as the process and outcome.  Generally, a stakeholder analysis will be in the project plan, but at this stage a high-level stakeholder study isn’t a bad idea.

Options; Yes, at the start I did say that the solution was a key inclusion.  However, you will find that many business cases also present options; in some cases, they are very real options, in others they are more ‘tactical’ options; see the video on the decoy effect to save explaining.  If there are options that can be presented, include them; the greater the number and nature of options presented at the start of the project the better.  This way they can be considered, voted on merit which often leads to a more robust solution.

Comparison of options; please don’t use this section for evil- if you have watched the decoy effect video you will know what I mean. Here you want to demonstrate (or rank) the alternate solutions.  You can use different metrics, whether financial; Return on Investment, Net Present Value, Payback Period etc., benefit based, qualitative and quantitative, risk based etc.  Remember to include the option of doing nothing- i.e. if no action is taken as really that is what you are using to get the business case approved.

Life cycle costing; this isn’t a real section in business cases, although it should be.  Too often the only resourcing (cost and human) considerations are those to get the solution implemented.  Care should be taken in assessing the costs over time, what are the maintenance costs over 5, 10, 15 years, who will own the deliverable, who will manage it etc.  This consideration should come into the comparison of options.

Recommendations; in most situations, it is useful to provide recommendations, the presumption of a recommendation is that the options have been considered, due diligence performed and there is an option which shows merit over the others.  If this is the case include a recommendation.  Be sure to establish the reasons why it has been selected.

Methodology; discussed earlier was the need to have a plan.  This may be a simple overview or a complex project plan. Use the logic of how much effort/accuracy is required to decide on this?  If it is for approval in principle, perhaps high-level indications are perfect, if it is in response to a request for tender or similar which will eventuate into a contract, then detailed specifics should be obtained.

Appendices: a great way to make the Business Case more digestible is by referring to extrinsic documentation rather than incorporating them into the business case.  This is also useful from a practical standpoint as if the source document changes the appendix has a greater chance of remaining current.

I am going to end the list here, I could keep going, but I fear if I continue you may not have the stamina; instead ask me any questions in the comments below.  Or use the comments to suggest items you find either useful or useless in Business Cases.