Units5&6 - Arab Open University

Project execution

Uni

ts5 & 6

M865 Units 5 & 6POSTGRADUATE ICT AND COMPUTING

Project management

This publication forms part of an Open University course M865

Project management. Details of this and other Open University courses

can be obtained from the Student Registration and Enquiry Service,

The Open University, PO Box 197, Milton Keynes MK7 6BJ,

United Kingdom: tel. +44 (0)845 300 60 90,

email [email protected]

Alternatively, you may visit the Open University website at

http://www.open.ac.uk where you can learn more about the wide range

of courses and packs offered at all levels by The Open University.

To purchase a selection of Open University course materials visit

http://www.ouw.co.uk, or contact Open University Worldwide,

Michael Young Building, Walton Hall, Milton Keynes MK7 6AA,

United Kingdom for a brochure: tel. +44 (0)1908 858793;

fax +44 (0)1908 858787; email [email protected]

The Open University

Walton Hall

Milton Keynes

MK7 6AA

First published 1995. Second edition 2004. Third edition 2008.

Copyright ª 1995, 2004, 2008 The Open University.

All rights reserved. No part of this publication may be reproduced,

stored in a retrieval system, transmitted or utilised in any form or by any

means, electronic, mechanical, photocopying, recording or otherwise,

without written permission from the publisher or a licence from the

Copyright Licensing Agency Ltd. Details of such licences (for

reprographic reproduction) may be obtained from the Copyright

Licensing Agency Ltd, Saffron House, 6–10 Kirby Street,

London EC1N 8TS; website http://www.cla.co.uk

Open University course materials may also be made available in

electronic formats for use by students of the University. All rights,

including copyright and related rights and database rights, in electronic

course materials and their contents are owned by or licensed to

The Open University, or otherwise used by The Open University as

permitted by applicable law.

In using electronic course materials and their contents you agree that

your use will be solely for the purposes of following an Open University

course of study or otherwise as licensed by The Open University or

its assigns.

Except as permitted above you undertake not to copy, store in any

medium (including electronic storage or use in a website), distribute,

transmit or retransmit, broadcast, modify or show in public such

electronic materials in whole or in part without the prior written consent

of The Open University or in accordance with the Copyright,

Designs and Patents Act 1988.

Edited and designed by The Open University.

Typeset by SR Nova Pvt. Ltd, Bangalore, India.

Printed and bound in the United Kingdom by The Charlesworth Group,

Wakefield.

ISBN 978 0 7492 2263 5

3.1

CONTENTS

Aims and objectives 6

Unit 5

1 Introduction 8

1.1 The project manager’s activities 8

1.2 Problems, problems 12

1.3 Summary 14

2 Project monitoring and control 15

2.1 Elements of project control 15

2.2 Measuring project status 17

2.3 Closing the loop 22

2.4 Summary 22

3 Monitoring the cost and schedule 24

3.1 Updating the schedule 24

3.2 Milestone tracking 27

3.3 The earned value method 29

3.4 Summary 44

4 Controlling the cost and maintaining theschedule 45

4.1 Combined cost and schedule graphs 45

4.2 Avoiding slippage 50

4.3 Controlling the project cost 52

4.4 Summary 55

Unit 6

1 Introduction 57

2 Maintaining the quality 59

2.1 Monitoring and controlling quality 59

2.2 Software quality 63

2.3 Auditing a project 70

2.4 Summary 74

Continued over page

3 Change: cause and effects 76

3.1 Changes to project deliverables (externalchanges) 77

3.2 Internal changes 79

3.3 Summary 82

4 Configuration management 83

4.1 An outline of configuration management 83

4.2 Configuration identification 89

4.3 Configuration control 94

4.4 Configuration status accounting 99

4.5 Configuration auditing 100

4.6 An example of configuration management 101

4.7 Issue management 104

4.8 Summary 105

5 Closing the project 106

5.1 Summary 111

References and further reading 112

Acknowledgements 114

SAQ answers 115

Unit 5 115

Unit 6 118

Index 124

M865 (REWRITE) COURSE TEAM

Steve Armstrong, Course Chair and Author

Darren Dalcher, External Assessor, University of Middlesex

Tom Docker, External Assessor, citi Ltd

Bill Gerrard, Author and Critical Reader

Felicity Head, Course Manager

Joan Jackson, Author and Critical Reader

Robin Kay, Critical Reader

David Morse, Critical Reader

Ken Platts, Critical Reader

Miles Shepherd, Author, Web Resources and Critical Reader

Pete Thomas, Critical Reader

Andy Allum, Course Website Developer

Ian Blackham, Editor

Jenny Chalmers, Freelance Copy Editor

Stephen Clift, Media Project Manager

Kim Dulson, Software Procurement

Richard Easterbrook, Editor

Phillip Howe, Media Assistant

Martin Keeling, Rights Media Assistant

Roy Lawrance, Freelance Graphic Artist

Tara Marshall, Print Procurement

Andrew Whitehead, Graphic Artist

Kaye Williams, Technical Tester

Kamy Yazdanjoo, Media Project Manager

Thanks are due to the Desktop Publishing Unit, Faculty of Mathematics, Computing and

Technology.

Aims and objectivesThe aims of this pair of units are to describe the monitoring and control of the

progress of a project, its quality and its cost against the plan, to discuss how to

cope with change during a project and finally to consider what happens as the

project comes to an end.

A number of methods and techniques are discussed, including the earned value system

for monitoring cost and progress, and configuration management for change control.

After studying Units 5 and 6, you should be able to:

c outline the project manager’s duties during the main implementation phase of the

project

c describe and criticise techniques for measuring the project status

c explain the earned value method and use it to produce measures of progress

against the plan and of expenditure against the budget

c compare and contrast several methods used for monitoring progress, including

milestone tracking, earned value and an updated project network

c discuss methods for avoiding slippage

c explain the purpose of a quality review and how it is conducted

c describe the mechanics of auditing a project

c explain the reasons for requiring change control

c explain how the conduct of a project is affected by the use of configuration

management

c explain the terms configuration control, configuration identification, configuration

status accounting and configuration auditing

c identify the components that need to be handled in a formal manner to avoid

uncontrolled change

c ask questions of a designer to identify likely change control problems

c outline the functions necessary to maintain adequate change control on a project

c describe the steps to be taken by a project manager as the project approaches its

close.

Finally, you may have noticed that this is the point where we move into the

implementation phase of the basic life cycle that was defined in Unit 1. We have

used an alternative and also popular name for that phase: execution. Using such a

title for Units 5 and 6 is a reminder that this is the phase in which most of the work is done

for just about every project. At the same time, you need to be aware that this is the

phase in which the critical success factors ‘come to the surface’. Having completed

Unit 4, for example, you have assembled the team and established a mechanism

for stakeholder management. So, the factor related to the appreciation of different

viewpoints may change quite a lot while the project plan is ‘being executed’.

Unit 5

MANAGING AND CONTROLLING PROGRESS

1 Introduction

The scope of the project has been defined, the project plan has been produced, the

‘temporary organisation’ has been set up, the resources have been allocated and the

project has been sanctioned. We are now entering the implementation phase of the

basic life cycle that was defined in Unit 1. So, we will be concerned with what the project

manager has to do while the project plan is being executed. The term ‘execution’ is used

here to mean all the activities in the project following the initial planning, organising

and authorisation, until the project is finished (in the handover and closeout phase).

You have already studied in Unit 4 the issues that arise in managing the project team so

Units 5 and 6 concentrate more on the techniques that may be used to ensure that the

project is monitored and controlled and brought to a successful conclusion.

1.1 The project manager’s activities

The activities of a project manager throughout a project may be considered to fall under

the following headings:

c initiating

c planning, organising and staffing

c monitoring and controlling

c directing

c communicating.

InitiatingThe most significant initiating actions by the project manager will normally occur

during project mobilisation. Project mobilisation is the first major activity once the

project has been authorised. Mobilisation consists of all the activities needed to get

the project up and running. It is not sufficient to make plans and obtain authorisation –

the project has to be pushed into action.

This will typically require the following activities:

c hold the project launch meeting(s)

c clarify roles and responsibilities

c identify training needs and arrange workshops

c hold start-up meetings with work package managers and stakeholders

c obtain agreements for work commitments from project staff (and their managers

where appropriate)

c set up the change control procedures

c ensure that the project support infrastructure is in place

c set up or invoke existing quality assurance mechanisms

c agree a timetable for monitoring and control meetings and reports

c ensure that the initial critical activities are started.

You might think that once this mobilisation phase has been completed the project

manager will have no more initiating to do. Although major unplanned initiatives are often

unwelcome, the project manager must be alert to the need for fresh action to grasp a

Unit 5: Managing and controlling progress8

profitable opportunity or, more often, to head off trouble before it becomes serious.

Nevertheless, excessive initiative at later stages may be counterproductive because the

project team already has a plan to work to, and it will be disruptive if the manager

continually produces new ideas about the direction of the project. Initiative has to be

used sparingly to avoid confusion about objectives and the loss of productive time in

considering alternatives to the current plan.

Planning, organising and staffingOnce the project has been mobilised the peak of the planning activity may have

passed, but planning is an evolutionary process that continues throughout the

project. Harrison (1992) uses the term ‘rolling wave’ to describe the way that

planning evolves through a large project. In a large project there will be a planning

hierarchy with coarse plans at the top, level 1, and more detailed plans at lower

levels as shown in Figure 1.1 (see also Lock, 2003, pp. 330–1). Harrison describes

how the planning wave rolls through the project:

Hierarchical planning normally incorporates the rolling wave concept of

planning. In many projects it is not practical or possible, because of the lack of

the necessary information to plan the complete project in any level of detail in its

early stages. Often the necessary information to plan the later stages of the

project in detail is actually generated in these earlier stages. In such projects

the use of the rolling wave concept overcomes this problem.

At the start of the project it is generally possible to create only a Level 1

summary plan outlining the complete project, with more detailed Level 2 or 3

plans for the early stages of the project. Then as more information is generated

by these earlier stages, it may be possible to create a Level 2 plan for the

complete project, and a Level 3 plan for the middle stages of the project. Later,

as the middle stages generate more information, the Level 3 detailed plans for

the final stages can be created.

This can be likened to a rolling wave, moving from left to right, that is from the

start of the project to its finish. The work in front of the rolling wave is only

planned in coarse detail to Level 1, or perhaps Level 2, with the crest of the

wave being the development of Level 3 or 4 plans. Within cost accounts, or

larger packages of work, the same concept can be used. The earlier activities

are fully developed work packages or job cards, and the later are larger

‘planning packages’ in which the work is not fully defined and detailed.

(Harrison, 1992, pp. 151–4)

You may remember the phrases work package level and cost account level, which

represent levels within the work breakdown structure (WBS) described in Unit 2.

Harrison emphasises that planning is not a once-and-for-all operation, rather that as the

project moves forward there is a planning wave that rolls ahead of activity execution and

elaborates the detail of the work about to be done. We would, therefore, have to modify

our working model of a life cycle if it had a planning phase followed by an execution

phase.

The hierarchy may alsobe constructed usingactivity-on-nodenetworks as well asGantt charts(particularly within acomputer planningpackage).

1 Introduction 9

Similarly, organising and staffing are continuing activities, although the bulk of this work

will have been completed when the project is mobilised. However, a project organisation

is much more fluid than the long-lasting organisations appropriate to the other

operations of a business, so occasionally the project manager may want to reassign

responsibilities, especially when the project team is expanding or contracting. It may

often be appropriate to reorganise completely as the project enters its handover and

closeout phase, as we shall discuss in Unit 6.

ACTIVITY 1.1

Give three examples of areas of a project for which plans are made only in outline at

project start-up, and explain why detailed plans cannot be made at that stage.

Discussion ............................................................................................................

There are many possible examples because this applies to almost all areas of a project

beyond the mobilisation activities. For example, construction plans, test plans,

commissioning plans and project closure plans are all necessarily only outline plans

initially because the detailed plans for these activities depend on the completion of

earlier activities, such as design. Furthermore, when adopting a phased or prototyping

life cycle, plans for the first phase will be prepared in detail, whereas outline plans for

later phases will be refined based on experience from each earlier phase. Using the

classification for projects discussed in Units 1 and 3, ‘quest’, ‘movies’ and ‘fog’ projects

require plans for later phases to be refined based on earlier work. This also fits with the

planning approach used in PRINCE (1998), which is a standard method used for

projects:

The PRINCE planning structure allows for a plan to be broken down into lower

level plans containing more detail. But all plans have the same overall structure

level 1 plan

level 2 plans

level 3 plans

Figure 1.1 A hierarchy of network plans (reproduced from Harrison, 1992, p. 148)


and are always matched back to the planned requirements, including quality

and benefits, before approval.

(p. 35)

Monitoring and controllingMonitoring and control are the project manager’s predominant activities during the main

execution phase. The project manager manages the risk to the project budget and

scheduled completion date by monitoring and controlling the work. Meredith and Mantel

(2006, p. 489) define project monitoring as follows: ‘Monitoring is collecting, recording

and reporting information concerning any and all aspects of project performance that

the project manager and others in the organisation may wish to know’. The same authors

define control rather succinctly: ‘Control is the act of reducing the difference between

plan and reality’ (p. 541).

Monitoring is a necessary prerequisite for control. Any effective control system must

have a desired status (the current plan) and a measurement of the actual status before

you can take action to make changes. We shall develop the subject of monitoring and

control in Sections 2, 3 and 4 of this unit.

DirectingIn simplified terms, directing is ordering something to be done. The distinction from

controlling is that a directive does not require a previously set objective or a

measurement of the current status.

For example, the following are directives:

c In this project quality standards X, Y and Z will apply.

c No overtime will be paid for unless it has been previously authorised by

your supervisor.

c There will be a progress review every Monday morning at 9 am.

c Frank Smith will take charge of the design of the conveying system.

c All the section leaders are to study the Open University course in Project

Management this year.

There are a number of managerial activities which might be considered to be part of

‘directing’ a project: supervising, delegating, motivating, counselling, coordinating and

setting standards. All these activities will be required from time to time during the

execution of the project. You have already met most of them in Unit 4.

CommunicatingHigh on the list of skills needed by a project manager is the ability to communicate.

As discussed in Unit 4, this means not just the outgoing half of communication,

talking and writing, but also the incoming half, listening and reading. All too often

the phrase ‘good communicator’ is used wrongly to describe someone who is good

at putting their case across but is deaf to the words of others.

As you have seen in Unit 4 the people with whom the project manager has to

communicate form a wide spectrum:

c senior management – to keep their continuing commitment

c client – to facilitate collaboration and to prepare for acceptance

c senior members of the project team – to coordinate their activities

c all team members – motivating, training, supervising, listening

c heads of functional departments – to avoid conflict over resources

1 Introduction 11

c suppliers and subcontractors – to help select and monitor them

c prospective operations/maintenance staff – to achieve smooth handover.

The project manager must not only be a good communicator but must also encourage

good communications between the team members. Although the work breakdown

structure attempts to break work into components which are as self-contained as

possible, in practice there must be a good deal of give and take on the interfaces

between the work elements. A good network of lower-level, informal communications is

invaluable.

SAQ 1.1

You may have encountered managers who hold the view that staff should be told only

what they need to know to do their job – nothing more, nothing less. Such managers

believe that information should be disseminated on a need-to-know basis. Give three

advantages and three disadvantages of such an approach. In what circumstances

would you use it?

1.2 Problems, problems

In the earlier stages of a project people are usually optimistic – sometimes to excess –

and plans are developed and estimates prepared in a spirit of enthusiasm for the

new venture. When the project moves into execution a more mature realism, even

pessimism, is likely to prevail. Where before there were challenges there are now only

problems. These problems will filter up through the team to the project manager with

whom the buck finally stops. As project manager you should expect most of the

following to occur during your project:

c technical design problems will arise

c there will be difficulties in meeting quality or reliability specifications

c the original specifications will prove deficient

c equipment will cost more than estimated

c some items will have been overlooked in the estimate

c activities will take longer than expected

c in the design phase it will be found that part of the requirements cannot be met

within the planned time and cost

c the selected technology will fail to deliver the expected performance

c key staff will leave the project

c changes will increase the workload

c other projects will be given priority over yours

c suppliers will be late delivering equipment

c a supplier may go bankrupt

c change in the market makes the original objectives obsolete

c installers may go on strike

c a subcontractor’s work will be below standard

c new legislation may prohibit a planned course of action.

Dealing with some of these problems is routine for the project manager during

execution. The project manager will probably have anticipated many of them by

performing a risk identification and analysis and have contingency plans. Contingency

planning will prove essential if the disruption caused by the problems is to be minimised.


Having a contingency plan will mean less time is lost in consultation and deciding what

to do next, and it will also mean that an appropriate budget can be invoked quickly.

Nevertheless, some problems will be unexpected, considered low-risk, and will now eat

into reserves of time and money if any still remain. A project manager needs resilience

not to be depressed by them and to maintain a balanced view.

ACTIVITY 1.2

Here is a typical problem for a project manager. You are halfway through the design

phase of a fixed-price project to design and supply a robotic manufacturing system when

the design engineers reach the conclusion that the level of reliability specified in the

contract cannot be met. The reliability of the robots that had been envisaged at the

estimating stage had been overestimated by the supplier who now will only guarantee

some lower performance. Further discussion with your designers reveals that a route to

higher reliability is uncertain. There may be alternative suppliers but costs and timescales

are uncertain and would require further research.

Consider the following questions:

(a) Would you prefer to keep this news from the client?

(b) When should your own management be informed?

(c) What steps could you take to recover from this blow?

Discussion ............................................................................................................

This kind of situation is not unusual.

(a) If this is a significant problem the client must be told as soon as possible. You may

recall from Unit 3 that one of the first tasks of the project manager is to establish

mutual confidence with the client. Secrecy will undermine your credibility.

Nevertheless, give yourself time to prepare an outline of options so that you are

prepared for some difficult negotiations. It is better to have a discussion with the

client armed with a range of potential answers than just with a nasty problem.

(b) Your own management should be informed at once – and before the client. (You

may need to fend off the suggestion from your management that there is no need as

yet to talk to the client.)

(c) Ask the engineers to produce an outline of the options, within the time constraint

of a few days. (No detailed research is possible.) Ask them to include the option

of using the robot originally envisaged with an estimate of the reliability now

expected. Then arrange a meeting with the client with the aim of negotiating

either for reduced reliability or for a delay in delivery and an increase in the price

to pay for the additional work and perhaps higher-cost equipment that may be

needed as well. As the contract is a fixed-price one you may expect some tough

bargaining ahead, but remember also that the client has to be realistic. The

client presumably still wants the project to be completed. If you are put into a

position where future costs will be more than the fixed price you may have to

recommend abandoning the project.

Although we have taken the supply of a robotic system as an example here you could

apply the same sort of problem to any project. Perhaps it has occurred (or will occur) in

your own project and you will have had to take similar actions.

1 Introduction 13

1.3 Summary

Most activities with which the project manager is concerned during execution fall under

the headings: initiating; planning, organising and staffing; monitoring and controlling;

directing; and communicating. Although the first four of these activities are primarily

performed at earlier stages of the project they continue throughout its execution.

An important initiative after project authorisation is the activity of mobilisation.

This means getting the project up and running. Planning continues after mobilisation.

We described Harrison’s concept of the rolling wave in which detailed planning runs

ahead of the activities that are about to be performed.

The main activities in the execution phase of a project are monitoring and control. These

rely heavily on the communication system used by the project team. We listed typical

problems that the project manager may have to face during the project. These are the

sorts of problems that most projects present during execution and which therefore have

to be watched for so that the project can be brought back under control.

Having studied this introductory section, you should now be able to:

c list the main types of activity that the project manager performs

c explain what is meant by mobilisation

c list typical problems likely to be encountered during execution and explain how

monitoring and contingency planning are likely to help overcome them.


2 Project monitoring and control

This section shows you what is meant by controlling a project. Techniques for

measuring the status of the project, including the use of milestones, periodic reports

and reviews, are discussed.

2.1 Elements of project control

A classical control loop, such as the equipment for controlling temperature in a room,

consists of measuring the value of the parameter you want to control, comparing that

value with what is wanted and taking appropriate action if there is any discrepancy.

Controlling a project is somewhat similar, though more complicated, as illustrated in

Figure 2.1.

What is controlled is the project itself. Unlike a simple control loop the project has

many variables contributing to its status. Because work progresses on a number of

activities simultaneously its status is multidimensional, and what you would like to

know about it may be difficult to measure.

In principle, the project manager compares all the current status measurements with

their desired values (as set out in the project plan documents). If there is any

discrepancy the manager signals the project team who take actions, and so change

project status to bring it closer to what is wanted.

Unlike the classical controller which simply increases any corrective action according to

the difference between the desired state and the actual state, the project manager must

use a great deal of skill and judgement in deciding what actions to take. There is a

similarity with the automatic controller which we want to emphasise – before taking

action the project manager must compare the desired and actual states. The control

loop cannot work unless the project manager knows both these quantities.

The desired status is of course continually changing as the project progresses, and is

the planned status at the current moment. So, for example, after six months’ work on a

two-year construction project you would compare the construction achieved with the

planned status at six months before deciding on the appropriate signals to the

constructors. The plans themselves will be continually evolving and the revised plans

will be part of the communication to the project team. At the end of the project the

desired status is fulfilment of the contract requirements.

desired status(plans)

project manager project team the project

measuring devices

output

disturbances (unforeseen problems)

detect disturbances

supervision actions

status measurements

Figure 2.1 Project control loop


Actual status may be measured through such devices as reports and progress

meetings, and these will be discussed in more detail later. As in many control loops

there are problems with accuracy and time delays, so some measurements of status are

exceedingly difficult to make.

Anticipation

A feedback control loop is good enough for most purposes but control engineers can do

even better with a technique called feed-forward control. This amounts to detecting

sources of disturbance, such as draughts in a room, and taking action in anticipation of

their effect, such as raising the heat input before the temperature has dropped. Project

managers can do the same.

A project manager using feed-forward control tries to counteract disturbances on the

project or on the project team by anticipating the effect of those disturbances and taking

action early. This is more difficult than feedback control because it requires timely

awareness of impending trouble. This is a technique that has been in use for centuries,

as the following passage from Machiavelli (1513) shows:

When trouble is sensed well in advance it can easily be remedied; if you wait for

it to show itself any medicine will be too late because the disease will have

become incurable. As the doctors say of a wasting disease, to start with it is

easy to cure but difficult to diagnose; after a time, unless it has been diagnosed

and treated at the outset, it becomes easy to diagnose but difficult to cure.

(Translated by Bull, G., 1970, p. 39)

So, if you are getting a bit worried or concerned about your current project, it might be

a good idea to carry out some form of ‘health check’. A project health check is an

assessment of its state with respect to its intended deliverables and processes in the

environment in which it is being executed. The assessment is often based on the

success criteria and the critical success factors, which were identified in Section 5 of

Unit 1, and recorded in the business case for the project (see, for example, Buttrick,

2005, pp. 447–51). Just as going to see your doctor may improve your health, an

independent project health check may improve the likelihood of the project being

successful.

Changes to the plan

The control scheme outlined in Figure 2.1 is an over-simplification in several ways,

one of which is that the plans themselves are continually subject to change. Ideally, the

objective specified in the contract would remain fixed and the initial plans would prove

to be adequate for the duration of the project. Unfortunately this is rarely, if ever, true.

Changes in the plans will almost always occur because of changes in the client’s

requirements, because of imperfections in the original plans or because of unforeseen

difficulties in executing them.

No project manager likes changes during the execution of a project because any

change usually increases both the cost and the duration of the project. Even when a

change appears to be beneficial, such as a reduction in the scope of the project, the

team can become demoralised – for example, if design work already completed has to

be abandoned. Project managers therefore usually have good reason to resist change

unless the case for making it is strong.

Some people hold the view that a contractor may actually welcome requests for change

from a client because changes represent an opportunity to charge the client extra. The

client is often unable to obtain competitive bids because the contract has already been

placed, so the contractor is apparently in a good position to make profit on the work

involved. While recognising the validity of this point when the scope of the changes is

sufficiently small for the contractor to accommodate them easily, it is the course team’s

See the course websitefor some moreinformation on projecthealth checks.


view that the cumulative effects of numerous changes will often be disastrous to the

execution of the project. The effects of large numbers of changes are well illustrated by

the Channel Tunnel project in which the contractors claimed that they had ended doing

a very different job from the one originally contracted for, from which arose much of the

delay in the tunnel opening.

In spite of the disadvantages, changes are inevitable if a project is to take advantage of

new opportunities, to adapt to changing circumstances or to avoid problems arising

from unforeseen events. Consequently, the project manager must set up procedures by

which all proposals for change, whether originated by the client or by the project team,

are carefully examined for their impact on the project. Such changes are then only

accepted if on balance they are predicted to be beneficial when account has been

taken of all the consequences. We shall return to consider this in detail in Sections 3 and

4 of Unit 6.

2.2 Measuring project status

Gathering the informationA large part of what a project manager has to do is to gather information about the status

of the project so that the appropriate control actions can be taken. There are many ways

to do this: team meetings, regular reports, small meetings on specific topics and

informal and casual discussions. These methods complement each other in giving the

information in different ways but vary in reliability and accuracy.

The project manager wants information to be:

c timely

c clear

c relevant

c accurate.

Not all the methods of acquiring information will be equally good on all these points. The

periodic reports may be designed to be clear and accurate, but if something happens

just after a periodic report has been submitted the project manager needs to know it; it is

much more relevant and timely to hear about this informally – though perhaps not

entirely accurately – from a communicative member of the team. This communication

can then be followed up by more purposeful enquiry.

The need for full up-to-date information has to be set against the provision of that

information imposing too heavy a burden on the project team and, indeed, on the project

manager who could become overloaded with too frequent and too detailed reports.

Ideally all the information received is relevant to the impending decisions and actions.

Improving accuracy: milestones within activitiesOne way to improve the accuracy of progress reporting is to use activity-level

milestones. We noted before that at the planning stage it is necessary to identify

milestones applicable to the project as a whole. We are now talking about a lower level

of detail: milestones within an activity. Activity-level milestones allow finer resolution

when measuring the position and improve the accuracy of the report. They may be

defined shortly before the activity is started or possibly as the first step within the activity

rather than at the outset of the project. Example 2.1 illustrates typically why these

intermediate milestones are necessary.


Example 2.1

An engineer was to design a piece of equipment, a task that she estimated

initially would take four months. She was issued with a work assignment at the

beginning of the year which specified the scope of the work quite precisely in

terms of the deliverables which she was to hand over at the end of April. At the

end of the first month she thought that as she had estimated four months for the

total job she had probably completed about a quarter of the work. Her

subsequent monthly progress reports appeared as follows:

January: Design 25% complete

February: Design 50% complete

March: Design 75% complete

April: Design 90% complete

May: Design 95% complete

June: ?

Presumably the job was eventually completed! The point of this story is that the

engineer had no yardstick against which to measure her own progress. She was

not being fraudulent but, like many an engineer, optimistic. Only when the well-

defined delivery point approached did she realise that the design was less than

100% complete. It is exceedingly difficult to determine when a piece of work is

25% or 50% complete.

It would have been preferable if the work could have been divided into several phases,

not necessarily four equal one month’s work, but phases which the engineer could

recognise as finished or not finished. The monthly reports would then have been able to

show which of these phases had actually been completed. The estimating by the

engineer concerned would be virtually eliminated.

There is an additional productivity advantage to having these activity-level milestones

because it is human nature to work a little harder as a deadline approaches. Deadlines

concentrate the mind.

Depend upon it, Sir, when a man knows he is to be hanged in a fortnight,

it concentrates his mind wonderfully.

(Dr Samuel Johnson, in a letter to James Boswell, 19 September 1777)

This might lead you to decide that all work must be broken down into as many

identifiable stages as possible, each with well-defined milestones, preferably with

deliverables specified. Indeed, why stop at monthly stages? Why not split the work into

weekly or even daily tasks? But clearly this can be taken too far. Consider the

disadvantages of excessively detailed breakdown. Close monitoring may be so irritating

to the engineer that she hands in her resignation. The monitoring itself costs time and

effort, and it may well be impossible to plan such detailed milestones. However, Boddy

and Buchanan (1992) in describing high-performance methods for fast-track projects

identify that short daily meetings enhance productivity, maintain project momentum and

are viewed positively by the team. This is a good way to track project progress but

avoids having to plan the work using daily milestones! The various Agile Methods that

are now used in software development have incorporated the notion of frequent

meetings for the benefit of their small teams as well as the following factor (Cohen et al.,

2004):

In fact, Agile is based on close interaction with the customer and expects that

the customer will be on-site to provide the quickest possible feedback, a critical

success factor.

(p. 67)


Probably the optimum is just enough milestones to enable corrective action to be

taken if slippage occurs. As a general rule each individual assignment should not

exceed more than about four weeks and some project managers would prefer fewer

weeks on short or fast-moving projects. For junior staff the optimum period between

milestones is probably about a week. In practice, a project manager might apply a

constraint so that there will be no activity with an overall duration of more than two

reporting periods, so that the first progress check has the chance of identifying any

slippage.

ACTIVITY 2.1

Suppose the project manager anticipates the problems of monitoring the four-month

assignment in Example 2.1 and asks the engineer to provide a more detailed breakdown

of the work to be done. She replies that as she has not yet started the design she cannot

yet give such a breakdown. How might the problem be resolved?

Discussion ............................................................................................................

Probably the best way forward is to schedule the first task within the design activity as

the top-level design, from which one of the deliverables is the plan for the remaining

detailed design. When this top-level design has been completed the engineer may need

to discuss the plan with the project manager so that the subsequent milestones can be

identified. The essential point is to achieve some early partitioning of the work into

recognisable modules.

Periodic progress reportsThe traditional tool of management for measuring the current position is the periodic

written report made monthly or weekly. The project manager needs such routine reports

on the cost, the effort expended and the progress of each element in the work

breakdown structure. The estimated progress for each activity is generally recorded as

‘% complete’, which was illustrated in Example 2.1 by using activity-level milestones.

Gathering the data for cost and effort reports is a routine function in most organisations

when managing continuous operations but particular attention to these reports, and

especially their timeliness, is more necessary when managing a project.

To be immediately useful the reports need to be presented to the project manager

classified under headings that correspond to the work breakdown structure. This

may or may not coincide with individual staff assignments. A collating job may be

necessary, so that valuable time is not wasted chasing reports, extracting the

relevant information and organising it. Keeping the reporting system relevant and

timely is a part of the job of a project administrator or a project control officer.

Timeliness

Timeliness cannot be overemphasised. The purpose of the periodic reports should be to

help the project manager to become aware of problems early. (Remember the

advantage in the control loop of feed-forward control.) Reports are often submitted too

late and processed too slowly to be useful.

Reporting by exception

A project manager needs to make the reporting requirements clear at the beginning of

the project. One way to encourage useful reports is to prescribe a standard report form

with suitable space allocated to what the project manager really wants to hear about.

Essential items on the report are not only what the expenditure, effort and progress have

actually been but also what they were planned to be. (Remember that control requires

comparison with the desired value.) The best kind of report will highlight those items


which differ significantly from the plan. This is called reporting by exception: ‘Everything

is on schedule/within budget except ...’. Forecasts of future problems are particularly

useful.

Progress reports are often uncommunicative. Their authors usually regard them as an

extra chore and a burden that they would rather not have, and their purpose is not

recognised: they become bland statements of business as usual, phrased

comfortingly to stop questions being asked. The reporting process can also be seen

as threatening and cause team members to exaggerate the work done. To overcome

these problems it is essential that the report writers are encouraged to report

accurately and honestly and get helpful feedback.

If the writers think that the reports are just filed for the record then naturally they regard

them as an annoying overhead activity, preventing them from getting on with their real

work. If, however, there is some response such as ‘I see there are problems with the

design of the communications system’ or ‘Glad to see the conveyor looks like coming in

under price’, then the team member is likely to write future reports more willingly,

especially if it is seen as a way of gaining help with problems and recognition of good

work. It may be helpful to discuss issues arising from the reports at review meetings

(which we shall discuss shortly). If this is to be done then the timing of meetings should

be arranged so that there is a recent set of reports available.

SAQ 2.1

List six uses to which a project manager might put the regular reports.

Electronic reporting

It is worth considering whether written reports are needed at all. Access by all team

members to an electronic information system can alleviate some of the drudgery

associated with preparing a written report, especially if that report needs to be

combined with others and edited for senior management. Shared access to a project

management information system has the advantage of providing much quicker

communication than is normal with periodic written reports and still allows the report to

be formally recorded in the system when such formality is needed (see, for example,

Meredith and Mantel, 2006, pp. 520–4).

An electronic system makes it much easier to create standard templates for reporting

project performance information and to process the information in different ways.

A database of status information can be updated by authorised users of the system and

interrogated by all the team members (not everyone will necessarily have access to all

the data). Technology can be used in many ways to create and distribute project

performance information. For example, many teams use a project website to

communicate with stakeholders and web logs (or blogs) to share information within the

team. Links can be inserted in Gantt charts created by project management tools to

documents with relevant information, such as cost estimates, risk logs or change

requests.

ACTIVITY 2.2

Consider ways in which technology could be used in your project work to create and

distribute project performance information. What are the advantages and disadvantages

of each approach? How familiar are each of the stakeholders in your project with

technology? Make notes to this effect in your project notebook.


Progress review meetingsThe project manager will require progress review meetings so that key members of the

project team can communicate regularly with each other as a group. The progress

review meeting allows the team to hear how other parts of the project are progressing

and to decide how problems affecting more than one section may be resolved.

(A progress review meeting is distinct from a quality review of the work, discussed

later in Unit 6.)

The progress review helps not only to highlight problems but also to establish the

commitment of the team to work together to achieve a successful outcome. A good

project review meeting fosters a team spirit; a bad one increases rivalry and induces

pessimism.

Review meetings are expensive. There may be half a dozen highly paid people in

attendance, so it is important to avoid spending too much time on routine reports, or on

matters which are of concern to only one or two members of the group. The project

manager, who normally chairs these meetings, should organise the business so that

routine reports are dealt with quickly and sectional concerns are discussed outside the

meeting. All documents should be circulated to participants some time before the

meeting.

A good progress review meeting consists of not just a series of dialogues between the

manager and individual team members but also involves discussions among several of

the team members on each topic. If a dialogue seems to be developing to the exclusion

of others, discussion of that topic should be cut short and continued outside the

meeting.

An important outcome of the progress review is that a number of actions should be

agreed by the team and specifically by individual members of the team responsible for

carrying them out. The public commitment to these actions in a progress review meeting

is a significant element. These commitments are recorded in the minutes which should

be circulated promptly after the meeting. The next meeting should review actions to see

what progress has been made. A useful technique is to arrange for the issue of an

actions list for each person along with the minutes so that the actions are less likely to

be overlooked.

In a large project, review meetings are required at lower levels to review progress on the

activities of different groups or sections within the project. Often these are conducted by

the members of the progress review team, so this is an opportunity not only to review

progress within the section but also to report on higher-level meetings to ordinary team

members. The lower-level review meetings are often more informal and may not

necessarily use minutes. Even if minutes are not taken, it is beneficial to record the

actions and decisions in some way, perhaps by a note pinned to the section notice

board or some form of electronic communication to the participants (common practice

for distributed teams these days!).

An issue that may arise is whether it is good for the client to be represented at the

internal progress meeting which the project manager holds with the team. Some clients

insist on being present, but if they do not, should the project manager encourage them

to come? The advantage is that it closes the communication gap between the team and

the client so that the client has a better understanding of what is going on and the team

will get a quicker reaction to questions raised. The disadvantage is the danger of

suppressing problems and inhibiting open discussion. The balance may depend on the

personalities of the people. Given the right client representative there is everything to be

said for it.


Informal discussionsInformal and casual discussions are a vital source of information to the project manager.

A manager who is sufficiently approachable will get to hear of problems much sooner

than one who relies only on regular reports and reviews. An approachable manager who

regularly makes informal contact with all members of the project team will have much

better knowledge of the true state of the project than one who gathers information only

through formal channels. This takes time, however, so a project manager must take care

not to become so overloaded with routine business that there is no time left for these

invaluable informal contacts.

2.3 Closing the loop

Gathering the information about the project status is only half the job required for control.

The other half is:

c evaluating the information

c taking action

c checking that the action has worked.

The action required will usually be to get some member(s) of the project team to do

something. This was the thrust of much of Unit 4. When the status information of the

project is less than satisfactory the project manager uses leadership skills to effectively

resolve the situation. If something is wrong then the next step is to decide, perhaps with

the team, what to do about it. And then do it!

To quote from a comment given by an engineer who was responsible for project work

in Matthew Hall Engineering in a case study for a previous Open University course:

Progress monitoring can be achieved in many ways according to the scale

of the contract, but the objective is always to provide management and

supervisors with the information they need to control that task. Monitoring

must never be confused with control nor knowledge be mistaken for action.

It warns management of deviations from plan so that corrective action can be

taken, but successful control relies on the skill and experience of the project

manager and supervisors.

The control loop is closed by taking action and then monitoring again what has

happened to the project. The regular cycle of monitor–control–monitor again is

the control loop of project management.

2.4 Summary

The control of a project can be compared to a feedback control loop. Control requires

both a definition of the desired status (a plan) and also a measurement of the actual

status. Control may be improved using a feed-forward technique: anticipation.

Project managers need status information that is clear, accurate, relevant and timely.

Activity-level milestones improve accuracy. Techniques for measuring the project

status include periodic reports, progress reviews and informal day-to-day contact

with members of the project team.

It is not enough merely to gather data. The data must be evaluated to check for its

reasonableness, and when necessary control action must be taken.


Having studied this section, you should be able to:

c describe the elements of project control

c explain in what ways the project manager improves on the simple classical

controller

c describe several ways in which the project manager gathers and distributes

information about the state of the project

c explain what is meant by closing the control loop.


3 Monitoring the cost and schedule

In this section we review several methods used by project managers to monitor

progress against the schedule. These methods include updating the project network

and milestone tracking. We also introduce the earned value method to measure the

current cost of the project and relate it to the achievements so far, so that an estimate

is continuously available for the cost of the project at its completion. We introduce a

number of cost control terms and show how the earned value method can also be used

to estimate overall performance against the schedule.

It is important to track progress on activities and compare this with the project schedule

and to track expenditure and compare it with the project estimate. As tasks are

completed late, on time or – more rarely – early, the schedule needs to be updated and

similarly tasks completed over budget, on target or – more rarely – under budget must

be incorporated into the current project estimate. Tasks not foreseen in the original plan

must be incorporated into both the schedule and the project estimate.

All this will tell the project manager where the project is and help to keep moving

towards the goal. Such tracking also gives us early warning of problems, thereby

allowing us to take corrective action. We discuss controlling the cost and maintaining

the schedule in Section 4.

3.1 Updating the schedule

The preferred method for estimating the date at which a project will be completed is to

update the project network diagram to reflect the current position. Using current data on

the progress of each activity, the calculations of all the earliest event times can be

repeated, but starting from the position as it is now known to be. This requires only the

durations of activities to be updated and need not involve redefining the network unless

there has been a change in the logic of dependencies.

If a computer planning package is used it should be a fairly straightforward task to

update the durations and recalculate all the event times. In this unit, the extent of

completion of an activity is shown by doubling the normal activity arrow (i.e. drawing two

parallel lines for its shaft) appropriately – along the whole length of a completed activity

or along a proportional part of its length for a partially complete activity. Completed

activities could, of course, be deleted from the network and replaced by a start node

representing the present time. This could be worthwhile at a late stage in a project to

simplify the resulting diagram. However, it is often convenient to retain the historical part

of the network to show the complete picture and to avoid redefining it.

The results of updating the activity-on-arrow or activity-on-node network could of course

be presented in the form of a Gantt chart, which is more understandable to most people.

A technique of showing completed work by a different colour or shading of the bar can

be used. Figure 3.1 shows an updated Gantt chart; the original plan has been baselined

as shown by the single line underneath the activity bars. The current date is shown by a

vertical line at the end of the week commencing 5 July. As the project is currently on

schedule all activities up to the current date have been completed and will be shown in a

single colour, for example green. Activities partially complete and not yet started at the

current date will be shown in the colours representing critical and non-critical activities

(usually red and blue). The updated Gantt chart helps the project team and


stakeholders to see the current position, the estimated completion date and any

divergence from the original baselined plan.

Example 3.1

Consider the project of installing a new oven discussed in Unit 3. The original

planned schedule based on the earliest start dates showed a latest project

completion time of 11 weeks. Suppose that the work for this project has gone

disastrously awry! After 7 weeks’ work on the project, the installation of the oven

is only half complete. The start of the installation was delayed because the

preparation of the plinth took 4 weeks instead of the planned 3 weeks and the

duration is now estimated to be 6 weeks instead of the original 4 weeks owing to

an error in the estimate. There have also been problems with the installation of

the piping which took 6 weeks instead of the planned 4 weeks. The activity ‘lay

cables’ is now ready to start after a delay of 5 weeks in the delivery of materials.

Only the installation of the trunking was completed according to plan!

Figure 3.2 shows the revised network based on current progress, with

calculations to provide a new estimate of the project completion time. The

revised network shows a new project completion time of 14 weeks. Since the

activities ‘prepare plinth’ and ‘install oven’ were both critical activities the project

completion date has slipped by the additional 2 weeks which will be needed to

complete the activity ‘install oven’ and the 1-week delay on the activity ‘prepare

plinth’. Since the activity ‘install piping’ had free float of 3 weeks the delay of

2 weeks on this activity has had no effect on the project completion date.

Fortunately, owing to the delays on the critical path, the delay in the activity ‘lay

cables’ will also have no effect on the project completion date. Double arrows

are used to represent completed or partially complete activities.

The initial network is as in Figure 4.15 of Unit 3, reproduced below as Figure 3.3.

Figure 3.1 Updated Gantt chart for the water supply project


SAQ 3.1

Suppose the project manager of the oven project investigates the cause of delays

in the installation of the oven after 7 weeks’ work on the project and finds that the

problem was caused not by an error in the estimate but by the unavailability of the

correct fastenings for the oven and plinth. All the parts have now been delivered and

the installation of the oven should now proceed as originally planned. What will be

the revised duration for the activity ‘install oven’ assuming the remaining work is

completed at the originally planned rate?

Derive the revised estimated completion date for the project assuming all remaining

work is completed at the originally planned rate.

Revising versus updating the scheduleSo far we have discussed how the project manager will update the schedule from

information gathered on the status of the project at regular reporting intervals. The

project manager uses experience on the project so far to predict the rate of progress

of future work. The project manager monitors the work and updates the schedule to

identify and communicate progress on the project so far. We shall discuss how the

project manager uses the information gathered to control the work in Section 4.

However, when major changes occur in the project – for example, a change in

requirements or a change in the design approach – then the original schedule is

2

4

5install trunking

prepare plinth1

10

00

102

3

2

44

34 2

8

7 1010

6 1011

8 1212

9 1414

complete/partiallycomplete activity

critical activity

2

test system

2

connect electrics

1

connect pipes

6

install piping

5

delay

2

lay cables

6

install oven

Units: weeks

other activity

Figure 3.2 Updating the activity-on-arrow network for the new oven

2

3

2

3

5

6

7 8

install trunking lay cables connect electrics

prepare plinth install oven test system

4

2

install piping connect pipes

4

1

Units: weeks2 2

1 4

nodeidentifier

earliest event time

latesteventtime

2

3

7

7

9 110 7

5

3

7

8

9 110 7

Figure 3.3 The initial network (Figure 4.15 from Unit 3)


no longer valid and the project manager will need to re-plan the project and produce a

revised schedule rather than update the original schedule. We shall discuss the

problem of controlling change in project work in more detail in Unit 6.

3.2 Milestone tracking

Senior management may prefer to be given a less detailed picture of progress that

concentrates on recording the rate of progress past the milestones. Milestone

tracking is a way of removing the detail and recording how dates for the milestones

have evolved during the project. This method has the advantage of being able to

show at a glance not only the present status of milestones but also the evolution of

that progress over the life of the project so far.

Let us see how milestone tracking would work on a project with five milestones. The

milestones represent significant events at which progress might be recorded. In the

oven project, shown in Figure 3.2, these might be events such as ‘cabling installed and

ready for connection’ (network identifier 5) or ‘oven installation complete’ (network

identifier 7). These would be reasonable candidate milestones. Suppose that the

milestones for a project have been well defined and that, in conformance with an earliest

starts schedule, their planned dates are as shown in Table 3.1 where we have assumed

that the project is due to start on 6 March and finish on 24 July. All days in the week are

working days.

Table 3.1 A project with five planned milestone dates

Scheduled date

A 6 March

B 10 April

C 29 May

D 19 June

E 24 July

During the project there will now be regular reports showing the dates at which

milestones were actually passed and giving revised predicted dates for those which

have yet to be passed. A milestone tracking chart as it would appear at the end of the

project is shown in Figure 3.4.


The chart evolves line by line during the life of the project. At the beginning of the project

the dates have been set for the milestones, as shown in Table 3.1. The positions of the

five planned milestones have been plotted across the chart as shown by the inverted

triangles containing the letters A, B, C, D and E. For example, letter E is positioned at

24 July, the scheduled completion date of the project.

To follow the evolution of the chart, take a piece of paper and cover up everything in the

chart below the line of planned milestones. Now imagine that there are reports at

fortnightly intervals showing new milestone dates. The dates of the reports are listed

down the left-hand side of the tracking chart. If you move your piece of paper down one

row at a time you first uncover the report for 6 March which might say that the project

had been started and that the predicted dates for all the other milestones were on

schedule. This is plotted on the chart by the black dots showing the new dates for each

milestone as at 6 March. Now move the paper down to expose the report on 20 March.

All milestones remain unchanged. But if you uncover the next report, on 3 April, you will

note that milestone B is now predicted to be delayed by one week – the dot representing

its position has moved one week to the right, to 17 April. All the other milestones are

predicted to be at their original dates. Uncovering further reports you will find that

milestone B is duly passed. It was last predicted to be passed at 17 April and the ringed

dot at milestone date 17 April for the report of 17 April confirms that it is duly passed.

There will be no further reports on milestone B after 17 April, which explains why the

chart has a diagonal line running across it. Clearly there can be no change in the status

of a milestone in reports made after the finally achieved milestone date. If you continue

to move your paper down to expose further reports you will find that further slippage of

other milestones is reported on 15 May and on other dates later on. On 10 July, it was

planned milestones

predicted milestone dates

actual milestone dates

AugustJulyJuneMayAprilMarch

75136 141281013 2119151720 2826222427 3129 3 10 17 24

March

6

20

April

3

17

May

1

15

June

12

26

July

10

24

August

7

21

29

A B C D E

finalslippage

Figure 3.4 Milestone tracking chart (after Archibald, 2003, p. 345)


reported that milestone D achieved its rescheduled date, but milestone E had slipped a

little more. The final milestone report on 21 August shows the project was completed

when milestone E was passed at 14 August.

SAQ 3.2

(a) In the report for 1 May, what is the date predicted for passing milestone D? When is

this milestone actually passed?

(b) For this milestone tracking method to work, is it necessary that reports are given at

regular intervals?

(c) What might you think of the status as reported on 12 June?

SAQ 3.3

What are the particular advantages of a milestone tracking chart?

A final word on milestone tracking: you may remember in Unit 2 that we discussed the

need to monitor risk throughout the project and this is generally tied to the tracking of

milestones. At each milestone the information gathered from progress meetings and

reports is reviewed in order to assess the status of the registered risks, identify new

risks, review probability of occurrence and impact of previously identified risks,

implement contingency plans and take any corrective action. Thus monitoring and

control of risk is inherently linked to key points in the project. In the oven project

monitoring risk at the milestone ‘cabling installed and ready for connection’ (network

identifier 5 in Figure 3.2), the project manager would assess the risks associated with

the installation of the oven and the potential risks associated with the connection of the

electrics. The project has suffered from many delays and there was a possible error in

the estimate for the installation of the oven (Example 3.1), so the project manager will

need to review all estimates for future work, to take action to avoid the risk of delays to

future work and even maybe to think about implementing contingency plans if the

new oven is not ready for use when required.

3.3 The earned value method

The accounting systems commonly used in a business are rarely adequate for

monitoring project costs. You saw in Unit 2 that there might be a conflict between

the cost classifications used in a project and an organisation’s standard accounting

practices. For example, in most businesses material and labour costs are not usually

recorded in the precisely attributable way that is required for project control, and often

the reports from the accounting system are not available in time for the manager to

exercise any control. Furthermore, it is rare in a non-project business to record the value

of work achieved alongside the cost of achieving it. Measurement of expenditure alone

is almost useless in a project: it is essential to know what has been achieved as a result

of this expenditure.

The consequence of these deficiencies of standard accounting systems is that many

project managers have to set up their own system for monitoring and controlling project

costs and achievement. The system that we describe here is called an earned value

system, because it seeks to show the manager not only the planned cost of the work

and the actual cost of the work performed so far but also the value earned by that work.

These systems are now quite common in organisations that do projects and some

clients may insist on using such a system.


Budgeted cost of work scheduledTo be able to compare achievement with the plan in cost terms we need to know the

planned profile of expenditure for the work: this is called the budgeted cost of work

scheduled (BCWS), sometimes called planned value (PV). The graph of BCWS against

time can be plotted at the outset of the project once the cost of each activity has been

estimated and a schedule has been produced showing when each activity is to be

performed. By adding together the amount to be spent on all the activities each week,

the total rate of expenditure on the whole project can be predicted from start to finish.

These weekly or monthly amounts of planned expenditure can be added up to give a

scheduled cumulative achievement in cost terms, the budgeted cost of work scheduled

(BCWS). Figure 3.5 shows the planned profile of expenditure against time for the project

(BCWS) – sometimes called a time-phased budget. Note that the final value for BCWS is

equal to the project budget (PB) at the scheduled completion date (SC) for the

project.

To calculate BCWS we need to know three things: the budgeted cost of each activity,

the time at which that activity is scheduled to be performed and the spend profile within

each activity. The budgeted cost should be available from the estimate and the

scheduled time can be found once each activity has been given a scheduled start time,

not necessarily the earliest start time. It will often be accurate enough to assume that the

rate of expenditure is constant during the activity, although a different profile could be

used if this was believed to reflect the nature of the activity better.

The planned schedule need not necessarily correspond to starting activities at their

earliest start. We noted in Unit 3 that the smoothest possible resource profile will often

require activities to be postponed. For planning purposes it is possible to calculate two

extreme BCWS curves, one assuming earliest starts and one assuming latest starts, as

shown in Figure 3.6. These two extremes show the limits between which any chosen

BCWS curve must lie. The actual BCWS will depend on what schedule the project

manager chooses.

scheduledcompletion (SC)

project budget (PB)

BCWSproj

ect c

osts

time

Figure 3.5 Planned profile of expenditure (BCWS) against time


Example 3.2

Table 3.2 gives the information we need in order to compute the value of BCWS

throughout the computer project (introduced in SAQs 4.10 and 5.1 of Unit 3)

and to be able to plot the graph of BCWS against time. From Table 3.2 we can

see that the project duration is 60 weeks (the final activity H has a start time of

50 and duration of 10 weeks) so it would be reasonable for the project manager

to monitor progress at 5-week intervals throughout the project (based on the

durations in Table 3.2). We will also assume that the rate of expenditure on each

activity is constant throughout its duration and that each activity will start at the

scheduled start time in the table (the project manager has already chosen to

use an earliest starts schedule).

Table 3.2 Scheduled expenditure on computer project

Activity Description Budgeted

cost (£000)

Start

time*

Duration

(weeks)

A design hardware 20 0 20

B build hardware 40 20 20

C procure test facility 10 20 10

D test hardware 4 40 5

E design software 30 0 30

F code software 26 30 20

G design tests 5 30 5

H test system 15 50 10

*NB These are times measured in weeks from the start of the project (not the same as week numbers).

The problem of denoting time in week numbers rather than elapsed time was discussed in Subsection 4.5

of Unit 3.


project budget (PB)

BCWS earliest starts

proj

ect c

osts

time

BCWS latest starts

Figure 3.6 Range of possible BCWS curves within which the planned BCWS must lie


Table 3.3 shows the expenditure on each activity in each 5-week period in thousands of

pounds. For example the expenditure on activity A, designing the hardware, is £5000 in

each of the first four periods. The value of £5000 is calculated from the given budgeted

cost of £20 000 together with the known duration of 20 weeks, i.e. four periods. The

values for the total expenditure in the period are calculated by adding up the entries in

each row. Thus in the row for weeks 1–5 the total is £5000 + £5000 = £10 000. The

cumulative BCWS is the total expenditure so far. Notice that the final value of BCWS

is £150 000, the project budget, as you would expect.

Table 3.3 Calculations of BCWS for computer project

Weeks Expenditure on each activity Total

expenditure in

period (£000)

Cumulative

BCWS (£000)A B C D E F G H

1–5 5 5 10 10

6–10 5 5 10 20

11–15 5 5 10 30

16–20 5 5 10 40

21–25 10 5 5 20 60

26–30 10 5 5 20 80

31–35 10 6.5 5 21.5 101.5

36–40 10 6.5 16.5 118

41–45 4 6.5 10.5 128.5

46–50 6.5 6.5 135

51–55 7.5 7.5 142.5

56–60 7.5 7.5 150

The graph of BCWS against time is shown in Figure 3.7. Note that the curve is not very

smooth; the changes in slope occur where there is a start or finish of an expensive

activity. If there were a larger number of activities starting at more random times the

curve would be smoother. In large projects using the basic project life cycle the graph of

BCWS is represented by a typical S-curve as shown in Figure 3.5. In the early stages of

a project, during mobilisation, few resources are required. In the middle of the project,

during execution, most resources are needed and towards the end fewer resources are

needed during installation and handover. In a project using a phased life cycle or

prototyping life cycle, the graph of BCWS is represented by a series of

S-curves. Each phase is a mini-project requiring fewer resources.


Although BCWS is usually measured in terms of cash it is really a measurement of a

quantity of work. An equally valid unit of measurement would be person-days if this unit

were applicable to all the work done on the project. (The trouble with person-days is that

this may not be costed the same for all people, but you may be prepared to tolerate

such an inaccuracy if it is more convenient to measure days.)

The use of the word work might also be taken to imply that we are only interested in the

labour aspects of the cost of a project and, in practice, earned value is most often used

to monitor just the cost of labour. However, the budgeted cost for an element of the WBS

will often be subdivided into categories such as labour, materials, equipment and

subcontracted work. Each of these categories can be analysed separately if the

information is available so that, for example, cost overruns can be identified as due to

higher equipment costs rather than staff costs. To keep the following discussion simple,

we shall not keep referring to each category separately but you should appreciate that

project costs would probably be broken down so that, were we to consider the work

done on a project as a whole, the same arguments would normally apply to these

individual categories separately.

Note that the budgeted costs required in these calculations should not include any profit

or loss element. The values should represent costs in a way that will be consistent with

the reported actual costs. So, for example, if staff costs are to be reported at standard

rates regardless of actual salaries then these are the costs that should be used in

calculating BCWS. Similarly, if staff costs are expected to rise with inflation then the

values of BCWS should be similarly inflated. For simplicity we shall not include the

complicating factor of inflation in any of our calculations.

SAQ 3.4

(a) Why can the slope of the BCWS curve never be negative?

(b) Will the BCWS curve change at any time throughout the duration of the project?


project budget (PB)co

st (£

000)

weeks

150

125

100

75

50

25

0 5 10 15 20 25 30 35 40 45 50 55 60

Figure 3.7 BCWS for computer project


Budgeted cost of work performedThe earned value (EV) of the work performed on a project is the cost that the

estimator attached to that work when the project budget was defined. Another term

for it which is rather more explicit is the budgeted cost of work performed (BCWP).

This is the term we shall employ in this course but it is interchangeable with earned

value. The budgeted cost of work performed up to any particular time during the

project can be calculated by adding up the component values of the elements of

work that contribute to the project, taking account of the fractional completion of

each element at that time.

When BCWP is based on the agreed budget for each element of the WBS, the

calculations can require a table of several pages. However, to show the principle, let us

take the new office system considered in Sections 4 and 5 of Unit 3, broken down into

only six activities. (The activity identifier would normally be the WBS reference but for

brevity we have used the letters A to F.) Suppose the budgeted values of each element,

agreed at the estimating stage of the project, are as shown in the third column of

Table 3.4. The contribution to budgeted cost of work performed of each element is then

calculated by multiplying the budgeted cost of the element by the fraction of the work

that is complete. The BCWP for the whole project is the sum of the individual elements.

Table 3.4 Tabular progress report showing calculation of BCWP for a new office

system

Activity

identifier

Description Budgeted cost of

element (£000)

%

complete

Contribution to

BCWP (£000)

A prepare offices 100 50 50

B procure equipment 200 50 100

C design tests 50 25 12.5

D install equipment 20 0 0

E test system 30 0 0

F train users 10 0 0

total 410 – 162.5

If, when the project manager monitors progress, milestones have been passed

corresponding to 50% completion of the office preparation and equipment procurement

and 25% of the tests have been designed, then the BCWP is calculated in Table 3.4 as

£162 500. (Although no breakdown has been shown within these elements we are

assuming that milestones have been defined to allow satisfactory estimates of

percentage completion to be made.) A more complete version of Table 3.4 would show

work packages subdivided into work elements, most of which would be either 0% or

100% complete, leaving the partial progress on only a minority of elements to be

assessed more subjectively.

It may be argued that subjective assessment of the fraction complete is so unreliable

that the only valid approach is to report work as being in one of only three states: not

started, started but not complete, completed. From this it is then possible to calculate

the lower and upper bounds for the value of BCWP. The lower bound, the minimum

value of BCWP, is calculated by taking zero as the value of fraction complete for all

partially completed elements. The upper bound, the maximum value of BCWP, can be

calculated by taking the fraction complete as 100% for the partially completed elements.


SAQ 3.5

Assume that progress on the computer project (the BCWS curve for this project is

shown in Figure 3.7) is as given in Table 3.5, where we have used the simple three-state

method of reporting described above.

(a) Calculate the range within which BCWP must lie.

(b) Is it reasonable to take the average of the lower and upper bounds as the actual

value of BCWP?

(c) What additional milestones will be required in the partially completed activities if

BCWP is to be known at this stage to within 10% of the total cost of the project?

(d) What will be the value of BCWP at the end of the project?

Table 3.5 Status of elements in the computer project

Activity

identifier

Description Budgeted cost

(£000)

Status

A design hardware 20 completed

B build hardware 40 completed

C procure test facility 10 completed

D test hardware 4 partially completed

E design software 30 completed

F code software 26 partially completed

G design tests 5 not started

H test system 15 not started

total 150

Remember that BCWP represents the accumulation of work done; it is not a rate of

working. BCWS represents the accumulation of scheduled work while BCWP represents

the accumulation of performed work. Remember that BCWS and BCWP are views of

planned costs not how much has actually been spent. We will look at actual costs later in

this section.

So, where are we now?

Schedule variance and slippage

By comparing the planned achievement with the work performed so far it is possible

to arrive at a measure of how far the current achievement differs from expectations.

The term used in the earned value method to measure this is the schedule variance

(SV). The schedule variance may be rather difficult to understand when you first meet it.

It is a measure of the work performed compared with the plan expressed in cash

terms (or whatever units are used for BCWP), not in terms of a length of time as

you might possibly have expected:

SV = BCWP – BCWS

The SV measures in cash terms how far work has progressed compared with the plan:

a positive value means it is ahead of plan, a negative value means it is behind plan.

You can remember which way round it is defined if you think that ‘positive is good,

negative is bad’. The value of SV measures how much work has been achieved at a

given moment compared with what was scheduled; it does not immediately reveal

how far the project is ahead or behind plan in terms of time. However, you can see

that such a time measure can readily be obtained from the graphs of BCWP and BCWS.


The scheduled rate of completion of the project is represented by the BCWS curve,

the budgeted cost of work scheduled. Remember that the term budgeted cost is

really a measurement of work, but is presented in cost terms in order to have a

standard unit of measurement. So BCWS represents the accumulated value of the

work which should be achieved at any date if all is performed to schedule. However,

we also have a measurement of the budgeted cost of work performed (BCWP) which

represents the work actually done in the same cost units. The time lag of one curve

behind the other at any date in the project is a measure of the slippage.

Figure 3.8 shows a typical situation. At the end of June the value of BCWP is £30 000

and BCWP has reached the value scheduled for the end of May. The current slippage is

therefore one month. At the end of June the value of planned achievement was

expected to be £40 000 but the value of BCWP is only £30 000. Hence, the schedule

variance is negative, i.e. –£10 000. It is important to appreciate that, as BCWS and

BCWP are both budgeted and not actual costs, there is no need to take any account of

cost escalation in making this calculation. This has been taken care of by using

budgeted cost in both curves.

Schedule–performance index

Some reports on project progress show an index called the schedule–performance

index (SPI). It is defined as:

SPI = BCWP/BCWS

The attraction of this index is that it is easy to compute from values which have

already been obtained without the need for drawing a graph to see how far behind

schedule the current value of BCWP is. The value of SPI will be greater than one

when the project is ahead of schedule and less than one when the project is behind

schedule. However, you probably already realise that the ratio of BCWP to BCWS at

a given time is not the same as the ratio of the time taken to achieve the same

amount of work, which is what you are primarily interested in. (If you need to be

convinced of this then try drawing some typical S-curves.) In particular, as a project

approaches completion the value of BCWP will, by definition, approach BCWS and

hence the value of SPI will always eventually approach one regardless of the length

of time that the project took. So, although this index is given here for completeness

you should treat its value with some care.

proj

ect c

osts

(£00

0)

time

100

80

60

20

0

40

DNOSAJJMAMFJ

BCWSBCWP

time now

schedule varianceslippage

project budget (PB)


Figure 3.8 SV and slippage deduced from BCWS and BCWP


Estimated completion date

We are now in a position to introduce another earned value term, the estimated

completion date (ECD). In Figure 3.8 the original scheduled completion date was the

end of December but given the progress information at the end of June the project

manager will need to revise the estimated completion date. This date will depend on

what assumption is made about the rate of working for the remainder of the project.

SAQ 3.6

Suggest two alternative assumptions that might be made, similar to those used in

updating the schedule in Subsection 3.1.

The effect on the estimated completion date of making different assumptions is shown in

Figure 3.9. If it is assumed that all remaining work is performed at the scheduled rate,

then the estimated completion date will be one month behind the original scheduled

completion date. If, however, it is assumed that the timescale for the outstanding

work has to be multiplied by the same factor as for work performed so far, then the

projected slippage is much greater. The work scheduled to be done in five months

has taken six months, so the time inflation factor is 1.2. The scheduled one-year

project will take 1.26 12 months, i.e. the estimated completion date (ECD) is

14.4 months from the start of the project. The projected slip is 2.4 months.

As the effect of different assumptions is so large the project manager needs to

choose between them and must decide whether the factors that have affected

progress so far are likely to persist or whether they are factors that belong only to

the past. The project manager must exercise their judgement according to the

apparent cause of the previous slippage.

proj

ect c

osts

(£00

0)

time

100

80

60

20

0

40

DNOSAJJMAMFJ

project budget (PB)

MFJ

BCWP

BCWS

time now

inflatedtimescale

extrapolation withno more slippage


constanttime factor

no furtherslippage

Figure 3.9 Alternative assumptions for predicted achievement


SAQ 3.7

Suppose the main cause of slippage has been identified as described below. For

each case, which of the two assumptions for completion of the remaining work do

you think more reasonable? Justify your answer.

(a) The original estimates of timescale were optimistic.

(b) Staff recruitment took longer than expected.

(c) There have been several changes requested by the client.

(d) The software design, now complete, took longer than planned.

Significance of S-curve slippage

The slippage estimated by the time difference between BCWS and BCWP is a

measure of the delay in the overall progress of the project. If the slip between two

curves is one month it cannot necessarily be inferred that each individual activity is

now one month behind schedule. The aggregation of all the components that make

up the earned value means that this earned value may have been reached by being

ahead on some parts of the work and behind on others so that the total achievement

is as reported. The value represented by BCWP is an overall measure of work done

and does not distinguish between work that it is critical to perform to reach the final

target and work that is less critical. The only way to find out whether the critical

activities are on schedule is to update the project network or Gantt chart.

ACTIVITY 3.1

Consider again the project of installing the new oven with an original planned schedule

based on the earliest start dates from the network shown in Figure 4.15 of Unit 3.

Assume, as in Example 3.1, that after 7 weeks’ work the installation of the oven is

only half complete and its total duration is now estimated to be 6 weeks instead of

the original 4 weeks. Remember that there were also delays in the installation of the

piping and the preparation of the plinth, but these activities are now complete. Owing

to more delays the activity ‘lay cables’ has not started.

(a) Plot the BCWS curve for the original (earliest starts) schedule assuming the budget

values in Table 3.6 for each activity and assuming a constant rate of work on each.

Table 3.6 Budgeted costs for the new oven project

Activity Budgeted cost (£)

prepare plinth 3000

install piping 4000

install trunking 2000

install oven 8000

lay cables 1000

connect pipes 1000

connect electrics 2000

test system 2000

total 23 000

(b) Calculate the budgeted cost of work performed after 7 weeks (when the installation of

the oven is only half complete).


(c) Use the earned value method to predict a completion date.

(d) Compare the date obtained assuming that all subsequent work is of planned duration

with the value obtained in the answer to SAQ 3.1 by updating the network. Should

you expect the two figures to be the same?

Discussion ............................................................................................................(a) The plot of BCWS is shown in Figure 3.10. If the project manager chooses to monitor

progress at fortnightly intervals the values needed to plot the BCWS curve are

(2, 6), (4, 12), (6, 16), (8, 20), (10, 22), (11, 23).

(b) The budgeted cost of work performed (BCWP) after 7 weeks is

3000 + 4000 + 2000 + 4000 = £13 000.

(c) Reading from the BCWS curve in Figure 3.10 the value of work performed

should have reached £13 000 after about 4.5 weeks. So the project is 2.5 weeks

late so far. If no further slippage occurs the project is expected to be complete

after 13.5 weeks. If, however, we assume the same time factor slippage in the

second half of the project then the project should be complete in just over

17 weeks (11 x 7/4.5).

(d) The date obtained in the answer to SAQ 3.1 was 13 weeks assuming no further

slippage occurs on the project, yet the earned value method implies that with

remaining work at the originally planned rate the project should finish after

13.5 weeks. In general you should not expect the two estimates to be the same.

In Activity 3.1 we calculated, using the earned value method, that the project will

take at least 13.5 weeks before it is completed. Yet the project completion using the

critical path was found to be at the end of week 13. So how has this discrepancy

come about and which estimate is likely to be correct?

To answer this we must consider the meaning of the calculations that have been

performed. The estimate using the network calculation depends only upon the length of

the critical path. Provided that the durations of activities on the critical path have been

correctly estimated, and provided also that activities off the critical path are not so

delayed that they become critical, then the network method should give an accurate

estimate of the completion date. The earned value method, based on the S-curves,

proj

ect c

osts

(£00

0)

time (weeks)

6

0 2

BCWS

BCWPafter 7weeks

project budget (PB)

2

4

8

10

12

14

16

18

20

22

24

4 6 8 10 12

� scheduledcompletion (SC)

Figure 3.10 BCWS for oven project


takes no account of the critical path and yields a result based on the overall amount

of work performed.

In the particular example of SAQ 3.1 and Activity 3.1 the work that has been delayed is

all on the critical path; but the activities off the critical path have also been delayed.

Hence the earned value method has overestimated the consequence of the delay for the

critical activities and given a pessimistic completion date. Note that the earned value

method may also underestimate the consequences of the delay for the critical activities

and give an optimistic completion date when activities off the critical path progress

ahead of schedule. Using the earned value method is particularly useful when there is

apparently no slippage on the critical path. Suppose, for example, that at the end of

three weeks the plinth has been installed and the installation of the oven is scheduled to

start but the installation of the piping and trunking has not started. It is possible that the

network method would show an unchanged finishing date and yet there has been

considerable loss of time in non-critical activities, so that work on all three paths at

this point has become critical. This will not matter if they can all be progressed to

meet the date of 7 weeks for event 4 given in Figure 4.15 of Unit 3 and all the

subsequent work can be kept up to schedule. Nevertheless, the earned value

method would show up this loss of time and forecast a delayed completion date.

This would be a warning signal that the project was not really progressing as

smoothly as an unchanged critical path estimate might suggest.

The network method, focusing only on the critical path, may mislead the project

manager into believing that the schedule is being maintained when in fact progress off

the critical path has been slow, and float is being consumed. Unless this consumption of

float is monitored, it could transpire that later in the project the amount of work

outstanding on previously non-critical activities turns out to be greater than can be

achieved with the available resources, and a number of new critical paths materialise.

The estimated completion date based on the earned value method is therefore a useful

measure of project progress which can probably be considered as a secondary

measure alongside the critical path calculations.

Cost variance, estimated cost at completion,cost–performance index and cost to completeWe are now in a position to introduce the earned value terms which will help us to

monitor project cost. As the project progresses, the actual cost of work performed

(ACWP) can be monitored by collecting data on the incurred costs of the labour and

materials used by the project. (Note that schedule slippage also affects the cost, but we

will deal with this issue in Section 4.) These costs must be on the same basis used for

the estimate of BCWP. So, if the labour cost in BCWP included an overhead factor for

office accommodation and administration, then the costs presented in ACWP must

either include the same factor or include the costs of accommodation and administration

if that has been measured directly. The ACWP, which is sometimes called the actual

cost (AC), can then be compared with the BCWP as shown in Figure 3.11.


The cost variance (CV) is a value that will be regularly updated throughout the project

and is the difference between BCWP and ACWP:

CV = BCWP – ACWP

(In the example shown in Figure 3.11 the value of CV will be negative because the

actual cost exceeds the budgeted cost.) At the end of the project, BCWP will reach

the agreed budgeted cost at completion (the project budget, PB), and the value of

ACWP will be the total costs incurred on the project. So the cost variance at that

time will, if positive, be the cost underrun of the project. A negative value of CV will

represent a cost overrun.

This definition of CV is the usual one used in project reporting but you may find the term

variance used the other way round, i.e. a positive variance will represent actual costs

over budget. You therefore need to be careful not to take a stated variance at face value,

but ensure that the term is being used in the sense that you expect. To remember the

way round that the term is being used in this course you may find it helps to think of a

positive CV being a ‘good thing’ and a negative CV being a ‘bad thing’ (in the same way

that we interpreted schedule variance, SV, earlier).

The estimated cost at completion (ECAC) will depend on what assumption the project

manager chooses to make about the cost of work still to be performed. One assumption

is that the work still to be performed will be done at the budgeted cost, the original

estimate. In this case the estimated cost at completion will be given by:

ECAC = PB – CV (assumption 1)

A more realistic assumption may be that the remaining work will be performed at the

same cost/budget factor that has been observed in the work performed so far. The ratio

BCWP/ACWP is sometimes called the cost–performance index (CPI). In that case the

estimated cost at completion will be given by:

ECAC = PB/CPI = PB 6 (ACWP/BCWP) (assumption 2)

The value of CPI will be greater than one when the project is under budget and less than

one when the project is over budget. Early in the project, when the fraction of work

completed is small, the cost–performance index may be an unreliable guide to the

costs of the rest of the project because it is based on insufficient data, so it is

probably better to use assumption 1 to calculate the estimated cost at completion

until at least, say, 30% of the work has been done. Later on, it is probably more

project budget (PB)

ACWP

proj

ect c

osts

time

BCWP

CV

estimatedcompletiondate (ECD)

Figure 3.11 Comparison of actual and budgeted costs of work performed

This assumptiondepends on where youare in the project. At theearly stages, youprobably do not haveenough data to make astatement like this,unlike the later stageswhere presumably youwill have moreinformation to hand – asexplained below.


appropriate to use assumption 2. As the project approaches 100% completion the

two estimates approach each other so then it does not matter which assumption is

used. In deciding which assumption to use to calculate estimated cost at completion

it is also worth considering whether or not the current cost variances on activities are

likely to be typical of variances on future activities. If experience so far is typical, use

assumption 2; and if not, assumption 1 is likely to be more appropriate.

Another item frequently required in a monthly cost report is the cost to complete

(CTC). The cost to complete (as opposed to the cost at completion) is the estimated

cost of the work still to be done. Since the cost so far is ACWP, the relationship

between the cost to complete and the estimated cost at completion is:

CTC = ECAC – ACWP

Should you ever be in a position of having to decide whether to continue a project or

cancel it and cut your losses, the CTC is the most relevant figure to know. Costs that

represent money or time already spent are water under the bridge, called sunk costs,

but the CTC is the money still to be spent. You may decide that it is best to cancel a

project if the CTC is greater than the benefits likely to be obtained if you were to

continue. In this case you will have to write off the sunk costs and chalk it up to

experience.

ACTIVITY 3.2

The project manager is monitoring cost for the oven project discussed in Activity 3.1.

After seven weeks, the project manager identified that the actual cost of the work

performed (ACWP) for the first four activities was

£4000 + £6000 + £2000 + £6000 = £18 000

(a) Calculate the cost variance (CV).

(b) Use the earned value method to predict the estimated cost at completion.

Discussion ............................................................................................................(a) CV = BCWP – ACWP = £13 000 – £18 000 = –£5000 (a cost overrun).

(b) ECAC = PB – CV = £23 000 – (–£5000) = £28 000

assuming that the remaining work will be done at the budgeted cost.

As the project is more than 30% complete, a more realistic assumption may be to

assume that the remaining work will be performed at the cost/budget factor experienced

so far. In that case

ECAC = PB 6 (ACWP/BCWP) = £23 000 6 18 000/13 000

= £31 850 (approx.)

Summary of earned value termsA number of terms have now been introduced and these are summarised in Table 3.7.

You should be aware that some literature sources and software tools use slightly

different earned value terms to those used in this course (see, for example, Meredith

and Mantel, 2006, pp. 507–18). It is always important to check the conventions being

used when studying earned value reports.

We expect you to usethe earned value termsin Table 3.7 in yourwork for this course.


Table 3.7 Summary of earned value terms

Term Description Meaning

BCWS Budgeted cost of work scheduled The planned profile of expenditure

against time for the project

BCWP Budgeted cost of work performed The budgeted (planned) cost for

work performed so far

ACWP Actual cost of work performed Actual costs incurred in performing

work so far

CPI Cost–performance index The ratio of the value of the work to

the actual incurred cost:

CPI + BCWP/ACWP

CTC Cost to complete Cost of work still to be done

CV Cost variance A measure of the difference

between planned costs and actual

costs for the work achieved so far:

CV = BCWP – ACWP

ECAC Estimated cost at completion The projected completion cost of

the project

ECD Estimated completion date The date at which the project is

predicted to be completed

PB Project budget The original budget for the project

SC Scheduled completion date The original completion date for

the project

SPI Schedule–performance index The ratio of the value of the work

performed so far to the value of the

work scheduled:

SPI = BCWP/BCWS

SV Schedule variance A measure of the work performed

compared with the plan in cash

terms:

SV = BCWP – BCWS

Slippage Slippage in time The time lag between BCWS and

BCWP curves

Time

inflation

factor

Time inflation factor The ratio of the time taken so far on

the project to the time taken to

achieve the same amount of work

from the planned profile of

expenditure

SAQ 3.8

Which of the terms in Table 3.7 vary throughout the project and which terms remain

constant?


SAQ 3.9

Six months into a one-year project with a budget of £200 000, it is found that the actual

cost of work performed is £110 000 and the budgeted cost of work performed

is £100 000.

(a) What is the estimated cost at completion if you assume that the cost–performance

index remains constant?

(b) What is the estimated cost at completion if you assume that the remaining work is

performed to budget?

3.4 Summary

The methods that are available for monitoring the schedule include: updating the project

network diagram or Gantt chart to show completed and partially completed activities;

milestone tracking to show how the dates of milestones move throughout the project;

calculating SV and slippage from earned value BCWS and BCWP curves.

The section has also described how earned value is used for comparing the current

cost of a project with its budgeted cost. It is necessary to split the work into elements,

each having a budgeted cost, which may be expressed in cash terms or in hours of

work. The budgeted cost of the work performed can be calculated by summing the

achievement over all the elements. CV is the cost variance and is a measure of the

cost under- or overrun for the same amount of work, a measure of how well you are

doing financially compared with the budget plan.

All the earned value terms are summarised in Table 3.7. All elements of Table 3.7 except

for the project budget and the original scheduled completion date vary throughout the

project.

Having studied this section, you should now be able to:

c show how to use an updated network diagram or Gantt chart to estimate a new

project completion date

c describe and use a milestone tracking graph

c use earned value curves to compute a schedule variance and deduce slippage

c describe the earned value method for monitoring costs

c calculate ECAC and ECD making different assumptions about the rate of progress

of future work

c define and explain the significance of all the terms listed in Table 3.7.


4 Controlling the cost andmaintaining the schedule

Controlling cost and schedule is much more difficult than monitoring cost and schedule.

There are numerous books on cost control which, in spite of optimistic-sounding titles,

are really mostly about techniques for cost monitoring. Cost monitoring is, of course,

an essential prerequisite for cost control – without it the project manager is left in the

position of one who can only exhort the team to do their best but does not know whether

to praise them or blame them for their past performance. It comes back to the project

control loop, Figure 2.1: status measurements are essential for control.

In The Mythical Man-Month, Brooks has an essay entitled ‘Hatching a catastrophe’

(1975). It happens that Brooks was writing about software but there is little in what

he says that does not apply to any kind of project. Consider the following extract:

When one hears of disastrous schedule slippage in a project, he imagines that a

series of major calamities must have befallen it. Usually, however, the disaster is

due to termites, not tornadoes; and the schedule has slipped imperceptibly but

inexorably. Indeed, major calamities are easier to handle; one responds with

major force, radical reorganization, the invention of new approaches. The whole

team rises to the occasion.

But the day-by-day slippage is harder to recognize, harder to prevent, harder to

make up. Yesterday a key man was sick, and a meeting couldn’t be held. Today

the machines are all down, because lightning struck the building’s power

transformer. Tomorrow the disk routines won’t start testing, because the first

disk is a week late from the factory. Snow, jury duty, family problems,

emergency meetings with customers, executive audits – the list goes on and on.

Each one only postpones some activity by a half-day or a day. And the schedule

slips, one day at a time.

(p. 154)

From these scenarios it would seem it is almost impossible to prescribe how the

project manager might control cost and schedule. However, in this section we

discuss how the project manager can interpret the earned value information

presented in Section 3 and hence use this information to identify ways of controlling

cost and schedule.

4.1 Combined cost and schedule graphs

The effectiveness of a cost and schedule control system can be greatly enhanced by

displaying the combined results graphically. You saw in Section 3 that the relative

positions of the curves for ACWP and BCWP tell you how well you are doing financially

and you have also seen that the relative positions of BCWP and BCWS tell you how well

you are doing in terms of achievement against the schedule. If all three curves are given

in the same diagram you should be able to deduce both these measures.

4 Controlling the cost and maintaining the schedule 45

ACTIVITY 4.1

Given the earned value curves for a project as shown in Figure 4.1 deduce the cost and

schedule variances and hence describe the situation as you would have seen it:

(a) at the end of May

(b) at the end of September.

(c) At the end of September what can the project manager do to manage a project in this

situation?

Discussion ............................................................................................................(a) At the end of May the value of BCWP is virtually equal to the value of ACWP and

hence the cost variance is zero. Financially the project is on budget.

The value of BCWP is higher than the value of BCWS by about 5% of the project

budget and so the SV is positive and the work is therefore ahead of schedule. The

achievement at the end of May is roughly the same as planned for the end of June

so the project is about a month ahead of schedule.

The slopes of the graphs might lead you to predict that the situation on both cost

and schedule was likely to deteriorate. (In real life you would make such a prediction

after taking into account information from progress meetings, etc.)

(b) At the end of September the situation is quite different. ACWP is above BCWP by

about 12% of project budget and so the value of CV is –12% of project budget,

a significant overspend. You might predict from the slopes of the curves that this

looks likely to get considerably worse.

The value of BCWP is below BCWS and the schedule variance SV is now about

–10% of project budget. The achievement at the end of September is roughly what it

should have been at the end of August. The achievement is therefore currently

about one month behind schedule. From the slopes of the curves this looks likely to

get considerably worse.

(c) In Section 3 we noted that schedule slippage also affects cost and we can see this

project has a negative SV and a negative CV at the end of September. The planned

resources have not been used to complete the work as quickly as predicted,

% o

f pro

ject

bud

get

elapsed months

100

70

50

20

0

40

DNOSAJJMAMFJ

BCWS

BCWP

MFJ

10

30

60

80

90

ACWP

Figure 4.1 Some earned value curves

In this figure, theearned value curveshave been plottedusing % of projectbudget but it is moreusual to use projectcosts as in Section 3 ofthis unit.


so although their costs have been charged to the project, the amount of work

completed has been less than expected.

When resources are not being used to complete the work at the planned rate the

project manager must check that staff have the necessary tools and training to do

the work at the planned rate. Assuming that the working environment is satisfactory,

the variances may have arisen because the project is more complex than

originally estimated. In this case the project manager may need to negotiate with the

client to reduce the scope of the work. In any event the project manager must

communicate with the team and client to identify the cause of the problem and the

most appropriate actions to take. The project manager needs to check that any

action initiated is successful and it may be necessary to update the plan several

times before the project is back on track or a new plan agreed with the stakeholders.

The project manager should again refer to the project control loop in Figure 2.1.

Note that we have not suggested adding more resources to the project to bring the

project back on schedule. We will refer to Brooks’ Law on adding extra resources to

a late project in Subsection 4.2, but here we will highlight that although adding

resources may help to reduce the schedule variance it will also increase the cost

variance. It is necessary to consider the combination of variances when interpreting

earned value information.

SAQ 4.1

In Activity 4.1 part (b) we described a project with a negative SV and a negative CV.

In practice, there are three other possible combinations of schedule and cost variance

that may occur in any project. Identify these three combinations and explain how these

situations may arise.

We consider the actions that the project manager can take to manage schedule and

cost variances in Subsections 4.2 and 4.3.

Since we are particularly concerned with the final cost we might find it useful to display

the progress of the estimated cost at completion (ECAC) against time, as each monthly

cost report becomes available, as shown in Figure 4.2. If the estimates were really

unbiased then you would expect to see a random walk progress across the page.

This means that there should not be any particular trend detectable except by chance.

However, as shown in Figure 4.2, successive estimates of the cost at completion for a

project tend to rise as costs seem almost invariably to exceed forecasts. The final cost of

the project seems likely to be rather higher than any of the estimates plotted so far.


Similarly, it is informative to plot successive estimates of the completion date, as shown

in Figure 4.3. Like cost estimates, the expected completion date will often show a

tendency to drift.

Archibald (2003) devised an informative way of combining the usual earned value

graphs with graphs showing the estimated cost and the completion date. This

combination is shown in Figure 4.4. Although this appears to be a fairly complicated

graph it contains a great deal of information.

ECD

(wee

ks fr

om s

tart)

report dateDNOSAJJMAMFJ

original planned completion date

DNOSAJJMAMFJ98

100

102

104

106

108

110

112

Figure 4.3 Project’s expected completion date (ECD) against report date

ECAC

report dateDNOSAJJMAMFJ

original budget

DNOSAJJMAMFJ

Figure 4.2 Project estimated cost at completion (ECAC) against report date


The usual three earned value curves, ACWP, BCWP and BCWS, are shown in the

middle of the graph. Superimposed above is the plot showing the progress of the

estimated cost at completion, ECAC. (The numbers E0, E1, E2, E3, etc. represent the

successive revised estimates.) Similarly, superimposed at the right-hand side of the

graph is a plot of the estimated completion date, ECD. (The numbers S0, S1, S2, S3, etc.

represent the successive revised schedule estimates.) To make the graph of completion

date more readable, each successive ECD is plotted at a height corresponding to the

actual cost of work performed at that report date and similarly with the ECAC plots

across the graph. Plotted in this way the graphs of ECAC and ECD will eventually

meet at a point which corresponds to the actual cost at the actual completion date.

SAQ 4.2

Suppose you happened to be the fortunate manager of an ideal project in which the

estimated cost and completion date remained constant throughout the project. What

would the graphs look like when presented as an Archibald cost and schedule

performance chart? (Assume an initial budget of £100 000, project duration of one

calendar year and an arbitrary shape for the BCWS curve.)

cost

(£ m

illion

)

month

0DNOSA

BCWS

0.1

original budgetand schedule

S0S1

S2S3

S4

S5

S6

S7

S8

E8E7

E6E5E4E3

E2

E1

E0

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1.0

1.1

1.2

1.3

1.4

1.5

1.6

1.7

1.8

DNOSAJJMAMFJ AJJMAMFJ

latest ECDACWP

BCWP

CVSV

latest ECAC

year 1 year 2 year 3

Figure 4.4 Cost and schedule performance chart (Archibald, 2003, p. 344)


4.2 Avoiding slippage

How does a project get to be a year late?

... One day at a time.

(Brooks, 1975, p. 153)

Brooks identifies three remedies in particular that help the project manager to keep

what he calls the ‘termites’ under control. He stresses the importance of having a

schedule. The milestones in the schedule ‘must be concrete, specific, measurable

events, defined with knife-edge sharpness’ (p. 154). (We discussed in Section 2 the

problem of the 95% complete syndrome and we discussed criteria to help to define

meaningful milestones in Subsection 4.1 of Unit 3.)

A second remedy is to use a critical path schedule to concentrate the effort on the

critical activities and to counter the excuse that ‘the other piece is late anyhow’.

A third problem to overcome is the lower-level manager who does not want to worry his

boss about the small slippage that he hopes to be able to make good later. Brooks

suggests that this problem is partly due to the lower-level manager’s fear that his boss

will overreact and so prefers to sweep the problem under the rug. Two solutions are

proposed to overcome this problem: one is to reduce the ‘conflict’ and encourage the

sharing of information openly, the other is to ‘yank the rug back’ using reviews and

reports. Brooks recommends the use of a watchdog group to handle the administration

of plans and controls.

Adding extra resourcesWhen a section manager reports to the boss that the schedule is slipping the boss will

often respond with the question ‘How many extra people do you need to get back on

schedule?’ This question is often unanswerable because of Brooks’ Law:

Adding manpower to a late software project makes it later.

(Brooks, 1975, p. 25)

The law could be expected to apply not only to software projects but to any technically

complex project where there is strong interaction between the workers.

Brooks’ Law is based on the fact that when work is partitioned there is a communication

effort that has to be added to the work to be done. Part of this communication is due to

the training and familiarisation required when a new member joins the project team.

Another part is the intercommunication which is proportional to the number of pair-wise

links in the team. Adding a new member to a team decreases the effort available from

the existing members by the amount required from each of them for communication with

the new team member. As the team size increases this loss will eventually more than

offset the extra effort added by the new recruit.

Some causes of slippageThe question of extra resources is not the only question to consider if a schedule is

slipping. Naturally, you will want to know why this slippage occurred. Here are some

questions you might consider based on issues that have already been raised in earlier

units (especially Unit 4).

Are the section objectives clear to the team?

If the objectives are not clear then time will be wasted on irrelevant activities.

Furthermore, when this waste becomes clear to the person involved, they are then likely

to be demoralised about the work and feel less committed to future tasks fearing that

they too will turn out to be a waste of time.


Are the team members committed to the project?

This commitment should have been gained early in the project by their involvement in

the planning stage, but it needs to be nurtured throughout.

Do the staff accept their targets as realistic?

By involving staff in the estimating stage the manager should have arrived at targets

that are accepted as realistic. If their estimates were disregarded the staff may be

unwilling to accept targets that are difficult to achieve. The targets must also take

account of the technical skills that the staff have.

Do the staff believe their work is valued?

If they do not think that the job they are doing is worthwhile they are unlikely to perform

enthusiastically. If they think that no one notices the work they do then they will see less

purpose in doing it well. People need rewards for good work – not necessarily financial.

You may be surprised at the effect that buying someone a cup of coffee can have!

Is training required?

Many managers will be reluctant to ‘waste’ valuable project time training staff when

they are needed on the job. Naturally, it would be better if the training requirement

had been foreseen. Nevertheless, if the skills of the team are inadequate for the task

in hand it is better to get them trained earlier rather than later. It is better to sacrifice

a few weeks’ effort early in the project and have an effective team member for the

whole life of that project than recognise the need too late and lose the same number

of weeks at a later date and have an effective person for only half the project.

Are technical standards set at an appropriate level?

If the standards are unnecessarily high then productivity may suffer. Worse still,

standards may be disregarded if they are not respected as appropriate.

Are people working on other things?

If there are other interesting activities to be done and there is no one to notice who is

doing what, then members of the team may be doing things which are quite irrelevant to

the project. Some policing is unfortunately necessary.

Should more work be subcontracted?

Possibly too much of the work on the project is being undertaken directly in-house. The

extent of subcontracting will have been decided at the planning stage but if the project

is slipping then perhaps more could be subcontracted. There are communication

problems here, as when adding any extra staff, but if the subcontracted work can be

identified as packages which are as self-contained as possible it may relieve the burden

on other staff. This is offset by an additional administrative burden.

Should the scope of work be reduced?

The scope of work may include optional items, or items that could be delivered as a

second stage. The contract with the client may be negotiable. Perhaps a phased

delivery can be agreed.

Are changes being made too frequently?

Changes during the project are very necessary to ensure that the client’s requirements

are met as closely as possible, but they can be a great hindrance. Perhaps the review

procedures, discussed in Unit 6, should be tightened so that only changes that are

absolutely necessary are accepted.


You might notice that very few of these questions can be answered by a manager who

uses only written reports and formal reviews to assess the situation. Most effective

managers spend at least half their time in less formal ways, talking to the people working

on the project, discussing their problems, helping them plan how to overcome them,

fostering cooperation between team members and showing appreciation of their efforts.

The project manager needs to find out what the members of the team think are the

reasons for slippage and whether they have any remedies. Remedies that come from

the team itself are more likely to be acceptable than remedies imposed from outside.

If the answers to the above questions suggest that very little can be done to improve

matters then the project plan will have to be revised. Perhaps the project is slipping

because of factors outside the manager’s control, such as late deliveries from suppliers

or subcontractors. Possibly the original estimates were too optimistic. This is not an

unusual situation but, as discussed in Unit 2, you should try to see that the mistake is not

repeated by ensuring that data from this project is used to improve the estimates for

future projects.

4.3 Controlling the project cost

One axiom should be stated at the outset:

You cannot control the cost of an item when the money has already been spent

or irrevocably committed.

A consequence of this axiom is that cost control is all about controlling future

commitments, not about controlling past expenditure. So the main element of cost

control is the authorisation to spend money, which we discuss below. If control can only

be exercised over future commitments, what is the point of cost monitoring – gathering

and reporting the costs of historical spending? Some would argue that such monitoring

is done purely to satisfy the accountants about where the money has gone, and is

useless as a tool for controlling cost. It is not, so how does it help?

The answer to this is threefold. First, there is the effect upon the attitude of the project

staff towards spending. The fact that the project manager is cost conscious must be

strongly communicated to the project team so that their attitude towards expenditure

reflects this. This attitude can be either fostered or neglected according to the

mechanisms which are instituted by the project manager for authorising expenditure

and for calling staff to account for their spending. Second, the cost monitoring system

gives feedback so that the project manager knows whether the authorisation controls

are working. Third, if costs do overrun, it gives the project manager advance warning to

seek more funds before the cash runs out.

AuthorisationDuring the execution of the project cost control is mainly exercised by authorising only

those commitments which are detailed in the project budget breakdown with some

margin, perhaps 10%, to allow for inaccuracies in the estimate.

In some companies each order for external expenditure will carry a code so detailed that

it can be checked against the estimate for that individual item before the official order is

placed. More commonly, the code embraces a number of component orders because

the cost account is set higher in the work breakdown structure (WBS) than the

component level. Even so, the person responsible for initiating the order will be

expected to ensure that the cost of all the components within the cost account does not

exceed the estimate by more than the tolerable limit.


Similar control is required for the expenditure on staff time. For close control a system is

required in which every unit of time is booked against a cost code representing an

activity within the WBS. Authority to book against a given code has to be given in

advance. The only difference from the system of monitoring commitments for equipment

is that the units of measurement are usually days or hours rather than money. The

translation of time into cost charged against the project is usually based on some

formula according to the grade of the employee, and includes a factor to cover all the

overheads such as the provision of office accommodation, heating, lighting and phones

(as you saw in Subsections 4.4 and 4.5 of Unit 2).

TimingA project manager’s power to influence the final cost of a project diminishes as the

project progresses. The most effective time in the project at which to exercise control is

at the conceptual stage when the scope of the project is being defined. At each

successive stage, the scope for exercising control diminishes until at the finishing

stages the project manager is almost powerless to affect the outcome.

In the definition phase there has been little expenditure and it is still possible, by

cancelling the project, to save nearly 100% of the project budget. Although this may

seem to express a rather pessimistic attitude there is no doubt that it would have

saved a great deal of money for many project sponsors if some projects had been

aborted at an early stage. Think of the Euro Disney project in France, where, rather

than cancelling it, a rescue package was put together when it turned out to be

unprofitable because the investment had already been made. Huge sums would

have been saved if this outcome had been foreseen earlier. (Of course this is easier

to see with hindsight, but it shows the importance of getting the concept right.)

The next most effective stage at which to save money is the feasibility study when the

scope of the project is defined. Perhaps some parts are less valuable than others. The

cost of each function needs to be carefully estimated to ensure that each piece of the

project is worthwhile. The specification may need pruning to get the best value for

money. (Very occasionally the reverse is true: the scope needs to be expanded to

achieve better returns.) To minimise risk it is better to start with a smaller scope and add

to it at a later phase. Value engineering (see Unit 1) is used to examine each part of a

system to see if there is a better or cheaper way to achieve the desired result. This may

be applied at various times but is useful particularly in the design phase where it can

have a significant impact.

Once the scope of the project has been defined the most important of all documents

for cost control can be produced: the project budget. This will give a detailed

breakdown of the cost of the project showing the budgeted cost of every item to be

ordered and every activity to be performed down to the lowest level of detail that it

is economically possible to achieve given the knowledge available at that stage.

This is the level at which cost control is exercised.

Knowing when to ‘pull the plug’Sometimes the most cost-effective action that a project manager could take would be to

‘pull the plug’ – to get the project closed down. Unfortunately, it is very difficult for a

project manager or the initiators of a project to see matters in a clear-sighted way. You

will find a paper on the course website by Staw and Ross, ‘Knowing when to pull the

plug’ (1987), which discusses the difficulties of making objective judgements. The

process of making such a decision will involve an assessment of the critical success

factors and the success criteria, which were identified in Section 5 of Unit 1, for the

current project.

Read that paper now and then do the following activity.

A number of authors,such as Meredithand Mantel (2006,pp. 629–35), havebased theirdiscussions about thedecision to terminate aproject early, on theStaw and Ross paper.


ACTIVITY 4.2

(a) Give six reasons why it is difficult for project participants to assess whether it is best

to ‘pull the plug’ on a project.

(b) Summarise the suggestions that the authors make for overcoming the problem.

Discussion ............................................................................................................(a) The nature of the project itself may have led to the expectation that there would be

temporary problems, so when these arise they may be dismissed as nothing other

than expected difficulties.

A project with high closing costs and little salvage value may be difficult to

abandon because of the exit costs.

Commitment may have been established too well to allow closure to be

contemplated.

Psychological factors are important. It’s hard for those who have been rewarded

for their previous tenacity now to be seen to be giving up.

Intermittent rewards encourage the hope that things may improve.

People perceive only what accords with their established beliefs. Consequently

they may bias the data to favour these beliefs and undermine the credibility of

contrary evidence, especially if the data is ambiguous.

Bad news in a project may be interpreted as a personal failure, so the project

manager may want to persist and prove that the project is in fact a success.

Social pressures lead us to admire people who are tenacious in the face of

adversity.

Organisational inertia may make it easier not to ‘rock the boat’.

Politics can make it difficult to back out – as in the case of Expo ’86 in British

Columbia. Lockheed and Pan Am are cited as examples of companies

committed to projects that were identified with their core business.

(b) Recognise overcommitment. A series of questions is proposed to test whether one

is overcommitted to a given course of action.

Try to take an outsider’s perspective. Ask yourself ‘If I took this job for the first

time today and found this project going on, would I support it or get rid of it?’

A ‘decision circle’ could include outsiders to take a less subjective view of the

state of a project.

Change the organisation. Replace people who have been associated too

deeply with the project. (This could be disruptive and costly.)

Separate later decision making from the initial decision makers.

Reduce the penalties that project managers pay personally if their project folds.

(This is contrary to the normal attitude that project managers need personal

incentives associated with project success.)

Improve the honesty of reporting. Reward candid reporting rather than solely

rewarding the bearers of good news.

Reward the honest recognition of problems.

All projects should to some extent be considered experimental so that they can

be subject to regular reconsideration.


4.4 Summary

The value of combining all the BCWS, ACWP and BCWP curves on a single graph was

demonstrated together with other diagrams such as graphs of ECAC and ECD. It is

necessary to consider the combination of cost and schedule variances when

interpreting earned value information.

The causes of slippage were described.

Cost control requires a system of cost monitoring coupled with appropriate authorisation

to members of the project team to spend money or book time to individual cost codes.

The power to influence the final cost diminishes as the project progresses.

Some projects ought to be closed early. This can be difficult both for the organisation

and personally for the project manager. The paper by Staw and Ross, which is available

on the course website, discusses these issues.


c interpret the meaning of a set of earned value curves and interpret other forms of

graphic display

c identify actions to avoid project slippage

c discuss ways of controlling costs

c discuss the effect of control actions at different stages of the project

c describe some ways of recognising ‘problem’ projects

c describe ways of dealing with overcommitment, organisational inertia and fears of

risk of failures.


Unit 6

MANAGING QUALITY AND CHANGE

1 Introduction

Unit 5 looked at two major aspects of project execution: managing progress –

measuring how much work has been done and how much money has been spent – and

controlling progress – comparing what has happened with what should have happened

and making adjustments in order to keep on track.

This unit looks at two further major aspects of project execution: maintaining quality and

dealing with the inevitable changes that arise during the life cycle of every project.

Perhaps we should start with a reminder of the definition of quality, which we introduced

in Unit 1 from the quality management standards that have been defined by the

International Organization for Standardization (ISO):

the degree to which a set of inherent characteristics fulfils requirements.

(ISO 9000, 2005)

Furthermore the APM’s Body of Knowledge uses the following definition of quality:

the fitness for purpose or the degree of conformance of the outputs of the

process.

(APM, 2005, p. 153)

The definitions show us that quality is difficult to define for any project or service.

Characteristics or distinguishing features must be defined and exist within the product

or service and must be related to or contribute to the fulfilment of the requirements. For

example, a characteristic might be the degree of reliability of the product expressed in

the requirement ‘the mean time between failures (MTBF) of the product shall be greater

than 200 hours’. Demonstrations or acceptance criteria can then be defined to test and

measure whether the product conforms to the requirement and is therefore fit for

purpose. We looked at defining requirements and demonstrations in Unit 1. The project

manager must also agree which standards and methodologies will be used within the

project. These might be quality standards such as the ISO 9000 series, project

management standards such as BS 6079, project management methods such as

PRINCE2, industry standards such as capability maturity model integration (CMMI)

which measures process quality in the software industry or an organisation’s own

company standards and methodologies for project management and execution of

the work.

These activities form the basis of quality planning in which the project manager will

balance time, cost and quality. In this unit we discuss how the project manager monitors

and controls quality throughout the project so that consistent processes are used to

ensure that the final product satisfies the defined demonstrations and therefore meets

stakeholder expectations.

Change is, as we have said, inevitable. It can involve substitution, for example of one

component for another; alteration, for example change made to a design for the purpose

of improving marketability of a product; additions, where the client may want more

features or functions; or deletions – as costs mount the client may decide to eliminate a

desirable but not strictly necessary feature or function in order to save money. The need

to make changes can also arise due to unforeseen circumstances revealing themselves

in the course of project work – new legislation, for example.

Quality managementsystems, in particularthe ISO 9000 series,are discussed on thecourse website.Standards and thePRINCE2 projectmanagement methodare discussed in moredetail in Unit 7.

1 Introduction 57

Unit 5 included a discussion of slippage on schedules: the sort that accumulates one

day at a time until, if unnoticed, it can reach substantial proportions. Change can

behave in the same way. Minor changes can accumulate quickly, and if not controlled

properly, can have a serious – even disastrous – impact on schedules, cost, quality or

even the ability to complete the project. This unit addresses the problem of controlling

change.

Unit 6: Managing quality and change58

2 Maintaining the quality

This section is about maintaining the quality during the execution of the project. It is the

first of three sections on quality issues. Sections 3 and 4 are concerned with the causes

and effects of change on a project and a method of handling it called configuration

management.

We assume that requirements have been defined as described in Unit 1, quality

standards and methodologies have been chosen as described earlier and plans have

been prepared as described in Unit 3. We now want to examine the activities used to

monitor and control quality after the project launch and see how they might be

performed. In the first part of this section we will try to keep the discussion general,

giving principles that you might expect to apply to many kinds of project, but especially

to those that include a ‘design’ element. The second part of the section will illustrate

quality principles as applied to software production. Although this second part is based

on software there are lessons to be learnt from it for many other types of project,

particularly those that deliver a ‘soft’ product, such as a new system, a document or a

service. The section concludes with a discussion of auditing methods.

2.1 Monitoring and controlling quality

The activities most commonly referred to in monitoring and controlling quality are

quality assurance and quality control. Both activities take place throughout the

project life cycle but satisfy different objectives as follows:

Objectives of quality assurance:

c to provide confidence to the client and stakeholders that the product will satisfy the

requirements in terms of time, cost and quality

c to reduce the cost of quality by the early detection and correction of errors and the

prevention of causes of error.

Objectives of quality control:

c to identify products or part-products which do not conform to specified standards or

requirements in order to avoid handover to the client of non-conforming products.

Quality assurance and quality control involve reviewing and testing what has been

produced. Effective quality activities periodically evaluate the quality of the project

deliverables. A quality review evaluates the deliverables against some specified quality

criteria and once into execution there will be testing of finished products and

part-products. Requirements for quality of deliverables are usually specified in work

package definitions and statements of work (as we discussed in Unit 2). Early in the

project there will be quality reviews of the requirements, the estimates and the plan.

(These reviews could be conducted using any of the methods listed here.) A prime

example is the design review, described below, necessary in all projects that have a

design phase.

Less formal methods are walk-throughs and inspections. In a walk-through the

originator of a product such as a design document or program code supplies copies of

the product to reviewers for familiarisation and then ‘walks them through’ it at an informal

review. The reviewers make comments to the originator about any errors or problems

they discover in the course of the walk-through. These are then discussed by the group.


In an inspection a colleague or colleagues of the producer of some product inspect the

product in detail and pass their comments directly to the originator. This course, for

example, used a team of critical readers to comment on drafts of the materials as they

were produced. This is a form of inspection.

Most products may be tested directly to see if they do what they are supposed to do.

Often it is possible to test components of the final product at various stages. Software is

a good example: a high proportion of the effort that goes into a software product will

go into its testing, described in more detail in Subsection 2.2. ‘Hard’ products or

components can be tested, using those methods and tests most suitable in each case.

These can range from visual inspection of materials and components to the use of

elaborate simulations, test harnesses and beds and highly technical inspection methods

using sampling, X-ray, ultrasound or tomography. What is required will be dictated by

the material, component or product, by the technological risk if it fails and by cost and

time constraints.

Measuring qualityReturning once again to the project control loop, Figure 2.1 in Unit 5: measurement is

necessary for control. This applies to quality as well as cost and schedule. In the same

way as the earned value information is used to monitor and control project cost and

schedule, information from reviews and testing needs to be monitored to predict the

quality of the product as perceived externally by the client (fitness for purpose) and

internally by the project team (conformance to specification, methodologies and

standards). The information is interpreted and action taken when necessary to maintain

product quality and to communicate the impact of any problems identified.

Measuring quality is necessarily more subjective than measuring performance against

the project budget or schedule, because it is intangible, but it would be unwise to adopt

a strategy of ‘no measurement’ for this reason.

In measuring the quality, the project manager should:

c define what is to be measured: typically a set of products and their associated

processes whose selection is likely to be based on the standards being applied to

the project

c choose measurements to be made: for example, defect counts from quality reviews,

mean time between failures (MTBF) from testing

c identify the point at which each assessment is to take place

c collect the data

c identify unusual measurements by comparison with previous measurements on the

current project; by comparison with historical data from past projects; by

comparison with targets set from quality improvement initiatives; or by comparison

with standards

c analyse and take action: the project manager must examine the components or

processes that have been assessed to discover the reason for the unusual

measurement and to determine the most appropriate action; for example, an

unusually high defect count in a review of a requirements definition may indicate

changing requirements rather than poor quality of the requirements process or

non-conformance of a deliverable with the standard may indicate a need for further

training of team members.

Early identification of problems also gives the project manager the opportunity to

communicate the impact to the stakeholders, giving them the opportunity to contribute

to decision making at an early stage.

In Unit 1, we discussedthe qualities andcontributing factorsassociated with theproducts as part oftheir specification.


Finally, quality measures should be used as part of the process for continuous quality

improvement for all project work. Continuous quality improvement is a key concept used

in the ISO 9000 family of standards and others such as CMMI. For example, a review is

not only a formal mechanism for the early detection of defects, but also a means of

disseminating good practice within an organisation.

Design reviewAs part of the development of the terminology and vocabulary associated with the

subject of quality, particularly in the domain of engineering, the British Standards

Institute defined a design review as:

A formal documented, comprehensive and systematic examination of a design

to evaluate the design requirements and the capability of the design to meet

those requirements and to identify problems and propose solutions.

(BS 4778, 1991)

The Project Management Institute in the USA uses a slightly different definition:

A management technique used for evaluating a proposed design to ensure that

the design of the system or product meets the customer requirements, or to

assure that the design will perform successfully, can be produced and can be

maintained.

(PMI, 2004)

The primary function of the design review is to provide the client and the contractor’s

management with information about design status and identified problem areas. With

this information, the client and the contractor’s management can make decisions about

approving production or can explore alternatives; project staff can use the information to

evaluate changes to specifications and establish test programmes. The design review

satisfies the objectives of both quality assurance and quality control. The go/no go

decision making of the design review allows work on the next stage of the project to

begin, which is an example relating to the discussion of a gate review in Unit 1.

We see from this that a design review is a distinct type of meeting with a different

purpose from the regular progress review meetings. Its purpose is to test the technical

quality of the work done.

Design reviews are usually conducted as a series of formal meetings during the

design phase of the project. In addition to the primary objective of ensuring that

requirements will be met and no design weaknesses will jeopardise the project,

there are some more specific objectives to be borne in mind. Design reviews should

attempt to confirm that the optimum (or at least a perfectly satisfactory) design

approach which will meet the requirements will be achieved. They should also

attempt to identify and confirm the final design as a basis for later production and

seek to avoid errors that will cause problems in later fabrication or use of the product.

A design review is held at the end of an important phase of the design work, before the

next phase begins. It will probably start with a presentation by one or more team

members, describing their work. Criticism and comment from other team members will

then be used to examine the quality of the design.

Reviews can range from simple to complex and expensive – from two or three key

people meeting semi-informally to a highly formal meeting involving a dozen or more

people. The outcome of a design review will be a summary showing which aspects of a

design have been accepted as satisfactory and which problems have still to be

resolved, specifically:

c a list of design items approved

c lists of tasks to be completed

Total qualitymanagement,Six Sigma and leanmethods also includepractices associatedwith continuous qualityimprovement. Leanmethods are discussedin Unit 7.

The two definitionshave been used toillustrate thesignificance ofappreciating differentviewpoints withinproject working,particularly sinceglobalisation hasincreased thecomplexity of projectsfrom the perspectivesof national,organisational andprofessional cultures.Both definitions areused for our definitionin the course glossary.


c preparation of data for design changes

c reports of action items to correct deficiencies in design.

The design review may suggest approaches to solving the outstanding problems but

the reviewers should be discouraged from spending too much time finding solutions

during the meeting. Rather than finding solutions the meeting should identify people

who will be responsible for solving the problems.

Who should attend?The project manager should attend and probably chair the meetings. If the project is so

large that it has to be partitioned into subprojects then this role would probably be taken

by the manager of the subproject. A design review coordinator may be appointed where

the meeting is large, or where smaller meetings are frequent. The other attendees

constitute a design review board: the person(s) responsible for the design and other

specialists in design, testing, producibility, quality, reliability, logistics. It is preferable

that they have contributed in some direct way to the aspect of design under review.

The presence of peers from other project teams can often be used as a catalyst for a

fruitful exposure of deficiencies. Many project managers regard the presence of these

outsiders as essential.

The satisfactory completion of a thorough design review is a signal that the project can

proceed to the next phase. Therefore, an important aspect of any design review is the

corrective action items that result. To note this in an unambiguous way, the minutes of

such a meeting must be recorded carefully and completely, and must identify clearly

individuals and dates for action items, and be distributed to all interested parties.

In addition to minutes, the person chairing the meeting should write and distribute a

design review report after each design meeting. The writer should include a list of

attendees, a synopsis of the decisions or results of the review, any corrective action

items and the names of those responsible for them, and a schedule for completing

action items. This should also be sent to all participants.

SAQ 2.1

What are the differences in the timing, the team composition and the subject matter of a

progress review and a quality review?

Probably second only to getting the requirements right, the design phase of a project is

critical to the success of the project. Getting the design phase right greatly increases

the chances of producing a satisfactory, indeed ‘good’, product. A careful and frequent

review at all stages and in all phases of design greatly increases the chances of ending

with the ‘right’ and ‘good’ product at the end of the project.

It is at the design phase that value engineering becomes crucial. Each item of the

design needs to be examined to determine whether it gives optimum value. Is this

aspect over-specified, given the parameters of the requirements, or will it produce a

satisfactory product? Is this the best option here, or is there a better one? The answer to

questions like these depends, of course, on what the requirements specify and what

options are available to the designers.

Finally, the early review of design is likely to reduce the possibility of intractable or

difficult problems arising during later phases of the project. It is easier, and cheaper, to

correct a fault at the design stage than it is to carry out the same correction later, when

considerable rework may be required.


SAQ 2.2

What aspects of a project is a preliminary design review likely to look at?

2.2 Software quality

The previous subsection outlined a general approach to maintaining quality in the

execution phase of any kind of project. In this section we will illustrate these general

principles by showing their application to software projects. We discuss first what we

mean by software quality and then how we might ensure that we get it in a project.

The meaning of ‘software quality’The definition for software quality suggested by the Institute of Electrical and Electronics

Engineers (IEEE) is as follows:

The degree to which a system, component or process meets specified

requirements. The degree to which a system, component or process meets

customer or user needs or expectations.

(IEEE, 1991)

Although quality of the software process is highlighted in the above definition, it

seems to be commonly agreed that the quality that is most difficult to achieve is

what the user requires. Unless the user requirements and expectations are well

specified in the first place there is room for a lot of acrimonious debate regarding

software quality. It is virtually impossible for a project manager to commit to fulfilling

expectations within an agreed timescale or at a specific cost unless those expectations

can be made explicit in terms of precise requirements that can be tested. From our

discussions in Unit 1 and Unit 3 you will remember that when the basic characteristics

of the project are difficult to define it may be necessary to develop a prototype to

clarify the what questions before the project can proceed using a basic project life

cycle or phased approach. This is not to say that requirements cannot be changed

at a later stage. The requirements specified at the contract stage may not be the

same as the client’s real requirements at the end of the project. This need for

change will be discussed later in this unit.

The problem of how to measure software quality is discussed by Wesselius and Ververs

(1990). They identify three components of quality: part which is objectively assessable,

part which is only subjectively assessable and part which cannot be assessed at all.

Clearly it is desirable from everybody’s point of view that as many as possible of the

user’s expectations should be defined in terms of objectively assessable requirements.

Requirements are often classified as functional or non-functional.

Functional requirements express what the software will do. For example: ‘the supervisor

must be able to retrieve from the employee database the hours worked for all staff

reporting to him/her’. The initial requirement expressed by the user may be rather

ambiguous and the functional requirements will need to describe the function in more

detail, specifying inputs, outputs and exception conditions. For example: ‘the staff

records will be accessible based on a number of parameters’, ‘the supervisor must be

able to distinguish between standard hours worked and overtime hours worked’.

Functional requirements should be complete and consistent, meaning that there

should be no omissions and no conflicting requirements. For large systems, this is

not easy to achieve as many stakeholders have many differing needs and it is easy

for requirements to be missed and for inconsistencies to arise. Specifying

measurable requirements and adopting a structured approach to documenting

You will find this paper‘Some elementaryquestions on softwarequality control’ on thecourse website.


requirements helps to reduce the problem. One such approach is the Volere

requirements engineering method (Robertson and Robertson, 2006).

Non-functional requirements generally relate to qualities which the system must

possess, such as reliability, rather than individual features of the system. While modern

software engineering practices often allow features to be changed or added without

major rework, a system which fails to satisfy a non-functional requirement may be

unusable. Sommerville (2007) uses the following classification for non-functional

requirements:

Product requirements: usability, efficiency, reliability, portability

Organisational requirements: delivery, implementation, standards

External requirements: interoperability, ethical, legislative

Other models for non-functional requirements or software quality factors have been

proposed and Galin (2004) includes a good discussion of the work of various authors.

It is difficult to pin down non-functional requirements, but help in specifying these

requirements may be provided by using software metrics. A metric is a numerical

measure of some quality of the software which might otherwise seem subjective.

For example, reliability can be measured by ‘mean time between failures’ or ‘probability

of unavailability of the system’, portability can be measured by specifying ‘the number of

target systems’ or other environments (such as Windows XP or Unix) into which the

product will be installed. During testing these measures are used to check whether the

system satisfies the non-functional requirements.

ACTIVITY 2.1

Suggest how you might devise a metric for ease of use of a piece of software.

Discussion ............................................................................................................

A metric for ease of use might be specified by measuring the performance of users of

the software in comparison with their performance on other software with similar

capability. For example, you might measure the time taken for experienced operators to

perform a given list of operations on the system.

There are many metrics for software usability which you might have thought of; among

the most common are ‘time to train a new employee’ on a given list of operations.

Improving usability of software systems is an area of active research.

Finally to conclude this discussion of software quality let us return to the need to

measure quality of the software process. Management needs measures of effectiveness

in order to identify improvements to development procedures and maintenance and

support procedures after installation of a new system and to improve the management

of software development projects.

Within the software industry such metrics are usually split into two categories:

Process metrics: relating to the development and management practices before

system installation

Product metrics: relating to the maintenance and management practices after

system installation

Process metrics include defect counts, earned value information, development

productivity measures and measures of code reuse. Product metrics include number of

helpdesk calls, counts of system failures in operation and system availability metrics.

For the project manager to be able to monitor performance and make comparisons

between projects measurable targets need to be set which take account of project size.


Two measures for quantity of software were discussed in Unit 2 and the supporting

material on the course website: KLOC (thousands of lines of code) and FP (function

points). A project manager can therefore monitor and compare metrics such as defects

found per FP from quality reviews and testing and take appropriate action to improve

quality of the development process.

Mature organisations in the software industry as defined by the CMMI standard

mentioned in Section 1 actively establish quantitative objectives and measure

performance in order to improve processes and standards based on measurable

targets. CMMI is discussed in more detail in Unit 7.

ACTIVITY 2.2

Suggest how you might devise a metric to measure the success of helpdesk services

within a software company.

Discussion ............................................................................................................

A product metric for the success of helpdesk services might relate to the ability of

the helpdesk to solve customer queries within a given time. Such service level

agreements (SLA) can be defined within a service contract. The project manager

can then compare the actual performance with the agreed service levels over a

defined period of time. If actual performance falls below the required level, the

manager will need to identify the cause of problems with the service, perhaps

using Pareto analysis (which was discussed in Unit 1) and take action.

Note that the number of calls to the helpdesk is related to the usability of the software

and the effectiveness of the user manual and on-screen help facilities. Analysing a

metric for density of calls to the helpdesk, for example number of calls per KLOC,

will lead to improvements in usability of software.

To summarise the importance of metrics in software quality, consider our discussions in

Activities 2.1 and 2.2. First, measurable requirements for the qualities the software must

possess, such as usability, are defined. The developer can then demonstrate to the

client that the software design matches the requirement and subsequently product

metrics can demonstrate that the software performance during, say, the first year of

operation is acceptable. Any deviation from the target metrics can be investigated as

part of a continuous quality improvement programme for software development and

maintenance.

Validation and verificationThe terms validation and verification are used to distinguish two different kinds of

activity in quality assessment. Validation is the process of checking that a product is

what the client requires, whereas verification checks that the product produced at one

stage conforms to the specification that was supplied to it, not necessarily in the form of

a user requirement. For example, one validation activity may be to invite the client to

send some typical users to check that they are happy to work with some particular

method of inputting data. A verification activity at this stage would check that the way

the data was to be input agreed with the design specification.

Boehm translated these terms into:

Verification: ‘Are we building the product right?’

Validation: ‘Are we building the right product?’

(1981, p. 37)

For more informationon software qualitymetrics, seeGalin (2004) andSommerville (2007).


Reviews and testing are the key activities involved in validation and verification. We have

already discussed quality reviews in some detail in the previous subsection and will

concentrate on the specific activities of software testing here. The principles involved in

testing a product or part-product will also apply to many other types of project.

Testing for software qualityTesting is an integral part of software development. It needs to take place at all stages

so that faults are found as early as possible and the cost of rectification is minimised.

Sommerville (2007) describes a general approach to testing which identifies three major

stages:

c component (or unit) testing

c system testing

c acceptance testing.

These tests have been listed in the order in which they will generally occur. This is also

an order that represents an increasing size of scope of the test being conducted.

However, remember that in a phased or incremental project life cycle, the testing will be

spread throughout the project duration as each part-product becomes available.

Software testing is complicated by the fact that four distinct aspects need to be tested:

c it functions as required

c it is as correct as possible (errors are found and eliminated – debugging)

c it performs as required: it is robust enough, fast enough and efficient enough to

meet requirements now and for the foreseeable life of the product

c it is usable by its intended users.

These may seem self-evident, but it is perfectly possible to have software that is logically

correct but does not function as required, or to have software that functions as required

but is not robust or does not operate fast enough. An example is provided by the

London Ambulance Service project.

Although the developers in the London Ambulance Service project had trouble getting

the function right they largely solved the problem. However, the system contained a very

simple error that caused it to fail disastrously after a few days, nor was it robust enough

to withstand the failure of one of its components: the file server. It was also too slow for

peak requirements and had very serious usability problems.

Component testing

Component testing is the testing that a programmer performs on their own code during

the development of a unit or module. As far as possible the programmer will want to

ensure that the unit behaves as required and conforms to good programming practice.

The component test is the lowest-level test and therefore the most detailed. The

programmer should be able to ensure that as much of the code within the unit as

possible is exercised. This testing may require special code to be added to the unit to

simulate interfaces with other components or for diagnostic purposes that is later

removed or rendered inactive.

System testing

Sommerville (2007) describes system testing as a multi-stage process, involving

integration testing, release testing and stress testing.

Integration testing is the testing that takes place when components are combined to

provide a useful functional grouping of components or components providing common

services. These groupings are sometimes called subsystems. This testing concentrates

on the interfaces between the components and seeing that they work correctly together.

The LondonAmbulance Servicecase study is availableon the course website.


Additional code may need to be added to simulate components or subsystems not yet

included in integration. It is worth noting that a mismatch between what one component

expects of another should have been identified at the design review stage. Integration

testing will nevertheless reveal those occasions when the review has inadvertently

allowed a mismatch to slip through. Integration testing is primarily concerned with

identifying defects as compared with the specification and it is therefore a verification

activity.

Release testing is the first testing of a version of the system which could be released

to the customer. In the basic project life cycle this would be a complete system;

however, when adopting a phased or incremental approach to development, this will

be a part-product which will be of use to the customer. The testing team will verify

that the release satisfies the requirements specification and if the customer is involved

in devising the tests, then release testing also helps to validate the system.

Stress testing (or performance testing) demonstrates that the system satisfies specified

qualities like robustness and speed of execution. These are factors that are difficult to

estimate with precision at earlier stages. Once all software and hardware has been

integrated it is possible to ensure that the speed of response to a user’s or an operator’s

actions is adequate, that the rate of working overall will meet the requirements and that

the system is robust enough for its intended peak loads and is unlikely to fail

catastrophically. A series of tests needs to be devised which overload the system

beyond the design limits. If a system is intended to be able to respond to 10 requests

per minute the tester might subject it to a request rate of 20, 50 or 100 requests per

minute to see whether it behaves acceptably. An orderly queue building up might be

acceptable but random acceptance of the requests might not be. Severe stress testing

(until the software fails under the load) will indicate what are the maximum parameters

under which it will operate in an acceptable way and what behaviour it will exhibit when it

fails. Rigorous stress testing is important in systems such as the London Ambulance

system.

Acceptance testing

Acceptance testing is the final stage of system testing before the system can be

released. This stage of testing uses data supplied by the customer and finally validates

the system for operational use.

Acceptance testing is often known as alpha testing. This is the formal testing against

agreed criteria for the fulfilment of the contract between the developer and the client.

These tests may be repeated until the client confirms that the developer has fulfilled all

obligations.

Beta testing is used when a new version of a product is to be released to many

customers. At this stage the system can be used by real users but in an exploratory way,

to ensure that they are happy with its behaviour before they become committed to using

it in routine fashion.

It is at this stage that usability is most severely tested. Typically there would need to be

special support for trials at this stage so that in the event of faults appearing the user has

expertise available to overcome the sort of teething problems that may be expected.

The system can then be modified and released for further beta testing or released for

general use.

Tools for testingTesting is a lengthy part of the software development process and hence contributes

significantly to the cost. It is the iterative nature of testing which contributes to the cost.

Consider the need to test a new function of the system which requires a new group of

components to be integrated with a previously tested group of components. Errors may


become apparent during the integration testing which can be attributed to errors in the

newly integrated components or errors in previously integrated components which

come to light with the addition of the new functionality. Several components may need to

be changed to correct the problem and component testing and integration testing will

need to be redone. This process of rerunning previously completed tests is called

regression testing. It is useful to have a range of automated standard tests which can

be repeated very rapidly when it is expected that virtually every test should be passed

without trouble. Tools which automate the testing process can therefore speed up the

process and reduce cost. In some methods of software development, for example

extreme programming (XP), whenever new code is integrated the complete set of

previously run tests must be executed successfully before the new code is accepted.

An automated testing environment is essential using such methods.

Sommerville (2007) lists a number of types of tool which may be available to the testing

team:

c tools to keep track of data, expected results and tests completed

c generators for test data

c tools to predict expected results

c tools to compare test results with previous results

c report generators

c analysers to count how often code has been executed and therefore tested

c simulators.

SAQ 2.3

Why might it be necessary to perform regression testing of components after they have

been integrated with others?

Planning for testingThe tests that are to be conducted, the purpose and order of the tests, the people, the

procedures and the resources all need to be planned for and documented in advance.

As testing has a high customer involvement the availability of stakeholders to specify or

perform the testing needs to be planned with the client. To successfully validate the

system, system testing and acceptance testing need to be based on an agreed

definition of requirements. Ince et al. (1993) suggest that the following information

should be contained in most test plans:

c the objectives of each kind of test

c the criteria determining when a particular testing phase is complete, e.g. when

integration testing is complete

c the test schedule

c individual responsibilities

c resources required:

c support software, including testing tools

c hardware configuration

c the amount of computer time

c personnel

More informationregarding XP can befound in Beck (2000)Extreme ProgrammingExplained and in Unit 7.


c testing strategy, including procedures for:

c identifying, generating and documenting test cases

c tracking progress

c stress testing the software

c reporting and correcting detected errors

c regression testing

c documentation produced

c test procedures.

(p. 185)

This list may raise a few questions. Why should we need criteria for when to regard a

particular testing phase as complete? The obvious answer might seem to be that testing

is complete when no more faults can be found. The trouble with this answer is that it is

impossible to say when the last fault has been found because you cannot know that

another will not be found tomorrow. Hence some criterion is needed which reflects the

importance of diminishing the estimated number of undiscovered faults to as few as

possible, balanced against the likely testing effort required to find another fault. Testing

to ensure perfection is impossible.

It should be noted that scheduling the testing relies on making decisions concerning the

order of integration of components and the plan of releases to the customer. In situations

where the customer has close involvement with the project, the order can be based on

customer priority. However, there may be design issues which determine the order of

integration such as the need to implement components supplying infrastructure services

first, for example database access. It is also worth considering integrating components

which will be used most frequently by the customer first. These components will receive

most testing and therefore are more likely to be defect-free.

Who does the testing?There are several candidates for the job of testing: the software designer, the

programmer who wrote the code, other members of the software development team,

an independent test team and customers, or technical people from the client’s

organisation. You might use these different candidates in different ways at different

phases of the testing.

At the component testing stage it is usually the programmer who does the testing

initially, especially while the code is still subject to frequent correction as a result of the

testing. The programmer knows the structure and can devise tests that will exercise the

program to the fullest possible extent. Also, the efficiency of detecting a fault, correcting

it and retesting is likely to be higher at this stage if just one person is involved. Then

there is a human factor to consider: the satisfaction to the programmer of producing

tested components rather than components which have faults which someone else will

discover.

However, the programmer lacks independence and the same weakness that caused an

error to exist in the code may also cause that error not be tested for. There is also the

problem that, unconsciously, many programmers design tests to show that the module

they have written works, and such tests tend to find fewer errors than if the tester sets

out, instead, to break the module in order to reveal as many errors as possible. So once

the programmer believes that the software is ready for integration it is advisable to

scrutinise it independently. In extreme programming (XP) the concept of pair

programming is used so that two programmers work on a module together to

independently assure quality on a daily basis.


However, this independent scrutiny can be supplied by someone who has been trained

for this purpose. An independent team of testers will develop skills in testing so that they

will find more of the errors more quickly. They should also have been trained to present

their test results in a way that will not cause ill-feeling in the programmer concerned.

Whether such a team is available to the project or not, someone with a quality assurance

(QA) role (not necessarily in a QA department) should sign off the documents that show

which tests have been performed and the outcome of those tests. The documentation

should be so arranged that those same tests can be replicated if necessary.

SAQ 2.4

(a) Complete Table 2.1 below by indicating whether a particular type of test will

certainly or possibly test that aspect of software quality. We have completed one

column using two ticks (33) for certainly, one tick (3) for possibly and a cross (x) for

not at all to show you what is wanted.

Table 2.1 Test type and quality aspect

Quality Component

test

Integration

test

Release

test

Alpha

test

Beta

test

function 33

correctness 33

performance x

usability x

(b) We have left regression testing out of Table 2.1. Can you think why?

Preserving the qualityAs we have already discussed, there is a danger that further modifications to tested

software undermine the quality of that software. Any modification, no matter how trivial,

invalidates the testing to the item, so that it is no longer possible to guarantee that this

software passes the tests. To avoid this danger the tested software, whether at the

component level or after integration with other subsystems, should become an item

under configuration management. This means that it is an identifiable object that will

subsequently be changed only after proper procedures have been carried out. In recent

years component-based software engineering (CBSE) has emerged which relies on the

reuse of previously tested components or integration of commercially developed

components (commercial off-the-shelf systems or COTS). The process should reduce

cost and risk because products of known quality are integrated. However, change to

any of the components reduces these benefits. Change can occur because externally

provided components change or change to components is necessary to meet specific

requirements. Careful control of change is necessary to avoid losing the benefits of this

approach. We discuss configuration management in detail in Section 4.

2.3 Auditing a project

The main aim of an audit is to reduce uncertainty.

An audit is an official examination that is usually performed against a specified

standard. Although the most commonly known type of audit is a financial audit – an

official examination of the accounts of an organisation – this is not the kind of audit with

For more information onCBSE see Heinemannand Councill (2001).


which we are concerned here. In project work we are most often concerned with two

types of audit: a general project audit to determine the status of the project and a quality

audit to determine how closely the processes adhere to standards and how closely the

products match the user’s requirements. (The term audit implies a degree of formality.

However, an incoming project manager taking over an existing project would normally

need to conduct an informal audit of the project to check its status.)

A project audit, in contrast to a financial audit, is an appraisal of the technical status of a

project, or a specified part of a project, and will most usually be performed during a

project rather than at its end. A project audit is performed by an independent auditing

body external to the project team; it is conducted in a formal and systematic manner,

and its object is to assess the project’s current status and future prospects in

comparison with the project requirements.

The quality audit is a planned examination of all or part of a project by:

c determining whether practices conform to specified standards

c critical analysis of the deliverable that is the result.

It differs from a project audit in that its focus is on adherence to standards and the

QA aspects of the project. It is usually carried out for the specific purpose of

checking that quality standards are being applied when:

c a quality problem is suspected, and a manager would appreciate a fresh look at the

area by an impartial observer

c a company’s business requirements are such that it must be registered as

conforming to an external standard (e.g. ISO 9001:2000 which refers to quality

management systems). This may be to conform with the client’s requirements, such

as conditions for tendering for government contracts. In such cases internal audits

are necessary to prepare the company for audits by the registering body.

In what follows we shall not distinguish between a project audit and a quality audit

because, although the quality audit is aimed specifically at quality standards, both kinds

of audit contribute to quality. The purpose of the project audit is, in the end, to ensure

that the project achieves quality by producing the correct end-product for the agreed

price, with work completed according to the agreed schedule. It takes a wider view than

design or progress reviews, looking not just at one deliverable or one aspect of the

project, but at the totality of work carried out up to the time of the audit, the work that

ought to have been done and the work remaining to be done. It compares what it finds

with what it expected, based on the contract and its supporting documents, and makes

recommendations on how any deviation can be corrected. Thus a project audit helps

ensure that the project produces what it should.

Who does the auditing?Auditors must be independent from and external to the group being audited so that

there can be no accusation of bias nor temptation to justify the status quo. Their function

is to discover the facts. Auditing usually requires a small team, typically about three or

four highly skilled people, but the team may be larger if the audit is a big one or it may

consist of just one person, say the quality manager. Although auditors must be external

to the group being audited they need not be external to the organisation. Audits can be

either internal or external.

The auditors need to be mature people who will be convinced only by arguments

supported by evidence. Yet they need to be sensitive to the feelings of the people

whose area is being audited. It is very uncomfortable for the people being audited to

have their work examined so closely by outsiders. The auditors therefore have to be able

to gain cooperation and respect.


Chilstrom (1983) suggests requirements for prospective members of an auditing team.

Criteria in the selection process would generally include but not be limited to the

following:

c specialist or generalist (an audit team needs a good mix)

c must have professional acceptance at all levels

c technical competence in specialised areas

c analytical mind, articulate and personable

c writing and listening ability

c maturity and adaptability

c experience of supervising staff

c no project involvement – to increase objectivity

c enthusiasm for and support of the audit assignment.

In addition to Chilstrom’s list we would add that, above all, the auditors must have the

determination to uncover the truth and the integrity to report it honestly and impartially.

When to auditAn audit is usually a short, sharp exercise. It could take as little as a day but more

typically takes about two weeks of investigative work together with another week or so

for preparations and for reporting afterwards.

The audit may arise in various ways. It may have been planned at the outset of the

project. If a project is technically or managerially complex, the need for an audit may

have been identified at the contract stage to satisfy both the client and the contractor

that the project is not exposed to excessive risk in its later, usually more expensive,

stages. Alternatively, an audit may not have been planned but arises when the requester

wants to establish project status, perhaps because the project appears to be in

difficulty, or because of a change of ownership, or perhaps because the project

manager feels an audit is required. The request will often come from a concerned client,

worried that a late project will mean financial loss, but an audit may also be requested by

other parties who have some stake in the outcome. The right of a party to call for an audit

may be written into the contract.

The project is usually in progress. An audit is more useful as a tool for assessing the

progress of an ongoing project than for reporting on the achievements of a completed

one. Unlike a financial audit, project auditors are often expected to make

recommendations or at least to clarify the status. The future conduct of the project may

be materially affected by the auditors’ actions.

The timing of an audit depends very much on the circumstances. If it is a planned

audit it will probably follow the end of a key phase of the project and contribute to

the decision making regarding the future of the project as in a gate review. An

unplanned audit may be required at any time. The only general rule seems to be that

an early audit of a project is likely to be much more useful than a late audit because

there is then much more time in which to make use of the auditors’ work. Note the

contrast here with the usual financial audit that might be expected at the end of a

project. This does not mean that an audit, or evaluation, at the end of a project may

not be useful for the future conduct of other projects (see Section 5).

An audit is expected to reveal not only current status but also likely future prospects so

that the recommendations of the report can influence the future conduct of the project.

An essential feature of the audit is the comparison with project requirements: the

auditors have to consider not only the current status but also the project’s expectations

as expressed in the contract.

Chilstrom’s article isreproduced as thepaper entitled ‘Projectmanagement audits’ onthe course website.


How is auditing done?An audit is formal and systematic. It will be initiated formally and conducted with a

prescribed scope, to produce a report within a given time. Systematic methods ensure

that the conclusions of the report are properly justified as confirmed fact, free from

subjective judgements.

c The audit must be focused on a particular topic (a process, procedure or

deliverable).

c The criteria against which the audit is to be made must be identified.

c The audit team must be properly briefed and must be given access to all relevant

documents and personnel.

c The audit team must be given adequate time and resources to produce a proper

report, but reports should be prepared within an agreed timescale.

c There should be no prior indication from management as to what results they

expect.

c The report from the audit team should be reviewed with the relevant managers

(project manager, senior management in client and contracting organisations,

quality manager).

c Any disagreements should be recorded in the report or, if these are a result of error,

the report should be corrected.

An audit may be considered to consist of the following six phases (described in more

detail in Chilstrom’s paper):

c Phase 1: initiation and planning – agree the purpose, constraints, terms of

reference.

c Phase 2: establish project baseline – what was expected at this point according to

the contract and all agreed changes.

c Phase 3: investigation – gather the facts and record where they have come from.

c Phase 4: analysis – try to draw conclusions from the data.

c Phase 5: report and present conclusions – report to the requester of the audit and

other parties as agreed at the outset.

c Phase 6: termination – evaluate the audit.

SAQ 2.5

What are the features of an audit that distinguish it from:

(a) a visit by senior management

(b) a major design review

(c) a progress report

(d) a project evaluation after termination?

The health checkSo far in this subsection we have looked at the formal approach of auditing to reduce

uncertainty in projects. At this point it is worth remembering that in Unit 2 we discussed

the activity of risk management as a way of reducing uncertainty in projects. This activity

is an integral part of the management of a project and therefore does not exhibit the


independence or big picture of an audit. The project health check, which we identified in

Unit 5, may be interpreted as a way of managing risk and reducing uncertainty which

addresses these issues. Buttrick’s health check, for example, identifies seven key areas

which need to be assessed as the project progresses in order to identify project risk at a

given point in the project (2005, pp. 447–51). These key areas are similar to the critical

success factors discussed in Unit 1. A set of pre-defined questions are used to assess

the degree to which a project has the following:

c a clear project plan

c sufficient resources to do the work

c stakeholder ownership of the project

c a justified business case

c expertise to do the work

c a clear specification of what needs to be done

c top-level support.

Data concerning the seven key areas can be collected from senior management in the

client and contracting organisations, the project team and stakeholders. A profile for the

project can be calculated, identifying areas of risk which must be addressed if the

project is to be completed successfully. A simple statistical analysis of everyone’s

responses is used to provide an assessment of the project’s current health, so that the

project manager can decide in which direction to apply the subsequent effort.

The topics to be assessed could be tailored to a particular project by considering

the success criteria and critical success factors defined for this project as we

discussed in Unit 1. Wateridge (2000), in his version of the project health check,

places an emphasis on:

ensuring that all stakeholders agree on the success criteria and are, therefore,

pulling in the same direction.

(p. 151)

The use of critical success factors to define the health of a project retrospectively at

completion of the project in order to identify lessons learnt is discussed in Section 5

of this unit.

2.4 Summary

This section concerned the actions that the project manager and others can take to

maintain the quality of the project during the execution stage. (At an earlier phase a

quality policy and quality activities were put in place, defining standards to be used,

ensuring well-defined requirements, sensible estimates and good planning.)

At the execution phase we are concerned with products that are being or have been

produced. The most important activity is the quality review, of which the prime example

is a design review. Other activities include testing, walk-throughs and inspections.

Assessing quality measures from quality reviews and testing can help to predict product

quality and help with quality improvement.

The conduct of a design review was described in detail. Maintaining the quality of

software production was used as an example.

Auditing a project was described: a general audit determines the status of a project and

a quality audit determines how closely the products match the user’s needs.

See the course websitefor some moreinformation on projecthealth checks.



c outline the activities performed to maintain quality during the execution phase of a

project

c describe the conduct of a design review

c differentiate between a progress review and a quality review

c illustrate quality monitoring with specific examples on software quality

c explain the value of a metric

c outline the various kinds of testing that may be performed for software (and similar

products)

c describe a project audit, a quality audit and the health check; explain how they

differ, how, when and why they are done and by whom.


3 Change: cause and effects

This section discusses two kinds of changes: those that have obvious external impact

and those that appear to be internal to the project. Changes may be called external if

they directly affect the contract with the client: the need for their control is self-evident.

Changes which are internal affect the working relationship between members of the

project team. This section establishes the need to control not only the first kind of

change but also the second.

The consequences of a change can be out of proportion to the actual change made.

A small change in the user’s requirements late in a project may mean a radical

rethink by a top-level designer. The consequence of a change of design at the top

level is amplified in the lower-level design and construction work. An experienced

designer should perhaps be able to anticipate some requests but there is a limit to

how much tolerance to change can be built in. Later in the project it may be necessary

to make changes at a low level in the design very quickly so that the project meets

its schedule. The effects of some changes may not be apparent until long after the

project has been completed. An undocumented change can lead to chaos later.

If there is a large amount of uncontrolled change the result is lost effort. This contributes

not only to overspending on the project but also to poor morale in the project team.

Change for which no plans or provision of resources have been made can also

adversely affect the allocation and utilisation of resources on the project: for example, by

causing unexpected and expensive reworking. Allocation and utilisation of resources on

linked projects within a programme of work or on other projects competing for common

resources can also be affected.

All this sounds depressing and some project managers may react by attempting to ban

all change. However, in spite of the difficulties, it is impractical to prevent change,

whether external or internal. The answer is to organise the management, development

team, testers, the users’ representatives and the client in some way in order to cope with

the effects of change and to minimise its disruptive impact; this is change control.

A change control system should include the following elements:

c a means of defining the current state of the item, to which any change is referred

c a means for submitting and recording proposals for change

c a mechanism for evaluating the impact of the change, including cost, time and

effects on others

c a decision-making authority to approve or reject

c a method of recording the approved (or rejected) change and the rationale behind

the decision

c a means of publishing the change

c a method for updating the plans

c a means of monitoring the implementation of the change.

The use of change control is appropriate to all projects concerned with developing

products, particularly those that are large or complex or both. All projects will employ

some kind of change control, even if it is not known by that name, with varying degrees

of success. However, it is important that the correct type and amount of change control

be employed: for large projects extensive, strict and formal control will be required; for

smaller projects a minimal amount of control may be indicated, conducted informally.


Measuring changeThe discussion of testing in Section 2.2 alluded to the relationship between the number

of changes and likely defects. More testing will be required if many changes are made,

so the project manager will have to assess the implications for the plan.

Managing change is usually considered to be a part of quality management as

discussed earlier in this unit. Change control systems are essential for quality

certification in both ISO 9000 and CMMI. Change is also a measure of the quality of the

evolving product. The rate of change in a product indicates the stability and maturity of

that product. For example, the number of change proposals raised gives the project

manager an indication of the quality of that product. If changes are requested to correct

errors, then the project manager may wish to investigate the cause of these errors and

take corrective action. However, if changes are requested to introduce new features,

this may not necessarily imply there was a problem in the definition of requirements,

but may reflect an evolutionary change in requirements as a result of increasing

familiarity with the proposed product by the customer. In either case, the project

manager needs to monitor the rate of change in order to control change and

communicate the impact of such requests.

In software systems the number and type of outstanding change requests are often

defined as part of the acceptance criteria and used by the client as one of the tests to

determine whether the product is accepted or rejected. It is also worth noting the need

to decide whether a change is relevant and also whether the cost and effect of the

analysis should be borne by the project. This is particularly pertinent when major

change requests with substantial cost and effort implications are received during the

implementation stage. For example, the client organisation might have instigated a

major strategic change such as a rebranding that could well have a significant impact

upon the user interface for the software system under development. If the time needed

to implement the change request is close to the time remaining before the existing

handover date, the project manager may well decide that it should be a new project.

3.1 Changes to project deliverables(external changes)

Proposals for changes to project deliverables will usually arise because the client now

wants something different from what was previously agreed. The proposal for change

may come from within the project team because a team member thinks that the client’s

needs have changed or because the original proposal is not cost-effective or because a

better way of satisfying the client’s needs has been identified.

Initially, neither those who want the project performed nor those who undertake it fully

understand each other’s needs. Furthermore, despite efforts to keep fixed what the

project is to achieve, new facets requiring development are always uncovered during its

execution. These two factors naturally lead to changes in the project’s aim, which in turn

result in changes to its design and implementation. Often the designers and clients

understand the requirements fully only when most of the deliverables have been

produced. At this late stage the effects of changes can be enormous.

It is quite common for some change in the project’s external environment to occur: the

market for the product changes, a new technique or a new component becomes

available, resources required may not materialise, a machine that was to be purchased

is no longer manufactured. The changed environment may imply a changed aim,

a change in the design, a change in the way of working or even cancellation.


Nearly all project managers recognise the need to cater for these changes because

they have an obvious impact on the project scope and the payment to be received from

the client. A mechanism for handling them should be agreed between client and

contractor as part of the contract.

There is usually a standard form for the purpose of requesting and approving changes

to a project, such as that shown in Figure 3.1. Harrison (1992) says that it should contain

the following information:

1 It identifies the change, describes it and gives the cost account, work package or

cost control number it affects.

2 It gives the reason for the change.

3 It identifies who is initiating or requesting the change and provides for that person’s

signature.

4 It gives a first descriptive appreciation of the consequences of the change and the

segments of the project it affects.

5 It gives a rough estimate of the effect on the project schedule.

6 It gives an order of cost estimate of its effect on cost.

7 It can optionally give a code number to identify the cause of the change for

post-project analysis, for example: customer request, late design change,

error/omission in design, legal, environmental reasons, increase in economic return.

(p. 206)

If the same form is used to record the stages of approval and implementation,

the following information should be included (Sommerville, 2007):

c change priority

c who analysed the change initially

c date change approved

c responsibility for implementing the change

c implementation notes

c date completed

c date submitted to QA

c QA decision

c date submitted for implementation approval.


Once approved the change needs to be incorporated in the plans and budgets.

For example, the earned value system discussed in Unit 5 will need an amendment to

the BCWS otherwise the work performed will be compared with an inappropriate plan.

Too often you see exaggerated reports of projects which have overspent, with the

implied criticism that the project management has been ineffective. These reports would

be unfair to the project manager if it is the client who has decided that new requirements

should be introduced and a revised budget has been agreed. It has to be clearly on the

record that the impact of the change on cost and time has been discussed with and

approved by the client.

3.2 Internal changes

Internal changes are often not as tightly controlled as external changes. By internal

changes we mean changes that are confined to the internal work of the project:

apparently not requiring consultation with the client because the agreed deliverables

are unaffected. For example, it may be found necessary to correct mistakes or desirable

to make improvements in designs that may have been thought complete.

Consider for example a software project that uses a top-down, stepwise refinement

method of development. This means that the aim of the project is defined first, the

outline design is produced next (high-level design), followed by successive design

levels down to the detailed technical information before construction begins. In

principle, the top-level designers conceive the whole design at once and divide it up

with well-defined boundaries between all its components. But these top-level designers

are fallible, and it is likely that revision of at least one level of the design will be needed

for a project requiring more than a few months of effort. So the members of the

development team generate change themselves as they realise, when attempting to

Project:CHANGE REQUEST

Number:Revision:Date:

Item affected: Name:Work package:

Item no(s):Change requested by:

Description of change:

Reason for change: Code:

Items/areas affected by change:

Initial estimate of cost or saving:Firm estimate:Effect on schedule:Analysed by:Date:

Change approved/rejected:Contractor signature:Client signature:

Date:Date:

Change priority:Implementation notes:Change implementor:QA decision:Date submitted for implementation approval:

Date completed:Date submitted to QA:

Comments

Figure 3.1 A typical change request form


expand a lower level of the design, that deficiencies in a higher level must be corrected

before they can make progress.

Another internal change is simply the correction of earlier mistakes. It may not always be

appreciated that correcting a mistake is making a change. The extent to which control

over the correction of mistakes is required depends on how far the original defective

item may have affected the work of others.

There are always interfaces between individual work areas and some overlap is

unavoidable as a result of the interaction between components even in a hierarchical

design. This leads to constant negotiation of the boundaries between the various work

areas and difficulty in providing each team member with exactly the information required

to carry out the job efficiently.

Design reviews help to keep a design coherent, but in a large project in order to

keep the review team manageable, only the designers whose work area is under

investigation will be involved. It would be a waste of people’s time for the whole team

to attend every review. Consequently, no one has a full understanding of the entire

design. Changes will result from errors detected in the reviews and also during

development work.

Change control is a form of communication. In a small project this can be informal

and unstructured without undue risk of the message (the change) being lost or

misinterpreted. However, a large project will require a formal, structured and

documented method of communication. Even in the smallest projects it is essential that

a record be kept of agreements between team members where the work of one affects

another. Communication using electronic mail is good for this sort of agreement

because of the ease with which a record is kept. Alternatively many managers of small

projects can assemble the whole team for a very short meeting each morning to make

sure communication takes place. The ‘stand-up’ meeting encourages effective

communication in a short time because there are no chairs!

To illustrate the need for control over internal changes, Example 3.1 describes the

progress of a typical software project in an organisation which employed change control

only over project deliverables.

Example 3.1 A defective internal change control procedure

The project was well defined, with a change control board to authorise all

changes to the project deliverables. In the early stages, each team member was

supplied with all the available information about the project, as the team was

composed of only four people working together to devise the initial, highest level

of the project design. Frequent reviews of this top design level took place, using

peer group review. At this stage, interaction between team members was

personal, so the originator could communicate all that was known about the

project to each team member and reviewer.

As the work progressed into successively lower levels of the design, the job

became more complex as more components were developed and more

information on both new and existing components was generated. More

designers were assigned to the team (as planned) but consequently the

personal interaction between all team members became difficult because of the

greater number of people involved. No single person kept track of all the

components being developed.

The project manager realised that communication between designers can

absorb large proportions of productive time so he told them to keep control of

their own work area and to disseminate information about the changes they


made to other designers only as necessary. With pressing deadlines, the

designers became less concerned with the performance of their colleagues and

failed to communicate adequately with them about the changes they were

making. They naturally put first priority on meeting targets for their own

deliverables.

As the work progressed, there were about a dozen people working on the

project, each of whom was responsible individually for ensuring that the

changes they made did not adversely affect other people’s work without prior

agreement. However, in such an environment, nobody was quite sure what

everybody else was doing or which version of each item of the design they were

using. As the communication paths are numerous in any team of a significant

size, the team spent a great deal of time communicating!

A change coordinator

It soon became apparent that the team members could not retain a knowledge

of their own work and disseminate it effectively to others, so frustration grew and

lack of progress was blamed on changes by certain team members which

affected others. The project manager asked for a volunteer to coordinate design

changes by acting as a link between those requiring change and those from

whom agreement was required. As the new coordinator could not possibly

understand the entire system completely and the ramifications of each change,

she could not present a full account of the requirements of each change to

either party, which resulted in arbitrary and distorted decisions. Several months

passed with no improvement and in consequence the unfortunate coordinator

bore the brunt of all complaints. At this point she collapsed under the strain and

left the project.

The point to note from Example 3.1 is that trying to communicate the effects of any

change after it has taken place is insufficient: it is important that the effect of a change is

understood before it occurs. The development team involved in that project would have

had to go through a traumatic reorganisation in order to re-establish control over

changes that affected the project’s internal conduct.

Agile software development methods, such as XP, deal with the problem of control of

internal change by frequent (usually daily) integration of new code followed by execution

of the complete set of previously run tests. We discussed regression testing in Section 2

of this unit. Errors found are reported back to the developers who make corrections

while continuing to expand functionality. This process works well in small projects with a

small development team and encourages rigorous component testing because

developers are embarrassed to deliver components which cause an integration test to

fail. Change control is still necessary in an XP environment as faults found, corrected

and outstanding need to be carefully monitored and many versions of components and

systems exist simultaneously and must be managed. External change must also be

controlled.

SAQ 3.1

In Example 3.1, do you think that the change control board proposed for changes to

project deliverables could have had its remit extended to include internal change?

Justify your answer.

There is more about theeffect of team size oncommunication inUnit 7.


ACTIVITY 3.1

Consider how changes are handled in your own area of work. Focusing on a particular

piece of work, write down in your project notebook how a particular change is handled,

including who initiates it, how its effects on cost and timescale are assessed and how

approval is given to proceed. Assess the suitability of this process and whether it could be

improved in the light of the previous discussion of the effects of uncontrolled change.

ACTIVITY 3.2

How will a change in project scope affect the earned value system? Consider in particular

what needs to be done about the value for the project budget and values for budgeted

cost of work performed and scheduled, and hence the cost and schedule variances.

Discussion ............................................................................................................

The impact of the change on the cost and the timescale will have to be estimated before

the change is approved. These changes will therefore be reflected in new values for the

project budget and for all budgeted values and timings of components affected. Actual

costs and progress are only fairly comparable with these new estimates.

When there are horrific reports in the press about amazing overruns in cost or time of a

substantial project the comparison is often being made with the original project scope

and timescale. Although such comparisons may be of interest politically, they more

usually reflect the amount of change to the scope of the project that has occurred rather

than the management of the project. This is not to say that the escalation of scope is not

of interest, but the distinction needs to be made in fairness to the project manager.

3.3 Summary

Changes create problems for project managers but it is impractical to prohibit them.

Changes that affect the project deliverables (external changes) are more often

recognised than changes that affect only the internal conduct of the project (internal

changes). Merely monitoring change is insufficient. Rate of change gives a measure of

the stability and maturity of the product as well as the effectiveness of processes used

within the project. External changes are often handled by setting up a change control

board, with membership from both client and contractor organisations, to agree the

changes before implementation. Handling internal changes is often more difficult, partly

because of the potential volume of internal change as designers see better ways to do

things and partly because of the problem of knowing exactly how to apply change

control procedures.


c explain the reasons for needing a system for change control

c list the elements which any change control system needs to contain

c outline the content of a suitable change control form and its purpose

c explain why internal changes affecting the interfaces between team members need

just as much attention as external changes.


4 Configuration management

This section outlines a formal method of change control called configuration

management. This is a way of conducting a project so that changes from all levels can

be handled. The section concludes with a discussion of issue management, which is the

process of dealing with threats to the project objectives that the project manager cannot

resolve. The topic is covered here because issues are often resolved by the

identification of a change and the same tools and recording mechanisms are used

for issues and changes.

4.1 An outline of configuration management

The term configuration management (CM) was originally applied to hardware systems

such as the production of an aircraft. It is now increasingly used in change control

systems for software and today this is probably the most significant area of its

application. Configuration management means the use of a management discipline

designed to ensure that a system retains consistency between its components when

parts of it are subject to change. Bersoff et al. (1980) give the following definition:

the discipline of identifying the configuration of a system at discrete points in

time for purposes of systematically controlling changes to this configuration and

maintaining the integrity and traceability of this configuration throughout the

system life cycle.

(p. 20)

Some people use the term configuration management as though it applied just to the

specification of some product after it has been tested. The techniques of configuration

management are then confined to ensuring the integrity of that product during its useful

life. This is only a limited use of the techniques of configuration management. The

definition given above includes the phrase ‘throughout the system life cycle’ and

implies a much earlier introduction of configuration management into the process.

If CM is used throughout the life cycle it means that it starts as soon as there is any

agreed document that will be used as the basis for later development work. It is this

wider-ranging use of the term configuration management that we will be assuming in

this course, based on the ISO definition:

coordinated activities to direct and control configuration.

(ISO 10007, 2003)

The basic idea is that the components produced during the development of a project

form a configuration of identifiable items which may be changed only in a

systematically approved and recorded manner. The items can be sets of documented

requirements, specifications, manuals, outlines for modules of software, drawings of

pieces of equipment, project plans, plans for testing – in fact anything that can be

identified and that contributes in any way to the end use of the project. The word

configuration means the totality of these components and the interrelationship between

them.

A key concept of configuration management is knowing which items in the configuration

are dependent on a given item, as in Example 4.1.


Example 4.1

In the design of a refrigerator it is likely that the specification of the door handle

is dependent on the specification of the door but is independent of the

specification of many other parts of the refrigerator, such as the motor. Knowing

this dependency will define the scope of the effects of changing any one item.

Notice that in this example we have used the phrase ‘specification of the door

handle’ rather than just ‘the door handle’. This is because we are usually

interested in documents describing or defining an object rather than in the

particular object itself.

The configuration is progressively built up as components are developed. At the

beginning of a project the configuration consists of the documents specifying the scope

of the project: the requirements specification. By definition, once this specification has

been authorised as a component of the configuration it becomes subject to the change

control procedures and work can begin on design. In a large project the requirements

may consist of a set of items rather than a single item so that the requirements

themselves can be subdivided. This would be the case in a project using a phased or

incremental life cycle as design begins in increments which relate to sets of

requirements.

Notice that the configuration does not include components which are still in the process

of formation. The burden of applying change control to a component while it was being

actively developed would be too heavy. Thus, during the development process, the

‘configuration’ forms only part of all the existing design, as shown in Figure 4.1. The

large box contains the items that are inside the configuration. These have been

identified and their subsequent progress will be recorded. No changes to them will take

place without authority. But outside the box there are components which are not yet part

of the configuration because they are changing day by day and have not yet reached

sufficient maturity to make change control appropriate. Remember that once a

component is mature enough to be used as the basis for future work change to that

component must be controlled.

configuration boundary

CI 4

DO

CI = configuration item DO = design objectdepends on

CI 3CI 2

CI 1

DODODO

DO

Figure 4.1 A configuration diagram showing configuration items and design objects


We shall call the items outside the box design objects and the items inside the box

configuration items. From a change control point of view we shall be concerned only

with the configuration items: the designer still has freedom to manipulate design objects

at will. It is the designer’s own responsibility to keep track of changes to design objects,

but no one else need know about such changes. For example, during component

testing a developer may correct errors in the component freely. However, once the

component is released for integration testing and change to the component may impact

other components under change control, change must be formally controlled and the

component becomes a configuration item. In fact a software component could be

described as four items: a description, source code, executable version and test plan.

It is particularly useful to have any interface agreements between members of a project

team defined as configuration items. In the case of the refrigerator, if the door and its

handle are being designed separately it would be sensible to get agreement first on

exactly how the handle will fit to the door so that both the handle designer and the door

designer can proceed independently. This agreed interface specification would

become a configuration item that both designers could rely on not to be changed

without their common agreement. The specification might need to be added to if other

issues arose that needed agreement before design of one or other of the dependent

components could proceed. For example, if Figure 4.1 represents a partial configuration

diagram for the refrigerator, item CI 1 could be the ‘handle/door fixing interface

specification’, CI 2 the ‘handle specification’ and CI 3 the ‘door specification’. To

complete the items in the configuration so far, CI 4 might be the ‘test plan for

handle/door operation’.

Freezing?Some people like to think of the transition from design object to configuration item as

‘freezing’ the object. It rightly conjures up the idea that the object is no longer fluid.

However, freezing is a little too strong a term. Configuration items may still need to

change, and under the discipline of configuration management they may still do so. The

more appropriate phrase to describe their state is that they are ‘under change control’

rather than ‘frozen’. For example, the refrigerator door handle designer may

subsequently realise that the specification of the fixing interface gives a problem when

she comes to select from a range of standard products. With the agreement of the door

designer the interface specification can be changed provided that no other team

member has since declared that they too are relying on that specification. All the team

members who had declared that they relied on an item would need to be consulted; in

this case the team member preparing the test plan would also need to be consulted.

SAQ 4.1

(a) What is the difference between a design object and a configuration item?

(b) What is the advantage of allowing design objects to exist in the project system?

(c) What is the advantage of having an interface specification recorded as a

configuration item separately from the complete specification of one or other of the

components that use that interface?

(d) What is the latest stage at which you expect the requirements specifications to

change from being design objects to being configuration items?

In answering SAQ 4.1 you will have realised that a configuration management system

must be set up at a very early stage in the project: ideally from the outset. It should then

remain in existence throughout the life of the system which it describes, so that it can be

used for maintenance until the system is dismantled.

Traceability is afundamental aspect ofconfigurationmanagement. So, indifferent domainswhere the process ofdesign has a potentialinfluence on theeventual product, suchas an aeroplane, eachdrawing would be aconfiguration item.


Constructing the configurationMost projects are constructed hierarchically from the top downwards; that is, the

highest-level design of the project is generated first, then divided into lower levels which

are themselves subdivided. This method of design and construction applies to most

physical objects and systems. Within each subdivision on each level of the hierarchy,

items should be identified whose concept and implementation can be grasped by

individual members of the project team. The design structure of the project is a natural

basis for the choice of configuration items.

For example, Figure 4.2 shows a part of the configuration diagram for the project to

develop this course. At the top are the course requirements which specify such things

as the subject of the course, its aims and objectives, the overall length, its academic

standard and position in the study programme. At this level there need be no mention of

how individual topics are to be treated or what the structure of the course should be. At

the next level is the course specification (produced by the course team) which shows

the structure of the course, the documents to be prepared and the topics to be covered

within each unit. The arrow from the course specification to the course requirements

shows that the specification is dependent on the course requirements. This means that

if the course requirements were to change then there is a potential impact upon the

specification. The meaning of an arrow from an item X to another item Y in Figure 4.2

means that item X ‘is dependent on’, ‘uses’, ‘invokes’ or ‘relies upon’ item Y, so that any

change to Y potentially affects X.

The configuration below the course specification fans out into specifications of each

booklet for the course, typically documents of about a dozen typed pages, showing the

proposed structure in terms of the topics to be included in each section. The

specification of the project management software package to be used with the course is

also dependent on the course specification. Units 5 and 6 comprise a single booklet and

so it is necessary at the next level in the configuration to develop outlines for each unit

within the booklet. The arrows from these outlines to the specification again mean that

they depend only on this specification. Below this the structure fans out even further into

the actual text for each section within the unit or a software item.

This purely hierarchical structure is an ideal which may not account for all the

dependencies between items. For example, there might need to be a dependency of

the software package upon the detailed content for Unit 5. This would be shown by an

additional arrow from the software package specification to the Unit 5 outline. A

dependency could be in both directions, which would mean that the two items depend

upon each other. The complete configuration diagram could look very complicated with

a large number of extra arrows showing the non-hierarchical links as well as the

underlying simpler structure.


In practice a database rather than a diagram is required to record the structure. There

are normally too many items to make a diagram intelligible. Computer tools are available

which can not only hold the data equivalent to this diagram but also provide the services

required for change control, status accounting and auditing which we describe later.

Several tools are available ranging from simple open-source tools such as Bugzilla to

expensive integrated systems covering most aspects of configuration management

such as Rational ClearQuest. If we continue to use the term configuration diagram it is to

be understood that the term embraces the equivalent information held in a database.

SAQ 4.2

What is the implication of a dependency link for the order of development of the items

linked?

The use of a design hierarchy such as the one shown in Figure 4.2 is not a prerequisite

for configuration management. Configurations can be set up in which there is no

particular pattern to the structure, so that the relationships are amorphous, as shown in

Figure 4.3. The relationship between components in an amorphous structure is more

difficult for a design team to comprehend, so some easily understood underlying

structure, such as the tree of Figure 4.2, is preferred, even if this has to be

supplemented by additional relationships.

When assessing the impact of change, the primary concern will naturally be with the

effect on those items that directly depend on the change. However, if in consequence

any of these dependent items themselves have to be changed, the effect will extend to

CI 5

depends onCI 4

CI 2

CI 3

CI 1

Figure 4.3 A configuration diagram showing a non-hierarchical structure

course requirements

course guidespecification

units 5/6specification

software packagespecification

unit 1specification

course specification

unit 5 outline unit 6 outline

section 6 textsection 1 textdepends on

Figure 4.2 Partial configuration diagram for this course showing a hierarchical structure


all the items that depend on those items, and so on. The most satisfactory design from a

change control point of view is one that reduces the interfaces between items to a

minimum thus reducing the knock-on effects of change.

Subdivision of items has advantages and disadvantages for configuration control. The

advantage of subdividing configuration items into smaller identifiable items is that any

request for change can be focused more precisely on the area affected. However,

below a certain level of detail it becomes counterproductive to subdivide items further.

The advantage of greater precision in identifying the item is outweighed at low levels by

the volume of items and the difficulty of interpreting requests for change when focused

on too small a detail.

For example, suppose for the purpose of precise configuration management the design

of this course were to be subdivided further than Figure 4.2. In Figure 4.2 the text for

each section of a unit is a configuration item. This precision would allow one author to

request approval for change to an individual section from the other team members. This

might be tolerable. However, if the sections were further subdivided into paragraphs,

the requests for change would be too numerous, too trivial and not easy to interpret. The

degree of subdivision of configuration items needs to be judged to minimise the overall

effort involved.

The mechanics of configuration managementThere are four main elements that make up the discipline of configuration management:

configuration identification, configuration control, configuration status accounting and

configuration auditing. In brief these elements serve the following purpose.

c Configuration identification identifies uniquely all the items within the

configuration.

c Configuration control is a system through which changes may be made to

configuration items.

c Configuration status accounting records and reports the current status and the

history of all changes to the configuration. It provides a complete record of what

happened to the configuration to date.

c Configuration auditing is the audits performed to ensure conformity between the

items in the configuration and their specifications. Audits ensure not only a match

between what is delivered and what was requested but also consistency throughout

all the project documents.

At project initiation a configuration management (CM) plan must be prepared which

describes the standards and procedures for configuration management which will be

used in the project. A CM plan should define the following:

c what is to be managed and the identification convention for items

c responsibilities for the CM activities

c the configuration control procedures the team will use

c the tools to be used and the information to be recorded in the database.

The four main elements of configuration management will be discussed in greater detail

in the rest of this section.

SAQ 4.3

(a) What is the scope of configuration management when it is used throughout the

project life cycle?

(b) What are the four principal elements of configuration management?


4.2 Configuration identification

Identification conventionsIn order to establish a successful method of requesting change, a clear identification

scheme must be adopted within the configuration. Therefore, once the structure of the

configuration and the unit of control have been chosen, each item must be identified so

that it is unique within the system and recorded in a register. The activity of registering

names is called configuration identification.

The exact identification scheme chosen is not significant as long as the identification

given to each item within the configuration is unique and always remains the same:

several people will be involved with the item in various capacities and confusion will

arise if its identification is changed. It is usual to split the identification into a ‘name’

which remains fixed throughout the life of the item and a ‘version reference’. For

example, a course unit could be called ‘Planning unit’ and to distinguish the second

version we could say ‘Planning unit: draft 2’. It would be difficult to keep track of the item

if its name were changed every time it was modified. In most discussions about the item

its name would be used by itself without the version reference.

Choosing item names

Names are best kept reasonably short but unique and meaningful: a name is tedious

to remember if it consists of a paragraph of text, but meaningless if it is merely a

single letter. It is tempting to make an item’s name correspond to its position in the

hierarchy, but this is not recommended because then the item’s position will be fixed

permanently. For example, if instead of the name ‘Planning unit’ we had used the

name ‘Unit 3’ during the development of this course, it would be rather inconvenient

if at a later date we had wanted to rearrange the units so that ‘Planning’ became the

second unit of the course.

Another disadvantage of names based on the current structure is that in order to use

the item in another application it would have to be renamed. Once it is renamed it

becomes a different item and any changes to the new item will have no effect on the

original, as the relationship between them will have been broken. Generally, schemes

which attempt to make names correspond to position work well for a short time, but

degenerate into confusion as the design is developed further. The naming scheme

may also inhibit sensible rearrangement of the design.

In large projects the naming convention must be planned early so that problems

do not arise later with name clashes. For example, if a project employs several

subcontractors it is necessary to ensure that names used by one subcontractor

cannot replicate names used by another. The name of an item should be chosen

so that it will be unique in the largest configuration ever expected for it.

SAQ 4.4

Judge the quality of the following names for configuration items:

(a) names section of change control unit

(b) motor bearing

(c) Y37

(d) door

(e) software component 4.


Labelling the items

Every configuration item needs to be physically labelled in some way to proclaim its

identity, in other words a label that says that this physical item is the item recorded in the

configuration register. For documents, the label is usually just the name and version

number written in some prominent place. For a physical item it may be an identification

tag or an identifier etched into it during manufacture. The point is that the label is

required to identify this object unambiguously as the item referred to in the configuration

register.

In the days before word processors it was easier to recognise a master document

because of the way it was produced, with corrections and amendments (sometimes

initialled) clearly visible. The use of word processors and computer-aided design

techniques has made it much more difficult to be sure a document is what it claims to

be, because it may have been copied and unauthorised changes may have been made

to it. Careful consideration must therefore be given to how the rightful owner of the item

name will be recognised. It may, for example, be necessary to produce a physical

document and have it signed and safely stored after it has been approved or to lock the

item in such a way that it can be replaced only by an authorised person.

Automated version management tools for software control the repository of configuration

items. To change an item the developer must check out a copy of the item. After the

changes have been made the item is checked in to the repository and the version

number is automatically updated. Simple tools allow only one copy of a component to be

checked out at any time, but more sophisticated tools allow multiple copies of a

component to be checked out and resolve clashes between different versions when the

item is checked in.

When a change is required, such as a modification to a piece of equipment already

operating in the field, there must be a simple mechanism for indicating that the change

has been carried out. For example, a circuit card may be etched with numbers which

can be scored out as each change is made. Although this is not so easy with software it

should be possible to identify which version of a piece of software is actually installed.

Ideally the identity label should be protected so that the version number cannot be

changed without authorisation.

SAQ 4.5

Identify one advantage and one disadvantage of including the project name in the

naming convention for a configuration item.

BaselinesIn a large project the development of numerous configuration items in parallel may lead

to a sense of chaos even though each individual item is fully under control. A technique

favoured by some project managers and clients to bring the development into order is to

impose a structure of baselines into the development. A baseline is the state of the

configuration, or a defined part of the configuration, at a particular point in the

development, usually at a major milestone in the system life cycle. A baseline may be

defined as a set of known and agreed configuration items under change control at a

discrete time from which further progress can be charted.

The baselines to be used in a project may be defined in advance in consultation

between client and contractor to give greater visibility to the status of the project.

A typical set of baselines is shown in Figure 4.4.


Each of the baselines shown in Figure 4.4 marks a plateau in the development of the

system. Briefly, these are:

c Functional baseline: requirements documents defining what the system is expected

to do.

c Allocated baseline: after initial outline design. Records what functions will be

performed by which parts of the system.

c Design baseline: after detailed design. All the detailed documents and drawings

show how the product will be built. Good basis for a design review.

c Product baseline: after developing the first article. The documents that describe it.

c Operational baseline: after testing and improvements. The baseline defines the

product in operation.

Not all projects need conform to these baselines. It may be more appropriate to

define a different set in a particular project to reflect the circumstances. For example,

at the end of a review of the status of a project the project manager may wish that

status to be on record as the baseline as at the review.

Note that a baseline need not apply to a whole configuration: it may apply to a

defined part of it. For example it is possible to select a particular subsystem or

part-product and to baseline all the configuration items that are relevant. This gives

greater flexibility so that not all parts of a system need reach a given baseline at the

same time.

Any given baseline must be identified uniquely so that anyone investigating the baseline

has a definite starting point. This means that the full status of the whole configuration at

that baseline needs to be stored and identified so that it is possible to retrieve it later.

The current state of a project can then be determined as the baseline plus all the

implemented changes.

operational state

production/deployment

first article development

detailed design

advanceddevelopment/validation

system conceptformulation

operational baseline

product baseline

design baseline

allocated baseline

functional baseline

life cycle stage corresponding baseline

Figure 4.4 The system life cycle and associated baselines (Bersoff et al., 1980)


You may think that once a baseline, such as the design baseline, has been established

the design ought to be frozen. This baseline design would then act as a firm platform on

which to base the further development. However, this could seriously devalue the worth

of the project since proposals for amendment often arise from the omission of a valuable

function from the original design or from an incorrect initial design. If it is impossible to

gain permission for change, progress will be held back. Nevertheless, the impact on the

project of a change to the design at the baseline should be carefully considered,

particularly if it entails change to a high-level area of the design structure at a late stage

in the development plan.

Software project baselines

In a software project it is particularly difficult to track the cost and progress of the

project, owing to the lack of well-defined intermediate stages in its design. Change

control baselines, over and above the standard baselines that were mentioned above,

can be used to establish progress points for each level of a hierarchically constructed

software system. For example:

c completed and approved requirements specification

c completed and approved design

c tested components ready for integration

c integration testing complete and approved

c release testing complete and approved

c alpha testing complete and approved.

These additional baselines give the project management more reference points from

which to track the cost and progress of a project. Subsequent modifications can then be

performed under control. Note that the above baselines are unlikely to apply to a

complete system, but only to some defined part of it, otherwise, for example, none of the

components could be baselined as ‘tested ready for integration’ until all the components

were in that state. In a phased or incremental project life cycle the baselines will be

applied to each increment. Following alpha testing or beta testing (if any) the first

operational version of the system will be released to the customer.

SAQ 4.6

(a) What is a baseline?

(b) What is the purpose of using baselines?

Multiple configurationsIt is often necessary for more than one configuration of hardware or software to coexist.

For example, if you were developing a refrigerator you might want one version for use in

Europe and another in the USA. These parallel configurations are usually referred to as

variants. One variant does not supersede the other. Both are available simultaneously.

Another way that different versions arise is when a product is improved or otherwise

changed over time. The new version supersedes the old but nevertheless if the old

product is still in existence its configuration has to be maintained. You will almost

certainly be familiar with this situation when trying to obtain a spare part for a broken

piece of equipment. The replacement may not fit if the supplier has not kept careful track

of the configuration of your equipment.


SAQ 4.7

Consider the configuration management of the production of this course, i.e. the

configuration shown in Figure 4.2.

(a) Suggest one way in which another variant could arise.

(b) Suggest how a different version of one variant could arise.

Protecting the configurationOnce an item has been identified as a configuration item it requires protection:

protection from unauthorised change and protection from accidental destruction such

as in a fire. The usual way to provide this protection is to set up an archive or

configuration store, a physical store of the configuration items with duplicate copies

held in a physically remote location so that an accident that destroyed the master would

be unlikely to destroy the copy. The archive requires a custodian (archivist or librarian)

to ensure that items are changed only after authority has been granted to do so, using

the proper consultation procedures.

You may wonder whether it is really necessary to centralise the configuration store.

Would it not be possible to appoint the designers as custodians of their own

configuration items? Informally this may work but the trouble with such a democratic

system is that it may fail for one of the following reasons:

c the whole system fails if even one designer abuses the procedures

c designers will be tempted to make small unauthorised changes

c designers prefer technical work to security work

c the security activities are time-consuming and tedious.

For these reasons it is better in a formal system to appoint a custodian of the store or

alternatively to use an automated tool that will not allow designers to make changes until

the proper authority for change to an item has been granted. An advantage of using an

automated tool as the custodian is that an automated tool cannot be persuaded to make

unauthorised changes!

If a mistake in a configuration item needs correction then the change control procedure

still needs to be invoked before the correction can be made. This may seem pedantic

and frustrating to the person who made the mistake. Nevertheless there needs to be a

publication of the proposal to correct the mistake and a record of the change. It would of

course be sensible to minimise the bureaucracy associated with matters like this, which

is why it is important to appoint an appropriate authority to approve change for each

configuration item.

SAQ 4.8

Why should mistakes not be rectified immediately by the designer without any fuss?

SAQ 4.9

Last week a designer was developing a component and was allowed to make changes

freely. The component then became a configuration item. This week the designer

notices a silly mistake and wishes to correct it. The custodian tells her that she cannot do

so without authority. The designer says this is crazily bureaucratic. Is it? Justify your

answer.


4.3 Configuration control

Procedures should be set up to ensure that the configuration control system works

as intended. It is necessary to establish a change control procedure so that no

change is made without assessment of its impact by people potentially affected

by the change or without approval by an appropriate authority.

A configuration control mechanismA mechanism is required which can handle a wide spectrum of requests for all sorts of

change, ranging from minor details of implementation to radical changes of system

function. The requester may be a senior manager or a junior designer, and may be

well informed about the structure of the project or almost totally ignorant. Not every

request will be supported by convincing argument. The problem is to find a

mechanism in which the work of assessing the impact and the work of approving

the change are performed by the right people in the project. This is the advantage

of a system that allows individual item controllers rather than referring everything

to a top-level change control board (or configuration control board).

The essence of change control is that all change to configuration items requires prior

approval by a recognised authority for that item, the item controller. There is an

important distinction to be drawn between the role of the item controller and the

custodian mentioned earlier. The item controller authorises change to an item and the

custodian ensures that no changes take place without that authorisation and according

to approved practices. The item controller may be a person or a committee and it is

often appropriate to have various authorities appointed, according to the position of

each item in the project. For example, it has already been noted that some items will

require approval for change from both client and contractor, while others are matters of

detailed design, internal to the project.

A typical authority for change control for items at the top of the project hierarchy is a

change control board consisting of:

c client technical representative

c client commercial representative

c project manager (contractor organisation)

c senior designer.

There may also be someone to give the maintenance and operational points of view. It is

not usually appropriate to submit every proposal for change to this top-level committee

for approval as the composition of this board is unsuitable for minor amendments.

Possibly the project manager or administrator could handle all internal changes within a

small project, but in a large project it is necessary to delegate authority. In general, when

each design object becomes a configuration item someone will be appointed as the

item controller and given the authority to approve changes to it.

SAQ 4.10

Would it be feasible to appoint a single person, say the project manager or a senior

engineer, as the controller for all items below the top level? What would be the

advantages and disadvantages?

A configuration administrator is useful as the person to whom all requests for change

are sent in the first place. The administrator routes the request to the appropriate

controller.


The basic steps in a mechanism for change control using configuration management

are as follows:

1 A requester sees the desirability for a change and sends a change request, giving

reasons for the change, to the configuration administrator.

2 The administrator records the request and sends it on to the named item controller.

3 The item controller appoints someone to assess the feasibility and the impact of the

change unless this has been done by the requester already.

4 The assessor consults the designers and users potentially affected and submits an

assessment to the item controller for decision. To ensure that the consultation is

performed properly the assessor should place on record the responses from all the

people affected.

5 The item controller approves or disapproves.

6 The administrator records the decision and reports it to all concerned.

7 The project manager or team leader appoints someone to implement the changes

(if any).

8 The implementer reports completion to the administrator.

9 The item controller authorises the new version.

10 The administrator records and publishes the new status.

There are some points to notice about this mechanism. Several people seem to be

involved: a requester, an administrator, an item controller, an assessor and an

implementer. These are not necessarily separate people, but are simply names for

functions to be performed. The impact of the change must be assessed before the

decision to make it is made. All significant events are recorded and published.

SAQ 4.11

Suppose the lead designer of an item is also registered as the controller for the item (a

reasonable practice). If this designer sees the need for a change, is it sensible to cut the

bureaucracy, implement the change and then perform steps 9 and 10 of the procedure?

If not, why not? What would prevent this?

Assessing the impact of a proposed changeWho is needed to assess the impact of a proposed change depends very much on the

scope of the change, which is usually reflected by the position of the item in the

configuration hierarchy. For example, to assess the impact of a change on the functions

to be performed by the system may require the participation of several senior people in

the client and contracting organisations. In contrast, if the change is merely correcting a

minor fault in a low-level item it may require only a junior designer to assess its impact.

Each component, or at least each design area within the configuration, is normally the

responsibility of an individual designer. It is therefore best to use that designer, who has

a detailed knowledge of a particular area, to assess the impact of change upon that

item. This is better than asking an outsider to do the work because an outsider will take

much longer to investigate and may overlook a vital factor.

As a result of a request for change to one item, consequential change to other items may

be required. The configuration dependency diagram can be used to stimulate

designers of affected items to provide details of the effects of the change on factors

such as cost or performance for their own items. These can then be aggregated to

provide the overall effects of the original change request.


To decide whether a change ought to be carried out, it is necessary to:

c estimate the benefits of making the change and the consequences if the change is

not made

c predict and assess whether the change will affect the overall system and what any

such effects are likely to be: the viewpoints of all the users of the system are often of

particular concern

c estimate what will need to be changed elsewhere in the design as a result of the

original change and what the ramifications of the change are likely to be at all levels

within the design hierarchy

c estimate the consequences on the cost and time taken to complete the project.

Gathering this information requires the estimating skills discussed in Unit 2.

Note that, after assessment, item controllers of all affected items will need to approve or

reject the change.

SAQ 4.12

(a) How can the configuration diagram or the equivalent database be used to help in

impact assessment?

(b) Suggest two advantages and two disadvantages if a project manager were to

decide that all requests for change should be accompanied by an assessment of

the impact of the change.

Active controlsConfiguration management is unlikely to work if it is purely a passive system. The project

manager needs to exert active control, first to ensure that design objects are brought

under change control at an appropriate time, and secondly to ensure that other team

members are using the latest approved versions of items as soon as possible. These

two issues are considered below.

Timing

Consider the problem of a designer working on some aspect of a project within a team

of other designers with whom cooperation will be needed to produce a complex piece of

equipment. Assume that a specification has been produced for a deliverable and

registered as a configuration item. It has specified the interfaces which affect other

deliverables and she now has to develop a detailed design.

Before producing the detailed design, the designer will need to experiment a great deal,

incorporating improvements, testing them and correcting or replacing them if they do

not work. This trial-and-error cycle may have to be repeated several times before finding

a solution and may produce a huge quantity of data and intermediate work in the

process. However, these experimental cycles have no relevance for the rest of the

project team: providing them with details of this intermediate work would only serve to

confuse. At this stage all that is required is for the designer to keep careful track of their

own versions privately. Change control is inappropriate.

However, at some point the designer will reach a stage where fairly firm conclusions

have been reached and will be able to record a first draft design for the benefit of

colleagues and subsequent stages of the work. This is the time to submit the work to

change control. This need not prevent further changes, but any such changes will

require prior approval and will be on the record. The design object has become a

configuration item.


The timing of the application of control to a component is critical.

c Applied too early, change control will slow down the development of the item by

introducing restrictions on change.

c Applied too late, the lack of change control will lead to confusion at the interfaces

between components.

The project manager must judge the optimum time at which to bring a component under

change control, taking account of the rate of change of the component and the

requirements of other members of the team.

SAQ 4.13

Name one item which should be placed under change control as soon as a contract is

agreed between client and contractor.

Checkpoints

The initial registration of an item as a configuration item under change control is only the

start of the change control process. Normally, work will continue on an item and this

means that the changes produced by this process should be regularly submitted for

approval. Left to themselves, designers tend to continue development without

submitting the changes for approval. This means that the registered version gets more

and more out of date compared with the version that designers are currently using in

their own private workspace. This does not contradict the principle of configuration

management but it keeps work private for too long. This tendency may be overcome by

instituting checkpoints.

The ideal arrangement is that a designer should agree with the project manager on a

number of stages during the work at which the latest controlled version will be updated.

This has two advantages: first, less work will be lost if this designer is unable to complete

all the development work and, second, other team members benefit from using updated

versions.

At a minimum there should be a checkpoint at the completion of any distinct subset of

work and at the completion of any agreed change. However, if too many checkpoints

are imposed the designer concerned will have to spend too much time ensuring that the

work is under control. If control checks are applied every six days it will be expensive,

whereas if control checks are applied every six months there is a risk of losing all

intermediate work if some unforeseen, disastrous event occurs. There is a trade-off

between the reduction in efficiency caused by enforcing too many checkpoints and the

risk of losing work if there are too few.

Use of out-of-date versions by othersSuppose a designer has implemented a change and tested it, and it has been declared

fit to replace the previous version. At what stage should this new version be adopted by

the other members of the project team? Immediately? Within some time limit? Or at the

designer’s discretion?

The most straightforward course of action, from the project manager’s point of view, is to

insist that only one version of any item is in use at a time and that everyone should adopt

the new version immediately it has been approved. By this means, the project manager

can be more confident that each item will interface satisfactorily with the latest versions

of all other items in the design hierarchy.

Unfortunately, this strategy makes progress difficult. If a change is made to a particular

design environment, other designers working in that environment will naturally be


suspicious about how it has affected their work area. For example, if they are developing

software and are forced to use a new version of a common component developed

elsewhere they may blame the change for any subsequent failures, regardless of

whether the change has had any impact on their work; consequently it will be difficult to

re-establish confidence.

However, as soon as someone is allowed to continue to use an out-of-date version

the introduction of the new version is delayed and it is possible that, in the extreme

case, the new version will never be adopted by all the designers. Clearly, this is not

acceptable in the development of a system where all the parts must eventually work

together. Some procedure is required to ensure that new versions are adopted within

a reasonable time.

If latest versions are to be adopted within a reasonable time it is necessary to establish

some kind of checking procedure on the versions in use. Consider the following three

possibilities:

1 Set a time at which the whole project team must adopt the latest approved version,

in synchronism, for example ‘every Thursday at 7 pm’.

2 Inspect the versions which people are using and implement a time-out rule such as:

‘You may not use versions which have had a successor for more than two weeks.’

3 Inspect the versions which people are using and judge whether it is reasonable

for them to be used, depending on the prevailing circumstances.

The first of the three options is the easiest to implement, but requires people to terminate

their hypothesis-forming and testing cycle at the same time: this will not always

constitute the most efficient use of personnel. (In a software project it might also

consume significant computing resources on Thursday nights.)

The time-out option is practical but relies on the project manager’s ability to persuade

the development staff to be disciplined in their approach. It can be implemented with

reasonable ease but you can never be sure that everyone is in synchronism.

The last option is the most friendly but also the most difficult to implement as it relies

heavily on personal interaction and wise decision making. It could take a lot of the

project manager’s time unless this checking can be delegated to someone else.

The mechanism chosen for a given project will depend upon the project manager’s

confidence in the development team and the importance of maintaining synchronism for

the task. It will also depend on how much time the project manager can afford to devote

to the task.

SAQ 4.14

A project manager on a large job using formal configuration control insists that work

should be entered into the change control system at the end of every day and that

everybody must use only the latest versions of all components. Give two major flaws in

this procedure.

Configuration control in extreme programming (XP)XP and other agile methods propose daily builds of new versions of the software.

A deadline is set each day for developers to contribute new code. Clearly rigorous

configuration control cannot be enforced on a daily basis, but the record of problems

identified and repaired must be maintained for traceability. When customers are

involved within the project team, they can assess the impact of change of requests for

new features with the team and prioritise agreed changes. Changes which affect other

systems must adopt a formal configuration control process. Technical improvements to


the software regarding efficiency, reliability and so on, known as refactoring in XP, are

recorded but do not need formal control. The nature of agile methods necessarily

requires a reduction in paperwork to meet the requirement of rapid development.

However, the approach is likely to be most successful in small projects with a small

development team.

4.4 Configuration status accounting

The purpose of configuration status accounting is to keep a record of all the events

that have happened to a system under development to allow comparison with the

development plan and to provide traceability. It should be possible to answer

questions such as: ‘What is the current status of development of deliverable X?’

‘By what route did it reach this state?’

As we discussed in Unit 5, control of a project requires both a plan and a measurement

of status. Status accounting is a contribution to the second of these two requirements.

To answer questions about status and history it is necessary for the system to record all

transactions affecting each configuration item from the time that the configuration

management system is established for the project. The history of transactions should

extend throughout the development of the product to the release of the product to

the operational environment and any subsequent maintenance. This means that

meticulous records must be kept. Although it would be possible to keep such

records manually this is obviously an area where a database is invaluable for

assembling the relevant facts, so we will assume that such a system is employed.

Most of the input to it probably goes via the administrator who handles the change

requests, but the precise mechanics of who physically enters the data are immaterial.

The records that are accumulated in the database include:

c the creation of new configuration items together with the name of the change control

authority (that is, the item controller)

c change requests

c change approval/rejection decisions

c change notices (issued when items have been changed)

c updates to items stored in the system itself

c baseline configurations

c users of specific versions of configuration items.

Using this data the status accounting system should be able to produce reports on the

status and history of any item or collection of items, such as a baseline. Such reports

may be scheduled to be released periodically, for example before regular project review

meetings, but may also be required on an ad hoc basis to respond to queries from

members of the project team or project auditors or later by people maintaining the

developed system.

Some typical queries could be:

c What is the history of development of the power supply unit? Why is it now handling

10 amps when the original specification only called for 5 amps?

c Who needs to approve any changes that are proposed for this software component?

c On what items have changes been approved which have not yet been

implemented?

c What items in the design baseline have been changed since it was approved?

c Has our new system of checkpoints reduced the incidence of spurious change

requests?

A transaction beginswith an indication that aconfiguration item inthe repository is goingto be modified, and it islocked to preventconcurrentmodification.


c Which customers have taken delivery of version 3.0 of the power supply unit?

c How many versions of the configuration item edit.cde have been created?

The project manager can also use the status accounting reports to assess the present

state of achievement in all areas within the project. The current state of progress can

then be compared with the plans for each area, and appropriate corrections can be

made. Thus the status accounting system can be used not only as a record of change

but also as a record of progress to help the project manager to make decisions during

the execution of the project.

SAQ 4.15

(a) What are the main purposes of configuration status accounting?

(b) Describe briefly how it is done.

4.5 Configuration auditing

Configuration auditing developed from the aircraft industry’s need to be sure that each

aircraft was constructed exactly as the designers intended it to be. It ensured, for

example, that an outmoded component was not replaced by a new one without proper

consideration and a record of that decision being made. The same method is now used

to check that every item delivered by a project has been developed and produced as

agreed.

The aim of configuration auditing is to check that, in spite of changes that may have

taken place in requirements and design, the items produced conform to the current

specification and that all the quality assurance procedures claimed to be in place have

actually been performed satisfactorily. This is done by verifying that when any item is

produced it conforms to the specification produced for it at the previous stage. That

specification will itself have been verified for conformity with the project requirements.

Clearly, the introduction of changes can lead to a breakdown in this chain of

development unless great care has been taken to ensure that the changes are applied

consistently from requirements definition, to specification, to the finally constructed

deliverable.

Auditing does not necessarily involve the auditors in performing the verification

themselves: it is a matter of ensuring that the verification has been done and that the

records are complete and satisfactory. The verification process could be carried out at

any time but in particular, when a baseline is to be established, an audit is required to

ensure that the configuration at each successive baseline has been verified as

conforming with the items in the configuration at the previous baseline.

If auditing is to be feasible then each item produced must be identified, the

interrelationships between all items defined and the history of change maintained. For

example, the name and version reference must be etched into a circuit card or stamped

onto a metal component. This makes it plain to everyone what the object is supposed to

represent. By reference to the configuration diagram, items on which the component

depends, such as the specification, will be identified and by reference to the status

accounting system it should be possible to recreate its history precisely.

Audits should also be carried out to make sure that changes have been implemented

and recorded correctly. How often and to what depth such audits are undertaken will

depend on the importance of ensuring that a component conforms to its specification.

For an aircraft component it will be extremely important for safety reasons but for a

domestic appliance it may be less important (although safety may be a factor in some


cases). Sometimes a configuration audit can only be thoroughly carried out by taking

the finished product to pieces, but this could be an expensive procedure, so most

verification will need to be built into the design and construction activities, checking for

conformity at each stage. The auditor can then examine the records that show that this

verification was indeed carried out, usually from a document signed by the person who

did the checking.

The use of manual change control procedures often results in discrepancies between

the finished component and the specification, which the auditing procedure should

discover. However, if automated change control procedures are used it is much more

likely that the discrepancy will not be allowed to occur in the first place.

4.6 An example of configuration management

The following example is intended to illustrate the way that configuration management

affects the conduct of a project by following through a project to develop a ‘green’

refrigerator. While the example, and the design team involved, may seem too small to

warrant the application of full configuration management, we have chosen it because it

illustrates principles which are appropriate in larger and more complex projects.

A small but increasingly successful company has built a good reputation for its

products, refrigerators and freezers. The management are now convinced that there is a

developing requirement in the market for a ‘green’ refrigerator. Since the company is

small, the management feels that it is possible to fill this expanding niche in the market

with a good product, quickly. After much consultation a product requirements definition

document is agreed and this becomes the first configuration item.

Configuration item

Item name:

Created:

Change authority:

Description:

Requirements definition

10/1/05

Engineering Division manager plus Marketing

manager

Master copy held in Engineering files ref Green/1/1

Items depended on: Nil

This information is held on a database under the control of an administrator in the

Engineering Department. The description is a pointer to show exactly which document is

being referred to, the requirements definition itself being held securely in a file. This item

depends on no items already in the system – there are no others, yet!

The design team has two lead designers, who decide that one will be responsible for the

refrigeration unit, the controls and the motor, and the other for the carcase, the interior

fittings and the door. Together they draw up a top-level design and submit it to a

meeting chaired by the marketing manager at which it is confirmed that this design

conforms to the requirements definition. This now becomes the second configuration

item.


Configuration item

Item name:

Created:

Change authority:

Description:

Top-level design

25/1/05

Lead designers with project manager

Master design held in Engineering files ref Green

1/2/1

Items depended on: Requirements definition

The point to note here is that this item is dependent on the requirements definition,

an item already in the configuration. If anyone requests a change to the requirements

definition then this second item could be affected. Note that although the original design

was approved by the marketing manager, the change authority (item controllers) for this

item is the designers and project manager. Assuming that changes to the design still

conform to the requirements definition there is no need to gain the approval of the

marketing manager for changes to the design. As the design of individual components

proceeds other configuration items are stored in the database, such as the designs for

the carcase, the motor, the interior fittings and so on. As each item is added to the

database it is necessary to record precisely where that design is held and it must be

held in such a way that no changes take place without authority. Some items spawn

others (the door design, for example, has a fastening design which is dependent on the

carcase and door designs). The configuration after a month or so looks like Figure 4.5.

Change requests start to appear. The designer responsible for the refrigeration unit

undertakes some research on non-CFC refrigerants. He discovers that this will require

some changes: the coils have a different geometry from the one specified in the

top-level design. Consequently there needs to be a change request not only for the

refrigeration unit itself but also for the top-level design.

depends on

requirementsdefinition

top-leveldesign

interiordesign

motordesign

refrigerationunit design

fasteningdesign

testspecification

doordesign

carcasedesign

Figure 4.5 Refrigerator configuration


Change request

Originator:

Date:

Abel Baker, designer

15/2/05

Item(s) to be changed: Top-level design and refrigeration unit design

Outline of change: The refrigerator will use liquid propane as a

coolant, and will require a design for the

refrigeration coils and a motor suitable for this

coolant.

Reason for change: Liquid propane is presently the most effective

non-CFC coolant available for domestic

refrigeration.

The administrator checks the database to find out what other items are recorded as

directly dependent on any of the items for which the change is requested so that the full

impact of the effect of a change can be assessed. Notice that in the first instance there

need be consideration only of items that have been declared dependent on the items for

which the change has been requested. There could be lower-level items that depend

indirectly on the top-level design, via say the carcase design, but there is no need to

consider them unless a change is necessary in the carcase design itself.

The designers meet at the project manager’s instigation, and determine that the

changes required by using liquid propane will affect the refrigeration unit and the

top-level design. No other directly dependent items are affected as the motor

specified is already suitable for the proposed coolant and the changes will not affect

design of the carcase, door or interior fittings. There is also no need to worry about

items dependent on the carcase design. Nevertheless, the fact that there has been a

change is notified to all the design team in case someone working on the design of

something which is not yet part of the configuration is relying on the earlier designs.

All the change requests, the impact assessments and the decisions of the item

controllers are recorded by the administrator using the database. Occasionally the

administrator is asked questions by the designers, such as: ‘How do we come to be

using this size motor?’ The administrator uses the database to recall the history of its

design from the original document identified as the motor design and all subsequent

changes to it.

The quality manager also asks questions to ensure that the product is meeting the

intentions of the managers of the Marketing and Engineering Divisions.

c Is there a record of all the configuration items, uniquely identified, with records of all

requests for change and the outcome of each?

c Have all changes been properly authorised?

c What evidence is there of verification that the detailed designs conform to the

top-level design?

c Is there a record of management agreement to the top-level design?

c Are there any outstanding requests for change to the designs?

c Is there a specification of the tests which will be conducted before the refrigerator

design is approved for manufacture?

c Overall, if a refrigerator were constructed to the detailed designs, would it meet the

sponsor’s requirements?

Everyone in the department who had anything to do with the development of this

refrigerator is affected by the decision to use configuration management.


The project manager finds that he has quite a ‘selling’ job to ensure that everyone

adheres to the system even if they do not really like it. Some find it onerous and are

irritated by the extra administration and the delays caused by the change control

procedures. But others find it useful that nobody changes things without letting

them know and like the way that they can get information about the reasons for

past decisions.

SAQ 4.16

Find examples in the above description of the development of the refrigerator of the

use of:

(a) configuration identification

(b) configuration control

(c) configuration status accounting

(d) configuration auditing.

4.7 Issue management

APM (2005) defines an issue as a threat to the project objectives that cannot be

resolved by the project manager. In the PRINCE2 project management method an issue

is any concern which may arise during the project. The rather open-ended nature of

issues means that they should be differentiated from problems, which the project

manager is generally expected to deal with on a day-to-day basis.

Issues include:

c change requests (already discussed in Sections 3 and 4 of this unit)

c off-specifications which are products that stakeholders have identified as not

currently provided by the project but that should be or a product not meeting its

specification; off-specifications are types of change request

c any other concern or query usually raised by the project stakeholders.

It is clear from these definitions of an issue that there is a great deal of overlap

between issue management and configuration management. Issues are recorded

in an issue log and this tool is used to monitor the resolution of the issue. The

information recorded for an issue is similar to that recorded for the change request

given in Figure 3.1 and the same tools and database are often used. The information

recorded for an issue includes an assessment of the impact of the issue on the

project, the final outcome and the date the issue is resolved. A number of authors,

such as Buttrick (2005), have also made a connection between issue management

and risk management:

an issue occurs either as a result of an identified risk or opportunity event

occurring or as a result of some unexpected event.

(p. 413)

The database of historical information on issues enables the project manager to answer

queries such as:

c How many issues were recorded in the last month?

c How many issues were resolved in the last month?

c How many issues have led to change requests in the last month?

The chief purpose in recording issues before they become change requests and

recording stakeholders’ concerns is to encourage a thorough understanding of


stakeholder expectations. This understanding is fundamental to stakeholder

management (discussed in Unit 4). Stakeholder issues that are not resolved can

become a significant cause of stakeholder dissatisfaction and lead to project failure.

4.8 Summary

Subsection 4.1 outlined configuration management. Following Bersoff et al. we have

defined configuration management as: ‘the discipline of identifying the configuration of a

system at discrete points in time for purposes of systematically controlling changes to

this configuration and maintaining the integrity and traceability of this configuration

throughout the system life cycle’.

We introduced the four components of configuration management: identification,

control, status accounting and auditing. Configuration identification means knowing

exactly what is in the configuration at any one time. Configuration control means the

processes which are used to protect the configuration so that items are changed only

through procedures that ensure a proper assessment of the impact of the change.

Configuration status accounting means keeping records of everything that affects the

system so that reports can be produced showing what happened and when. It provides

traceability. Configuration auditing means checking that the items produced have been

tested and inspected for conformity with the requirements and that the product

delivered conforms to the documentation which purports to describe it.

We outlined issue management which is the process of dealing with threats to the

project objectives that cannot be resolved by the project manager. Issues often become

requests for change dealt with by the configuration management system. Issue

management is concerned with managing stakeholder expectations.


c define the content of a configuration management plan

c explain what is meant by the terms configuration identification, control, status

accounting and auditing

c distinguish between design objects and configuration items

c propose a suitable identification scheme for a given project

c explain what procedures you might use for configuration control

c outline the benefits of configuration status accounting

c explain the roles of a configuration custodian and an item controller

c explain what is meant by issue management

c explain the purpose of an issue log.


5 Closing the project

This section alerts you to particular difficulties that arise as a project approaches

completion and presents techniques that can be used to overcome them.

Right from the beginning the project manager should focus on the target: successfully

closing the project. The project will have a finite duration and the project manager will

want to ensure not only that the project has been completed technically to the required

quality, within its budget and schedule, but also that the ongoing business after the

project has been completed is as healthy as possible. However, note that the

responsibility for realising the benefits from the projects rests with the client rather than

the project manager. As the project progresses, the plan for its closure will need to be

developed. This is sometimes called a phase-out plan.

There are several factors for you to bear in mind:

c the future of project staff

c handover and maintenance

c documentation

c contract completion

c financial accounting

c project review.

These tasks are rather unexciting, even downright tedious, compared with the tasks

being undertaken at the project launch. Spirer (1983) presents the problems of closing

the project in the form of a tree as shown in Figure 5.1.

fear of no future work

loss of interest in tasks remaining

loss of project-delivered motivation

loss of team identity

selection of personnel to bereassigned

reassignment methodology

diversion of effort

change in attitude

loss of interest in project

change of personnel dealingwith project

unavailability of key personnel

identification of remainingdeliverables

certification needs

identification of outstandingcommitments

control of changes to project

screening of uncompleted tasksnot needed

closure of work orders and workpackages

identification of physical facilitiesassigned to project

identification of project personnel

accumulation and structuring ofproject historical data

disposing of material of project

agreement with client on remainingdeliverables

obtaining needed certifications

agreement with suppliers onoutstanding commitments

communicating closures

closing down physical facilities

determining external requirements(client/organisation) for audit trail data

project terminationproblems

emotional

staff client

intellectual

internal external

Figure 5.1 Project termination problems (Spirer, 1983)


Under the ‘intellectual’ heading Spirer lists the actual work to be done and under the

‘emotional’ heading he lists the human problems to be overcome. Both the staff and the

client may be affected. Let us consider some of the problems.

Future of project staffThe approach of the close of a significant project may be a very uncomfortable time for

the project staff. If people are not assured of their future, then it may be very difficult for

the manager to maintain the project’s impetus over its final stages. A hitherto successful

project may become sluggish and difficult to manage. Sometimes this uncertainty is

unavoidable, but if possible the manager should try to ensure that each member of staff

knows his or her own future prospect as closure approaches.

The timing may be delicate. On the one hand the manager wants to reassure the staff

that they will not be unemployed after the project, but on the other hand the manager

also wants to ensure that the staff complete the current project before getting too

enthusiastic about the next one. Once a team member has started work on the next

project it will be exceedingly difficult to get that person back to tie up any loose ends,

so the project manager must make sure that any outstanding work is taken care of

properly. The manager may of course be concerned about his or her own future.

Towards the end of a large project it would not be surprising if thoughts of the next job

were distracting. Hopefully, the manager’s manager will be preparing a plan for this!

The problem of the effect of the approaching closure of the project on staff attitude is of

course easier to handle if the team have been well motivated towards a successful

outcome throughout the project. If the team building has gone well then it is likely that, in

spite of concern over the future or the attraction of a novel assignment, the strongest

factor will be the satisfaction of seeing the present project succeed.

Handover and maintenanceThe outcome of many projects is a working system or product to be handed over to

some other organisation to operate. For example, at the end of a factory construction

project there is a manufacturing plant to be operated. The handover process prepares

all deliverables and documentation which will be passed over to the client organisation.

The deliverables must be formally accepted by the client after the successful

completion of the agreed acceptance test plan. There is a formal transfer of ownership

to the client and responsibility transfers from the project team to the client organisation.

Clearly this process is likely to be more successful if stakeholders have been fully

involved throughout the project, as we discussed in Unit 4.

The ease of future operation and maintenance of the product is specified among the

objectives for the project manager at the outset but as the project approaches

completion the prospective operation and maintenance managers are likely to take a

progressively greater interest. The operating and maintenance staff also need to be

trained. Maintenance procedures need to be established and this may require an input

from the project personnel. It can be helpful to involve some of the future maintenance

and operations staff in testing and commissioning. These people are then well placed to

write the operations and maintenance documentation or at least provide input to them.

DocumentationAllied to the maintenance issue is the need to complete the project documentation. All

phases of the project should already have produced documentation but this needs to be

reviewed to ensure that it is complete, indexed and accessible. Copies may need to be

archived for future reference. Seen through the eyes of maintenance staff the project

documentation may not appear as satisfactory as the project staff believed. It is a good


idea to expose the documentation to the staff who will have to use it long before the

project closes. The maintenance staff may well assist in preparing the documentation.

The documentation includes complete lists of all the project deliverables, showing how

they fit together and how they were designed and tested. Furthermore, the documents

should show how it was intended that the product should be used and maintained. This

applies just as much to software as it does to more tangible products.

Contract completionThe manager needs to obtain from the client a formal acceptance that the contract has

been fulfilled. This could be a sticky point unless the project manager has taken care to

ensure that acceptance criteria and project deliverables have been well defined. The

greatest problems are likely to occur where the specification is so loose that there is

room for wide disagreement over the interpretation of what constitutes completion.

All this should have been foreseen at the time that the contract was placed. (Informal

contracts between departments of the same organisation are likely to produce the worst

problems of this kind.)

Ideally, it should be possible to refer to a document produced at the project launch

which specifies precisely the criterion for acceptance. Acceptance need not necessarily

be 100%. The client may accept that the project has been completed, but with

reservations. The reservations will list the items still outstanding, and these may then be

dealt with by the project team or an agreement may be reached between the contractor

and client that payment for the work is adjusted to take account of those reservations

that cannot be tackled economically.

The project manager in a reversed role will in turn ensure that all subcontracts have

been fulfilled correctly and authorise final payments to subcontractors and vendors. All

contracts and purchase orders must be finalised. The project manager should ensure

that any project equipment and materials are transferred or sold as appropriate. There

may be a number of minor matters that have to be handed over to a post-project

administrator to tie up after the project has closed.

Financial accountingThe project manager is responsible for the preparation of a financial statement of the

project. How much did it finally cost compared with the original sanctioned budget? The

discrepancies will need to be explained. Often the scope of work will have changed

during the project but if all changes have been documented, justified and the costs

agreed with the client there should be little argument. The project manager will want to

find out where the money went so that the estimating on future projects is improved.

Problems will arise, however, if expensive changes have been made without adequate

consultation and recording. The client may well be reluctant to agree that so many

changes were actually requested, and the project organisation may stand to make a

loss. The client’s memory of requested changes is invariably short. Clients are often

horrified to discover how many changes they have made, so it is essential to have a

formal record of all changes and their costs as discussed in Sections 3 and 4 of this unit.

Remember the heated public arguments over the responsibility for the extra costs of the

Channel Tunnel project!

Project reviewFinally the project is reviewed. Performance of personnel may be reviewed against their

objectives. Did the project manager satisfy their objectives to manage risk associated

with the project’s critical success factors (as discussed in Unit 3)? Was the project

completed to quality, time and cost targets? If not, why not? Are there lessons to be


learnt? Are there any follow-up actions on this project? Answers to these questions

should be documented and presented to the management for the benefit

of future projects.

APM (2005, p. 90) lists the aims of the project review as follows:

c evaluate the project management processes used

c establish lessons learnt and actions arising from them

c raise any concerns and agree corrective actions

c review the likely technical success of the project

c validate overall progress against the plan: schedule, budget, resources, quality

c consider stakeholder relationships and perceptions.

Meredith and Mantel (2006, pp. 641–3), in discussing the form of the final report,

conclude that although the report may take a variety of forms the following issues should

be addressed:

c project performance – compare achievement with plan

c administrative performance – review administrative practices within organisation

c organisational structure – recommendations for changes to structure

c team performance – confidential report to senior management on the team

members’ effectiveness

c techniques of project management – review the methods used for estimating,

planning and cost control.

Meredith and Mantel make the following remarks about the use of the final report:

For each element covered in the Final Report, recommendations for changing

current practice should be made and defended. Insofar as is possible, the

implications of each potential change should be noted. Commonly ignored, but

equally important, are comments and recommendations about those aspects of

the project that worked unusually well. Most projects, project teams, and PMs

develop informal procedures that speed budget preparation, ease the tasks of

scheduling, improve forecasts, and the like. The Final Report is an appropriate

repository for such knowledge. Once reported, they can be tested and, if

generally useful, can be added to the parent organization’s list of approved

project management methods.

(2006, p. 643)

SAQ 5.1

How might the project review help an immature organisation involved in the process of

introducing good project management practices?

SAQ 5.2

The project manager’s objectives and measures devised in Unit 3 to manage risk

associated with the critical success factors can be used in a project review to identify

strengths and weaknesses in a project management process. The following table is

reproduced from Unit 3. Use the table to devise questions that might be explored in a

project review.

The project review willbe discussed in moredetail in Unit 7.


Table 5.1 Critical success factors, objectives and measures

Critical success factor Objective Measure

Clear realistic objectives To establish clear and

realistic objectives

An agreed specification for

the work exists and is

included in the contract

Sound basis for the project To establish a business

case for the project

The business case exists

based on the agreed

specification and has been

accepted by the client

Skilled/suitably qualified/

sufficient staff

To establish an appropriate

project organisation

No staff or skills shortages

exist

The team agree that roles

and responsibilities are

clear

Effective change

management

To establish a mechanism

for keeping track of

changes

The mechanism for change

is documented in the

contract

Strong/detailed plan kept

up to date

To establish the project

plan and communicate the

plan to all stakeholders

A plan exists and is agreed

by all stakeholders

The plan is updated

regularly at agreed

intervals

Milestones are defined

Project closure listsChecklists are useful at all stages of a project, including project closure. In his second

edition of Managing High-technology Programs and Projects (1992), Archibald

suggested that at project closure the benefits of a checklist are to:

c Clearly indicate the close-out functions and responsibilities, reducing ambiguity and

uncertainty.

c Reduce oversight of important factors.

c Permit close-out progress to be monitored.

c Aid project team members with little or no experience in closing out a project.

c Inform other project team members about the activities of other projects during the

close-out phase.

(p. 364)

SAQ 5.3

Archibald’s checklist is designed for a large project where a project office is involved.

Produce a shorter checklist, say about a dozen items, that might be used in closing a

smaller project.

Make project closure a projectTo overcome the loss of interest in the project that is likely to come in the closing stages,

Spirer (1983) proposes that ‘project termination’ should be treated as a project. This is a

Archibald’s checklist isreproduced on thecourse website.Although it is not usedin his current edition(2003), a number ofauthors, such asMeredith and Mantel(2006, p. 639),continue to useArchibald’s checklistfor project closure.


psychological trick, perhaps, but it may be necessary to try to produce that same

enthusiasm that marked the beginning of the project. Specifically, Spirer proposes:

Make it clear that close-out has its own project identity. Some project

managers give the close-out its own project name. Start-up meetings for

the beginning of the termination phase help to establish the concept that there

is a well-defined goal to be met – closing out the job properly.

(p. 251)

Once termination has been made a project, there are a number of suggestions for

encouraging the project spirit:

c Provide a team identity – New project name? Newsletter?

c Hold frequent informal team meetings.

c Keep in touch with members personally.

c Plan the reassignment strategy – keep the best people until last (if you can!).

c Set objectives for good closure – documents and spares for trouble-free

maintenance.

5.1 Summary

At the end of a project two kinds of problem have to be coped with: technical problems

and emotional problems. One of the more difficult problems is arranging a smooth

transition for the project staff so that they contribute effectively to the project until they

leave it. Technical issues include handover and maintenance, documentation, contract

completion, the financial account and a project review. Checklists are recommended to

ensure that nothing is overlooked.


References and further readingAPM (2005) Body of Knowledge (5th edn), High Wycombe, Association of Project

Management.

Archibald, R.D. (2003) Managing High-technology Programs and Projects (3rd edn),

Hoboken, NJ, John Wiley and Sons Inc.

Contains a number of useful charts and techniques for monitoring and control. Russ

Archibald is one of the most well-known experts in project management. His

consultancy was based on his military and aerospace experiences which began in

the 1960s.

Babich, W.A. (1986) Software Configuration Management: Coordination for Team

Productivity, Reading, MA, Addison-Wesley.

This book is mainly about software configuration management used as a

technique to coordinate programmers. Some of the nomenclature differs from

that used in this unit.

Beck, K. (2000) Extreme Programming Explained, Boston, MA, Addison-Wesley.

Bennatan, E.M. (1992) Software Project Management: a Practitioner’s Approach,

London, McGraw-Hill.

Bersoff, E.H., Henderson, V.D. and Siegel, S.G. (1980) Software Configuration

Management: an Investment in Product Integrity, Englewood Cliffs, NJ, Prentice

Hall.

This book is primarily about software projects but the techniques described are

applicable elsewhere. It contains numerous references.

Boddy, D. and Buchanan, D.A. (1992) Take the Lead, London, Prentice Hall.

Boehm, B.W. (1981) Software Engineering Economics, Englewood Cliffs, NJ, Prentice

Hall.

Brooks, F.P. (1975) The Mythical Man-month, Reading, MA, Addison-Wesley.

A classic and enjoyable read although now a bit dated technically, but it has been

reprinted several times since its first publication.

Bryan, W., Chadbourne, C. and Siegel, S. (1980) Tutorial: Software Configuration

Management, IEEE.

This tutorial brings together a number of articles on software configuration

management. There is extensive coverage of management failures in the American

defence contracting industry and the reasons for government agencies insisting on

configuration management.

Buckle, I.K. (1982) Software Configuration Management, London, Macmillan.

Similar scope to Bersoff, Henderson and Siegel but British rather than American.

Buttrick, R. (2005) The Project Workout: a Toolkit for Reaping the Rewards from All Your

Business Projects (3rd edn), Harlow, Pearson Education.

CCTA (1993) PRINCE User’s Guide to CRAMM (the CCTA Risk Analysis and

Management Method), London, HMSO.

Chilstrom, K.O. (1983) ‘Project management audits’ in Cleland and King, pp. 465–81.

Cleland, D.I. and King, W.R. (eds) (1983) Project Management Handbook, New York,

Van Nostrand Reinhold.

Units 5 & 6: Project execution112

Cohen, D., Lindvall, M. and Costa, P. (2004) ‘An introduction to agile methods’,

Advances in Computers, vol. 62, pp. 1–67.

Czewinski, F.L. and Samaras, T.T. (1971) Fundamentals of Configuration Management,

Hoboken, NJ, John Wiley and Sons.

A classic introduction to the subject: not software. You may have difficulty obtaining

a copy as it is unfortunately out of print. It is included here for historical reasons.

Galin, D. (2004) Software Quality Assurance: From Theory to Implementation, Harlow,

Pearson Education.

Harrison, F.L. (1992) Advanced Project Management (3rd edn), Aldershot, Gower.

Heineman, G.T. and Councill, W.T. (2001) Component-based Software Engineering:

Putting the Pieces Together, Hoboken, NJ, Addison-Wesley.

IEEE (1991) IEEE Std 610.12-1990 – IEEE Standard Glossary of Software Engineering

Terminology, New York, Institute of Electrical and Electronics Engineers.

Ince, D., Sharp, H. and Woodman, M. (1993) Introduction to Software Project

Management and Quality Assurance, London, McGraw-Hill.

Lock, D. (2003) Project Management (8th edn), Aldershot, Gower.

Machiavelli, N. (1513) The Prince (trans. Bull, G., 1970), Harmondsworth, Penguin.

He would have made a good project manager.

Meredith, J.R. and Mantel, S.J. (2006) Project Management: a Managerial Approach

(6th edn), Hoboken, NJ, John Wiley & Sons.

Contains substantial chapters on monitoring, control, evaluation and termination and

includes many case studies.

PMI (2004) A Guide to the Project Management Body of Knowledge (3rd edn),

Newtown Square, PA, Project Management Institute.

PRINCE (1998) Managing Successful Projects with PRINCE2 (revised edn), London,

The Stationery Office.

Robertson, S. and Robertson, J. (2006) Mastering the Requirements Process (2nd edn),

London, Addison-Wesley.

Sommerville, I. (2007) Software Engineering (8th edn), Harlow, Addison-Wesley.

This new edition of a well-established text came out during the production of

this unit.

Spirer, H.F. (1983) ‘Phasing out the project’ in Cleland and King, Chapter 13.

Staw, B.M. and Ross, J. (1987) ‘Knowing when to pull the plug’, Harvard Business

Review, vol. 65, no. 2, pp. 68–74.

Turner, J.R. (1999) The Handbook of Project-based Management (2nd edn),

Maidenhead, McGraw-Hill.

Turner, J.R. and Simister, S.J. (eds) (2000) Gower Handbook of Project Management

(3rd edn), Aldershot, Gower Publishing.

Wateridge, J. (2000) ‘Project health checks’ in Turner and Simister, pp. 145–60.

Wesselius, J. and Ververs, F. (1990) ‘Some elementary questions on software quality

control’, Software Engineering Journal, vol. 5, no. 6, pp. 319–30.

References and further reading 113

AcknowledgementsGrateful acknowledgement is made to the following sources:

Unit 5

Figures

Figure 1.1: Harrison, F.L. (1992) Advanced Project Management: a Structured

Approach, 3rd edn, Gower Publishing Company Limited; Figures 3.4, 4.4: based on

Archibald, R.D. (1992) Managing High-technology Programs and Projects, 2nd edn,

John Wiley and Sons Inc.

Unit 6

Figures

Figure 4.4: Bersoff, E.H., Henderson, V.D. and Siegel, S.G. (1980) Software

Configuration Management, an Investment in Product Integrity. Prentice-Hall Inc.;

Figure 5.1: Spirer, H.F. (1983) ‘Phasing out the project’, in Cleland, D. and King, W.R.

(eds) Project Management Handbook, Van Nostrand Reinhold Company Inc.

Every effort has been made to contact copyright holders. If any have been inadvertently

overlooked the publishers will be pleased to make the necessary arrangements at the

first opportunity.


SAQ answersUnit 5SAQ 1.1 ................................................................................................................

The advantages of restricted communications include:

c more focusing by staff on their assigned tasks

c better control of the confidentiality of information

c less time spent on reading papers and attending meetings not directly related to

assigned tasks

c reduced costs of paper and reproduction.

The disadvantages include:

c poorer understanding of global objectives

c weaker cooperation between staff in separate sections

c lack of mobility between job functions

c discouragement of team spirit.

The need-to-know approach seems appropriate only where confidentiality is paramount,

because the disadvantages are likely to outweigh the time and cost savings. Top secret

projects are an exception because the team is likely to understand the need for

restricted communication in these circumstances and so will not be as demoralised by

it.

SAQ 2.1 ................................................................................................................

Your answer should include six of the items listed below. Periodic reports could be used

to:

c detect technical problems early

c detect cost overrun

c detect schedule slippage

c identify staff resource shortages

c reveal unforeseen events

c identify bottlenecks arising from limited facilities

c detect unplanned work being performed

c reveal the need to change priorities

c indicate that a contingency plan may need activating

c detect staff conflict

c monitor staff performance.

SAQ 3.1 ................................................................................................................

The activity ‘install oven’ was originally scheduled to take 4 weeks, but after 3 weeks

(note that ‘install oven’ started at time 4 owing to the delay in the preparation of the

plinth) the activity is only 50% complete. Assuming that the remaining work is now

estimated to complete to the original schedule, ‘install oven’ will take a further 2 weeks to

complete (50% of the original duration of 4 weeks). The revised duration for ‘install oven’

will therefore be 5 weeks rather than 6 weeks. The revised estimated completion date for

the project would be 13 weeks rather than the 14 weeks which was calculated

previously on the assumption that progress on the installation of the oven would

continue at the same poor rate of progress experienced so far. Using this updated

SAQ answers 115

schedule, the activity ‘lay cables’ becomes critical, and the schedule now has two

critical paths.

SAQ 3.2 ................................................................................................................

(a) On 1 May milestone D is predicted to be passed at 19 June. It is confirmed as

passed in the report on 10 July (but may have been passed on 3 July as last

predicted – as the reports are fortnightly).

(b) It is not necessary for reports to be at regular intervals. The chart is neater if the

report date rows are spaced regularly, but, for example, if one of the rows in the

chart were missing then each milestone prediction date would remain at the

previously reported date until a report was given to show differently.

(c) On 12 June milestone D has been reported to have slipped by another week, yet

milestone E is still predicted to be unchanged from its last prediction. This would

need to be justified since normally the slipping of one milestone will be expected to

cause subsequent dates to slip similarly.

SAQ 3.3 ................................................................................................................

The main advantage of the milestone tracking chart is that it shows the evolution of key

dates in an easily understood form (which could be included in a report to senior

management). The absence of detail is an advantage for anyone who wants a quick

overview of the status now and the history of progress, although this lack of detail would

be a disadvantage to someone looking for the reasons for slippage.

SAQ 3.4 ................................................................................................................

(a) The slope can never be negative because the curve is an accumulation of all the

work planned. The slope is the rate of achievement so a negative slope would

represent a negative rate of progress. This is certainly not something you plan for!

(b) Once established the planned profile of expenditure for the project (BCWS) remains

constant in order to monitor achievement against the plan. However, if a major

change occurs and the plan needs to be revised, as discussed in Subsection 3.1,

and the schedule revised, then the BCWS curve will need to be redrawn.

SAQ 3.5 ................................................................................................................

(a) Taking the value of partially completed elements as zero yields a lower bound for

BCWP of £100 000. Taking the fraction complete of partially completed elements as

100% gives an upper bound for BCWP as £130 000.

(b) It is a very crude assumption to take the average of the upper and lower bounds for

the actual value of BCWP. It is equivalent to assuming that all partially completed

work is 50% complete.

(c) If the range of BCWP is to be reduced at this stage to 10% of the total budget,

i.e. £15 000, it will be necessary to include extra milestones within activity F. As

activity D accounts for only £4000 it will not refine the value of BCWP very much

to insert extra milestones within it. So allowing for £4000 uncertainty in the BCWP

of activity D means that the BCWP of activity F must be assessed to within £11 000.

This can be done by inserting two extra milestones reasonably spaced within it.

(This assumes that suitable milestones representing significant events can be

identified; this is not always possible.)

Note that at other stages in the project there are yet more elements that need to be

broken down because they contribute large amounts to the budgeted cost.

(d) The value of BCWP at the end of the project will be £150 000. (This figure remains

fixed unless the project budget, the total budgeted cost, is changed.)


SAQ 3.6 ................................................................................................................

One possible assumption is that the remaining work is performed at the rate originally

planned. An alternative is to assume that timescales are inflated by the same factor

that has applied to work performance so far.

SAQ 3.7 ................................................................................................................

The answers to this question must be to some extent subjective, depending on how far

you believe that the cause was an isolated historic event and to what extent you believe

that there will be other similar events. A personal view from a member of the course team

is as follows:

(a) Assume a time inflation factor. The estimates for future work are likely to be equally

optimistic.

(b) Assume scheduled performance for the remainder of the work (provided the staff

recruitment is now complete).

(c) Assume a time inflation factor. These changes are likely to be followed by more

changes unless you can convince the client that it will be more expensive at later

stages in the project. If the changes persist you will need to be even more

pessimistic because late changes have much greater impact!

(d) Uncertain. If the design took longer than planned then possibly the job is bigger

than expected and this will affect the coding and testing. If the job is the same size

as expected and the design is good and complete then pessimism may be

unjustified.

SAQ 3.8 ................................................................................................................

The only terms which remain constant are the project budget, PB, and the original

scheduled completion date, SC. All the others will vary throughout the project.

SAQ 3.9 ................................................................................................................

(a) The cost performance index:

CPI = BCWP/ACWP = 100/110

The estimated cost at completion using assumption 2:

ECAC = PB/CPI = PB 6 ACWP/BCWP = £200 000 6 110/100 = £220 000

(b) The cost variance CV after 6 months is –£10 000.

If the remainder of the work is performed to budget the further costs to complete are

£100 000.

The estimated cost at completion is:

ECAC = PB – CV = £200 000 – (–£10 000) = £210 000

SAQ 4.1 ................................................................................................................

The three possible combinations are:

c SV5 0, CV5 0, the project is on or ahead of schedule and on or under budget. The

staff are completing the work more quickly than planned or exactly on time.

c SV < 0, CV 5 0, the project is behind schedule and on or under budget. The staff

are not completing the work as quickly as planned but the project is costing less

than anticipated. This situation may arise because not all the planned resources are

being used on the project.

c SV 5 0, CV < 0, the project is on or ahead of schedule and over budget. This

situation may arise because more resources are being used on the project than

planned and this is costing more than planned; however, the additional resources

mean the project is ahead of schedule.

SAQ answers 117

Remember that in order to interpret the earned value information effectively the project

manager must always investigate the causes of the variances and communicate the

situation to the stakeholders.

SAQ 4.2 ................................................................................................................

The graphs of an ideal project would look like Figure S.1. Successive revised estimates

of cost (E1, E2, E3, etc.) run horizontally across the top, and estimated completion dates

(S1, S2, S3, etc.) run vertically up the side. The graphs of ACWP and BCWP would

coincide with BCWS as planned.

Unit 6SAQ 2.1 ................................................................................................................

The main differences are shown in Table S.1.

Table S.1 Differences between progress and quality reviews

Progress review Quality review

Usually held periodically – monthly or

weekly

Held at a fixed point in project, usually at

the end of a major phase: for example,

at the end of the design phase

Attendees represent all functions within

the project

Attendees are those able to comment on

the review document, for example the

design, and often concentrate on a single

function

External contributors are not usually

present

Attendees usually include non-project

staff for their independent view

Scheduling issues often predominate over

technical issues

Technical issues are the predominant

subject

cost

(£00

0)

month

100

70

50

20

0

40

DNOSAJJMAMFJ

BCWS

10

30

60

80

90

ACWP and BCWPcoincide with BCWS

S0S1

S2S3

S4

S5

S6

S7

S8

S9

S10

S11

E11E10E9E8E7E6E5E4E3E2E1E0

Figure S.1 An ideal project


SAQ 2.2 ................................................................................................................

A preliminary design review is likely to look at questions such as:

c Do we (the attendees) understand the requirements we are attempting to meet?

c Is this design following a proper path to reach our objectives?

c Is this design feasible?

c Have alternatives been considered? Have the advantages and disadvantages of the

alternatives been fairly assessed?

You may have thought of other points.

SAQ 2.3 ................................................................................................................

When a component is tested in isolation it is usually necessary to provide some

additional code to simulate the environment in which the component will work and

additional code may be needed to enable the tester to see how the component

operates. After integration some of this will no longer be required and the component

can be tested in an environment closer to its final configuration. This may reveal faults

that were not apparent before. At however late a stage a change is made to a

component, it can have unforeseen side-effects, and regression testing is necessary to

ensure that no such effects exist.

SAQ 2.4 ................................................................................................................

(a) The answer appears in Table S.2.

Table S.2 Test type and quality aspect

Quality Component

test

Integration

test

Release

test

Alpha

test

Beta

test

function 33 33 33 3 x

correctness 33 33 3 3 x

performance x 3 33 33 33

usability x x 3 33 33

(b) Regression testing repeats other tests such as component, integration and release

tests. At each stage the quality aspect tested for is the same as for the original tests.

SAQ 2.5 ................................................................................................................

(a) Senior management visits are not formal enquiries. They usually rely on

presentations by the project manager and team, without undertaking systematic

enquiry.

(b) Major design reviews may be very like project audits but they are not usually

independent. They are usually conducted by members of the project team. Even

quality assurance staff associated with the ongoing project should not be regarded

as independent.

(c) Progress reports are regular updates of status which are not external to the project.

(d) Evaluation after termination will not assist the future conduct of a current problem.

SAQ 3.1 ................................................................................................................

A change control board set up to control changes across the client–contractor boundary

of the project is unlikely to be appropriate for monitoring internal change because it

probably has the wrong membership. Not all clients wish to be concerned with matters

which are internal to the conduct of the contracting organisation (although some clients

may).

SAQ answers 119

SAQ 4.1 ................................................................................................................

(a) A design object may be freely changed by its designer, but a configuration item

may be changed only under control and the change must be recorded.

(b) While an item is being actively developed on a workbench or drawing board it would

hamper progress if every change had to be approved.

(c) An interface specification may be quite small compared with the components being

interfaced. It is therefore easier for designers to concentrate just on the interface

when reaching an agreement rather than being concerned with the design of the

whole of the adjacent components.

(d) Assuming that the configuration management system has been set up, the

requirement specifications should become a configuration item (at the latest) when

the contract is agreed. Any subsequent changes require approval and recording.

(The requirements could become a single item but a grouping of items could be

useful to allow more flexibility.)

SAQ 4.2 ................................................................................................................

Clearly an item cannot be dependent upon a design object which has not yet become a

configuration item, because that object may be changed at any time without reference

to anyone. So the direction of a dependency implies that the item being pointed to has to

become a configuration item first. If the link is in both directions then both may be

developed as design objects in parallel but they become configuration items at the

same time.

SAQ 4.3 ................................................................................................................

(a) The scope of configuration management is usually applicable to all documents or

other items in a project which are products of the project in the widest sense,

including items that are used for subsequent development. A configuration does not

encompass the whole of the system under development, only those items that have

matured sufficiently for change control to be applied. Items that are still being

changed frequently are not put under change control and are called design objects.

(b) The four principal elements of a configuration management system are

identification, control, status accounting and auditing.

SAQ 4.4 ................................................................................................................

The answers must depend on the context of the configuration, but here is one

judgement:

(a) Quite good (slightly long?).

(b) OK in the context of one bearing in one motor but not if there is more than one of

either motors or bearings.

(c) Not descriptive and therefore not memorable.

(d) Unlikely to be unique.

(e) Poor. It is not very descriptive and fixes the position of this component in relation to

others, so it may be difficult to move later if required. The naming convention used

here also identifies a particular problem for software. Software can be available in a

number of different representations. For example there will be a description of a

component, some source code and the compilation of the source code into an

executable version of the program. The name used here does not identify the item

clearly enough. An item name such as edit.cde would identify more clearly that the

configuration item was source code for the component dealing with edit functions.

SAQ 4.5 ................................................................................................................

The advantage of including the project name in the naming convention for a

configuration item is that all items which relate to that project can be clearly identified


and retrieved. An automated tool for configuration management will use the name to

identify all the items for that project. However, such conventions reflect the origin of an

item and as such create complications if an item can be reused within another project.

Maintaining two copies of the same item with different names within the repository of

configuration items should be discouraged owing to the problems of keeping both items

in step when changes are made independently.

SAQ 4.6 ................................................................................................................

(a) A baseline is a set of known and agreed items under change control.

(b) Baselines render the development process more visible by providing the status at

fixed points (usually major milestones) from which progress may be measured.

SAQ 4.7 ................................................................................................................

(a) A variant could arise if a similar course were required for a different student

population. For example, there could have been variants for those studying mainly

courses provided by the Mathematics, Computing and Technology Faculty as

opposed to those studying with the Business School, or if the course were translated

into another language for use abroad.

(b) After a course has been studied for a while experience shows that it could be

improved. The original version has errors and omissions. A new version may be

produced, superseding the old, perhaps with two or three of the units rewritten.

SAQ 4.8 ................................................................................................................

Once an item has been registered it may be in use by other team members and they will

need to be aware of the original mistake and of the proposal to correct it. Even if the item

is not being used the history of changes which have made to the item will be incomplete.

Traceability will be compromised.

SAQ 4.9 ................................................................................................................

Last week the component was a design object. No one else placed reliance on it. This

week other team members may already be using it and relying on the fact that any

impending change, even a correction, will be notified to them, asking for approval. If

small improvements are allowed through without approval it will be impossible to draw a

firm line on which changes need to be controlled.

SAQ 4.10 ..............................................................................................................

The advantages of appointing a single authoritative person to control all items would be

that everyone would know immediately who was responsible for approving all changes

and that person would be aware of all the current change proposals. This could be

satisfactory in a small project.

The disadvantages are that in a large project it would be difficult for one person to be

sufficiently conversant with every aspect to make good decisions on change requests.

Furthermore, it would involve a senior engineer unnecessarily in many trivial matters.

This would slow down development enormously and the senior engineer would become

a bottleneck. The system would also appear less democratic and would tend to arouse

resentment.

SAQ 4.11 ..............................................................................................................

Although this could often work satisfactorily in a small, informally organised project,

several important stages are being by-passed. First, by omitting the formal change

request there is no record of the reason for change. Second, the assessment of impact

may not be adequate. Third, no one else knows of the impending change until after the

work has been done and it may then be too late to point out some defect in the proposal.

The use of a custodian or an automated tool to take the role of the custodian should

SAQ answers 121

prevent this happening (as well as enforcing a disciplined approach by designers who

see the benefit of configuration management).

SAQ 4.12 ..............................................................................................................

(a) The configuration diagram shows what other items potentially depend on the item

under consideration. If a change is made to the item then further changes may be

needed to dependent items and to items dependent on these in turn.

(b) One advantage would be a reduction in the number of requests because this extra

work would deter a requester; so the total throughput of work would be reduced.

Another advantage would be an improvement in the quality of the request, since the

act of making the assessment would enable the requester to improve the proposal

or abandon an ill-advised request.

The disadvantages are that valuable requests may be left aside because of the

additional burden and the requester may not have the skills required to make the

assessment.

SAQ 4.13 ..............................................................................................................

There may be more than one component placed under change control at contract but

one essential item is the contract itself, or at least the part of the contract that specifies

the work to be done. (Some parts of the contract, such as the commercial terms, may be

someone else’s province and subject to separate change control procedures.)

SAQ 4.14 ..............................................................................................................

c Too much time will be spent on the change control procedures.

c Having to change their work to fit in with other people’s changes too frequently will

be unnecessarily disruptive to a designer. It may well be more efficient to

accommodate the latest changes in a composite round-up after a suitable interval.

SAQ 4.15 ..............................................................................................................

(a) The main purposes are: to report the current state of the system, or any items in it,

and the history of events leading to this state; and to provide traceability.

(b) It is necessary to capture all significant events as they occur and store the data in

some organised way so that reports can be produced quickly. A computer-based

system is appropriate for this task.

SAQ 4.16 ..............................................................................................................

(a) Configuration items such as the top-level design are identified unambiguously.

(b) The way that a change to the refrigeration unit has to be requested, approved by

controllers and recorded.

(c) Recording all changes by the administrator and answering questions about status

and history.

(d) The questions asked by the quality manager.

SAQ 5.1 ................................................................................................................

The project review is a source of lessons learnt and should identify follow-up actions

which can be used as part of a continuous improvement programme for project

management practices in any organisation. In an immature organisation in terms of

project management practices the project review should help to prioritise the actions

needed for improvement.

SAQ 5.2 ................................................................................................................

Those involved in conducting the project review can use the measures identified to

monitor risk associated with the critical success factors to measure at the end of the

project whether the project management objectives were satisfied. Senior management,


team members, the project manager and stakeholders can be consulted to identify the

degree to which the objectives were satisfied.

The reviewer might explore the following (there are many more issues which you might

have included):

c Was there an agreed specification for the work?

c Was the specification included in the contract?

c Was a business case produced and accepted by the client?

c Were there any staff or skill shortages in the project?

c Was the team clear about roles and responsibilities?

c Was the mechanism for change documented in the contract?

c Was the mechanism for change adhered to?

c Was there a project plan agreed by all stakeholders?

c How frequently was the plan updated?

c Were milestones defined?

c Was there milestone slippage in the project?

SAQ 5.3 ................................................................................................................

Tasks Completed By whom

Close internal work orders

Close external contracts

Check completion of all tasks

Summarise any outstanding commitments

Prune and complete the project file

Index the project file and store it

Ensure drawings are complete and indexed

Ensure maintenance procedures are

documented

Dispose of unused equipment and materials

Hold a review meeting with users

Prepare final report on project

Present final report to management

SAQ answers 123

IndexA

activity-level milestones 17

actual cost of work performed 40

alpha testing 67

anticipation 16

archive 93

audit 70

authorisation 52

avoiding slippage 50

B

baseline 90

beta testing 67

blog 20

budgeted cost of work performed 34

budgeted cost of work scheduled 30

C

causes of slippage 50

change control board 94

changes to the plan 16

checkpoint 97

closing the loop 22

combined cost and schedule graphs 45

communicating 11

configuration 83

configuration administrator 94

configuration auditing 88

configuration control 88

configuration control board 94

configuration identification 88

configuration item 85

configuration management 70, 83

configuration status accounting 88

configuration store 93

controlling 11

controlling future commitments 52

controlling the project cost 52

cost to complete 42

cost variance 41

cost–performance index 41

custodian 93

D

design object 85

design review 61

directing 11

E

earned value 34

earned value method 29

earned value system 29

electronic reporting 20

estimated completion date 37

estimated cost at completion 41

extra resources 50

F

feed-forward control 16

G

Gantt chart 24

gathering the information 17

I

informal discussions 22

initiating 8

inspection 60

issue 104

issue log 104

item controller 94

M

measuring project status 17

milestone tracking 27

milestones within activities 17

monitor–control–monitor again 22

monitoring 11

monitoring the cost and schedule 24


O

off-specification 104

organising 9

P

performed work 35

periodic progress reports 19

phase-out plan 106

planned value 30

planning 9

progress review meetings 21

project audit 71

project budget 30

project control loop 45

project health check 16

project mobilisation 8

project network diagram 24

public commitment 21

pulling the plug 53

Q

quality assurance 59

quality audit 71

quality control 59

quality review 59

R

regression testing 68

reporting by exception 19

revising the schedule 26

S

schedule variance 35

scheduled completion date 30

scheduled work 35

schedule–performance index 36

S-curve slippage 38

slippage 35

software metrics 64

staffing 9

sunk costs 42

T

testing 59

time inflation factor 37

timeliness 19

time-phased budget 30

traceability 99

U

updating the schedule 24

V

validation 65

variant 92

verification 65

W

walk-through 59

Index 125

Units5&6 - Arab Open University

Documents

Transcript of Units5&6 - Arab Open University