Lntroduction Software: Pro¡ect
Lntroduction Software: Pro¡ect
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
.,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(.
Uncertainty
Rout¡ne
of outcome
EXERCISE 1.1
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.
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.
Feasibility study
How do we
do it?
ls it worth
doing?
Plan
Do itl
+
Project execution
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.
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
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
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:
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:
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,
EXERCISE 1.4
EXERCISE 1.5
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
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.
t Time constrained There should be a defined po;nt ¡n time by which the objective
should have been achieved.
EXTRCTSI 1.7
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?
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.
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:
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.
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
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
I
20 Chapter I lntroduction to software project management
staff absences through holidays, sickness or temporary transfer to other, more urgent,
jobs. Discuss the control system that will need to be in place to control that
sub-project.
6 The idea behind a project is that students should be able to access details of available
placements via an intranet. When there is a placement opportunity for which they
wish to be considered, they would be able to apply for it electronically, This would
cause a copy of their CV, which would also be held online, to be sent to the potential
employer.
Details of interviews and placement offers would all be sent by e-mail. While
some human intervention would be needed, the process would be automated as far
as possible.
You are required to produce a business case report for such an application, which
justifies the potential development by showing that the value of its potential benefits
outweighs its development and operational costs.
Create lists of the main benefits and costs for the project. You do not have to specify
actual figures, just the headings under which they would appear.