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.