CHAPTER

P ro iect
evaluation and
programme
management

N. ourcrruEs
When you have completed this chapter S use a variety of cost-benefit
you will be able to: evaluation techn iques for choosing
among competi ng project proposals;
$ describe the contents of a typical
business plan; * evaluate the business risk involved
in a project;
* explain project portfolio
managemenu ù explain how individual projects can
be grouped into programmes;
rt cârry out an evaluation and
selection of projects against * explain how the implementation of
programmes and projects can be
strategic, technical and economic
criteria; managed so that the planned
benefits are achieved.

-l-hu first that many developers hear of an ICT project is when they are allocated to the
I 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. ln 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.

21
tl Ghapter2 Proiect evaluation and programme management

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.
It might not be possible to measure the benefits of a project in financial terms. lf you
create a iystem which allows the more accurate recording of data concerning the medical
conditíon of patients, it might contribute to the alleviation of pain and the preservatìon 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.
ln 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 managemenf. 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'

rganizations may have different titles such as a feasibility

study or a project justification for what we call the business
case. lts objective is to provide a rationale for the project by
showing that the benefits of the project outcomes will exceed
the costs of development, implementatíon and operation (or
production).
Typically a busíness case document might contain:

1 lntroduction and background to the proposal

2 The proposed project
3 The market
4 Organizational and operational infrastructure
5 The benefits
6 Outline implementation Plan
./ LOSTS

B The financial case

9 Risks

10 Management plan
These sections will be now be described in more detail

lntroduction and background

This ís a description of the current envíronment of the proposed project, A problem to be
solved or an opportunity to be exploited is identified.
 2.2 A business case 23

The proposed proiect

A brief outline of the proposed project is provided

The market
This is needed when the project is to create new product or a new service
capability. This would contain information like the estimated demand for
the product or service and any likely competitors.

Organizational and operat¡onal 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. lt 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.
ln an example we used earlier relating to an lT system that improved the diagnosis of a
particular disease, an increase in the rate of diagnosis might be quoted,

0utline implementation plan

ln 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 wilI see, for a large implementation a number of projects may be needed
which can be managed as a programme.

Gosts
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.
24 Chapter 2 Project evaluation and programme management

The financial case

There are a number of ways in which the inforrnation 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 risl< should take account of this. ln the last
chapter we distinguished betweerr project and business objectives. We can similarly
distirrguislr project risk * relating to threats to successful project execution - from business
risk -_ relating to factors threatening the benefits of the delivered project. ln the business
case the main focus is on business risk.

2.3 Project portfolio management

portfolio prof ect management provides an overview of all the projects
Ouite a good
introduction to the
I that an organization is undertaking or ís considering. lt prioritizes the
concepts of allocation of resources to projects and decides which new projects should
portfolios can be be accepted and which existing ones should be dropped.
found in B. De Reyck The concerns of pro.iect portfolio management incude:
et al. The ímpact of
project portfolio r identifying which project proposals are worth implementation;
management on r assessin¡1 the amount of risk of failure that a potential project has;
information
technology projects'
r deciding how to share limited resources, including staff time ancl
(2005l' lnternational finance, between projects - or-re problem can be that too many projects
Journal of Project are started given the resources available so that inevitably some projects
Managenent will miss planned completion dates;
23524-37.
r being aware of the depenclencíes between projects, especially where
several projects neecJ to be completed for an organization to reap
benefits;
r ensuring that projects do not duplicate work;
r ensuring that necessary developments have not been inadvertently been missed.
The three key aspects of project portfolio managementare portfolio definitiort, portfolio
management and portfolio optimization. An organization would undertake portfolio
definition before adopting portfolio management and then proceeding to optimization.

Projeet portfolio definition

An organization should record in a single repository details of all current projects.
A decision will be needed about whether projects of all types are to be inclr¡ded. Should
 2.3 Project portfolio manaqement 25

just ICT projects be included in the repository, or should other proiects

-{tdii:;;#;ì;-
Warren McFarlan,s
such as the setting up of a new warehouse also be included? Orre problem
appioachto for many organizations is that projects can be divided into new product
information systems' developmen¿s (NPD) where the project deliverable is a product, such as
Haruard Business a computer game, that is sold to customers, and renewal projects which
ReviewS\(5| 142-50 improve the way an organization operates
íntroducedthe
-
informatiorr systems projects
are often like this. The distinction is not always clear-cut. For example,
,f,t-!-:l^:""it:ltl
vvv¡v'¡re'
rnformatr0n svstems.
a new information system coulcl 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 m;ry be less
frequent and thus inherently more risky as there is less experience of these types of
project. NPD projects find attracting furrding easier with their clear relationship
between the project and inconre. Where both types of project call upon the same
pools of resources, including finance, the argument for a common portfolio is strong.

Project portfolio management

Once the portfolio has been established, more detailed costings of projects can be
recorded. l-he 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.

Proiect 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 achievecl. Some projects could potentially be
very profitable but could also be risky. lrr the case of an e-commerce site, for example,
sales may not be as great as hoped because established competitors 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 thoughGout balance between
the two types of project.

Some problems with project portfolio management

An important role of project portfolio management is sharing resources
lnteresting insights
between projects. l-here can be problems because while apparently
into the practical fL¡ll-time staff are allocated to a project, they may effectively be part-time
problems of because they still have routine work to do. This is particularly so with
portfolios can users, and with developers who may on occasion be callecl away from
be found in project work to deal with support tasks.
B. S. Blichfeldt and The official project portfolio may not accurately reflect orgarrizational
P. Eskerod (2008)
'Project portfolio
activity if some projects are excludecJ. A formal decisiorr mary be made that
only projects over a certairr level of cost will be recorded in the portfolio.
26 Chapter 2 Project evaluation and programme management

. I he 'below the lirre'projects could in fact consume sul¡stantial staff effort

.1119^s:T:t:.
tnere s more ro rr
anc] bleed away effort from the official projects. lt can be argued that all
portfolio.
türî,urrìãr.rì projects should be included in the official
enacts, However, there are advantages in allowing tlrese tasks. lt allows
lnternational small ad hoc tasks to tre done, such as qurick fixes to systems to deal with
Journal af Project externally imposed changes. They reduce work for higher management by
Management saving them from having to process a large number of small worl< requests'
26357-65' Devetpers may firrd these small tasks rewarding: dealing with these
small requests is an easy way to keep r-rsers 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 pro¡ects

W e will now
evaluated.
lool< more closely at how the feasibility of an individual project can be

Technical assessment
Tech¡ical 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 tal<en into
account in the cost-benefit analysis.

Gost-benefit analysis
Even where the estimated benefits will exceed the estimated costs, it is
Any project aiming
often necessary to decide if the proposed project is the best of several
at a return on
investment must, as
options. Not all projects can be undertaken at any one time and, in any
a minimum, provide case, the most valuable projects should get most resources.
a greater benefit Cost-benefit analysis comprises two steps:
than putt¡ng that
investment in, say, t costs and benefits of carrying out the proiect and
lclentifying all of the
a bank. operating the clelivered application 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 ir-l
sales due to the use of the new system.
Expressit'rg, these costs and benefits in common unifs We must express each cost and
benefit - ancl the net benefitwhich is the difference between the two - itr money.

Most clirect costs are easy to quantify in monetary terms and can be categorized as:
 2.4 Evaluation of individual projects 27

The different types of

t development costs, including development staff costs;
benefits will be . setup cos¿s, consisting of the costs of putting the system into place,
discussed ín greater mairrly of any new hardware but also including the costs of file
detail in the context 0f conversion, recruitment and staff training;
benefits management
later in this chapter.
t operational costs relating to operating the system after installation.

TXERCISE 2.1

f) rightrnouth College is considering the replacenrent of the existing payroll setvice,

I-Doperated by a third party, with a tailorecl, off-the-shelf cornputer-based system. List
some of the costs it might consider under the headings of:

r Development costs
r Setup costs
r Operational costs
List some of the benefits u¡rder the headings:
r Quantified and valued benefits
r Quantified but not vaÌuecl
r Identified but not easily valued
For each cost or benefit, explain how, in principle, it might be measured in monetary terms.

Typically products
generate a negative
cash flow during their
Gash flow forecasting
development followed by
a positive cash flow over As important as estimating the overall costs and benefits ol a project is
their operating l¡fe. producing a cash flow forecast which indicates when expenditure ancl
There might be income will tal<e place (Figure 2.1).
decommissioning
We need to spend money, such as staff wages, durir-rg a project's
costs at the end of a
product's life. development. Such expenditure cannot wait until income is received
(eitlrer from using software developecl in-house use or from selling it).
'The difficulty and We need to know that we can fund this developnrent expencliture either
importance of cash flow from the company's own resources or by borrowing. A forecast is
forecasting is evidenced needed of when expenditure, such as the payment of salaries, and any
by the number of income are to be expected.
companies that suffer Accurate cash flow forecasting is difficult, as it is done early in
bankruptcy because, the project's life cycle (at least before any sigr-rificant expencliture is
although they are
committed) and many items to be estimatecl (particularly the benefits
developing profitable
of usirrg software) might be some years in the fr-rture.
28 Chapter 2 Project evaluation and programme management

4)
E
o
c

OJ

l
Time ---|
.t
c
o
0.,

x
UJ

FIGURE2.l Typical product life cycle cash flow

When estinrating futr-rre cash flows, it is usual to ignore the effects

products or services,
they cannot sustain an
of inflation. Forecasts of inflation rates tencl to be uncertain. Moreover,
unplanned negative if experrditr-rre is increased dr"re to inflation it is lilcely that income will
cash flow. i ncrease proportionately.

2.5 Gost-benefit evaluat¡on techniques

at some methods for conrparins projects on the basis of their cash
W;trî.::::r1J:.-
Table 2.1 illustrates cash flow forecasts for for-¡r projects. ln 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.

EXERCISE 2.2

¡-ìonsider the project cash flow estirnates f'or fbur projects at IOE shown in Table 2.1.
L-rNegative values represent expencliture and positive values income.
Rank the fbur projects in orcler of firrarrcial desirability and make a lote of your reasons
f'or ranking therrr in that way befbre reading firrther.

Net profit
Tlre 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 lable 2.1 shows the ¡4reatest net prof¡t but this is at
the expense of a large investment. lndeed, il we had f 1m to invest, we might undertake all
of the other three projects and obtain an even greater net ¡rrofit. Note also that all projects
corrtain an element of risk arrd we might not be preparecl to risk f 1m. We shall look at the
effects of risk ¿lnd investment later irr this chapter.
 2.5 Cost-benefit evaluation techniques 29

Year Proiect 1 Proiect 2 Project 3 Proiecl 4

0 -100,000 -1,000,000 -r00,000 -r 20,000

1 r 0,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 r00,000 300,000 30.000 75,000

Net profit 50,000 1 00,000 50,000 75,000

TABTE 2.1 Four project cash flow projections - figures are end of year totals (f)

Moreover, the simple net profit takes no account of the timin¡¡ of

Cash flows take
the cash flows. Projects 1 and 3 each have a net profìt of f50,000 and
place at the end of therefore, according to this selection criterion, would be equally preferable.
each year. The year The bulk of the income occurs late in the life of project '1, whereas project 3
0 represents the retlrrns a steady income throughout its life. Having to wait for a return
initiâl investment has the disadvantage that the investment must be funded for longer. Add
made at the start of
to that the fact that, other things being equal, estimates in the more distant
the pro¡ect.
future are less reliable than short-term estimates and we can see that the
two projects are not equally preferable.

Payback per¡od
The payback period is the time taken to break even or pay back the initial irrvestment.
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'.

TXERCIST 2.3

onsider the four project cash flows given in Table 2.1 and calculate the payback period
C lbr each of them.

The advanta¡;e of the payback period is that it is simple to calculate and is not
particularly sensitive to small forecastin¡¡ 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 brol<en even, Thus the fact that projects 2 and 4 are,
overall, more profitable than project 3 is ignored.
30 Chapter 2 Proiect evaluation and programme management

Return on ¡nvestment
fhe return on investment (ROl), also known as the acco¿tnting rate of return (ARR),
provides a way of comparing the net profitatrility to the investment required. There
are some variations on the formula used to calculate the return on investment but a
straightforward common version is:

OO, _ average annual profit *,OO

total investment

EXERCISE 2.4

¡rìalculating the ROI for project1, the net profit is f50,000 and the total investment is
L-¡¿ioo.oo0. The return on investment is th.erefore calculated as
avt¡rag,e annual Profit ,
on, - roo
total investntent

- 5o'ooo/5 x 1oo = 1o%

100,000
Calculate the ROI for each of the other projects shown in Table 2.1, ancl decide which, on
the basis of this criterion, is the most worthwhile'

l-he return on investment provides a simple, easy-to-calculate measure of return on

capital. Unfortunately, it sLrffers from two severe disadvar-rtages. Like the net profitab¡l¡ty, it
tal<es no accout"ìt 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 tlre
conrpounding of irrterest. lt is therefore, potentially, very misleading'

Net present value

Tlre calculation of net present valtte is a project evaluation technique that
Net present value
takes into accour'ìt the profitability of a project and the timing of the cash
(NPVI and internal
rate of return (lRR)
flows that are producecl. This is based on the view that receivirrg f 100
are collectively today is better than havin¡; to wait until next year to receive it. We could,
known as for example, invest the f'100 in a bank today ancl have f100 plus the
discounted cash interest in a year's time. lf we say that the present value o{ f 100 in a
flow (DCFI year's tinre is L91 , we me¿ìn that f 100 irr a year's time is the equivalent
techniques. of f9'l now.
The equivalence of [9'l now and f 100 in a year's tirne means we
Note that this are discounting tlre future income by approximately 10"/". lf we received
example uses f91 now and investecl it for a year at an annual interest rate of 1Ou/", il
approximate figures.
would t¡e worth f 100 in a year's time. The annual rate by whiclr we
 2.5 Cost-benefit evaluation techniques 3l

discount future earnings is known as the drscount rate - 1O% in the above
example.
Similarly, f100 received in two years'time would have a present value
of approximately fB3 - in other words, f 83 invested at an interest rate of
10% would yield approximately f 100 in two years'time.
The present value of any future cash flow may be obtained by applying the following
formula
value in year t
Present value =
('l + r)t

where r is the discount rate, expressed as a decimal value, and f 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 calculated by multiplying the cash flow by the appropriate
discount factor. A small table of discount factors is given in Table 2.2.
The NPV for a project is obtained by discounting each cash flow (both
negative and positive) and summing the discounted values. lt is normally
assumed that any initial investment takes place immediately (indicated as
year 0) and is not discounted. Later cash flows are normally assumed to
take place at the end of each year and are discounted by the appropriate
amount.

Discount rate (%)

Year 5 6 I r0 l2 r5
1 0.9524 0.9434 0.9259 0.909r 0.8929 0.8696

2 0.9070 0.8900 0.8573 0.8204 0.7972 0.756r

3 0.8638 0.8396 0.7938 0.7513 0.71r8 0.6575

4 0.8221 0.7921 0.7350 0.6830 0.6355 0.57t8

5 0.7835 0.7473 0.6806 0.6209 0.5674 0.4972

ô 0.7462 0.7050 0.6302 0.5645 0.5066 0.4Í123

7 0.7107 0.6651 0.5835 0.5132 0.4523 0.3759

I 0.6768 0.6274 0.5403 0.4605 0.4039 0.3269

I 0.0446 0.5919 0.5002 0.4241 0.3806 0.284Íì

10 0.6r39 0.5584 0.4632 0.3855 0.3u0 0.2472

l5 0.4810 0.4173 0.3152 0.2394 0.1821 0.r229

20 0.3769 0.3r18 0.2145 0.r486 0.1037 0.06r1

25 0.2953 0.2330 0.1460 0.0923 0.0588 0.0304

TABTE 2.2 NPV discount factors

32 Chapter2 Proiectevaluation and programme management

EXERCISE 2.5,

/\ ssuming a 1.Oo/o discount rate, the NPV for project 1 (Table 2.1) would be calculated as
fl,in Table 2.3. The net present value for project 1, using a 7Oo/" discount rate, is
therefore f,618. Using a 1,Oo/o 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.

Year Proiect I cash flow (f) Discount factor @ l0% Discounted cash flow {Ê}

0 -r00,000 r.0000 -100,000

1 10,000 0.9091 9,0sr

2 r0,000 0.8264 8,264

3 r0,000 0.7513 7.513

4 20,000 0.6830 13,660

5 100,000 0.6209 62,090

Net Profit f50,000 NPV: f618

TABLE 2.3 Applyìno the discotlnt factors to project 1

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, w¡th 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, ¡t ¡s 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

l-alculate the net present value for each of the projects A, B and C shown in Table 2.4
L:using each of the discount rates 8o/o,1\o/o and 72o/o'
For each of the discount rates, decide which is the best project. What can you conclude
from these results?
 2.5 Cost-benefit evaluation techniques 33

Yea¡ Pruiect A {f) Prciect B (f) P¡oiect C (fl

0 -8,000 -8,000 -10,000
I 4,000 1,000 2,000

2 4,000 2,000 2,000

3 2,000 4.000 6,000

4 1.000 3,000 2.000

5 500 9,000 2,000

6 500 -ô,000 2,000

N et Profit 4,000 5,000 6.000

TABLE 2.4 Ïhree estimated project cash flows

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

lnternal 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 ¡nterest rate.
The internal rate of return (lRR) 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
1Oo/" 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.lt is most easily calculated using a spreadsheet or other computer program that
provides functions for calculating the lRR. 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 lRR.
One deficiency of the IRR is that it does not indicate the absolute size of the return.
A project with an NPV of f 100,000 and an IRR of 15olo can be more attractive than one
with an NPV of f 10,000 and an IRR of 1B% - 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 valr"¡e and ignore the others.
NPV and IRR are not, however, a complete answer to economic project evaluation.
34 Chaptet 2 Project evaluation and programme management

r A total evaluatiorl must also tal<e irrto 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?
r 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, irrvesting
with a banl<. We might r-rndertake a more detailed risl< analysis as described below.
r We must also consider any one project within the financial and econotric framework
of the organization as a whole - if we fund this one, will we also be able to fund other
worthy projects?

2.6 Risk evaluat¡on

very project involves risk. We have already noted that proiect risks, which prevent the
E project from being completed successfully, are different from the business risl< that the
deliverecl products are not profitable. Project risl<s will be discussed in Chapter 7' Here
we focus on business risk.

Risk identification and ranking

ln any project evaluation we should identify the risks and quantify their effects. One
approach is to construct a project risl< matrix utilizirrg a checklist of possible risks and
classifying risl<s according to their relative importatrce and lil<elihood. lmportance and
likelihood need to be separately assessecl - we might be less concerned with something
that, althor-rgh 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 lil<elihood classified as high (l-l), medium (M),
low (L)or exceedingly unlil<ely (-). So that projects may be comparecl, the list of risks
must be the same for each project assessed. lt ¡s lll(ely, in reality, that it would be lorrger
than shown and more precise.
The project risk matrix nray be used as a way of evaluating projects (those with hiSh
risks being less favoured) or as a means of identifying and ranl<ing the risl<s for a specific
project.

Risk lmportance [ikelihood

Cl¡ent reiects proposed look and feel of site H

Competitors undercut prices H M

Warehouse unable to deal with increased demand M L

0nline payment has security problems M M

Maintenance costs higher than estimated L L

Response times deter Purchasers M M

TABLE 2.b A fragment of a basic proiecvbusiness risk matrix for an e-commerce applicat¡on
 2.6 Risk evaluâtion 35

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 5o/o for a fairly risky one. Projects may be categorized as
high, medium or low risk using a scoring method and risk premiums designated for each
category. The premiums, even if arbitrary, províde 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 probability 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.7 illustrates how this may be done.

EXERCIS[ 2.7

p uyRight, a software house, is considering developing a payroll application for use in

I) academic irrstitutions 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
f,800,000. It estimates that there is a 1 in 10 chance of this happening, However, a com-
petitor 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 f650,000. BuyRight has therefore calculated its
expected sales income as in Table 2.6,

Sales Annual sales Probability Expected

income El value (fl
i p ixp
High 800,000 0.r 80,000

Medium 650,000 0.6 390,000

Low 1 00,000 0.3 30,000

Expected lncome 500,000

TABTE 2.6 BuyRight's ìnconre forecasts

36 Chapter2 Projectevaluat¡on and programme management

Development costs are estimated at f750,000. Sales levels are expected to be constant
f'or at least four years. Annual costs of marketing and product maintenance are estimated
at f200,000, irrespective of the rnarket sÌrare. 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 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 analys¡s

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 sensìtivity 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. lf neither is the case,
then we must live with the risk or abandon the project.

Using decision trees

The approaches to risk analysis discussecl 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
 2.6 Risk evaluat¡on 37

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
scherjuled.
It is calculated that extending the existing system will have an NPV of f75,OOO,
although if the market expands significantly, this will be turned into a loss with an NPV
of -f 100,000 due to lost revenue. lf the market does expand, replacing the system now
has an NPV of f 250,000 due to the benefits of being able to handle increased sales
and other benefits such as improved management information. lf sales do not increase,
however, the benefits will be severely reduced and the project will suffer a loss with an
NPV of -f 50,000.
The company estimate the likelihood of the market increasing significantly at 2Oo/o
- and, hence, the probability that it will not increase as B0%. 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 f40,000
(75,000 x 0.8 - 100,000 x 0.2) and the expected value of replacing the system f 10,000
(250,000 x 0.2 - 50,000 x 0.8). The company should therefore choose the option of
extending the existing system.

NPV (T)

- 100,000
Expansion
0.2

0.8

E No ex
75,000

250,000
Expansion
Replace
0.2

0,8

No expansion
- 50,000

FIGURE 2.2 A decision tree

38 Chapter 2 Project evaluation and programme management

2,1 Ptogtamme management

will be an element of
I t shoulcl now have been made clear that there
project. where projects procluce real financial
#ï;iilï,
"',.r;;ä;;;i
lrisl< wirh any single Everr
benefits, rhe precise size of those benefits will often be uncertain at the start
nìuìititoi:lriitu of the project. This makes it important for organizations to take a broad
Management view of all its projects to ensure that while some projects may disappoint,
August 1991. organizational clevelopments 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 berrefits. D. C. Ferrrs defined a
progriìmme as'a g¡ottp of projects that are managed in a coordinated wtty to g,ain ber¡efits
that wc¡ulcl not be possible were the projects to be manag,ed independently'.
Programmes can exist in different fornrs, 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 buclget for ICT clevelopment. Decisions have to be made
about which projects to implement within that budget within the accounting period,
which often coincides with the financial year.

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

I nf rastructu re prog rammes

Organizations can have various departments which carry out distinct, relatively self-
co¡tained, activities. ln a local authority, one department might have responsibilities for
the maintenance of highways, another for refuse collection, and another for education.
These flistinct activities will probably rec¡uire distinct cJatabases ancl information systems.
ln such a situation, the central lCl'function woulcl h;tve resporrsibility for setting up and
maintaining the ICT infrastructure, irrclr-rcling the networl<s, workstations and servers Llpon
whiclr these distinct applications run. ln these circumstances, a infrastructure programme
coulcl refer to tlre activities of identifying a commorr lC'I infrastructure and its
implementation and maitrtenance

Research and development programmes

Truly innovative companies, especially those that are trying to develop new products for
the marl<et, are well aware that projects will vary in terms of their risl< of failr'rre and the
 2.8 Managing the allocat¡on of resources with¡n programmes 39

potent¡al 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 existirrg ones on the market. Other projects rnight be extremely
risky, but the end result, if successful, could be a revolutionary
Alan Webb (20011 technological breal<through that meets some pressing but previously
'When project unsatisfied need.
managementdoesnt A successful portfolio would need to be a mixture of ,safe projects,
work' Project with relatively low returns and some riskier projects that might fail, but if
-';;';ri';;::;.'
Management
senerate handsome profits which will offset the losses on
ffiïiilJould
lnnovative partnerships
Companies sometimes come together to worl< collaboratively on new technologies
in a 'pre-competitive'phase. Separate projects in different organizations need to be
coordinated and this miglrt be done as a programme.

2.8 Managing the allocation of resources within programmes

\ Â /u are now going to examine in more detail programmes where resources have to
VV be shared between concurrent projects. Typically, an ICT department has pools of
particular types of expertise, such as software developers, database designers and networl<
support staff, and these might be called upon to participate in a numl¡er of concurrent
projects.
ln these circumstances, programme managers will have concerns about
The comoarison is the optimal use of specialist staff. l-hese concerns can be contrasted with
based on G. Reiss those of project managers - see Table 2.7.
11gg6l Programne The project managers are said to have an 'impersonal relationship'with
Management resource types because, essentially, they require, for example, a competent
Denystified, systems arralyst and who fills that role does not matter. -fhe programme
Chapman & Hall' manager has a number of individual systems arralysts 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 rnight have to be delayed

Programme manager Project manager

Many simultaneous projects One project at a time

Personal relationship w¡th skilled resources lmpersonal relationship wlth resource type
Need to maximize utilization of resources Need to minimize demand for resources

Projects tend to be similar Projects tend to be dissimilar

TABTE 2.7 Programme managers versus project managsrs

40 Ghapter 2 Project evaluation and programme management

until the requisite technical staff are freed from work on other projects. Where expensive
technical staff are employed fr-rll-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. lt is most economic when the clemand for work is everrly spread from
month to month.
As will be seen in Chapter 9 on monitorirrg 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
ancl the use of resources.

2.9 Strateg¡c programme management

I clifferent form of programme management is where a portfol¡o of projects all

f\contribute to a common objective. Tal<e, for example, a business which carries
out mainterrance work for clients. A custonrer's experience of the organization might be
found to tre 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
agairr from the clerk who cleals 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 miglrt require changes to a number of different systems which until
now have been largely self-containe<J. The work to reorganize each
indiviclual area could be treated as a separate proiect, coordinated at a
Recall that'GCis higher
""il#ffi;'" levelas a programme.
by large organizations
Government These types of programme are most ofterr neededstructure. Covernment
CoÃrãr."*¡,i.f, which have a large and complicated organizational
wasformerly departments are typical examples and it is not surprising that the OCC, the
the Central United Kingdom government agency which was responsible (as the CCTA)
Computing and for the introduction of PRINCE2 project management standards, has
Telecommunications clirected its attention to guidelines for effective programme management.
AgencyorCCTA'
rhe approach rrow describecl is based on the oCC guidelines.

2.10 Greating a programme

The programme mandate

The OCC envisages that the plarrning of a programme will be triggered by the creation of
an agreed programme mandate. ldeally this slrould be a formal document describing:

r the new services or capabilities the programme should deliver;

r how tlre organization will be improved by use of the new services or capability;
r how the programme fits with corporate goals and any other irritiatives.
 2.10 Creating a programme 41

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 progamme brief

A programme brief is now produced which outlines the business case for the programme,
It will have sections setting out:

r a preliminary vísion statementwhich describes the new capacity that the organization
seeks - it is described as 'preliminary'because this will later be elaborated;
r the benefits that the programme should create - including when they are likely to be
generated and how they might be measured;
r risks and issues;
r 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. lt should describe in detail the new capability that the programme will give the
organization. lf 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 ol
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:
r business models outlining the new processes required;
r organizational structure - including the numbers of staff required in the new systems
and the skills they will need;
r the information systems, equipment and other, non-staff, resources that will be needed'
r data and information requirements;
r 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
42 Chapter2 Project evaluation and programme management

way that it is to be achieved would have to be stated in the blueprint' This might, for
example, suggest:
r the appointment of 'account managers'who could act as a point of contact for the
client throughout their business transact¡ons with the company;
r 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 supportedby benefit profiles which estimate when the expected
benefits will be experienced 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 informatíon 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
program me sponsors
A major risk is that some of those whose work will be affected by
the programme wíll not be drawn into the programme effective lv.A
stakeholder map identifying the Sroups 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 proSramme planning stage, a preliminary plan
can be produced containing:

r the project portfolio;

r cost estimates for each Projec!
r the benefits expected (including the appropriate benefits profile);
¡ risks identified;
I the resources needed to manage, support and monitor the programme.
 2.1I Aids to programme management 43

This information allows a financial plan to be created. This enables higher management
to put ¡n 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.

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/desìgn A project is carried out which examines the various existing
lT applications in the two old organizations, analyses their functionality, and makes
recommendations about how they are to be combined.
B Corporate image design lndependently of Project A, this project is
designíng the corporate image for the new organization. This would
include design of the new logo to be put on company documents.
C Build common systems Once Project A has been completed, work can
be triggered on the construction of the new common ICT applications.

B Corporate G lmplement
image design corporate
interface

A System C Build F Data

study/design common migration
systems

D Relocate E Training
offices

F|GURE2.3 An example of a dependency diagram

44 Chapter2 Projectevaluat¡on and programme management

D Re/ocate offices This is the project that plans and carries out the physical co-location
of the staff in the two former organizations. ln 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 neq joint, applications have been developed and staff have
been trained in their use, data can be migrated from existing databases to the new
consol idated database.
C tmplement 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 deperrdency diagram would typically lead to the definition of
tranches of projects. A tranche 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.

Tranche 1 Tranche 2 Tranche 3

Project A
Project B

Project C

Project D

Project E

Project F

Project G

Benefìt Benefìt Benefit

delivery delivery delivery

FIGURE2.4 Delivering tranches of projectdeliverables

 2.13 Benefits management 45

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 managêment

Qome writers on project management have expressed reservations about the way
Jthey see the ideas of programme management being presentecl. lt is argued that
approaches lil<e 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 their execution. lf the super-project idea predominates then too much
planning at the beginning plus a reluctance 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 [re:

r programme management is notsimply a scaled-up project managemenu

r clifferent forms of programme management may be appropriate for different types of
project.

2.13 Benefits management

have already noted that providing a capability does not guarantee

\ Â /"
VV that the capability will be used to cleliver the planned benefits.
Thomas K. Landauer
Businesses have t¡ecome aware of the lack of evidence of some
(1995) I/re Trouble
with Conputers:
investments in ICT increasing the productivity of organizations. Even
Usefulness, with business process re-eng,ineering (BPR), the radical reorganization
Usability and of businesses to deliver improvements in efficiency and effectiveness,
Productivity,MlT there are many reported cases where the expected benefits have not
Press, explores the materialized.
issues of the Benefits management is an attempt to remedy this. lt errcompasses the
'productivity
identification, optimization and trackirrg of the expected benefits from a
paradox'in lT.
business change in orcler to ensure that they are actually achieved.
46 Ghapter 2 Proiect evaluation and programme management

To do this, you must:

r define the expected benefits from the programme;

r analyse the balance between costs and benefits;
r plan how the benefits will be achieved and measured;

r allocate responsibilities for the successful delivery of the benefits;

r monitor the realization of the benefits.

Benefits can be of many different types, including;

t Mandatory compliance Covernmental or European legislation might make certain

changes mandatory.
t Quatity of service An insurance company, for example, might want to settle claims by
customers more quicklY.
t Productivity The same/ or even more/ work can be done at less cost in staff time.
t More motivated workforce This might be because of an improved
rewards system, or through job enlargement or job enrichment.
t lnternal management benefits (for instance, better decision making)
To take an insurance example again, better analysis of insurance
claims could pinpoint those categories of business which are
most risky and allow an insurance company to adjust premiums to
cover this.
r Risk reduction The insurance example might also be applicable here, but measures to
protect an organization's networks and databases from intrusion and external malicious
attack would be even more pertinent'
t 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.
t Revenue enhancement/acceleration The sooner bills reach customers, the sooner they
can pay them.
t Strategic a particular group withirr the
/it A change might not directly benefit
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. ln 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.
 2.14 Conclusion 4l

0uantifying benefits
We have already seen that benefits can be:
r quantified and valued - that is, a direct financial benefit is experienced;
r 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:
r Can you explain in precise terms why this benefit should result from this business
change?
r Can you identify the ways in which we will be able to see the consequences of this
benefit?
r lf the required outcomes do occur, can they be attributed dírectly to the change, or
could other factors explain them?
r ls there any way in which the benefits can be measured?
We mentioned earlier the need for benefit profiles that estimate when and how benefits
wíll 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.
ln 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.

Some of the key points in this chapter are:

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

r Many projects are not justifiable on their own, but are as part of a broader programme
of projects that implement an organization's strategy.
r Not all benefits can be precisely quantified in financial values.
r 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.
48 Chaptor2 Projectevaluation and programme management

r Money received in the future is worth less than the same amount of money in hand
noq which may be invested to earn interest'
r 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.
I Cost-benefit analysis techniques and decision trees provide tools for evaluating
expected outcomes and choosing between alternative strategies.

1 ldentily 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 díscounted 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 information 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 8et 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 workforce
lnternal management benefits
Risk reduction
Economy
Revenue en hancemenVacceleratíon
Strategic fit
How could the actual benefit be assessed in each case?
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 tradespeople 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 dealwith these problems?
How would you assess your success in dealing with these problems?