2

OBJECTIVES
When you have completed this chapter you will be able to:
• describe the contents of a typical business plan;
• explain project portfolio management;
• carry out an evaluation and selection of projects against strategic, technical and economic criteria;
• use a variety of cost–benefit evaluation techniques for choosing among competing project
proposals;
• evaluate the business risk involved in a project;
• explain how individual projects can be grouped into programmes;
• explain how the implementation of programmes and projects can be managed so that the planned
benefits are achieved.

2.1 Introduction
The first that many developers hear of an ICT project is when they are allocated to the project team. However,
new projects do not appear out of thin air. There will be some process – varying in sophistication between
organizations – that decides that the project is worth doing.
As we saw in Chapter 1, sometimes managers justify a commitment to a single project as the benefits will
exceed the costs of the implementation and operation of the new application. In other cases, managers would
not approve a project on its own, but can see that it enables the fulfilment of strategic objectives when
combined with other projects.
Thus a project to establish an ICT infrastructure within an organization might not deliver a direct financial
benefit, but could provide a platform for subsequent projects to do so.
22 So ware Project Management

It might not be possible to measure the benefits of a project in financial terms. If you create a system which
allows the more accurate recording of data concerning the medical condition of patients, it might contribute
to the alleviation of pain and the preservation of life, but it would be difficult to put a money value on these.
The last chapter emphasized that an ICT or software project needed a business case. In this chapter we
explain what such a document might contain. A business case may be presented for several potential projects,
but there may be money or staff time for only some of the projects. Managers need some way of deciding
which projects to select. This is part of portfolio management. This chapter will discuss some ways in which
projects can be evaluated and compared for inclusion in a project portfolio. The chapter finishes by discussing
the way groups of projects which together contribute to a common business objective can be managed as
programmes of projects.

2.2 A Business Case

The section on the Organizations may have different titles such as a feasibility study or a project justifi-
business case draws cation for what we call the business case. Its objective is to provide a rationale for the
on B. Hughes (2008) project by showing that the benefits of the project outcomes will exceed the costs of
Exploiting IT for busi-
ness benefit. British development, implementation and operation (or production).
Computer Society.
Typically a business case document might contain:
1. Introduction and background to the proposal
2. The proposed project
3. The market
4. Organizational and operational infrastructure
5. The benefits
6. Outline implementation plan
7. Costs
8. The financial case
9. Risks
10. Management plan
These sections will now be described in more detail.

Introduction and background

This is a description of the current environment of the proposed project. A problem to be solved or an oppor-
tunity to be exploited is identified.

The proposed project

A brief outline of the proposed project is provided.

In Section 2.3 we will The market

explore further the dif-
ference between new This is needed when the project is to create new product or a new service capability.
product development This would contain information like the estimated demand for the product or service
and renewal projects.
and any likely competitors.
 Project Evaluation and Programme Management 23

Organizational and operational infrastructure

This describes how the structure of the organization will be affected by the implementation of the project.
This is of most relevance where the project is implementing or modifying an information system as part of a
broader business change project. It would also be relevant if a tailored production or distribution system has
to be set up when a new product is designed.

Benefits
Where possible, a financial value should be put on the benefits of the implemented project. For commercial
organizations this could be related to increased profits caused either by increasing income or by making
savings on costs. For not-for-profit organizations we would try to quantify the benefits even if we cannot
quote a precise financial value. In an example we used earlier relating to an IT system that improved the
diagnosis of a particular disease, an increase in the rate of diagnosis might be quoted.

Outline implementation plan

In addition to the ICT aspects of the project, activities such as marketing, promotion and operational and
maintenance infrastructures need to be considered. One consideration will be which project activities can be
outsourced, and which are best kept in-house.
This will also detail the management of the implementation. The responsibilities are allocated for the tasks
identified in the outline implementation plan. Key decision points or milestones, where a health-check on the
state of the implementation is taken, should be identified. As we will see, for a large implementation a number
of projects may be needed which can be managed as a programme.

Costs
Having outlined the steps needed to set up the operations needed by the proposal, a schedule of expected costs
associated with the planned approach can now be presented.
There will clearly be some uncertainties about some of the costs, especially as the details of the requirements
have not yet been worked out.

The financial case

There are a number of ways in which the information on income and costs can be analysed and these will be
the subject of the section on evaluation techniques later in this chapter.

Risks
Once again a more detailed discussion of risks will follow in a later section. We note here that many estimates
of costs and, more particularly, benefits of the project will be speculative at this stage and the section on risk
should take account of this. In the last chapter we distinguished between project and business objectives.
We can similarly distinguish project risk – relating to threats to successful project execution – from business
24 So ware Project Management

risk – relating to factors threatening the benefits of the delivered project. In the business case the main focus
is on business risk.

2.3 Project Portfolio Management

Quite a good introduc-
Portfolio project management provides an overview of all the projects that an organi-
tion to the concepts of zation is undertaking or is considering. It prioritizes the allocation of resources to
portfolios can be found projects and decides which new projects should be accepted and which existing ones
in B. De Reyck et al.
‘The impact of project
should be dropped.
portfolio management
on information technol-
The concerns of project portfolio management include:
ogy projects’ (2005) ● identifying which project proposals are worth implementation;
International Journal of
Project Management ● assessing the amount of risk of failure that a potential project has;
23 524–37.
● deciding how to share limited resources, including staff time and finance, between

projects – one problem can be that too many projects are started given the resources
available so that inevitably some projects will miss planned completion dates;
● being aware of the dependencies between projects, especially where several projects need to be
completed for an organization to reap benefits;
● ensuring that projects do not duplicate work;
● ensuring that necessary developments have not been inadvertently been missed.
The three key aspects of project portfolio management are portfolio definition, portfolio management and
portfolio optimization. An organization would undertake portfolio definition before adopting portfolio
management and then proceeding to optimization.

Project portfolio definition

Warren McFarlan’s
An organization should record in a single repository details of all current projects. A
(1981) ‘Portfolio ap- decision will be needed about whether projects of all types are to be included. Should
proach to information just ICT projects be included in the repository, or should other projects such as the
systems’ Harvard
Business Review 59(5)
setting up of a new warehouse also be included? One problem for many organiza-
142–50 introduced the tions is that projects can be divided into new product developments (NPD) where the
project deliverable is a product, such as a computer game, that is sold to customers,
portfolio concept to in-
formation systems.
and renewal projects which improve the way an organization operates – information
systems projects are often like this. The distinction is not always clear-cut. For
example, a new information system could be used to provide a customer service such as recording the details
of people buying a new insurance product.
NPD projects are often more frequent in organizations which have a continuous development of new goods
and services. Renewal projects may be less frequent and thus inherently more risky as there is less experience
of these types of project. NPD projects find attracting funding easier with their clear relationship between the
project and income. Where both types of project call upon the same pools of resources, including finance, the
argument for a common portfolio is strong.
 Project Evaluation and Programme Management 25

Project portfolio management

Once the portfolio has been established, more detailed costings of projects can be recorded. The value that
managers hope will be generated by each project can also be recorded. Actual performance of projects on
these performance indicators can then be tracked. This information can be the basis for the more rigorous
screening of new projects.

Project portfolio optimization

The performance of the portfolio can be tracked by high-level managers on a regular basis. A better balance
of projects may be achieved. Some projects could potentially be very profitable but could also be risky. In
the case of an e-commerce site, for example, sales may not be as great as hoped because established compet-
itors reduce prices. Other projects could have modest benefits, such as those cutting costs by automating
processes, but have fewer risks. The portfolio ought to have a carefully thought-out balance between the two
types of project.

Some problems with project portfolio management

An important role of project portfolio management is sharing resources between
projects. There can be problems because while apparently full-time staff are allocated Interesting insights into
the practical problems
to a project, they may effectively be part-time because they still have routine work to of portfolios can be
do. This is particularly so with users, and with developers who may on occasion be found in B. S. Blichfeldt
called away from project work to deal with support tasks. and P. Eskerod (2008)
‘Project portfolio man-
The official project portfolio may not accurately reflect organizational activity if some agement – there’s
more to it than man-
projects are excluded. A formal decision may be made that only projects over a certain agement enacts’ Inter-
level of cost will be recorded in the portfolio. national Journal of
Project Management
The ‘below the line’ projects could in fact consume substantial staff effort and bleed 26: 357–65.
away effort from the official projects. It can be argued that all projects should be
included in the official portfolio.
However, there are advantages in allowing these tasks. It allows small ad hoc tasks to be done, such as
quick fixes to systems to deal with externally imposed changes. They reduce work for higher management
by saving them from having to process a large number of small work requests. Developers may find these
small tasks rewarding: dealing with these small requests is an easy way to keep users happy. Thus when
allocating resources to projects, a margin should be set to allow first-line managers some judgement in
accepting non-planned work.

2.4 Evaluation of Individual Projects

We will now look more closely at how the feasibility of an individual project can be evaluated.

Technical assessment
Technical assessment of a proposed system consists of evaluating whether the required functionality can
be achieved with current affordable technologies. Organizational policy, aimed at providing a consistent
hardware/software infrastructure, is likely to limit the technical solutions considered. The costs of the
technology adopted must be taken into account in the cost–benefit analysis.
26 So ware Project Management

Cost–benefit analysis
Any project aiming at Even where the estimated benefits will exceed the estimated costs, it is often necessary
a return on investment to decide if the proposed project is the best of several options. Not all projects can
must, as a minimum,
provide a greater ben-
be undertaken at any one time and, in any case, the most valuable projects should get
efit than putting that most resources.
investment in, say, a
bank. Cost–benefit analysis comprises two steps:
● Identifying all of the costs and benefits of carrying out the project and operating the delivered appli-
cation These include the development costs, the operating costs and the benefits expected from the new
system. Where the proposed system is a replacement, these estimates should reflect the change in costs
and benefits due to the new system. A new sales order processing system, for example, could only claim
to benefit an organization by the increase in sales due to the use of the new system.
● Expressing these costs and benefits in common units We must express each cost and benefit – and the

net benefit which is the difference between the two – in money.

Most direct costs are easy to quantify in monetary terms and can be categorized as:
The different types of ● development costs, including development staff costs;
benefits will be dis- ● setup costs, consisting of the costs of putting the system into place, mainly of any
cussed in greater detail
in the context of ben- new hardware but also including the costs of file conversion, recruitment and staff
efits management later training;
in this chapter.
● operational costs relating to operating the system after installation.

EXERCISE 2.1

Brightmouth College is considering the replacement of the existing payroll service, operated by a third
party, with a tailored, off-the-shelf computer-based system. List some of the costs it might consider
under the headings of:
● Development costs

● Setup costs

● Operational costs

List some of the benefits under the headings:

● Quantified and valued benefits

● Quantified but not valued

● Identified but not easily valued

For each cost or benefit, explain how, in principle, it might be measured in monetary terms.

Typically products gen-

erate a negative cash Cash flow forecasting
flow during their devel-
opment followed by a As important as estimating the overall costs and benefits of a project is producing
positive cash flow over a cash flow forecast which indicates when expenditure and income will take place
their operating life.
There might be decom- (Figure 2.1).
missioning costs at the
end of a product’s life.
 Project Evaluation and Programme Management 27

We need to spend money, such as staff wages, during a project’s development. The difficulty and
importance of cash
Such expenditure cannot wait until income is received (either from using software
flow forecasting is
developed in-house use or from selling it). We need to know that we can fund this evidenced by the
development expenditure either from the company’s own resources or by borrowing. number of companies
that suffer bankruptcy
A forecast is needed of when expenditure, such as the payment of salaries, and any
because, although
income are to be expected. they are developing
profitable products or
Accurate cash flow forecasting is difficult, as it is done early in the project’s life services, they cannot
cycle (at least before any significant expenditure is committed) and many items to sustain an unplanned
negative cash flow.
be estimated (particularly the benefits of using software) might be some years in the
future.

FIGURE 2.1 Typical product life cycle cash flow

When estimating future cash flows, it is usual to ignore the effects of inflation. Forecasts of inflation rates tend
to be uncertain. Moreover, if expenditure is increased due to inflation it is likely that income will increase
proportionately.

2.5 Cost–benefit Evaluation Techniques

We now take a look at some methods for comparing projects on the basis of their cash flow forecasts.
Table 2.1 illustrates cash flow forecasts for four projects. In each case it is assumed that the cash flows
take place at the end of each year. For short-term projects or where there are significant seasonal cash flow
patterns, quarterly, or even monthly, cash flow forecasts could be appropriate.

TABLE 2.1 Four project cash flow projec ons – figures are end of year totals (£)

Year Project 1 Project 2 Project 3 Project 4

0 –100,000 –1,000,000 –100,000 –120,000

1 10,000 200,000 30,000 30,000
2 10,000 200,000 30,000 30,000
3 10,000 200,000 30,000 30,000
4 20,000 200,000 30,000 30,000
5 100,000 300,000 30,000 75,000
Net profit 50,000 100,000 50,000 75,000
28 So ware Project Management

EXERCISE 2.2

Consider the project cash flow estimates for four projects at JOE shown in Table 2.1. Negative values
represent expenditure and positive values income.
Rank the four projects in order of financial desirability and make a note of your reasons for ranking
them in that way before reading further.

Net profit
The net profit of a project is the difference between the total costs and the total income over the life of the
project. Project 2 in Table 2.1 shows the greatest net profit but this is at the expense of a large investment.
Indeed, if we had £1 m to invest, we might undertake all of the other three projects and obtain an even greater
net profit. Note also that all projects contain an element of risk and we might not be prepared to risk £1 m.
We shall look at the effects of risk and investment later in this chapter.

Cash flows take place

Moreover, the simple net profit takes no account of the timing of the cash flows.
at the end of each Projects 1 and 3 each have a net profit of £50,000 and therefore, according to this
year. The year 0 repre- selection criterion, would be equally preferable. The bulk of the income occurs late
sents the initial invest-
ment made at the start
in the life of project 1, whereas project 3 returns a steady income throughout its life.
of the project. Having to wait for a return has the disadvantage that the investment must be funded
for longer. Add to that the fact that, other things being equal, estimates in the more
distant future are less reliable than short-term estimates and we can see that the two projects are not equally
preferable.

Payback period
The payback period is the time taken to break even or pay back the initial investment. Normally, the project
with the shortest payback period will be chosen on the basis that an organization will wish to minimize the
time that a project is ‘in debt’.

EXERCISE 2.3

Consider the four project cash flows given in Table 2.1 and calculate the payback period for each of
them.

The advantage of the payback period is that it is simple to calculate and is not particularly sensitive to small
forecasting errors. Its disadvantage as a selection technique is that it ignores the overall profitability of the
project – in fact, it totally ignores any income (or expenditure) once the project has broken even. Thus the fact
that projects 2 and 4 are, overall, more profitable than project 3 is ignored.

Return on investment
The return on investment (ROI), also known as the accounting rate of return (ARR), provides a way of
comparing the net profitability to the investment required. There are some variations on the formula used to
calculate the return on investment but a straightforward common version is:
 Project Evaluation and Programme Management 29

average annual profit

ROI = 3 100
total investment

EXERCISE 2.4

Calculating the ROI for project 1, the net profit is £50,000 and the total investment is £100,000. The
return on investment is therefore calculated as
average annual profit
ROI = 3 100
total investment
50 ,000 / 5
= 3 100 = 10%
100 ,000
Calculate the ROI for each of the other projects shown in Table 2.1 and decide which, on the basis of
this criterion, is the most worthwhile.

The return on investment provides a simple, easy-to-calculate measure of return on capital. Unfortunately,
it suffers from two severe disadvantages. Like the net profitability, it takes no account of the timing of the
cash flows. More importantly, this rate of return bears no relationship to the interest rates offered or charged
by banks (or any other normal interest rate) since it takes no account of the timing of the cash flows or of the
compounding of interest. It is therefore, potentially, very misleading.

Net present value

The calculation of net present value is a project evaluation technique that takes into Net present value
account the profitability of a project and the timing of the cash flows that are produced. (NPV) and internal
This is based on the view that receiving £100 today is better than having to wait until rate of return (IRR) are
collectively known as
next year to receive it. We could, for example, invest the £100 in a bank today and discounted cash flow
have £100 plus the interest in a year’s time. If we say that the present value of £100 (DCF) techniques.
in a year’s time is £91, we mean that £100 in a year’s time is the equivalent of £91
now.
The equivalence of £91 now and £100 in a year’s time means we are discounting the Note that this example
future income by approximately 10%. If we received £91 now and invested it for a uses approximate
figures.
year at an annual interest rate of 10%, it would be worth £100 in a year’s time. The
annual rate by which we discount future earnings is known as the discount rate – 10%
in the above example.
Similarly, £100 received in two years’ time would have a present value of approxi- A rate of 10% may
mately £83 – in other words, £83 invested at an interest rate of 10% would yield be unrealistic but is
approximately £100 in two years’ time. used here for ease of
calculation.
The present value of any future cash flow may be obtained by applying the following
formula
value in year t
Present value =
(1 + r )t
30 So ware Project Management

where r is the discount rate, expressed as a decimal value, and t is the number of years into the future that the
cash flow occurs.
Alternatively, and rather more easily, the present value of a cash flow may be calcu-
More extensive or
detailed tables may be
lated by multiplying the cash flow by the appropriate discount factor. A small table of
constructed using the discount factors is given in Table 2.2.
formula discount fac-
tor 1
for various The NPV for a project is obtained by discounting each cash flow (both negative
(1 + t )t
and positive) and summing the discounted values. It is normally assumed that any
values of r(the discount
rate) and t (the number
initial investment takes place immediately (indicated as year 0) and is not discounted.
of years from now). Later cash flows are normally assumed to take place at the end of each year and are
discounted by the appropriate amount.

TABLE 2.2 NPV discount factors

Discount rate (%)

Year 5 6 8 10 12 15
1 0.9524 0.9434 0.9259 0.9091 0.8929 0.8696

2 0.9070 0.8900 0.8573 0.8264 0.7972 0.7561

3 0.8638 0.8396 0.7938 0.7513 0.7118 0.6575

4 0.8227 0.7921 0.7350 0.6830 0.6355 0.5718

5 0.7835 0.7473 0.6806 0.6209 0.5674 0.4972

6 0.7462 0.7050 0.6302 0.5645 0.5066 0.4323

7 0.7107 0.6651 0.5835 0.5132 0.4523 0.3759

8 0.6768 0.6274 0.5403 0.4665 0.4039 0.3269

9 0.6446 0.5919 0.5002 0.4241 0.3606 0.2843

10 0.6139 0.5584 0.4632 0.3855 0.3220 0.2472

15 0.4810 0.4173 0.3152 0.2394 0.1827 0.1229

20 0.3769 0.3118 0.2145 0.1486 0.1037 0.0611

25 0.2953 0.2330 0.1460 0.0923 0.0588 0.0304

EXERCISE 2.5

Assuming a 10% discount rate, the NPV for project 1 (Table 2.1) would be calculated as in Table 2.3.
The net present value for project 1, using a 10% discount rate, is therefore £618. Using a 10% discount
rate, calculate the net present values for projects 2, 3 and 4 and decide which, on the basis of this, is the
most beneficial to pursue.
 Project Evaluation and Programme Management 31

TABLE 2.3 Applying the discount factors to project 1

Year Project 1 cash flow (£) Discount factor @ 10% Discounted cash flow (£)

0 –100,000 1.0000 –100,000

1 10,000 0.9091 9,091

2 10,000 0.8264 8,264

3 10,000 0.7513 7,513

4 20,000 0.6830 13,660

5 100,000 0.6209 62,090

Net Profit: £50,000 NPV: £618

It is interesting to note that the net present values for projects 1 and 3 are significantly different – even though
they both yield the same net profit and both have the same return on investment. The difference in NPV
reflects the fact that, with project 1, we must wait longer for the bulk of the income.
The main difficulty with NPV for deciding between projects is selecting an appropriate discount rate. Some
organizations have a standard rate but, where this is not the case, then the discount rate should be chosen
to reflect available interest rates (borrowing costs where the project must be funded from loans) plus some
premium to reflect the fact that software projects are normally more risky than lending money to a bank.
The exact discount rate is normally less important than ensuring that the same discount rate is used for all
projects being compared. However, it is important to check that the ranking of projects is not sensitive to
small changes in the discount rate – have a look at the following exercise.

EXERCISE 2.6

Calculate the net present value for each of the projects A, B and C shown in Table 2.4 using each of the
discount rates 8%, 10% and 12%.
For each of the discount rates, decide which is the best project. What can you conclude from these
results?

TABLE 2.4 Three es mated project cash flows

Year Project A (£) Project B (£) Project C (£)

0 –8,000 –8,000 –10,000

1 4,000 1,000 2,000

2 4,000 2,000 2,000

(Contd)
32 So ware Project Management

(Contd)

3 2,000 4,000 6,000

4 1,000 3,000 2,000

5 500 9,000 2,000

6 500 −6,000 2,000

Net Profit 4,000 5,000 6,000

Alternatively, the discount rate can be thought of as a target rate of return. If, for example, we set a target rate
of return of 15% we would reject any project that did not display a positive net present value using a 15%
discount rate. Any project that displayed a positive NPV would be considered for selection – perhaps by using
an additional set of criteria where candidate projects were competing for resources.

Internal rate of return

One disadvantage of NPV as a measure of profitability is that, although it may be used to compare projects,
it might not be directly comparable with earnings from other investments or the costs of borrowing capital.
Such costs are usually quoted as a percentage interest rate. The internal rate of return (IRR) attempts to
provide a profitability measure as a percentage return that is directly comparable with interest rates. Thus, a
project that showed an estimated IRR of 10% would be worthwhile if the capital could be borrowed for less
than 10% or if the capital could not be invested elsewhere for a return greater than 10%.
The IRR is calculated as that percentage discount rate that would produce an NPV of zero. It is most easily
calculated using a spreadsheet or other computer program that provides functions for calculating the IRR.
Microsoft Excel, for example, provides IRR functions which, provided with an initial guess or seed value
(which may be zero), will search for and return an IRR.
One deficiency of the IRR is that it does not indicate the absolute size of the return. A project with an NPV
of £100,000 and an IRR of 15% can be more attractive than one with an NPV of £10,000 and an IRR of 18%
– the return on capital is lower but the net benefits greater.
Another objection to the internal rate of return is that, under certain conditions, it is possible to find more than
one rate that will produce a zero NPV. However, if there are multiple solutions, it is always appropriate to take
the lowest value and ignore the others.
NPV and IRR are not, however, a complete answer to economic project evaluation.
● A total evaluation must also take into account the problems of funding the cash flows – will we, for
example, be able to repay the interest on any borrowed money at the appropriate time?
● While a project’s IRR might indicate a profitable project, future earnings from a relatively risky project
might be far less reliable than earnings from, say, investing with a bank. We might undertake a more
detailed risk analysis as described below.
● We must also consider any one project within the financial and economic framework of the organi-
zation as a whole – if we fund this one, will we also be able to fund other worthy projects?
 Project Evaluation and Programme Management 33

EXERCISE 2.7

Check if the projects A, B, and C shown in Table 2.4 are worth taking up when the rate of interest on
borrowed capital is 15%.

2.6 Risk Evaluation

Every project involves risk. We have already noted that project risks, which prevent the project from being
completed successfully, are different from the business risk that the delivered products are not profitable.
Project risks will be discussed in Chapter 7. Here we focus on business risk.

Risk identification and ranking

In any project evaluation we should identify the risks and quantify their effects. One approach is to construct
a project risk matrix utilizing a checklist of possible risks and classifying risks according to their relative
importance and likelihood. Importance and likelihood need to be separately assessed – we might be less
concerned with something that, although serious, is very unlikely to occur than with something less serious
that is almost certain. Table 2.5 illustrates a basic project risk matrix listing some of the business risks for
a project, with their importance and likelihood classified as high (H), medium (M), low (L) or exceedingly
unlikely (—). So that projects may be compared, the list of risks must be the same for each project assessed.
It is likely, in reality, that it would be longer than shown and more precise.
The project risk matrix may be used as a way of evaluating projects (those with high risks being less favoured)
or as a means of identifying and ranking the risks for a specific project.

TABLE 2.5 A fragment of a basic project/business risk matrix for an e-commerce applica on

Risk Importance Likelihood

Client rejects proposed look and feel of site H —

Competitors undercut prices H M

Warehouse unable to deal with increased demand M L

Online payment has security problems M M

Maintenance costs higher than estimated L L

Response times deter purchasers M M

Risk and net present value

Where a project is relatively risky it is common practice to use a higher discount rate to calculate net present
value. This risk premium might, for example, be an additional 2% for a reasonably safe project or 5% for a
fairly risky one. Projects may be categorized as high, medium or low risk using a scoring method and risk
34 So ware Project Management

premiums designated for each category. The premiums, even if arbitrary, provide a consistent method of
taking risk into account.

Cost–benefit analysis
A rather more sophisticated approach to the evaluation of risk is to consider each possible outcome and
estimate the probability of its occurring and the corresponding value of the outcome. Rather than a single
cash flow forecast for a project, we will then have a set of cash flow forecasts, each with an associated proba-
bility of occurring. The value of the project is then obtained by summing the cost or benefit for each possible
outcome weighted by its corresponding probability. Exercise 2.8 illustrates how this may be done.

EXERCISE 2.8

BuyRight, a software house, is considering developing a payroll application for use in academic institu-
tions and is currently engaged in a cost–benefit analysis. Study of the market has shown that, if BuyRight
can target it efficiently and no competing products become available, it will obtain a high level of sales
generating an annual income of £800,000. It estimates that there is a 1 in 10 chances of this happening.
However, a competitor might launch a competing application before its own launch date and then sales
might generate only £100,000 per year. It estimates that there is a 30% chance of this happening. The
most likely outcome, it believes, is somewhere in between these two extremes – it will gain a market
lead by launching before any competing product becomes available and achieve an annual income of
£650,000. BuyRight has therefore calculated its expected sales income as in Table 2.6.

TABLE 2.6 BuyRight’s income forecasts

Sales Annual sales income (£) Probability Expected value (£)

i p i3p

High 800,000 0.1 80,000

Medium 650,000 0.6 390,000

Low 100,000 0.3 30,000

Expected Income 500,000

Development costs are estimated at £750,000. Sales levels are expected to be constant for at least four
years. Annual costs of marketing and product maintenance are estimated at £200,000, irrespective of
the market share. Would you advise going ahead with the project?

This approach is frequently used to evaluate large projects such as the building of motorways, where variables
such as traffic volumes, and hence the total benefit of shorter journey times, are uncertain. The technique, of
course, relies on being able to assign probabilities of occurrence to each scenario, which requires extensive
research.
When used to evaluate a single major project, the cost–benefit approach, by ‘averaging out’ the negative and
positive outcomes of the different scenarios, does not take full account of ‘worst-case scenarios’. Because
 Project Evaluation and Programme Management 35

of this, it is more appropriate for the evaluation of a portfolio of projects where overall profitability is the
primary concern, more successful projects can offset the impact of less successful ones.

Risk profile analysis

An approach which attempts to overcome some of the objections to cost–benefit averaging is the construction
of risk profiles using sensitivity analysis.
This involves varying each of the parameters that affect the project’s cost or benefits to ascertain how sensitive
the project’s profitability is to each factor. We might, for example, vary one of our original estimates by plus
or minus 5% and recalculate the expected costs and benefits for the project. By repeating this exercise for
each of our estimates in turn we can evaluate the sensitivity of the project to each factor.
By studying the results of a sensitivity analysis we can identify those factors that are most important to the
success of the project. We then need to decide whether we can exercise greater control over them or otherwise
mitigate their effects. If neither is the case, then we must live with the risk or abandon the project.

Using decision trees

The approaches to risk analysis discussed previously rather assume that we are passive bystanders allowing
nature to take its own course – the best we can do is to reject over-risky projects or choose those with the best
risk profile. There are many situations, however, where we can evaluate whether a risk is important and, if it
is, decide a suitable course of action.
Such decisions will limit or affect future options and, at any point, it is important to be able to assess how a
decision will affect the future profitability of the project.
As an example, say a successful company is considering when to replace its sales order processing system.
The decision largely rests upon the rate at which its business expands – if its market share significantly
increases (which it believes will happen if rumours of a competitor’s imminent bankruptcy are fulfilled) the
existing system might need to be replaced within two years. Not replacing the system in time could be an
expensive option as it could lead to lost revenue if it cannot cope with increased sales. Replacing the system
immediately will, however, be expensive as it will mean deferring other projects already scheduled.
It is calculated that extending the existing system will have an NPV of £75,000, although if the market
expands significantly, this will be turned into a loss with an NPV of –£1 00,000 due to lost revenue. If the
market does expand, replacing the system now has an NPV of £250,000 due to the benefits of being able to
handle increased sales and other benefits such as improved management information. If sales do not increase,
however, the benefits will be severely reduced and the project will suffer a loss with an NPV of –£50,000.
The company estimate the likelihood of the market increasing significantly at 20% – and, hence, the proba-
bility that it will not increase as 80%. This scenario can be represented as a tree structure as shown in
Figure 2.2.
The analysis of a decision tree consists of evaluating the expected benefit of taking each path from a decision
point (denoted by D in Figure 2.2). The expected value of each path is the sum of the value of each possible
outcome multiplied by its probability of occurrence. The expected value of extending the system is therefore
£40,000 (75,000 3 0.8 – 100,000 3 0.2) and the expected value of replacing the system £10,000 (250,000 3
0.2 – 50,000 3 0.8). The company should therefore choose the option of extending the existing system.
36 So ware Project Management

FIGURE 2.2 A decision tree

2.7 Programme Management

It should now have been made clear that there will be an element of risk with any
Ferns’ paper appeared single project. Even where projects produce real financial benefits, the precise size
in the International
Journal of Project of those benefits will often be uncertain at the start of the project. This makes it
Management August important for organizations to take a broad view of all its projects to ensure that while
1991. some projects may disappoint, organizational developments overall will generate
substantial benefits.
We introduced project portfolios in Section 2.3. We will now examine how careful management of
programmes of projects can provide benefits. D. C. Ferns defined a programme as ‘a group of projects
that are managed in a coordinated way to gain benefits that would not be possible were the projects to be
managed independently’.
Programmes can exist in different forms, as can be seen below.

Business cycle programmes

The collection of projects that an organization undertakes within a particular planning cycle has already been
discussed under the topic of project portfolios. We have seen that many organizations have a fixed budget for
ICT development. Decisions have to be made about which projects to implement within that budget within
the accounting period, which often coincides with the financial year.
 Project Evaluation and Programme Management 37

Strategic programmes
Several projects together can implement a single strategy. For example, the merging of two organizations’
computer systems could require several projects each dealing with a particular application area. Each activity
could be treated as a distinct project, but would be coordinated as a programme.

Infrastructure programmes
Organizations can have various departments which carry out distinct, relatively self-contained, activities. In
a local authority, one department might have responsibilities for the maintenance of highways, another for
refuse collection, and another for education. These distinct activities will probably require distinct databases
and information systems. In such a situation, the central ICT function would have responsibility for setting up
and maintaining the ICT infrastructure, including the networks, workstations and servers upon which these
distinct applications run. In these circumstances, an infrastructure programme could refer to the activities of
identifying a common ICT infrastructure and its implementation and maintenance.

Research and development programmes

Truly innovative companies, especially those that are trying to develop new products for the market, are
well aware that projects will vary in terms of their risk of failure and the potential returns that they might
eventually reap. Some development projects will be relatively safe, and result in the final planned product,
but that product might not be radically different from existing ones on the market. Other projects might be
extremely risky, but the end result, if successful, could be a revolutionary techno-
Alan Webb (2001)
logical breakthrough that meets some pressing but previously unsatisfied need. ‘When project manage-
ment doesn’t work’
A successful portfolio would need to be a mixture of ‘safe projects’ with relatively Project Management
low returns and some riskier projects that might fail, but if successful would generate Today May.
handsome profits which will offset the losses on the failures.

Innovative partnerships
Companies sometimes come together to work collaboratively on new technologies in a ‘pre-competitive’
phase. Separate projects in different organizations need to be coordinated and this might be done as a
programme.

2.8 Managing the Allocation of Resources within Programmes

We are now going to examine in more detail programmes where resources have to be shared between
concurrent projects. Typically, an ICT department has pools of particular types of expertise, such as software
developers, database designers and network support staff, and these might be called upon to participate in a
number of concurrent projects.
In these circumstances, programme managers will have concerns about the optimal
The comparison is
use of specialist staff. These concerns can be contrasted with those of project managers based on G. Reiss
– see Table 2.7. (1996) Programme
Management
The project managers are said to have an ‘impersonal relationship’ with resource Demystified, Chapman
types because, essentially, they require, for example, a competent systems analyst & Hall.
38 So ware Project Management

TABLE 2.7 Programme managers versus project managers

Programme manager Project manager

Many simultaneous projects One project at a time

Personal relationship with skilled resources Impersonal relationship with resource type

Need to maximize utilization of resources Need to minimize demand for resources

Projects tend to be similar Projects tend to be dissimilar

and who fills that role does not matter. The programme manager has a number of individual systems analysts
under his or her control whose deployment has to be planned.
When a project is planned, at the stage of allocating resources, programme management will be involved.
Some activities in the project might have to be delayed until the requisite technical staff are freed from work
on other projects. Where expensive technical staff are employed full-time, then you would want to avoid them
having short periods of intense activity interspersed with long periods of idleness, during which they are still
being paid. It is most economic when the demand for work is evenly spread from month to month.
As will be seen in Chapter 9 on monitoring and control, when a project is executed activities can take longer
(or sometimes even less time) than planned. Delays can mean that specialist staff are prevented from moving
on to their next project. Hence it can be seen that programme management needs continually to monitor the
progress of projects and the use of resources.

2.9 Strategic Programme Management

A different form of programme management is where a portfolio of projects all contribute to a common
objective. Take, for example, a business which carries out maintenance work for clients. A customer’s
experience of the organization might be found to be very variable and inconsistent. The employee who
records the customer’s requirements is different from the people who actually carry out the work and different
again from the clerk who deals with the accounts. Often a customer has to explain to one company employee
a problem that has already been discussed at length with some other employee. A business objective might be
to present a consistent and uniform front to the client. This objective might require changes to a number of
different systems which until now have been largely self-contained. The work to reorganize each individual
area could be treated as a separate project, coordinated at a higher level as a programme.

Recall that OGC is the These types of programme are most often needed by large organizations which have a
Office of Government large and complicated organizational structure. Government departments are typical
Commerce which was examples and it is not surprising that the OGC, the United Kingdom government
formerly the Central
Computing and agency which was responsible (as the CCTA) for the introduction of PRINCE2 project
Telecommunications management standards, has directed its attention to guidelines for effective programme
Agency or CCTA. management. The approach now described is based on the OGC guidelines.
 Project Evaluation and Programme Management 39

2.10 Creating a Programme

The programme mandate
The OGC envisages that the planning of a programme will be triggered by the creation of an agreed programme
mandate. Ideally this should be a formal document describing:
● the new services or capabilities the programme should deliver;

● how the organization will be improved by use of the new services or capability;

● how the programme fits with corporate goals and any other initiatives.

At this point, a programme director ought to be appointed to provide initial leadership for the programme. To
be successful, the programme needs a champion who is in a prominent position within the organization. This
will signal the seriousness with which the organization takes the programme.

The programme brief

A programme brief is now produced which outlines the business case for the programme. It will have sections
setting out:
● a preliminary vision statement which describes the new capacity that the organization seeks – it is

described as ‘preliminary’ because this will later be elaborated;

● the benefits that the programme should create – including when they are likely to be generated and how

they might be measured;

● risks and issues;

● estimated costs, timescales and effort.

The vision statement

The programme brief should give the sponsors enough information to decide whether to request a more
detailed definition of the programme. This stage would justify the setting up of a small team. A programme
manager with day-to-day responsibility for the programme would be appointed.
This group takes the vision statement from the project brief and refines and expands it. It should describe in
detail the new capability that the programme will give the organization. If estimates for costs, performance
and service levels cannot be provided, then there should at least be an indication of how they might be
measured; for example, one might be able to say that repeat business will be increased, even if the precise
size of the increase cannot be provided.

The blueprint
The achievement of the improved capability described in the vision statement can come only through changes
to the structure and operations of the organization. These are detailed in the blueprint. This should contain:
● business models outlining the new processes required;

● organizational structure – including the numbers of staff required in the new systems and the skills they

will need;
● the information systems, equipment and other, non-staff, resources that will be needed;
40 So ware Project Management

● data and information requirements;

● costs, performance and service level requirements.
To return to the example of the organization which wants to present a consistent interface to its customers:
while this aspiration might be stated in the vision statement, the way that it is to be achieved would have to
be stated in the blueprint. This might, for example, suggest:
● the appointment of ‘account managers’ who could act as a point of contact for the client throughout

their business transactions with the company;

● a common computer interface allowing the account manager to have access to all the information

relating to a particular client or job, regardless of the computer system from which it originates.
The blueprint is supported by benefit profiles which estimate when the expected benefits will be experi-
enced following implementation of the enhanced capability. One principle is that a programme should deliver
tangible benefits. Being provided with a capability does not guarantee that it will be used to obtain the benefits
envisaged. For example, as a part of the programme above, the marketing department might be provided
with sales and demographic information which allows them to target potential customers more accurately.
This should improve the ratio of sales revenue to advertising costs. However, just because this information
is available does not mean that the marketing staff will necessarily make effective use of it. Hence the need
for evidence of actual business benefits. The timing of the benefits needs to be carefully considered. Thus
marketing campaigns that target particular customers might take time to plan and organize and the benefits in
increased sales and/or lower advertising costs could take some months to become apparent.
The management structure needed to drive this programme forward would also need to be planned and
organized.
A preliminary list of the projects needed to achieve the programme objectives will be created with estimated
timescales. This programme portfolio will be presented to the programme sponsors.
Communication plans A major risk is that some of those whose work will be affected by the programme
are considered in more will not be drawn into the programme effectively. A stakeholder map identifying the
detail in Chapter 12.
groups of people with an interest in the project and its outcomes and their particular
interests could be drawn up. This can be used to write a communications strategy and plan showing how the
appropriate information flows between stakeholders can be set up and maintained.
We noted back in Chapter 1 that with conventional project planning, it is not usually possible to plan all the
phases of a project at the outset, as much of the information needed to produce the detailed plans will not be
available. This is more so with programmes. However, at the initial programme planning stage, a preliminary
plan can be produced containing:
● the project portfolio;

● cost estimates for each project;

● the benefits expected (including the appropriate benefits profile);

● risks identified;

● the resources needed to manage, support and monitor the programme.

This information allows a financial plan to be created. This enables higher management to put in place the
budget arrangements to meet the expected costs at identified points in time. These will be tied to points in the
programme when higher management review progress and authorize further expenditure.
 Project Evaluation and Programme Management 41

2.11 Aids to Programme Management

Dependency diagrams
There will often be physical and technical dependencies between projects. For example, a project to relocate
staff from one building to another cannot start until the project to construct the new building has been
completed. Dependency diagrams, which are very similar to activity networks at project level, can show
these dependencies. However, where projects run concurrently in a programme and products interchange, the
dependency diagrams could become quite complicated.
Figure 2.3 shows a dependency diagram for a programme to merge two organizations, the constituent parts
of which are explained below.
A Systems study/design A project is carried out which examines the various existing IT applications in the
two old organizations, analyses their functionality, and makes recommendations about how they are to
be combined.
B Corporate image design Independently of Project A, this project is designing
There will be interde-
the corporate image for the new organization. This would include design of the pendencies between C
new logo to be put on company documents. and D that will need to
be managed.
C Build common systems Once Project A has been completed, work can be
triggered on the construction of the new common ICT applications.

FIGURE 2.3 An example of a dependency diagram

D Relocate offices This is the project that plans and carries out the physical co-location of the staff in the
two former organizations. In this scenario, this has to wait until the completion of Project A because that
project has examined how the two sets of applications for the previous organizations could be brought
together, and this has repercussions on the departmental structure of the new merged organization.
E Training Once staff have been brought together, perhaps with some staff being made redundant, training
in the use of the new systems can begin.
F Data migration When the new, joint, applications have been developed and staff have been trained in
their use, data can be migrated from existing databases to the new consolidated database.
42 So ware Project Management

G Implement corporate interface Before the new applications can ‘go live’, the interfaces, including the
documentation generated for external customers, must be modified to conform to the new company
image.

Delivery planning
The creation of a delivery dependency diagram would typically lead to the definition of tranches of projects.
Atranche is a group of projects that will deliver their products as one step in the programme. The projects in a
tranche should combine to provide a coherent new capability or set of benefits for the client. A consideration
in scheduling a tranche will be the need to avoid contention for scarce resources.
Figure 2.4 shows how the programme’s portfolio of projects can be organized into tranches, each of which
delivers some tangible benefits to the user.

FIGURE 2.4 Delivering tranches of project deliverables

At this point, the planning of individual projects can be considered. This could be initiated by the writing of
project briefs, defining the scope and objectives of each project.

2.12 Some Reservations about Programme Management

Some writers on project management have expressed reservations about the way they see the ideas of
programme management being presented. It is argued that approaches like the one we have described above
focus on structure – for example, who reports to whom – at the expense of process – for example, the basis
on which decisions are made.
The main concern is that the programme may be seen as some kind of ‘super-project’. This could lead to two
problems: first, that programme management may exert an unnecessary control over the subordinate projects,
leading to bureaucratic obstruction. The second is that programmes should be seen as the means by which
the objectives of the business are converted into action at the level of projects. The business environment is
constantly changing and as a consequence programmes need to evolve and be modified during the course of
 Project Evaluation and Programme Management 43

their execution. If the super-project idea predominates then too much planning at the beginning plus a reluc-
tance to change the scope of the programme may lead to inflexibility.
As we have seen in the case of the company merger programme, the projects within a programme may be
very different from one another. Also, some programmes – for example where engineering integration is
important – may need to be quite tightly coordinated, whereas other programmes could afford a more flexible
regime.
The main lessons here seem to be:
● programme management is not simply a scaled-up project management;
● different forms of programme management may be appropriate for different types of project.

2.13 Benefits Management

Thomas K. Landauer
We have already noted that providing a capability does not guarantee that the capability (1995) The Trouble
with Computers:
will be used to deliver the planned benefits. Businesses have become aware of the
Usefulness, Usability
lack of evidence of some investments in ICT increasing the productivity of organiza- and Productivity, MIT
tions. Even with business process re-engineering (BPR), the radical reorganization Press, explores the is-
sues of the ‘productiv-
of businesses to deliver improvements in efficiency and effectiveness, there are many
ity paradox’ in IT.
reported cases where the expected benefits have not materialized.
Benefits management is an attempt to remedy this. It encompasses the identification, optimization and
tracking of the expected benefits from a business change in order to ensure that they are actually achieved.
To do this, you must:
● define the expected benefits from the programme;

● analyse the balance between costs and benefits;

● plan how the benefits will be achieved and measured;

● allocate responsibilities for the successful delivery of the benefits;

● monitor the realization of the benefits.

Benefits can be of many different types, including;

● Mandatory compliance Governmental or European legislation might make certain changes mandatory.

● Quality of service An insurance company, for example, might want to settle claims by customers more
quickly.
● Productivity The same, or even more, work can be done at less cost in staff time.
● More motivated work force This might be because of an improved rewards system, or through job
enlargement or job enrichment.
● Internal management benefits (for instance, better decision making) To take an Job enlargement and
insurance example again, better analysis of insurance claims could pinpoint those enrichment will be dis-
cussed in Chapter 11.
categories of business which are most risky and allow an insurance company to
adjust premiums to cover this.
● Risk reduction The insurance example might also be applicable here, but measures to protect an organi-
zation’s networks and databases from intrusion and external malicious attack would be even more
pertinent.
44 So ware Project Management

● Economy The reduction of costs, other than those related to staff – procurement policies might be put
in place which encourage the consolidation of purchasing in order to take advantage of bulk-buying at
discount.
● Revenue enhancement/acceleration The sooner bills reach customers, the sooner they can pay them.
● Strategic fit A change might not directly benefit a particular group within the organization but has to be
made in order to obtain some strategic advantage for the organization as a whole.
A change could have more than one of these types of benefit. In fact, benefits are often inter-linked. An
example of this is an insurance company which introduced a facility whereby when settling claims for
damage to property, they directly arranged for contractors to carry out the remedial work. This improved
quality of service for customers as it saved them the trouble of locating a reputable contractor, reduced costs
to the insurance company because they could take advantage of the bulk purchase of services, and improved
staff morale because of the goodwill generated between the insurance company’s front-line staff and the
customer.

Quantifying benefits
We have already seen that benefits can be:
● quantified and valued – that is, a direct financial benefit is experienced;

● quantified but not valued – for example, a decrease in the number of customer complaints;

● identified but not easily quantified – for example, public approval of the organization in the locality

where it is based.
A particular activity might also have disbenefits. For example, increased sales might mean that more money
has to be spent on expensive overtime working.
There can be controversy over a whether a business change will lead to the particular benefits claimed for it,
for example that a new company logo will improve staff morale. Some key tests have been suggested in order
to sound out whether a putative benefit is likely to be genuine:
● Can you explain in precise terms why this benefit should result from this business change?
● Can you identify the ways in which we will be able to see the consequences of this benefit?
● If the required outcomes do occur, can they be attributed directly to the change, or could other factors
explain them?
● Is there any way in which the benefits can be measured?
We mentioned earlier the need for benefit profiles that estimate when and how benefits will be experienced.
Specific staff have to be allocated responsibility for ensuring that the planned benefits actually materialize.
These will often be business change managers.
Benefits cannot normally be monitored in a purely project environment because the project will almost
certainly have been officially closed before the benefits start to filter through.
In our view, benefits management brings to the fore the powerful idea that developers and users are jointly
responsible for ensuring the delivery of the benefits of projects.
 Project Evaluation and Programme Management 45

CONCLUSION

Some of the key points in this chapter are:

● Projects must be evaluated on strategic, technical and economic grounds.

● Many projects are not justifiable on their own, but are as part of a broader programme of projects that

implement an organization’s strategy.

● Not all benefits can be precisely quantified in financial values.

● Economic assessment involves the identification of all costs and income over the lifetime of the system,

including its development and operation and checking that the total value of benefits exceeds total
expenditure.
● Money received in the future is worth less than the same amount of money in hand now, which may be

invested to earn interest.

● The uncertainty surrounding estimates of future returns lowers their real value measured now.

● Discounted cash flow techniques may be used to evaluate the present value of future cash flows taking

account of interest rates and uncertainty.

● Cost–benefit analysis techniques and decision trees provide tools for evaluating expected outcomes and

choosing between alternative strategies.

FURTHER EXERCISES

1. Identify the major risks that could affect the success of the Brightmouth College payroll project and try
to rank them in order of importance.
2. Explain why discounted cash flow techniques provide better criteria for project selection than net profit
or return on investment.
3. An insurance company has examined the way that it settles house insurance claims. It decides to
introduce a new computer-based claims settlement system which will reduce the time taken to settle
claims. This reduction in effort is partly achieved by enabling the claims clerk to obtain the infor-
mation needed directly, rather than having to go through other departments. Also, as part of the new
process, new repair work will be allocated by the insurance company to authorized builders, decorators,
plumbers etc., rather than the claimant having to make arrangements to get estimates, and so on.
(a) Explain the possible benefits and disbenefits that might be generated by this application. Note
that the benefits could come under the following headings:
Mandatory compliance
Quality of service
Productivity
More motivated work force
Internal management benefits
Risk reduction
Economy
Revenue enhancement/acceleration
Strategic fit
How could the actual benefit be assessed in each case?
46 So ware Project Management

(b) When the application is implemented, some of the claims staff at the insurance company
complain about the additional stress of dealing with irate customers grumbling about trades-
people being slow to do repair work or about poor quality workmanship. Also, in some places
there are shortages of qualified repair people leading to delays in getting work done.
Which projected benefits are being affected by these developments?
How would you deal with these problems?
How would you assess your success in dealing with these problems?
4. Suppose Brightmouth College has the option of either buying payroll software off-the-shelf at £50,000
or employing a programmer for six months at a salary of £5000 to develop the software. Perform cost-
benefit analysis for the two options. You can make suitable assumptions regarding any factor that has
not been mentioned in this problem statement.