CHAPTER

lntroduction
to software
pro¡ect
management

.þ 0wrcrtvEs
When you have completed this chapter ô explain the maÍn elements of the
you will be able to: role of management;
ô define the scope of 'software project ô appreciate the need for careful
management';
planning, monitoríng and control;
s understand some problems and + identify the stakeholders of a project
concerns of software project and their objectives;
mana8ers; s define the success criteria for a
* define the usual stages of a software project.
project;

-fhis textbook is about 'softvvare project management'. The first question is whether
I the management of software projects is really that different from that of other
projects. To answer this, we need to look at some key ideas about the planning,
monitoring and control of software projects. We will see that all projects are about
meeting objectives. Like any other project, a software project must satisfy real needs.
To do this we must identify the project's stakeholders and their objectives. Ensuring that
their objectives are met is the aim of project management. However, we cannot know
that a project will meet its objectives in the future unless we know the present state of
the project.

1
 2 Chapter 1 lntroduction to software proiect management

1.2 Why is software pro¡ect management important?

-T-his book is for students of software engineering and computer science and also those
I stuclying business information systems. More tàchnically orientecl students can be
impatierrt at having to study something which keeps them away from
their code. So why is it important to become familiar with pro.iect
The information in management?
this paragraph First, there is the question of money. A lot of money is at stake with
comesfrom a ICT projects. ln the United Kingdom during the financial year 2OO2*2O03,
Natíonal Audit Offíce the central government spent more ot-ì contracts for ICT projects than on
report,lmproving lT contracts related to roads (about f2.3 billion as opposed Io f-1 .4 billion).

.,Pttult*::l',
November2004'
ì he biggest departmental spender was the Department for Work and
pensions, who spent over fB00 million on lCT. Mismanagenrent of
ICT projects means that tftere is less to spend on good things such as

There has been hospitals' projects are not always successful. ln a report published
some debate about Unfortunately,
the standish croup in the united states analysed l'3,522 projects
ir,- in 2003,
Jr.."."rl,a¡tv
of the Standish and concluded that only a third of projects were successful; B2o/, of
findings butthe key projects were' late and 43'/, exceeded their budget.
pointaboutthe The reason for these project shortcomings is often the management
prevalence oflT of projects. The National Audit office in the uK, for example, among ofher
profectfailings factors causing project failure iclentified 'lack of skills and proven approac:lt
remains clear'
b proiect management and risk managemen(.

1.3 What is a project?

The dictionary definitions put a clear emphasis on the project being a
Dictionary
plannec! activity.
definitions of
'projecf include: The emphasis orr being planned assumes we carl determine how
'A specific plan or to carry out a task before we start. Yet with exploratory projects this mi¡4ht
design"A planned be difficult. Planning is in essence thinl<irrg carefully about sometlring,
undertaking''A large belore you do it - even with uncertairr projects this is worth doing as
undertakíng: e.g. long as the resulting plans are seen as provisional. Other activities, such
a public works
as routine maintenance, will have been performecl so many times that
scheme', Longman
everyone l<nows exactly what to do. ln tlrese cases, planning hardly
Cancise English
Dictionary,1982. seems necessary, although proceclures might be documented to ensure
corrsistency and to help newcomers.
l-he activities that benefit most from conventional project management
Programme are lil<ely to lie between these two extremes * see Figure 1.1.
managenentis often There is a hazy bourrdary between the non-routine project and the
used to coordinate routine job. The first time you do a routirre tasl( ¡t will l¡e like a project. Orr
activities on the other hand, a project to develop a system sirnilar to previous ones that
concurrent jobs.
you have developed will have a large element of the routine.
 1.3 What is a project? 3

Uncertainty
Rout¡ne
of outcome

Jobs Projects Exploration

FIGURE t.1 Activities most likely to benefit from project management

The fol lowi ng characteristics d ísti ngu ish projects :

r non-routine tasks are involved;

r planning is required;
r specific objectives are to be met or a specified product is to be created;
r the project has a predetermined time span;
¡ work is carried out for someone other than yourself;
r work involves several specialisms;
r people are formed into a temporary work group to carry out the task;
r work is carried out in several phases;
r the resources that are available for use on the project are constrained;
r the project is large or complex.
The more any of these factors apply to a task, the more difficult that task will be. Project
size is particularly important. The project that employs 20 developers is likely to be
disproportionately more difficult than one with only 10 staff because of the need for
additional coordination. The examples and exercises used in this book usually relate to
smaller projects in order to make the techniques easier to grasp. However, the techniques
and issues discussed are of equal relevance to larger projects.

EXERCISE 1.1

Consider the following:

r producing an edition of a newspaper;
r putting a robot vehicle on Mars to search for signs of life;
r getting married;
r amending a financial computer system to deal with a common European cunency;
4 Chapter 1 lntroduction to software project management

r a research project ilrto what nrakes a good httmatr-cornpttter interface;

r an investigation into the reâson why a user has a problem with a computer system;
¡ a second-year programrtting assigtìütent fbr a cornputing studerrt;
r writing an operating system fbr a new computer;
r installing a new version ofa word processing package in an organization.
Some seem more like real projects tìran others. Prtt them into an orcler most closely
rnatching your ideas of what constitutes a project. For each entry in the orclered list,
clescribe the dilTerence between it and the one above which makes it less worthy of the
term'project'.
There is no one correct âÌtswer to this exercise, but a possible solution to this and the
other exelcises you will corne across may be fbund at the end of the book.

Some argue that projects are especially problematic ils they are
For example, see
Rolf A. Lundin and
temporary sub-organizations. A ¡4roup of people is brou¡¡ht together
Andres Söderholm to carry out a task. The existence of this sub-or¡lanization cuts across
t1995) 'A theory of the autlrority of the existing units within the organization. This has the
the temporary advantage that a group containing various specialists is focused on
organization' a single important task. However, the profect is lil<elyto be seen as
Scandinavian clisruptive to others. Also, expertise built up during the project may
Journal of
be lost when the team is eventually clispersed at the errd of the
Managenentlll4l
project.
437-55.

1.4 Software proiects versus other types of proiect

Brooks (1987).
h/ any techniques in general project management also apply to software
I V I pro¡ect management, but Fred Brooks identified some characteristics
F. P.
'No silver bullet:
essence and of software projects which make them particularly difficult:
accidents of
tnvisibility When a physical artefact such as a bridge is constructecl the
software
progress can actually be seen. With software, proS,ress is not inrmecliately
engineering'. This
essay has been visible. Software project management can be seen as the process of making
included in I/,e the invisible visible.
MythicalMan- Complexity Per clollar, pouncl or euro spent, software products contain
Monffi, Anniversary
more complexity than other engineerecJ artefacts.
Edition, Addison
Wesley,1995. Conforntity The 'traditional'engitreer usually works witlr physical systems
and materials like cenrent and steel. These physical systems have
complexity, but are ¡¡overned by consisterrt physical laws. Software
developers h¿lve to conform to the requirements of human clients. lt is rrot just that
individuals can be inconsistent. Organizations, because of lapses in collective memory/
in internal communication or in effective decision making, can exhibit remarkable
'organ izational stupid ity'.
 1.6 Act¡v¡ties covered by software proiect management 5

Flexibility That software is easy to change is seen as a strength. However, where the
software system interfaces with a physical or organizational system, it is expected that
the software will change to accommodate the other components rather than vice versa.
Thus software systems are particularly subject to change.

ln-house projects are where the users and the developers of new software work for the
f same organization. However, increasingly organizations contract out ICT development
to outside developers. Here, the client organization will often appoint a 'project manager'
to supervise the contract who will delegate many technically oriented decisions to the
contractors. Thus, the project manager will not worry about estimating the effort needed to
write individual software components as long as the overall project is within budget and
on time. On the supplier side, there will need to be project managers who deal with the
more technical issues. This book leans towards the concerns of these 'technical' project
mana8ers.

I software project is not only concerned with the actual writing of

/-\software. ln fact, where a software application is bought in 'off
the shelf', there may be no software writing as such, but this is still
fundamentally a software project because so many of the other activities
associated with software will still be present.
Usually there are three successive processes that bring a new system
into being - see Figure 1 .2.

Feasibility study
How do we
do it?

ls it worth
doing?
Plan
Do itl

+
Project execution

FIGUßE 1.2 The feasibility study/plan/execution cycle

 6 Chapter 1 lntroduction to software project management

1
Chapter 2 explores
The feasibility study assesses whether a project is wortlr starting -
that it has a valid business case. lnformation is gathered about the
somefurther requirements of the proposed application. Requiremerrts elicitation
aspects of
programme can, at least irritially, be complex and difficult. The stal<eholders may
management. krrow the aims they wish to pursue, br¡t rrot be sr-¡re about the means of
achievernetrt. The developmental and operational costs, and the value
of the benefits of the new system, will also have to be estimated. W¡th a large system,
the feasibility study coL¡ld be a project in its own right with its own plan. The study
could be part of a strategic planning exercise examinin¡1 a ranÊîe of potential software
developments. Sometimes an organization assesses a programme of clevelopment
macle up of a number of projects.

The pRtNCE2 2 Planning lf the feasibility study indicates that the prospective project
appears viable, therr project planning can start. For larger projects, we
method,which
is described in would not do all our detailed planning at the beg,inning. We create an
AppendixA,takes outline plan for the whole project and a detailed one for the first stage.
this iterative Because we will have more detailed and accurate project information
approach to after the earlier stages of the project have been completed, planning of
planning. the later stages is left to nearer their start.
Annex to this
3
1

;;ü;ñ';; Proiect execution The project can now be executed. The execution
outline of the of a pro ject often contain s design and implementation sub-phases.
content of a plan. Students new to project planning often find that the boundary between
design and planning can be hazy. Design is mal<irrg decisions about
the form of the producfs to be created. This coulcl relate to the external appearance
of the software, that is, the user interface, or the internal architecture. The plan details
lhe activities to be carried out to create these products. Plarrning and design can be
1
confused because at the most detailed level, planning decisions atre irrfluenced by
design decisions. Thus a software product with five major components is lil<ely to
require five sets of activities to create them.

Figr-rre.3 shows the typical sequence of software development

1
Figure 1.3 suggests .l
activities recommended in the international standard ISO 2207. Some
that these stages
must be done strictly activities are concenled with the system while others relate to software.The
in sequence - we development of software will be only one part of a project. Software could
will see in Chapter 4 be developed, for example, for a project which also requires the installation
that other, iterative of an ICT infrastructure, the design of user jobs ancJ user training.
approaches can be
adopted. Howeveç t Requirements analysis starts with requirements elicitation or
the actual activities requirements gathering which establishes what the potential users and
listed here would their managers require of the new system. lt could relate to a function -
still be done.
that the system should do something. lt coulcl be a quality requirement -
how well the functions rnust worl<. An example of this is dispatching an
ambulance in response to an emergency telephone call. ln this case transaction time
would be affected by harclware and software performance as well as the speed of
human operation. Training to ensure that operators use the computer system efficiently
is an example of a system requirementfor the project, as opposed to a specifically

a.
 1.6 Activities covered by software project management 7

n
ñ
E
(, oÊ.
Architecture design o
3
o
Requirements analysis =

Architecture design o
lD

ûq'
Requirements analysis f
-(,
o
Detailed design (D
AJ
(ú
3 Code and test ='
,Ë
o fD-
ô
o
3
lD
lntegration o. 3
rD qJ
rL
:
9J
= o
Qualifìcation test lD

E lntegration
(J

Qualification test

øo=
rl Þag
côJ
õl lnstallation rc lJ
ll ou: 0.,

f,üE
5l Acceptance support ão
ô5

FIGURE 1.3 The lS0 12207 software development life cycle

software requirement There would also be resource requirements that relate to

appl ication development costs.
t Architecture design The components of the new system that fulfil edch requirement
have to be identified. Existing components may be able to satisfy some requirements.
ln other cases/ a new component will have to be made. These components are not
only software: they could be new hardware or work processes. Although software
developers are primarily concerned with software components, it is very rare that these
can be developed in isolation. They will, for example, have to tal<e account of existing
legacy systems with which they will interoperate. The design of the system architecture
is thus an input to the software requiremenfs. A second architecture design process then
takes place that maps the software requirements to software components.
t Detailed design Each software component is made up of a number of software units
that can be separately coded and tested. The detailed design of these units is carried
out separately.

t.
I Chapter 1 lntroduction to software project management

t Code and test refers to writing code for each software unit. lnitial testing to debug
individual software units would be carried out at this stage.
t Integration The components are tested together to see if they meet the overall
requirements. Integration coulcl involve combirring different software components,
or combining and testing the software element of the system in conjunction with the
hardware platforms and user interactions.
t Qualification testing The system, includirrg the software components, has to be tested
carefully to ensure that all the requiremerrts have been fulfilled.
t lnst¿tllation This is the process of making the new system operational. It woulcl include
activities such as setting up standing data (for example, the details for employees in a
payroll system), setting system parameters, installing the software onto the hardware
platforms and user training.
t Acceptance support This is the resolving of problems with the newly installed system,
including the correction of any errors, and implementing agreed extensions and
improvements. Software ma¡ntenance can be seen as a series of minor software
projects. ln many environments, nlost software development is in fact maintenance.

EXTRCISE 1.2

þ rightrnouth College is a higher education institr-rtion which used to be managed by a

I-D local government authority but has now becorne autonomous. Its payroll is still
adrninisterecl by the local authority and pay slips and other output are produced in the
local authority's computer centre. The authority now charges the college for this service'
The college nÌanagement are of the opinion that it would be cheaper to obtain an 'off-the-
shelf' payroll package and do the payroll processing themselves.
What wolld be the main stages of the project to convert to indepenclent payroll
processing by the college? Bearing in mincl that an off-the-shelf package is to be used, how
would this ploject difÏer lì'orn one where the soflware was to be written from scratch?

1.7 Plans, methods and methodologies

A plan for an activity must be based on some idea of a ntethod of work. For example, if
you were asked to test sonre software, you may know nothing about the software to be
tested, br-rt you cor-¡ld assume that you would neecl to:

r analyse the reqr.rirements for the softwarei

r clevise and write test cases that will check that each requirement lras been satisfied;
r create test scripts and expected results for each test case;
r compare the actual results and the expected results and identify cliscrepancies.
 1.8 Some ways of categorizing software projects I

While a method relates to a type of activity in general, a plan takes that method (and
perhaps others) ancl converts it to real activities, identifying for each activity:

r its start and end dates;

r who will carry it out;
r what tools and materials - including information * will be rreeded.
-[he
or"rtput from one methocl might be the input to another. Croups of methods or
techniques are often grouped into methodologies sLrch as obiect-or¡ented clesigrr.

EXERCISE 1.3

tlhis shorrld ideally be clone in groups of about fortr, but you can think about how yor-r
I would go about this exercise on yollr own if neecls be. You are probably in a building
that has more than one storey. From the point of view ol this exercise, the bigger the
building the better.
In a group of f'our, work out how you would obtain an accurate estimate of the height of
the building. (If you happen to be in a single-storey builcling, you can estimate the floor
area instead!) Plan how you would carry out any actions needecl to obtain your estirnate.
Spend 20 minutes on this - you must remain in the same room for this pìannirrg phase,
Once plannirrg is complete, implement your plarr, timing how long it takes to produce
your final figure.
If there is urore than one gror-rp carrying out this exercise, after completion of the task
you can compare answers and also the approach you used when coming up with your
answer,

1.8 Some ways of categorizing software pro¡ects

rojects may differ because of the different technical products to be createcl. l-hus we
P need to identify the characteristics of a project which could affect the way in which it
shoulcl be planrred and nranaged. Other factors are cJiscussed below

Compulsory versus voluntary users

In workplaces there are systems that staff have to use if they want to do something, such
as recording a sale. However, use of a system is increasingly voluntary, as in the case of
computer games. Here it is difficult to elicit precise requirements from potential users ¿ìs
we could with a business system. What the game will do will thus depend nruch on the
informed ingerrr-rity of the developers, along with techniques such as market surveys, focus
groups arrd prototype evaluation.
10 Chapter 1 lntroduction to software proiect management

lnformation systems versus emhedded systems

A traditio¡al clistinction has been between infornt¿ttiott systems which
Embedded systems
enable staff to carry out office processes atrd enbetlcled sYstems which
are also called real-
time or industrial corrtrol maclrines. A stock control system would be an inlormatiorr system'
systems. An er-ltbeddecl, or process control, system nrig,ht control the air conditionirrg
equipment irr a building. Some systems may have elements of lloth where,
for exanrple, the stocl< control systetn also controls ¡rn autorn¿rted
warehouse.

EXERCISE 1.4

W ould an operating systern on a cornputer be art irrlbrulation system or an ernbedded

system?

0b jectives versus products

Projects may be distinguisherl by whether their aim is to produce a product or to meet
certairr objeclives.
A project rnight be to create a prodLrct, the cletails of which have been specified by the
client. Tlre client has the resporrsibility for justifying the product.
On the other hancl, the project requirement might be to meet certaitr
Service level objectives which coulcl be met in a number of ways. An organizatiot-t
agreementsare might have a problem and ask a specialistto recommend a solr¡tion.
becoming Many software projects have two stages. First is an objective-drivetr
ilt^::::n]l projecr resulting in recommendations. lhis might identify the need for a
¡mportant as
åiäiîiäiri, new software system. I'he next stage is a project actrrally to create the
cõnûact out software Procluct.
functi.nsto external This is useful where the technical worl< is being dorre by an external
service suppliers. g,rou¡r and the user neecls are unclear at the or¡tset. l-he external group can
produce a preliminary design at a fixed fee. lf the design is acceptable the
cJevelopers can then quote a price for the seconcl, implementation, stage based on an
agreed requirement.

EXERCISE 1.5

W oulcl the project to implement an independent payroil systern at the Brighlmouth

College clescribecl in Exelcise 1.2 above be an objective-driven ploject or a product-
driven project?

a.
 1.10 Setting objectives 11

1.9 Stakeholders
are people wlro have a stal<e or interest in the project. Their early identification
Jhese is
I important as you need to set up adequate communication channels with them.
Stakeholders can lre categorized as:

t lnternal to the project team This means that they will be under the direct managerial
control of the project leader.
t External to the project team but within the same organization For example, the
project le¿rder might need the assistance of the users to carry out systems testirrg.
Here the commitment of the people involved has to be negotiated.
; Extental to both the project team and the organizafion External
B. and
W. Boehm will benefit from the
stal<eholclers may be customers (or users) who
R. Ross,'Theory system that the project implements. They may be corrtractors who
Wsoftware project will carry out work for the project. The relationship here is usually
management: lrased on a contract.
principles and
examples', in Different types of stakeholder may have c.lifferent objectives and one of
B. W. Boehm (ed.)
the jobs of the project leader is to recognize these clifferent ¡nterests and to
|11989l. Software Rísk be able to reconcile them. For example, end-users may be concerned with
Managenent,I.EEE the ease of use of the new application, while their managers may be more
ComputerSociety focused
on staff savings. The project leadertherefore needs to be a good
communicator and negotiator. Boehm and Ross proposed a '1-heory W'of
software project management where the manager concentrates on creating
The role andformat
situations where all parties benefit from a project and therefore have an
of communication interest in its success.
(The 'W'stands for'win-win'.)
planswill be Project managers can sometimes miss an important stakeholder group,
explained in greater especially in unfamiliar business contexts. These could be departments
detail in Chapter l1 supplying important services that are taken for granted.
on managing people Civen the importance of coordinatirrg the efforts of stakeholders, the
:l::yiT recommended practice is for a comntunication planto be created at the
envlronments.
start of a project.

TXTRCISE 1.6

Identify the stakeholders in the Brightmouth College payroll project.

l.l0 Setting objectives

A mong all these stal<eholders are those who actually own the project. They control the
financing of the project. They also set the objectives of the project. The objectives
should define what the project team must achieve for project success. Although different

t.
12 Chapter I lntroductìon to software proiect management

stakeholders have different motivations, the project objectives identify the shared
intentions for the project.
Objectives focus on the desired oLttcomes of the project rather than the tasks within it
*
they are the 'post-conditions'of the project. lnformally the objectives could be written as a
set of statements followin¡; the opening words 'the proiect will be a s¿,ccess if. . . .'Thus
one statement in a set of objectives mi¡;ht be'custonters can order our proclucts onlind
rather than 'to build an e-commerce website'. There is often more than one way to meet
an objective and the more possible routes to success the better.
There may be several stakeholders, irrcluding users itl different business areas, who
might have some claim to project ownership. ln such a case/ a proiect
authority needs to be explicitly identified with overall authority over the
This committee is project.
likelyto contain user, This authority is often a project steering committee (or project board
developmentand or project man¿tgement board) with overall responsibility for setting,
managem.ent monitoring and modifying objectives. The project manaÉier runs the project
representatlves'
on a day-to-day basis, but regularly reports to the steering committee.

Sub-objectives and goals

An effective objective for an individual must be something that is within
ueflnrng suþ-
might be that the software
,¡¡ã.ii"ä.iäqri*, the control of that incliviclual.payArrforobjective reducing staff costs' As
assr*pt¡ons å¡out application produced must itself by
howthe main an overall business objective this miglrt be reasonable. For software
objective ¡sto be cJevelopers it would be unreasonable as any reduction in operational staff
achieved. costs depends not jr-rst on them but orr the operational management of the
delivered system. A more appropriate goal or sub-objective for the software
developers would be to keep development costs within a certain budget.
We can say that in order to achieve the objective we must achieve certain goals or subr-
objectives first. I'lrese itre steps on the way to achieving an objective, just as goals scored
in a football match ¿rre steps towards the objective of winnin¡¡ the match. lnformally this
can be expressed as a set of statements following the words 'To reach obiective . . . , the
following must be in place . . .'.
The mnemonic SMART is sometintes used to describe well<lefined objectives:
t Specific Effective objectives are concrete ancl well defined. Vague aspirations such as
'to improve custamer relations'are r-rnsatisfactory. Objectives should be defined so
that it is obvious to all whether the project has been successfl¡1.
t Measurab/e ldeally there should be nreas¿rres of effectiveness which
tell us how successful the project lr¿ls been. For example,'to reduce
This still leaves a customer complaints' wou ld be more satisfactory as an objective than
problem aboutthe ,Kt
improve custon'rer relations'. The measure cart, in some cases, be ;ln
to simple yes/no question, e.s. 'Dic! we install the new software
,iïii$ir['lJi:, ",,r*",
SoYo
e.g. wny, say, a
bY I June?'
reductionin t Achiev¿tble lt must be within the power of the individual or Sroup to
complaints andnot achieve tÌte oLrjective.
40% or 60%?
t Relev¿uttThe objective must be relevant to the true purpose of the project,
 1.1 t The business case 13

t Time constrained There should be a defined po;nt ¡n time by which the objective
should have been achieved.

EXTRCTSI 1.7

earing in mind the above discussion of objectives, comment on the appropriateness

B of the wording of each of the f'ollowirrg 'objectives' lbr software developers:
(i) to implement the new application on time and within budget;
(ii) to implement the new sofTware application with the fewest possible solTware errors
that might lead to operational fàilures;
(iii) to desigrr a system that is user-frienclly;
(iv) to produce full documentation fbr the new system,

Measures of effectiveness
rL-_- __-
_ ----a
I nese conceDts
Measures of effectiveness provide practical methods of checking that
are
;ffiir.d #; fñ' an objective has been met. 'Mean tinre between failures' (mtbf ) might,
ínChaptert3on for example, be used to measure reliability. This is a performance
software quality. measurement and, as sltch, can orrly be taken once the system is
operational. Project nlanagers want to get some iclea of the performance
of the completed system as it is being constructed. They will therefore seek predictive
measures. For example, a large number of errors found cJuring code inspections nright
indicate potential problems with reliability later,

EXTRCISE 1.8

Jclentify the objectives and sub-objectives of the Briglrtmouth College payroll project.
IWhat measrlres of efTectiveness coulcl be used to check the success in achieving the
objectives of the project?

l.1l The business case

The business case

À ,{ ost proiects need to have a justification or business case: the effort
should be
lVlnn¿'""punr" of pushing the project throu¡¡h must be seen to be
established at the worthwhile in terms of the benefits that will eventually be felt. A cost-
t¡me of the project's benefit analysis will often be part of the project's feasibility study. This will
feasibility study. itemize ancl quantify the project's costs and benefits. The benefits will be
Chapter 2 explains affected by the completiorr date: the sooner the project is completed, the
rhe idea 0f a sooner the benefits can be experiencecl. The quantification of benefits will
business case in
often require the formulation of a business modelwhich explains how the
more detail.
new application can gener¿ìte the claimed benefits.
14 Chapter t lntroduction to software project management

A simple example of a business model is that a new web-based application might allow
customers from all over the world to order a firm's products via the internet, increasing
sales and thus increasing revenue and profits.
Any project plan must ensure that the business case is kept intact. For example:
r that development costs are not allowecl to rise to a level wlrich threatens to exceed the
value of benefits;
r that the features of the system are not reducecl to a level where the expected benefits
cannot be realized;
I that the delivery date is not delayed so that there is an unacceptable loss of
benefits.

1.12 Project success and failure

A good íntroduction
-T-he prolect plan shoulcl be designed to ensure project success
to the issues I by prur"ruing the business case for the project. However, every
discussed here can non-trivial project will have problems, and at what stage do we say that a
be found in A. J. project is actually a failure? Because different stal<eholders have different
Shenhar and 0. Levy
interests, some stalceholders irr a project might see it as a success while
(19971 'Mapping the
others do not.
dimensíons of
project success' Broadly speaking, we can distinguish between proiect obiectives and
Project business objectives. The project objectives are the targets that the project
Management team is expected to achieve. ln the case of software projects, they can
Journal2Ûl2l 9-12. usually be summarized as delivering:

r the agreed fr-rnctiorralitY

r to the required level of qualitY
r on time
r within budget.
A project could meet these targets but the application, once delivered could fail to meet
the business case. A computer game could be delivered on time and within budget,
but nright then not sell. A commercial website used for online sales could be createcl
successfully, but customers might not use it to buy products, because they could buy
the goods more cheaply elsewhere.
We have seen that in business terms it can generally be said that a
The assessment of project is a success if the value of benefits exceeds the costs. We have
the value of project
also seen that while project managers have consiclerable control over
i:1tt]t^:::ilii:j development costs, the value of the benefits of the project deliverables is
"''',il#;ä.""" dependent on external factors such as the number of customers. Project
rn 0reater 0eoln tn

objectives still have some bearing on eventual business success. As we

will see in Chapter 2, increasing rlevelopment costs recllrce the chances of the delivered
procluct being profitable. A delay in completion reduces the amount of time during which
benefits can be generated and dirninishes the value of the project.
 1.13 What is management? t5

A project can be a success on delivery but then be a business failure, On the other
hand, a project could be late and over budget, but its deliverables could still, over time,
generate benefits that outweigh the initial expenditure.
Some argue that the possible gap betweerr project and business concerns can be
reduced by having a broader view of projects that includes business issues. For example,
the project management of an e-commerce website implementation could plan activities
such as market surveys/ competitor;rnalysis, focus groups, prototyping, and evaluation by
typical potential users - all designed to reduce business risl<s.
Because the focus of project management is, rrot unnaturally, on the
For a wider immediate project, it may not be seen that the project is actually one of a
discussion of the sequence. Later projects benefit from the technical sl<ills learnt on earlier
relationships projects. Technical learning will increase costs on the earlier projects, but
between successive later projects benefit as the learnt technologies can be cleployed more
cheaply and accurately. This expertise is often accompanied by
,ltt*ilffire,l,, quicl<ly,
;;;ffi;]i"ij.n;, additional software assets, for example re¡-rsable code. Where software
'l¡ní,ing
proir.ird development is outsourced, there may be immediate savings, but these
historyand conte)d' longer-term benefits of increased expertise will be lost. Astute managers
Research Policy n''ìay assess which areas of technical expertise it would be beneficial to
32789-808. develop.
Customer relationships can also be built up over a number of projects.
If a client has trust in a supplier who has done satisfactory worl< in the past, they are
more lil<ely to use that company again, particularly if the new requirement builds on
functionality already delivered. lt is much more expensive to acquire new clients than
it is to retain exisling ones.

1.13 What is management?

I /\ /e have explored some of the special characteristics of software. We now look at the
V V 'runogement' aspect of software project management. lt has been suggestecl that
management involves the following activities:
r planning - deciding what is to be dorre;
r organizing - making arrangements;
r staffing - selecting the right people for the job etc.;
r directing - giving instrr"rctions;
r morritorirrg - checkirrfl on progress;
¡ controlling - taking action to remedy hold-ups;
r irrnovating - coming up with new solutions;
r representing - liaising with clients, users, developer, suppliers and other stakeholders.
l6 Chapter 1 lntroduction to softwale proiect management

EXERCISE 1.9

J)aul Duggan is the manager of a software development section. On Tuesday at 10.00 a.m'
-F tr" and his fellow section heads have a meeting with their group manager about the
staffing requirements for the coming year. Paul has already drafted a document 'bidding'
for staff. This is based on the work planned for his section for the next year. The document
is discussed at the meeting. At 2.00 p.m. PauI has a meeting with his senior staff about an
important project his section is undertaking. One of the programming staff has just had a
road accident and will be in hospital for some time. It is decided that the project can
be kept on schedule by transferring another team member from less urgent work to this
project. A temporary replacement is to be brought in to do the less urgent work but this
may take a week or so to arrange. Paul has to phone both the human resources manager
about getting a replacement and the user for whom the less urgent work is being done,
explaining why it is likely to be delayed'
Identify which of the eight management responsibilities listed above Paul was
responding to at different points during his day.

M anagement/ in general, involves setting objectives for a system and then monitoríng
the performance of the system. ln Figure 1 .4 the 'real world' is shown as being rather
formless. Ëspecially in the case of large undertakings, there will be a lot going on about
which management should be aware.

EXEIICISE 1.10

I n ICT project is to replace locally held paper-based records with a centrally organized
f\d"t"b"re. Staff in a large number of offices that are geographically dispersed need
training and will then have to use the new ICT system to set up the backlog of manual
records on the new database. The system cannot be properly operational until the last
record has been transferred. The new system will only be successful if new transactions
can be processed within certain time cycles.
Identify the data that you would collect to ensure that during execution of the project
things were going to plan.

Thiswill involve the local managers in data collection. Bare details, such as 'location
X has processed 2OO0 documents', will not be very useful to higher management: data
processingwill be needed to transform this raw data into useful informafion. This might be
in such forms as 'percentage of records processed', 'average documents processed per day
per person'and 'estimated completion date''
 1.14 Management control 17

The Actions
real world

Data
collection

Data

Define Data
objectives processing

lnformation

Making
decisions/plans

Modelling Decisions

lmplementat¡on

FIGURE 1,4 The prolect control cycle

ln our example, the project management might examine the 'estimated completion
date'for completing data transfer for each branch. These can be checked against the
overall target date for completion of this phase of the project. ln effect they are comparing
actual performance with one aspect of the overall project objectives. They might find
that one or two branches will fail to complete the transfer of details in time. They would
then need to consider what to do (this is represented in Figure 1 .4 by the box Making
decisionsþlarrs). One possibility would be to move staff temporarily from one branch to
another. lf this is done, there is always the danger that while the completion date for the
one branch is pulled back to before the overall target date, the date for the branch from
which staff are being moved is pushed forward beyond that date. The project manager
would need to calculate carefully what the impact would be in moving staff from
particular branches. This is modelling the consequences of a potential solution.
Several different proposals could be modelled in this way before one was chosen
Íor implementation.
Having implemented the decision, the situation needs to be kept under review
by collecting and processing further progress details. For instance, the next time that
progress is reported, a branch to which staff have been transferred could still be behind
in transferring details. This might be because the reason why the branch has got behind in
transferring details is because the manual records are incomplete and another clepartment,
 l8 Chapterl lntroduct¡ontosoftwareprojectmanagement

for whom the project has a low priority, has to be involved in providing the missing
information. ln this case, transferring extra staff to do data inputting will not have
accelerated data transfer.
It can be seen that a project plan is dynamic and will need constant adjustment during
the execution of the project, Courses and books on project management (such as this one)
often focus considerable attention on project planning. While this is to be expected, with
nearly all projects much more time is spent actually doing the project rather than planning
it. A good plan provides a foundation for a good project, but is nothing without intelligent
execution. The original plan will not be set in stone but will be modified to take account
of changing circumstances.

This chapter has laid a foundation for the remainder of the book by defining what is meant
by various terms such as 'software project'and 'management'. Among some of the more
important points that have been made are the following:

r Projects are by definition non-routine and therefore more uncertain than normal
undertqkings.
r Software projects are similar to other projects but have some attributes that present
particular difficulties, e.g. the relative invisibility of many of their products.
r A key factor in project success is having clear objectives. Different stakeholders in a
project, however, are likely to have different objectives. This points to the need for a
recogn ized overal I project authority.
{ r For objectives to be effective there must be practical ways of testing that the objectives
have been met.
I Where projects involve many different people, effective channels of information
have to be established. Having objective measures of success helps unambiguous
communication between the various parties to a project.

r lntroduction
r Background: including reference to the business case
r Project objectives
r Constraints - these could be included with project objectives
r Methods
r Project products: both deliverable products that the client will receive
and intermediate products
¡ Activities to be carried out
r Resources to be used

).
 1.16 Further exercises 19

r Risl<s to the project

r Management of the project, including
o organizational responsibilities
. management of quality
o configuration management

1.16 Further exefc¡ses

1 List the problems you experienced when you carried out a recent lCl-related
assignment. Try to put these problems into some order of magnitude. For each problem
consider wlrether there was some way in which the problem could have been reduced
by better organization and planning by yolrrself.
2 ldentify the main types of personnel employed in an information systems department.
For each stage of a typical lS development project, list the types of personrrel who ¿rre
lil<ely to be involved.
3 A public library is considering the implementation of a computer-b¿rsed system to help
administer book loans at libraries. ldentify the stal<eholders in such a project. What
might be the objectives of such a project and how might the success of the project be
measured in practical terms?
4 A software house has developed a customized order processing system for a client.
You are an employee of the software house that has beerr asl<ed to organize a training
course for the end-users of the system. At present, a user hanclbool< has been produced,
but no specific training material. A plan is now needed for the project which will set
up the delivery of the training courses. The project can be assumed to have been
completed when the first training course starts. Among the things that will neecl to be
considered are the following:
o training materials will need to be designed and created;
r a timetable will need to be drafted and agreed;
o date(s) for the course will need to be arranged;
e the people attending the course will need to be identified and notified;
. rooms and computer facilities for the course will need to be provided.
A ldentify the main stal<eholders for this project.
B Draw up objectives for this project.
C For the objectives, identify the measures of effectiveness.
D For each objective, write down sub-objectives or goals and the stal<eholclers who
willbe responsible for their achievement.
5 A manager is in charge of a sub-project of a larger project. The sub-project requires the
transfer of paper clocuments into a computer-based document retrieval system and their
subsequent indexing so that they can be accessed via key-words. Optical character
readers are to be usecl for the initial transfer but the text then needs to be clerically
checked and corrected by staff. The project is currently scheduled to take 12 months
using permanent staff. A small budget is available to hire temporary staff in the case of