Options considered

Most problems or opportunities have a range of solutions, more than one of which may be compelling. The business case must successfully outline the solutions most likely to satisfy the need so that only one is selected for full expression. Here are some examples of alternatives for consideration:

e The business case to justify a new building for a company might consider the merits and risks of staying put, moving to a new, preconstructed building or commissioning a purpose-built office. e An operational inefficiency may be overcome by introducing a new computer solution. As well as living with the inefficiency, the business case could consider whether prepackaged software or a system developed in house would provide the best answer.

In both examples, the do-nothing option must feature. It is an essential part of any business case; not only does it provide a point of reference for other considered options, but it also often presents a compelling argument in favour of the project. Below are some examples of projects where the do-nothing option justified the eventual project:

e Automation project. Two computer systems were not connected but nevertheless were able to communicate because a single person copied data from a report from one system to the other once a month. The business sought to justify the investment needed to automate this process. It was only when it considered the costs of the staff member that it realised the investment needed to connect the two systems would take many years to justify and by then the two systems would already have been replaced. The do-nothing option prevailed. e Regulatory and legal changes. Companies such as banks are heavily regulated to avoid the risk that money is mishandled. When a bank is informed of a regulatory change that carries a legal penalty for failure to comply, it has little choice but to accommodate it in its systems and operating procedures. The only option may be when to adopt the change. e Year 2000 date change. During the late 1990s, it became necessary to amend the way in which many computer systems recorded calendar dates. Since many systems held only the last two digits of the year, there was real concern that some computers would fail to differentiate between the year 2000 and the year 1900. The change initiative was not justified by the benefits it would bring. Instead, projects went ahead because they would mitigate the risk of not amending the date. Millions were spent worldwide to avoid planes crashing, sewage plants flooding and hospital equipment failing.

Selected option

The selected option is the one that provides the most compelling argument in its favour. The use of the word compelling is intentional. Although the heart of the business case is formed from a balance of costs and benefits, during the early days of a project much of the debate will be emotional. It is important to avoid becoming either too driven by the stark numbers, or too persuaded by the power of an eloquent but unsubstantiated argument. The words and numbers used to describe the selected option must compel the organisation to put in a calculated figure, to face certain risks and to foresee the likelihood of a return on the investment. The costs, risks and benefits subsections must be expressed robustly.

Selected option: risks

A risk is a possible future event that may have adverse consequences. The business case should identify the risks to a project as well as its benefits from the outset. Although the project outline may have contained a highlevel risk assessment, the sponsor will have been focused on selling the idea, so this may be the first opportunity to consider the risks properly. An early example of the risk register might look like Table 8.2.

Table 8.2 Example of a risk register

Risk Likelihood Impact Mitigations

Pre-written, packaged software High Medium 1 Continue to use existing sales and solution will not hold key sales marketing system alongside new data needed by marketing solution.

team, resulting in their 2 Request a specific change from inability to work effectively software supplier.

If the live date is missed, Low High 1 Make this project mandatory to legal sanctions may be taken ensure it has a priority call on against our business, resulting essential resources.

in reputational and other 2 Commence project early to allow for losses any slippage.

The risk register identifies things that may have an untoward effect on the project and the mitigations that may be possible.

Since the business case is, by definition, not a plan, it is not expected that the costs (in money or time) of mitigation will have been fully assessed. When the project manager starts to create the project plan, these risks (and any others identified) will be subjected to a fuller assessment to determine more precisely their effect on the time, cost and quality expectations of the project. However, a rudimentary assessment will be necessary if the cost of mitigation is likely to increase substantially the timescale or significantly affect the costs/net benefits of the project.

The risk assessment also allows the project's effect on others in the portfolio to be seen. The second example in Table 8.2 shows how a choice made at this stage may affect the provision of resources to, or the duration of, other projects.

Selected option: benefits

This section should describe clearly each benefit in turn, including how they are to be measured and quantified in financial terms.

In preparation for the cost/benefit analysis, it is necessary to show the benefits over time (see Table 8.3).

Table 8.3 Benefits over time ($)

Year 0

Year l

Year 2

Year S

Year 4

Increased revenues

5,OOO

60,000

6O,OOO

7O,OOO

Increased customer satisfaction

5,000

10,000

10,000

10,000

Competitor removal

20,000

20,000

20,000

Customers from new market

30,000

30,000

40,000

Cost savings

S,OOO

1O,OOO

11,000

11,000

Headcount savings

5,000

5,000

5,000

5,000

Removal of redundant IT kit

3,000

5,000

6,000

6,000

Total

13,000

7O,OOO

71,000

81,000

Cumulative total

13,000

S3,OOO

154,000

235,000

Selected option: costs

Every cost associated with the project should be identified so that it can be quantified. Costs should not be only those expected up to the point of project closure; they should also include the operational, maintenance and support of the deliverable the project is producing. There is a good reason for this. The benefits of a project are unlikely to be realised until some time after it has been closed, yet running costs will be incurred while waiting for those benefits. Consequently, they must be shown over the same time period for a realistic comparison of costs and benefits to be made.

Budgets may be needed in:

E

company personnel;

E

external contract staff;

E

consultants;

E

hardware;

E

software;

E

e expenses (accommodation, travel, and so on); e maintenance contracts; e environment and operations.

To aid the cost/benefit analysis, the costs shown over time should be presented in the same form as the benefits (see Table 8.4).

Table 8.4 Costs over time ($)

Year 0

Year 1

Year 2

Year 3

Year 4

Resources

1,300

12,250

16,820

12,600

19,850

Consumables

1,000

Hardware

28,000

Software

17,000

Environmental

11,000

Accommodation

500

1,200

1,200

1,200

1,200

Expenses

700

2,400

1,600

1,600

3,200

Total

2,500

15,850

64,620

27,400

24,250

Cumulative total

2,500

18,350

82,970

110,370

134,620

Selected option: cost/benefit analysis

This will show whether the project is forecast to deliver a successful outcome and when. It provides a single view of the costs and benefits (see Table 8.5).

Table 8.5 Costs and benefits ($)

Year 0

Year 1

Year 2

Year 3

Year 4

Benefits

0

13,000

70,000

71,000

81,000

Costs

2,500

15,850

64,620

27,400

24,250

Total

-2,500

-2,850

5,380

43,600

56,750

Cumulative

-2,500

-5,350

30

43,630

100,380

Payback will be achieved in year 2 but it may also be desirable to show the discounted cash flow (see Table 8.6).

Table 8.6 Discounted cash flow ($)

Year 0

Year 1

Year 2

Year 3

Year 4

Benefits

0.00

13,000.00

70,000.00

71,000.00

81,000.00

Costs

2,500.00

15,850.00

64,620.00

27,400.00

24,250.00

Net

-2,500.00

-2,850.00

5,380.00

43,600.00

56,750.00

Cumulative

-2,500.00

-5,350.00

30.00

43,630.00

100,380.00

Discount factor

1.00

0.94

0.89

0.84

0.79

Discounted net

-2,500.00

-2,688.68

4,788.18

36,607.40

44,951.32

Net present value

-2,500.00

-5,188.68

-400.50

36,206.90

81,158.22

Note: Figures have been rounded.

If the project is part of a wider programme, it may be appropriate to include a financial dependency network to show the relationship between the different parts of the programme, and identify this specific project, like this example from Chapter 5 (Figure 8.2).

Selected option: deliverables and timescales

The business case has yet to describe what the project will deliver; so far, it is no more than a commercially focused response to a problem or an opportunity. This section presents a chance to describe what the project will produce during its initiation, delivery and closure stages, and when. This will give readers an early understanding of the project's outcome from a non-commercial perspective, identifying target dates by which key milestones should be met.

This is not a plan. A separate set of materials will be produced to describe how, if at all, these dates are to be met. Until the project plan is produced, the high-level deliverables and timescales listed here are only aspirations. However, unrefined as they may be, they are probably an improvement on what was included in the project outline and describe another important dimension of the management environment. Table 8.7 shows what this section may look like.

Table 8.7 Deliverables and timescales

Product

Target completion date

Status

Project outline

dd/mm/yy

Complete

Business case

dd/mm/yy

Under way

Project governance report

dd/mm/yy

User requirements document

dd/mm/yy

Solution design document

dd/mm/yy

Developed solution

dd/mm/yy

Tested solution

dd/mm/yy

Approved solution

dd/mm/yy

Project closure report

dd/mm/yy

Lessons learned

dd/mm/yy

Benefits realisation report

dd/mm/yy

Selected option: planning assumptions

None of the numbers or dates in any of the examples in this chapter has been explained. There is no audit trail to describe how they were derived or calculated. Although it is dangerous to make assumptions, by its nature, planning is educated guesswork. Those considering the business case will wish to know how the numbers and dates quoted were arrived at, so a list of planning assumptions must be included that fully describes the calculations in the business case.

Example planning assumptions include the following:

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Responses

Post a comment