The Business Case is the driving force in a PRINCE2 project.  Which is really sensible.  You are doing the project to deliver business benefit.  You might think you are doing it for fun, or for the good of your health, but actually it is to deliver business benefit!

It is important to realise that the Business Case is kept up to date throughout the project and there are constant checks to make sure that the project is still on track.  In PRINCE2, the minimum is the end of each management stage, but it could be updated more often than that.

It is important in the PRINCE2 method then, so it probably as well to get it right.  However, many (or even most, if you look at examples on the Internet) are not right.  There is a tendency to misunderstand benefits.  Even alleged PRINCE2 compliant project software products, including one that claims to come ‘in a box’ J gives examples of business benefits that are extremely bad, and actually are not benefits at all and especially not in the way that PRINCE2 looks at them.

So, what makes for a good Business Case then?  Here are a few hints and tips on business benefits in the Business Case, and then in keeping the Business Case up to date, but for a fuller picture, you might like to contact Inspirandum to buy a copy of our printed guide on writing Business Cases.

It is the justification

The Business Case is primarily the justification for the project.  Now immediately you need to be careful and actually you need to think a bit wider than the PRINCE2 manual suggests.  There are three main types of justification.

Business benefits – Okay the simple one first.  Most projects deliver business benefits and in PRINCE2 it is rather assumed that these are always measurable.  In fact that isn’t true, but it is the case that most are and wherever possible you should have measurable benefits so that it can be checked at the end if the project actually delivered.

Compliance.  Sometimes you are running the project because you have to.  There are no business benefits, but you will still run the project anyway.  A common example is with a legal requirement.  Suppose there has been a change in the tax laws and you have to run a project to change your computer systems to reflect them.  What are the business benefits?  Well, there aren’t any.  But you are still going to run the project because you have to; it’s the law.  You run the project to comply.

Enabling.  This is a project that doesn’t deliver any business benefits, but it allows other projects to run which do deliver benefit.  An example is with infrastructure projects.  The new computer network won’t save us any time or money and will actually cost us money.  But it will enable other projects to run which will deliver considerable benefits.

When is a benefit a benefit?

You need to be really sure that benefits are actually that, benefits.  It is easy to get these wrong.  Here are a few examples of some non-benefits.

The new computer system will have an integrated database.

That isn’t a business benefit but rather just a technical feature.  Beware of Business Cases from ‘techies’ (technical specialists) who don’t understand benefits because often their Business Cases will be a list of such technical features.

The new business procedure will free up a basement room.  Given the building value, the annual recurring saving will be $120,000 a year.

Well, maybe, but only if you have a use for the basement room.  If it is going to stand empty then actually there will be no saving at all.

The working environment will be better which will improve staff retention.

This is not a business benefit.  What do the words ‘better’ and ‘improve’ mean?  They would be extremely difficult to measure and use to offset the cost of the project.  This is far too vague to be a business benefit, and especially so in a PRINCE2 project where the emphasis is on measurable benefits.

Avoiding benefits contamination

‘Benefits contamination’ is a phrase coined by Inspirandum to describe the problem where a benefits claimed by a project is actually affected by something outside the project.  For example, in a project to improve staff retention by improving the working environment (to use the poor example from above), suppose that in the six months following the project, no staff left the organisation.  Would that mean that the project had been successful?  Well, not necessarily.  If the economic climate had worsened in that time and made it very hard to get another job in that industry sector, that could account for the lack of staff resignations, not the project at all.

You may need to think long and hard to be sure that you can isolate benefits and be sure that they are due to the project and only due to the project.

The life of the PRINCE2 Business Case

In PRINCE2, the Business Case is developed at two levels.  In start up, it is just rough and generalised; ‘ball park’.  This is known as the Outline Business Case, but be careful if you work on really large projects where that phrase can have a very different meaning.  Then in the planning or Initiation Stage, it is worked into full detail and it is this fully detailed Business Case that is kept up to date throughout the project.

The Project Mandate

The Project Mandate, the trigger to a PRINCE2 project, could include the Outline Business Case.

Start Up

If the Business Case is not included on the mandate, it is developed in start up, the informal preparation work that precedes the project.  It is included in the Project Brief which is  now used by the PRINCE2 Project Board to decide whether or not to start the project and do the full planning – the Initiation Stage.

Initiation

In the Initiation Stage, the Business Case is worked up into full detail and that will involve investment appraisal if necessary.  It is now included in the Project Initiation Document or PID, which is used by the Project Board to decide if they want to commit to running the whole project.

During PRINCE2 management stages

During stages the Business Case will be checked so that early warning can be given if the project is not longer predicted to deliver the required level of benefit, but it may also be updated.  It could be, for example, that examination of a Project Issue reveals an impact on the business benefits so the Business Case might then need to be updated to reflect that.

At the end of a management stage.

The PRINCE2 process ‘SB – Managing Stage Boundaries’ requires that the Business Case is updated towards the end of each stage so that the Project Board has the very latest position in view when deciding whether or not to authorise the next stage.

At end project

At the end of the project, any benefits immediately visible are measured and reported.  The Business Case gives the information on this, including the measures to be applied.  In addition, for any benefits that can’t be seen for a while, a Post Project Review (PPR) Plan is drawn up.  This too will be based on the Business Case information.

At PPR

The Post Project Review will measure and report on benefits that were not visible, or could not yet be measured accurately, at the end of the project.  There may be enough information in the PPR Plan to do this, but typically there won’t be and the Business Case will be referenced to check on the benefits measures.

   Back to top

back to the PRINCE2 page

Looking for more detail? 

Please contact us to order a copy of our Business Case Project Guide.

Measurable benefits in PRINCE2

Be careful to ensure that the benefits in your Business Case really are benefits

Avoiding "benefits contamination"

On the Project Mandate

In the Project Brief

In the PID

Update when looking at Issues

Update at end stage

Measuring benefits at the end of the project

Measuring benefits at PPR

home page │ site map │ contact us

PRINCE2 Practitioner│ PRINCE2 for Dummies book│ project management course │ risk management workshop

© Inspirandum 2008