<SCI>

<SCI>clopaedia

Swanston Cottage Industries

Business Case Theme


4.1 PURPOSE

The purpose of the Business Case theme is to establish mechanisms to judge whether the project is and remains desirable, viable, and achieveable as a means to support decision making in its continued investment.

It is a PRINCE2 principle that a project must have a continued business justification.

So, the reason for doing the project is written down and agreed amonst all interested parties before it starts in earnest as a part of pre-project preparations. It is verified and made more complete during the initiation stage. It is important to plan Business Case maintenance throughout the project. If the project is tested and found unfit for purpose while in flight it must be stopped or chaned.


4.2 BUSINESS CASE DEFINED

It is the optimum mix (for you Rooster) of information used to judge whether the project is and remains viable, desirable and achievable. The Business Case is the tool that allows you to ascertain if the whole kit and kaboodle is worth doing.

Outputs, outcomes and benefits are what we use to understand if the project is still a good thing.

  • Output - Any of the project's specialist products.
  • Outcome - Result of the change derived from using the project's outputs.
  • Benefit - Measurable improvement resulting from an outcome that is percieved as an advantage by one or more stakeholders.

Example of output, outcome and benefits
Output: New sales system
Outcome: Sales orders are processed more quickly and accurately
Benefit: Costs are reduced by 10%, the volume of sales are increased by 15% and revenue is increased by 10% annually.

If the original purpose of the project is not to get lost it is imperative that the connnections between the products being produced as outputs, their outcomes and ultimate benefits are clearly exposed to the project team.

4.2.3 TYPES OF BUSINESS CASE

Project triggers are many and varied. Their raison d'ĂȘtre influences the objectives used to judge the ongoing desirability. Measuring those objectives varies depending on the business driver.

  • Compulsory
  • Not-for-profit
  • Evolving
  • Customer/supplier
  • Multi-organization

Most project can be measured on ROI but others, like the compulsory ones, are measured by such things as clinical adhereance to the law.

Whatever the driving force the question remains; for this level of project investment are the products desireable, viable and achievable?

If there is a better option, you must recommend or take it.

Please see Tailoring PRINCE2


4.3 APPROACH TO THE BUSINESS CASE

The Business Case is is developed at the beginning of the project, maintained throughout the life of the project. It is formally verified by the Project Board at each key decision point, and confirmed throughout the period that the benefits accrue.

  • Develop - Get the right information to base decisions on.
  • Verify - Assess if the project is still worthwhile.
  • Maintain - Update the Business Case with actual costs and recalculate forecasts.
  • Confirm - Assess if the benefits can still be realized with latest forecasts. This is also done following project closure.

The Business Case is at the centre of any impact from risks, issues and changes being the instrument against which all these variables are measured.

4.3.1 DEVELOPING THE BUSINESS CASE

The Executive is responsible for the Business Case. This does not mean it writes it more that it ensures it's written and approved.

As a project or programme manager I ask for this task to be delegated to me. I work with a business analyst if available and write it up. This gives me a clear understanding of the project and reduces risk.

The outline Business Case is derived from the project mandate and developed during the "Starting up a Project" process in order to gain approval by the project board in the Directing a Project process to initiate the project. It is at best based on timescales and costs that are approximate.

The detailed Business Case puts meat on the bones of the outline from which it is derived. For this we need a Project Plan and the Risk Register. Now we have the initial justification to proceed, OR once the costs and timescles are better understood the desirability, viability and achievability may have diminished then the approach may need to change or the project be abandoned.

4.3.2 VERIFYING AND MAINTAINING THE BUSINESS CASE

Made sure the Business Case is still valid by checking it;

  • At the end of Starting a Project
  • At the end of Initiating a Project
  • As part of any impact assessment
  • In tandem with and exception plan
  • At the end of each stage
  • During the final stage
  • As a part of the benefits review

The project executive have accountability to the stakeholders to confirm the project's viability throughout its life cycle. Project assurance can assist with this task if available.

The necessary information to validate project viability is documented in the "Investment Appraical" section of the Business Case.

4.3.3 CONFIRMING THE BENEFITS

The approach to confirming the benefits is to:

  • Identify the benefits
  • Select objective measures that reliably prove the benefits
  • Collect the baseline measures from which the improvements will be quantified.
  • Describe how, when and by whom the benefit measures will be collected

It is the job of the Senior User to specify the benefits and that they are realized upon completion of the project. This will involve commitment by the Senior User beyond the life of the project and involve some readiness to set up a senond project team to plug any gaps required if the benefits are not quite as expected.

PRINCE2 defines the Benefit Review Plan during initiation inreadiness for the end of project success tests. It sets out the scope of the tests, timing and responsibilty for a number of reviews based on the timing and nature of the expected benefits.


You as the jobbing PM will create the first Benefits Review Plan for approval by the project board. This plan is updated at the end of each stage perhaps with some of the benefits already ticked off and those outstanding more clearly defined, especially those which run beyond the end of the project.

I have found that post project benefit reviews are most effective when given to the finance department for follow up at year end to see if the operational prodcuts are delivering successfully or if there have been and side effects (+ or -) to report that may provide useful lessons learned for other projects.


4.3.4 Contents of the Business Case

It describes the reasons for the project based on estimated costs, risks and expected benefits.

Contents

Click here to see an example of a Product Description or a Business Case.


4.3.4.1 Reasons

Why is this project needed? Set the project in the context of the broader organizational strategy and objectives. Extract the reasons from the project mandate or seek clarification from the project board.

4.3.4.2 Business options

There are three

  • Do nothing
  • Do the minimum
  • Do something

Do nothing is your starting position for reasoning why the project is needed. The difference between this and something is the business benefit.

Analyse each option and present them to the board so that they can choose which is the best.

4.3.4.3 Expected Benefits

List them here. Define the current status of each benefit as a baseline against which the benefit delivery can be measured.

Benefit are financial and non-financial (cashable/non-cashable) and should be;

  • Aligned to corporate objectives and strategy
  • Mapped from the outputs and outcomes provided by the project
  • Quantified with tolerances
  • Measurable
  • Assigned

The senior user is responsible for the set of benefits. The realisation of those benefits may be delegated.

It is important to map any and all products delivered by the project to one of these benefits. A tracability matrix mapping products, through outcomes to benefits is an important management tool. All products will be related to a benefit or it is canned.

Express benefits in tangible ways. For example; Happier staff = reduced staff turnover. Improved sales = increase of 5% next financial year.

This done it is possible to establish if the project has been a success and the defined benefits are set out in the Benefits Review Plan to check them.

4.3.4.4 Expected dis-benefits

These are things that will get worse at a result of your project. Things like merging two sites, while there will be benefits in terms of costs and efficienies there will be a period of lower productivity and staff discontent while the merger is in progress. They need to be considered as a part of the overall investment appraisal before the project is kicked off.

4.3.4.5 Timescale

Interested parties (and you) would like to know;

  • Over what period are costs going to be incurred, usually by month.
  • Over what period will the cost benefit analysis be based
  • When do the benefits begin
  • What's the earliest/latest feasible start date
  • What's the earliest/latest feasible completion date

Write them down and share with your project team for enlightened discusssions.

4.3.4.6 Costs

Summarize the costs from the project plan here and the accompanying assumptions. A precis of ongoing operations and maintenance costs here is also very helpful.

4.3.4.7 Investment Appriasal

Now you have gathered enough information to compare the development costs with the anticipated benefits over a period of time.

You collect the development, management and operational costs, compare to the benefits and see what and when your stakeholders get their ROI. And you tell them and the team.

4.3.4.8 Major Risks

Do a risk assessment and highlight only the major risks at this point or people get lost in too much detail. Those risks which are most clearly connected to the benefits are the best choice to allow this Business Case to be approved or otherwise.


4.4 Responsibilities

Here are the responsibilities for the business case theme.
Corporate/programme management: Provide mandate, define standards. Hold Senior Users to account. Post project Benefit Review Plan.
Executive: The Business Case throughout the project
Senior User: Specifying the benefits. Specifying the desired outcomes. Ensure the benefits are realized. Provide actual vs. forecast benefits reviews.
Senior Supplier: Supplier Business Case (if needed) see Tailoring PRINCE2.
Project Manager (you!): Prepare the Business Case. Copnduct impact analysis on risk and issues as the project progresses. Assess and update the Business Case at the end of each management stage. Report on the project performance against this case upon project closure.
Project Assurance: Assist in the development of the Business Case. Verify and monitor it. Ensure alignment with overall programme / corporate strategy. Monitor finance and value for money. Monitor changes. Review impact assessment. Verify and monitor Benefits Review Plan.
Project Support: Baseline the Business Case and inform the PM of any changes to products that affect said document.


<SCI> | a crea8tive collective