"Do the Right Project" BEFORE "Do the Project Right"

Project Managers are typically concerned with Doing the Project Right i.e. correctly executing a Project for a given objective. However most organisations don't have limitless funds and resources. Therefore the step before fully committing to Project execution is to establish whether there is sufficient justification against potentially competing initiatives i.e. Do the Right Project. This takes us into the world of the Project or Programme Business Case - hopefully not a world of fantasy as per the cartoon :-) 

Project Manager initial check-list when picking up a new Project

Although a good quality Project Business Case isn't the responsibility of the Project Manager, as a Project Management professional you should be encouraging good practice. Here is my start-up checklist:

1. Do you have a Sponsor (aided by others to OWN the Project depending on it's scale)? If not, you will need to seek one
2. You establish there is a Business Case already baselined (signed off by the right people in the organisation hierarchy). If so, confirm whether this is a constraint. When you build your Project Budget as part of Initiation you can validate whether this constraint can be met. If it is not a constraint, the Business Case may need to be modified out of Initiation
3. You establish there isn't a Business Case created. Then this should be on the list to achieve during the Initiation / Definition phase. You need to be clear that this is owned by the Sponsor but depending on his/her experience, you should be prepared to help author the document. But I will not send out this document for review / approval as ownership for this must clearly sit with the Sponsor

Things to consider in the Business Case

Fundamentally the Business Case answers the question WHY should the Project be undertaken i.e. what business benefits will it deliver to the organisation. Typically I would expect the following as a minimum:

1. Executive Summary - no more than a page of background, what the project will deliver, the costs and benefits
2. Cost breakdown - considering what costs can / can't be capitalised
3. Financial Benefits - with analysis in line with organisation standards. You typically represent money being spent against when revenue will be generated using a Net Present Value (NPV) analysis. Some organisations prefer Return on Investment (RoI) which is basically the same data represented slightly differently
4. Non Financial Benefits - these can be more nebulous in definition. It is important to establish the Critical Success Factor(s) and Targets with Proxy Measures if necessary. "Make Sydney a city on the World Stage" may have been part of the Business Case for the Sydney Opera House Construction Project? Agreement on how this will be measured (even by a proxy measure / Key Performance Indicator) needs to be developed if not present in the first cut Business Case (via the Benefit Realisation Plan - see below)
5. Assumptions underpinning the Business Case. This is sometimes where creative benefits are driven so these warrant active review! If the project budget has not been created out of Initiation, there should be an assumption around costs
6. Risks which may impact the Business Case

Beware the Mandatory "Get out of Jail Free" Card for Project Justification

Many Projects are justified on the basis of being Mandatory so if possible you should go beyond this statement to get to a better business justification. In such circumstances asking the question, what will happen if the Project doesn't get approved? is a way of flushing out the Business Case. 

I have been involved in many IT Upgrade projects for third party products and have seen the Mandatory card used. Better to ask the "not approved" question. If this means no third party support, has this support been used in the last year i.e. what risk is the organisation running? Is it possible to obtain vendor support for the existing Production version at a premium rate? By asking these questions and formulating a Business Case, the organisation may determine it is better to delay the Project (maybe waiting for a major new release) and take a risk and/or pay a additional support cost for a period of time.

Benefit Realisation Plan - the antidote to "fantasy business cases"

If within an Organisation the Business Case is just a mechanism to confirm funding for a Project, then this will encourage the use of too many creative assumptions as there is nobody on the hook for anything.

The most popular approach I have seen to ensure accountability for benefits is for one of the Project deliverables (or Products in PRINCE2 terminology) to be a Benefit Realisation Plan. I have detailed this in another post but the bottom line is that it quantifies who is on the hook to deliver what benefits and exactly how measurement will take place at some defined future date. This applies for both financial and non-financial benefits.

The Organisation needs to have a way of policing this as the benefits of the Project most often happen post closure of the Project itself (see my previous post on Project Success). A good example from one client organisation I have worked with is that as part of the Gate reviews to achieve funding for the next Stage in Project Execution, the latest Business Case is reviewed (i.e. it needs to be refined during the Project life-cycle). There is a final Gate review at a time agreed Post Project completion (typically a maximum of 1 year after completion), attended by the Project Sponsor, confirming whether benefits have been secured in line the Business Case.

Benefit Realisation - the ultimate example

I was involved in a Programme to introduce a variety of IT system improvements to reduce operational costs. A series of enhancement ideas across all IT systems in use were specified, evaluated for cost (effort to develop and implement) against the benefit (for the enhancement sponsor). Before the enhancement went into development the enhancement sponsor agreed to reduce his/her operational budget by the benefit amount. As soon as the change was signed off and went into Production, the enhancement sponsor's operational budget was reduced for the next year of operation. This was the ultimate Benefit Realisation as the Benefit was effectively captured within the Project life-cycle. It put the Enhancement Sponsor(s) on the spot to achieve the head-count reductions in the following year!