MODULE-4: MONITORING AND CONTROL

Creating the Framework

 Exercising control over a project and ensuring that targets are met is a matter of regular monitoring – finding out
what is happening and comparing it with targets. There may be a mismatch between the planned outcomes and the
actual ones. Replanning may then be needed to bring the project back on target. Alternatively, the target could
have to be revised.

 Figure illustrates a model of the project control cycle and shows how, once the initial project plan has been
published, project control is a continual process of monitoring progress against that plan and, where necessary,
revising the plan to take account of deviations.

 It also illustrates the important steps that must be taken after completion of the project so that the experience
gained in any one project can feed into the planning stages of future projects, thus allowing us to learn from past
mistakes.

The project control cycle

Responsibility
The overall responsibility for ensuring satisfactory progress on a project is often the role of the
project steering committee, project management board or, in PRINCE2, Project Board. Day-to-
day responsibility will rest with the project manager and, in all but the smallest of projects, aspects
of this can be delegated to team leaders.
Figure below illustrates the typical reporting structure found with medium and large projects. With
small projects (employing around half a dozen or fewer staff) individual team members usually
report directly to the project manager, but in most cases team leaders will collate reports on their
section’s progress and forward summaries to the project manager. These, in turn, will be
incorporated into project-level reports for the steering committee and, via them or directly,
 progress reports for the client.

Project reporting structures

Reporting may be oral or written, formal or informal, and regular or ad hoc – see Table Informal
communication is necessary and important, but any such informal reporting of project progress
must be complemented by formal reporting procedures – and it is those we are concerned with in
this chapter.

Categories of reporting:

Report type Examples Comment

Oral formal regular Weekly or monthly progress meetings While reports may be oral, formal written
minutes should be kept

Oral formal ad hoc End-of-stage review meetings While largely oral, likely to receive and generate
written reports

Written formal regular Job sheets, progress reports Normally weekly using forms

Written formal ad hoc Exception reports, change reports

Oral informal ad hoc Canteen discussion, social interaction Often provides early warning; must be backed up
by formal reporting

Assessing progress:
Some information used to assess project progress will be collected routinely, while other
information will be triggered by specific events. Wherever possible, this information should be
objective and tangible – whether or not a particular report has been delivered, for example.
Sometimes, however, assessment will have to depend on estimates of the proportion of the current
activity that has been completed.
Setting checkpoints:
It is essential to set a series of checkpoints in the initial activity plan. Checkpoints may be:
● regular (monthly, for example);
● tied to specific events such as the production of a report or other deliverable.
Taking snapshots:
The frequency of progress reports will depend upon the size and degree of risk of the project. Team
leaders, for example, may want to assess progress daily (particularly when employing inexperienced
staff) whereas project managers may find weekly or monthly reporting appropriate. In general, the
higher the level, the less frequent and less detailed the reporting needs to be.
Collecting the Data:
As a rule, managers will try to break down long activities into more controllable tasks of one or two
weeks’ duration. However, it will still be necessary to gather information about partially completed
activities and, in particular, forecasts of how much work is left to be completed. It can be difficult to
make such forecasts accurately.
Where there is a series of products, partial completion of activities is easier to estimate. Counting the
number of record specifications or screen layouts produced, for example, can provide a reasonable
measure of progress.
In some cases, intermediate products can be used as in-activity milestones. The first successful
compilation of a program, for example, might be considered a milestone even though it is not a final
product.
Partial completion reporting:
Many organizations use standard accounting systems with weekly timesheets to charge staff time to
individual jobs. The staff time booked to a project indicates the work carried out and the charges to the
project. It does not, however, tell the project manager what has been produced or whether tasks are on
schedule.
It is therefore common to adapt or enhance existing accounting data collection systems to meet the
needs of project control. Weekly timesheets, for example, are frequently adapted by breaking jobs
down to activity level and requiring information about work done in addition to time spent. Figure 9.3
shows an example of a report form, in this case requesting information about likely slippage of
completion dates as well as estimates of completeness. Other reporting templates are possible. For
example, rather than ask for estimates of percentage complete, some managers would prefer to ask for
the number of hours already worked on the task and an estimate of the number of hours needed to
finish the task off.
A weekly timesheet and progress review form
Red/amber/green (RAG) reporting:
One popular way of overcoming the objections to partial completion reporting is to avoid asking for
estimated completion dates, but to ask instead for the team members’ estimates of the likelihood of
meeting the planned target date.
One way of doing this is the traffic-light method. This consists of the following steps:
 identify the key (first level) elements for assessment in a piece of work
 break these key elements into constituent elements (second level)
 assess each of the second-level elements on the scale green for ‘on target’, amber for ‘not on
target but recoverable’, and red for ‘not on target and recoverable only with difficulty’.
 review all the second-level assessments to arrive at first-level assessments;
 review first- and second-level assessments to produce an overall assessment.
 For example, Amanda decides to use a version of the traffic-light method for reviewing
activities on the IOE project. She breaks each activity into a number of component parts
(deciding, in this case, that a further breakdown is unnecessary) and gets the team members to
complete a return at the end of each week. Figure 9.4 illustrates Justin’s completed assessment
at the end of week 16.

A traffic-light assessment of IoE/P/13

Traffic-light assessment highlights only risk of non-achievement; it is not an attempt to estimate work done or
to quantify expected delays.

Following completion of assessment forms for all activities, the project manager uses these as a basis for
evaluating the overall status of the project. Any critical activity classified as amber or red will require further
consideration and often leads to a revision of the project schedule. Non-critical activities are likely to be
considered as a problem if they are classified as red, especially if all their float is likely to be consumed.
Review:

From a manager’s perspective, review of work products is an important mechanism for monitoring the progress
of a project and ensuring the quality of the work products.

 Every project is developed through iterations over a large number of work products such as
requirements document, design document, project plan document, code, etc.
 Each of these work products can have a large number of defects in them due to mistakes committed by
the development team members.
 It is necessary to eliminate as many defects in these work products to realize a product of acceptable
quality. Testing is an effective defect removal mechanism.
 However, testing is applicable to only executable code. How can the defects from the non-executable
work products such as requirements document and design document be removed? Review is a very
effective technique to remove defects from all work products including code.
 In fact, review has been acknowledged to be more cost-effective in removing defects as compared to
testing. Early review techniques focused on code and systematic review techniques were developed for
this specific purpose.
 But over the years, review techniques have become extremely popular and have been generalized for use
with other work products.

Utility of review:

Besides being a cost-effective defect removal mechanism, review of any work product has several other benefits
including the following mentioned below:

● Review usually helps to identify any deviation from standards, including issues that might affect
maintenance of the software.

● Reviewers suggest ways to improve the work product such as using algorithms that are more time or space
efficient, specific work simplifications, better technology opportunities that can be exploited, etc.

● In addition to defect identification, a review meeting often provides learning opportunities to not only the
author of a work product, but also the other participants of the review meeting. The lessons acquired from a
review meeting allows participants to avoid committing similar defects that were discussed in the review
meeting and also allows them to make use of the best practices that were suggested.

● The review participants gain a good understanding of the work product under review, making it easier for
them to interface or use the work product in their work.

Candidate work products for review:

All interim and final work products are usually candidates for review. Usually, the work products considered to
be suitable candidates for review are as follows:
● Requirements specification documents
● User interface specification and design documents
● Architectural, high-level, and detailed design documents
● Test plan and the designed test cases
● Project management plan and configuration management plan

Review roles

 A few key roles need to be assigned to the review team members. These roles are moderator, recorder
and the reviewers.
 The moderator plays a key role in the review process. The principal responsibilities of the moderator
include scheduling and convening meetings, distributing review materials, leading and moderating the
review sessions, ensuring that the defects are tracked to closure.
 The main role of the recorder is to record the defects found, the time, and effort data. The review team
members review the work product and give specific suggestions to the author about the existing defects
and also point out ways to improve the work product.
In the following, we will first discuss a generic review process. Subsequently, we shall discuss the importance
of collection of all relevant data to the success of the review process.

Review process
Review of any work product consists of the following four important activities, viz. planning, review prepa-
ration and overview, review meeting, rework and follow-up. A review process model is shown in Figure
The model in Figure captures the sequence of the activities that need to be carried out, the input to the activities,
and the output produced from the activities. In the following, we briefly discuss these review activities.

Review process model

● Planning Once the author of a work product is ready for submitting the work for review; the project
manager nominates a moderator. A moderator can be someone who is familiar with the work product. In
consultation with the moderator, the project manager nominates the other members of the review team. Usually,
the review process works best when the number of members is between five and seven.
The effectiveness of review drastically reduces if there are less than three members. The review team is usually
selected from the following types of project team members.
■ The author of the preceding work product based on which the work product under review was developed
■ The member who would use the work product under review
■ Peers of the author
■ The authors of the work products that would interface with the work product under review The moderator
usually schedules all review meetings.
● Preparation To initiate the review process, the moderator convenes a brief preparation meeting. In
the preparation meeting, copies of the work product are distributed to the review team members. The author
presents a brief overview of the work product. The moderator highlights the objectives of the review. The
reviewers then individually carry out review and record their observations in separate documents called review
logs.
● Review Meeting In the review meeting the reviewer’s give their comments based on the logs they have
prepared beforehand. The comments may pertain to a defect, work simplification, maintainability, etc. The
author responds to the reviewers’ comments and in this discussion other reviewers may also take part. The
moderator ensures that the discussions remain focused and productive. The recorder scribes all the defects and
points that the author agrees to, as well as the review statistics in the form of a review log.
● Rework The author addresses all the issues raised by the reviewers by carrying out the necessary
modifications to the work product and prepares a rejoinder to all the points scribed in the review log. The
rejoinder records the exact ways in which the comments have been taken care of by the author. The corrected
work product along with the author’s rejoinder is circulated among all the review team members. In a final brief
meeting, the review team members check whether all the issues scribed in the review log have been resolved
satisfactorily. At the end of this meeting, a final summary report of the review is prepared.

Data collection

Since a review meeting is a completely human endeavor, unless the data representing the results of the meetings
is properly recorded, it can get lost. In addition to recording all defects, the data about the time spent by the
reviewers in the review activity must also be captured. A record of the defect data is needed for tracking defects
in the project.

The different reports in which the review data are captured are as follows:

1. Review Preparation Log Each reviewer prepares a review preparation log. The different items recorded in
it by the reviewer are the data about defects he observes, their locations, their criticality, and the total time spent
in doing the review of the work product.

2. Review Log in the review log only those defects that are agreed to by the author are logged. Defect logs are
a crucial record since these help in tracking all defects to closure.

3. Review Summary Report This report summarizes the review data and presents an overall picture of the
review. It contains information regarding the total defects and the amount of time spent on each of the review
process activities.

Project Termination Review

 A manager decides when a project should be terminated. As soon as a decision regarding project
termination is taken, it is a good practice to conduct a project review meeting.
 Project termination reviews are important for successful, failed, as well as prematurely abandoned
projects.
 The project termination review meeting marks the official closure of a project. Project termination
reviews provide important opportunities to learn from past mistakes as well as successes.
  By analyzing past mistakes the project teams can learn to do better by improving their methods and
practices. The project termination review summary report is not only beneficial to the terminated
project, but it can also benefit of other teams and therefore should be disseminated across the
organization.
 It is important to note that project termination need not necessarily mean project failure or premature
abandonment. A project may be terminated for a variety of reasons, including successful completion of
the endeavor.
 When it becomes evident that the project objectives cannot be satisfactorily met, it often makes sense to
reach a negotiated closure.
 On the other hand, an aborted project generally means a loss for most stakeholders. According to a
report, about 31% of projects are cancelled during the development phase. Even a failed project should
not be viewed negatively.
 It should be realized that wisdom is required on the part of the project manager and the stakeholders to
determine when it is desirable to terminate a project otherwise it can only be a drag on the resources
without achieving anything substantial.

Reasons for project termination

Here are a few reasons why a project gets terminated before the natural closing date:

● Project is completed successfully and handed over to the customer.

● Incomplete requirements

● Lack of resources

● Some key technologies used in the project have become obsolete during project execution.

● Economics of the project has changed, for example, because many competing products may have become
available in the market.

Project termination process

The important activities that are carried out as a part of the project termination review process are as follows:

● Project Survey The objective of the project survey activity is to collect various types of information
pertaining to the project, without compromising the confidentiality of the respondents. An electronic survey is
usually very effective. The information is collected through a set of carefully designed questionnaire that can
bring out the important process and management issues, which have a strong bearing on the success or failure of
the project.

● Collection of Objective Information A critical aspect of the postmortem review is to collect various
project metrics. Real data helps to focus discussions on most crucial issues during the postmortem review. The
different types of metrics that are collected include the cost, schedule, and quality metrics.

● Debriefing Meeting A debriefing meeting is a preparatory meeting that helps to ensure the final project
review meeting focuses on the most relevant aspects. In this meeting, only the senior members of the team
participate. The debriefing meeting helps to obtain some direct feedback about the project from the senior
members of the team.
● Final Project Review This meeting usually addresses various issues arising out of project planning and
tracking, preliminary phases (requirements analysis, specification and design), configuration management,
verification, and validation. Guided by the information collected in the previous steps, the project leaders
determine the focus of the review discussions only on the relevant topics in various project activities. For
example, if the collected data or the debriefing meeting data suggest schedule slippage, discussions on how the
schedule slippage could have been avoided are conducted. It should be remembered that fault finding or
blaming individuals must be avoided.

● Result Publication The project leader summarizes the positive and negative findings arrived at during the
termination review process as well as prescriptions for improvement. The summary is published so that all the
teams can to refer to it and also the management can take initiative for any necessary corrections based on it.

Visualizing Progress:

Having collected data about project progress, a manager needs some way of presenting that data to greatest
effect. In this section, we look at some methods of presenting a picture of the project and its future. Some of
these methods (such as Gantt charts) provide a static picture, a single snapshot, whereas others (such as timeline
charts) try to show how the project has progressed and changed through time.

The Gantt chart:

One of the simplest and oldest techniques for tracking project progress is the Gantt chart. This is essentially an
activity bar chart indicating scheduled activity dates and durations, frequently augmented with activity floats
Reported progress is recorded on the chart (normally by shading activity bars) and a ‘today cursor’ provides an
immediate visual indication of which activities are ahead or behind schedule. Figure 9.6 shows part of
Amanda’s Gantt chart as at the end of Tuesday of week 17. ‘Code and test module D’ has been completed
ahead of schedule and ‘Code and test module A’ appears also to be ahead of schedule. The coding and testing of
the other two modules are behind schedule.

Part of Amanda’s Gan chart with the ‘today cursor’ in week 17

The slip chart

A slip chart is a very similar alternative favored by some project managers who believe it provides a more
striking visual indication of those activities that are not progressing to schedule – the more the slip line bends,
the greater the variation from the plan. Additional slip lines are added at intervals and, as they build up, the
project manager will gain an idea as to whether the project is improving (subsequent slip lines bend less) or not.
A very jagged slip line indicates a need for rescheduling.

The slip chart emphasizes the relative position of each activity

The timeline

One disadvantage of the charts described so far is that they do not show clearly the slippage of the project
completion date through the life of the project. Analyzing and understanding trends in the project so far allows
us to predict the future progress of the project. For example, if a project is behind schedule because so far
productivity has not been as high as assumed at the planning stage, it is likely that the scheduled completion
date will be pushed back even further unless action is taken to compensate for or improve productivity.

The timeline chart is a method of recording and displaying the way in which targets have changed throughout
the duration of the project

Figure shows a timeline chart for Brigitte’s project at the end of the sixth week. Planned time is plotted along
the horizontal axis and elapsed time down the vertical axis. The lines meandering down the chart represent
scheduled activity completion dates – at the start of the project ‘analyse existing system’ is scheduled to be
completed by the Tuesday of week 3, ‘obtain user requirements’ by Thursday of week 5, ‘issue tender’, the final
activity, by Tuesday of week 9, and so on.
 Brigitte’s Timeline chart at the end of week six

At the end of the first week Brigette reviews these target dates and leaves them as they are – lines are therefore
drawn vertically downwards from the target dates to the end of week 1 on the actual time axis.

At the end of week 2, Brigette decides that ‘obtain user requirements’ will not be completed until Tuesday of
week 6 – she therefore extends that activity line diagonally to reflect this. The other activity completion targets
are also delayed correspondingly.

By the Tuesday of week 3, ‘analyse existing system’ is completed and Brigette puts a blob on the diagonal
timeline to indicate that this has happened. At the end of week 3 she decides to keep to the existing targets.

At the end of week 4 she adds another three days to ‘draft tender’ and ‘issue tender’.

Note that, by the end of week 6, two activities have been completed and three are still unfinished. Up to this
point she has revised target dates on three occasions and the project as a whole is running seven days late.

The timeline chart is useful both during the execution of a project and as part of the post-implementation
review. Analysis of the timeline chart, and the reasons for the changes, can indicate failures in the estimation
process or other errors that might, with that knowledge, be avoided in future.

Cost Monitoring:

Expenditure monitoring is an important component of project control, not only in itself, but also because it
provides an indication of the effort that has gone into (or at least been charged to) a project. A project might be
on time but only because more money has been spent on activities than originally budgeted. A cumulative
expenditure chart such as that shown in Figure provides a simple method of comparing actual and planned
expenditure. By itself it is not particularly meaningful –

Figure could, for example, illustrate a project that is running late or one that is on time but has shown
substantial costs savings. We need to take account of the current status of the project activities before
attempting to interpret the meaning of recorded expenditure.
 Tracking cumulative expenditure

Cost charts become much more useful if we add projected future costs calculated by adding the estimated costs
of uncompleted work to the costs already incurred. Where a computer-based planning tool is used, revision of
cost schedules is generally provided automatically once actual expenditure has been recorded. Figure illus-
trates the additional information available once the revised cost schedule is included in this case it is apparent
that the project is behind schedule and over budget.

The cumulative expenditure chart can also show revised estimates of cost and completion on date

Earned Value Analysis

Earned value analysis is based on assigning a ‘value’ to each task or work package (as identified in the WBS)
based on the original expenditure forecasts. One way of looking at this is as the equivalent of the price that
might be agreed by a contractor to do the unit of work. The assigned value is the original budgeted cost for the
item and is known as the planned value (PV) or budgeted cost of work scheduled (BCWS). A task that has not
started is assigned an earned value of zero and when it has been completed, it, and hence the project, is credited
with the original planned value of the task. The total value credited to a project at any point is known as the
earned value (EV) or budgeted cost of work performed (BCWP) and this can be represented as a money value,
an amount of staff time or as a percentage of the PV. EV is thus analogous to the agreed price to be paid to the
contractor once the work is completed.
Where tasks have been started but are not yet complete, some consistent method of assigning an earned value
must be applied. Common methods in software projects are:

● the 0/100 technique: where a task is assigned a value of zero until such time that it is completed when it is
given a value of 100% of the budgeted value;

● the 50/50 technique: where a task is assigned a value of 50% of its value as soon as it is started and then
given a value of 100% once it is complete – this matches some contractual arrangements where a contractor is
given half the agreed price when starting the work, perhaps to help pay for raw materials, and the remainder on
successful completion;

● the 75/25 technique: where the task is assigned 75% on starting and 25% on completion – this is often
used when a large item of equipment is being bought: 75% is paid when the equipment is actually delivered and
the remainder when installation and testing has been satisfactorily completed;

● the milestone technique: where a task is given a value based on the achievement of milestones that have
been assigned values as part of the original budget plan;

● percentage complete: in some cases there may be a way of objectively measuring the amount of work
completed – for example, as part of the implementation of an information system, a number of data records
have to be manually typed into a database and the actual number so far completed can be objectively counted.

The baseline budget

The first stage in setting up an earned value analysis is to create the baseline budget. The baseline budget is
based on the project plan and shows the forecast growth in earned value through time. Earned value may be
measured in monetary values but, in the case of staff-intensive projects such as software development, it is
common to measure earned value in person-hours or workdays. Amanda’s baseline budget, based on the
schedule shown in Figure 8.7, is shown in Table 9.2 and diagrammatically in Figure. Notice that she has based
her baseline budget on workdays and is using the 0/100 technique for crediting earned value to the project.

Amanda’s baseline budget

Monitoring earned value

Having created the baseline budget, the next task is to monitor earned value as the project progresses. This is done
by monitoring the completion of tasks (or activity starts and milestone achievements in the case of the other
crediting techniques).

As well as recording EV, the actual cost of each task can be collected as actual cost (AC). This is also known as
the actual cost of work performed (ACWP). This is shown in Figure 9.12, which, in this case, records the values
as percentages of the total budgeted cost.

Figure below also illustrates the following performance statistics, which can be shown directly or derived from the
earned value chart.

Schedule variance (SV)

The schedule variance is measured in cost terms as EV – PV and indicates the degree to which the value of
completed work differs from that planned. Say, for example, that work with a PV of £40,000 should have been
completed by now. In fact, some of that work has not been done so that the EV is only £35,000. The SV would
therefore be £35,000 – £40,000, that is – £5,000. A negative SV means the project is behind schedule.

Time variance (TV)

Figure 9.13 also indicates the time variance (TV). This is the difference between the time when the achievement
of the current earned value was planned to occur and the time now. In this case, the current EV should have been
achieved in the early part of month 9 and as the time now is the end of month 11, the TV is about –1.75 months.

An earned value tracking chart

Cost variance (CV)

This is calculated as EV – AC and indicates the difference between the earned value or budgeted cost and the
actual cost of completed work. Say that when the SV above was calculated as –£5,000, £55,000 had actually been
spent to get the EV. The CV in this case would have been £35,000 – £55,000 or –£20,000. It can also be an
indicator of the accuracy of the original cost estimates. A negative CV means that the project is over cost.

Performance ratios
Two ratios are commonly tracked: the cost performance index (CPI = EV/AC) and the schedule performance
index (SPI = EV/PV). Using the examples above, CPI would be £35,000/£55,000, that is, 0.64, and SPI would be
£35,000/£40,000, that is, 0.88. The two ratios can be thought of as a ‘value-for-money’ indices. A value greater
than one indicates that work is being completed better than planned, whereas a value of less than one means that
work is costing more than and/or proceeding more slowly than planned.

In the same way that the expenditure analysis in Figure 9.9 was augmented to show revised expenditure
forecasts, we can augment the simple earned value tracking chart with forecasts as illustrated in Figure.

An earned value chart with revised forecasts

Prioritizing Monitoring

So far we have assumed that all aspects of a project will receive equal treatment in terms of the degree of
monitoring applied. We must not forget, however, that monitoring takes time and uses resources that might
sometimes be put to better use. In this section we list the priorities we might apply in deciding levels of
monitoring.

 Critical path activities Any delay in an activity on the critical path will cause a delay in the completion
date for the project. Critical path activities are therefore likely to have a very high priority for close
monitoring
 Activities with no free float A delay in any activity with no free float will delay at least some subsequent
activities even though, if the delay is less than the total float, it might not delay the project completion
date. These subsequent delays can have serious effects on our resource schedule as a delay in a
subsequent activity could mean that the resources for that activity will become unavailable before that
activity is completed because they are committed elsewhere
 Activities with less than a specified float If any activity has very little float it might use up this float
before the regular activity monitoring brings the problem to the project manager’s attention. It is
common practice to monitor closely those activities with less than, say, one week free float.
 High-risk activities A set of high-risk activities should have been identified as part of the initial risk
profiling exercise. If we are using the PERT three-estimate approach we will designate as high risk those
activities that have a high estimated duration variance. These activities will be given close attention
because they are most likely to overrun or overspend
 Activities using critical resources Activities can be critical because they are very expensive (as in the
case of specialized contract programmers). Staff or other resources might be available only for a limited
period, especially if they are controlled outside the project team. In any event, an activity that demands a
critical resource requires a high level of monitoring.

Getting the Project Back to Target

Almost any project will, at one time or another, be subject to delays and unexpected events. One of the tasks
of the project manager is to recognize when this is happening (or, if possible, about to happen) and, with the
minimum delay and disruption to the project team, attempt to mitigate the effects of the problem. In most
cases, the project manager, at least initially, tries to ensure that the scheduled project end date remains
unaffected.

There are two main strategies to consider when drawing up plans to bring a project back on target –
shortening the critical path or altering the activity precedence requirements.

Shorten the critical path

The overall duration of a project is determined by the current critical path, so speeding up non-critical path
activities will not bring forward a project completion date. However, there are several ways in which this
might be done.

● Adding resources – especially staff Exhorting staff to ‘work harder’ might have some effect, although
frequently a more positive form of action is required, such as increasing the resources available for some
critical activity. Fact-finding, for example, might be speeded up by allocating an additional analyst to
interviewing users.

● Increase use of current resources Resource levels can be increased by making them available for longer.
Thus, staff might be asked to work overtime for the duration of an activity and computing resources might
be made available at times (such as evenings and weekends) when they might otherwise be inaccessible.

● Reallocate staff to critical activities The project manager might consider allocating more efficient staff
to activities on the critical path or swapping resources between critical and non-critical activities. When a
project is actually executed, the critical path may change as the actual durations of activities will vary from
the original estimates and staff allocations may be adjusted to reflect this.

● Reduce scope The amount of work to be done could be reduced by reducing the scope of the function-
ality to be delivered. The client may prefer to have a subset of the promised features on time – especially if
they are the most useful ones – rather than have the delivery of the whole application delayed.

● Reduce quality Some quality-related activities such as system testing could be curtailed. This would
probably lead to more corrective work having to be done to the ‘live’ system once it has been implemented.

Reconsider the precedence requirements

If attempting to shorten critical activities proves insufficient, the next step is to consider the constraints by
which some activities have to be deferred pending completion of others. The original project network would
most probably have been drawn up assuming ‘ideal’ conditions and ‘normal’ working practices. It might be
that, to avoid the project delivering late, it is now worth questioning whether as yet unstated activities really
do have to await the completion of others. It might, in a particular organization, be ‘normal’ to complete
system testing before commencing user training. In order to avoid late completion of a project it might,
however, be considered acceptable to alter ‘normal’ practice and start training earlier.

Maintaining the business case

In making decisions about the management of the project, the main concern of the project sponsor, that is,
the stakeholder who is putting up the money for the project, is whether the business case for the project has
been preserved. You may recall from Chapter 2 that the value of the benefits of a project must be greater
than its cost for the project to be viable. If costs increase, then this reduces the value of the benefits at the
end of the project. If the project is delayed or the amount of functionality in the deliverables is curtailed, it
means that the benefits that the project will generate will be reduced. At some point the costs may exceed
the benefits and the project then loses its viability. A decision could then be made to cancel the project.

Exception planning

The project manager will normally be allowed to change the detail of a plan as long as the agreed project
outcomes are produced on time and within budget.

In some cases, an operational change may affect other stakeholders. One such case would be where the
timing of acceptance testing by users had to be changed. In such a case the project manager would need to
gain the acceptance of these stakeholders for the change.

Some changes to the plan might have an impact on the delivery date, project scope or costs. These, in turn,
could affect the business case for the project. Here the project manager would need to gain the approval of
the business sponsors of the project. We saw above that the interests of the sponsors could be represented
through a group variously known as a Project Board (in PRINCE2), project management board or steering
committee.

Change Control

So far in this chapter, we have assumed that the nature of the deliverables has not changed. A project leader
like Amanda or Brigette might find, however, that requirements are modified because of changing circum-
stances or because the users get a clearer idea of what is really needed. The payroll system that Brigette is
implementing might, for instance, need to be adjusted if the staffing structure at the college is reorganized.

Other, internal, changes will crop up. Amanda might find that there are inconsistencies in the program
speci- fications that become apparent only when the programs are coded, and these would result in
amendments to those specifications.

When a document such as the user requirements is being developed there may be many different versions of
the document as it undergoes cycles of development and review. Any change control process at this point
would be very informal and flexible. At some point what is assumed to be the final version will be created.
This is baselined, effectively frozen. Baselined products are the foundation for the development of further
products – for instance interface design documents may be developed from baseline user requirements.

Change control procedures

A simple change control procedure for operational systems might have the following steps:
1. One or more users might perceive a need for a modification to a system and ask for a change request to
be passed to the development staff.

2. The user management would consider the change request and, if they approve it, pass it to the
development management. It is important that there is a single authorized channel for requests for change
(RFCs) between the client community and the management of the developers. There would be some
filtering within the client community to ensure that the proposed change does genuinely provide a benefit
before the RFC is generated.

3. There would be one person within the development area who would receive and process RFCs. They
would delegate a member of staff to look at the request and to report on the practicality and cost of carrying
out the change. The developer would, as part of this, assess the products that would be affected by the
change.

4. The development representative would report back to the user management on the findings and the user
management would decide whether, in view of the cost quoted, they wish to go ahead.

5. There would be some individual or group who represented the major stakeholders, both users and
developers and also the project sponsor, who would have the authority to prioritize the RFCs for action.
Ultimately this should be the Project Board or equivalent.

6. Once an RFC has been approved for action, one or more developers are authorized to take copies of the
master products that are to be modified. This would need to be done through the configuration librarian –
see below.

7. The copies are modified. In the case of software components this would involve modifying the code and
recompiling and testing it.

8. When the development of new versions of the product has been completed the user management will be
notified and copies of the software will be released for user acceptance testing.

9. When the user is satisfied that the products are adequate they will authorize their operational release.
The master copies of configuration items will be replaced.

Changes in scope of a system:

A common occurrence with IS development projects is for the size of the system gradually to increase. One
cause of this is changes to requirements that are requested by users.

Configuration librarian’s role

Control of changes and documentation ought to be the responsibility of someone who may variously be
named the configuration librarian, the configuration manager or the project librarian. Among this person’s
duties would be:

 the identification of all items that are subject to change control

 the establishment and maintenance of a central repository of the master copies of all project
documentation and software products;
 the setting up and running of a formal set of procedures to deal with changes;
 the maintenance of records of who has access to which library items and the status of each library
item (e.g. whether under development, under test or released).
 It will be recalled that it was suggested that the setting up of change control procedures might be one
of the first things the Brigette would want to do at Brightmouth College.

Software Configuration Management (SCM)

SCM is concerned with tracking and controlling changes to the software. In any systematic development
and maintenance environment, various work products (code, design document, code, etc.) associated
with the software continually change during the development as well as the maintenance phase. In a
team devel- opment environment, each member of the development or maintenance team would be
assigned to handle some modification requests. Therefore every work product would have to be
accessed and modified by several members. In such a situation, unless a proper configuration
management system is deployed, several problems can appear. We first discuss the context in which
these problems appear, and subsequently we shall investigate the different problems that a development
team might face if it does not deploy an effective configuration management system. Finally, we discuss
the configuration management process.

Context in which configuration management is necessary

During the development phase, the work products get modified as development activities are carried out.
During the maintenance phase, the work products change due to various types of enhancements and
adapta- tions that are carried out including bug fixes. Thus, the state of the work products continually
change both during the development as well as maintenance phase. The state of all work products at any
point of time is called the configuration of the software product. Software configuration management
deals with effectively tracking and controlling the configuration of a software product during its entire
life cycle. For effective configuration management, it is necessary to deploy a configuration
management tool. Thus, we can say that the different concepts associated with configuration
management are carried out in a project with the help of a tool. There are many configuration
management tools available, some are open software that is free of any licensing fees and others are
commercial tools. At the end of this section, we review a few open software configuration management
tools.

Configuration management practices include version control and the establishment of baselines. Before
we discuss configuration management, we must clearly understand terms like version, revision, variant,
and baseline.

Purpose of software configuration management

There are several reasons why proper configuration management of the work products in a project is
essential. The following are some of the important problems that can occur if a proper configuration
management system is not used.

 Problems Associated with Concurrent Access Possibly the most important reason for
configuration management is to control the access to the different deliverable objects. Unless
strict discipline is enforced regarding update and storage of different work products, several
problems can appear. Let us assume that only a single copy of a program module is maintained,
 and several developers are working on it. Two developers may simultaneously carry out changes
to the different functions of the same work product, and while saving overwrite each other.
 Undoing Changes It becomes easy to undo some part of a revision or even rollback development
to a certain version. Unless proper configuration management system is in place, it becomes very
difficult to undo a change.
 System Accounting System accounting denotes keeping track of who made a particular change
to a configuration item, what change was exactly made, and when the change was made.
Knowing the what, who, and when of changes will help in understanding why changes were
made and whether some changes are redundant or for comparing the performance of particular
versions. It may at times be required to rollback to a previous baseline if a change is not justified
or is improper. Users may wish to compare today’s version of some software with yesterday’s
version or last year’s version. Since a configuration management system keeps track of every
version and revision, this becomes a simple task.
 Handling Variants As we have already discussed, it often becomes necessary to create variants.
In this situation, without a configuration management system, keeping track of all variants, their
versions and revisions is a nontrivial task. Further, existence of variants of a software product
causes some peculiar problems. Suppose you have several variants of the same module, and find
that a bug exists in one of them. Then it has to be fixed in all versions and revisions. To do it
efficiently, you should not have to fix it in each and every version and revision of the software
separately. Making a change to one program should be reflected in all relevant versions and
revisions.
 Accurate Determination of Project Status Normally, a project manager performs the configu-
ration management activity by using a configuration management tool. In addition, a
configuration management tool helps to keep track of various deliverable objects so that the
project manager can quickly and unambiguously determine the current state of the project. The
configuration management tool enables the developer to change the various components in a
controlled manner.
 Preventing Unauthorized Access to the Work Products Configuration management helps
implement a controlled change process. It therefore becomes possible to prevent unauthorized
changes to the work products.

Configuration management process

Configuration management is carried out through the following two principal activities:

● Configuration Identification: This activity involves deciding which parts of the system should be kept
under configuration management.

● Configuration Control: This activity is used to ensure that changes to a system occur smoothly. In the
following section, we provide an overview of these two activities.

● Configuration Identification

Project managers normally classify the work products associated with a software development process into
three main categories, viz., controlled, pre-controlled, and uncontrolled. Controlled work products are those that
are put under configuration control. The team members must follow some formal procedures to change these.
Pre-controlled work products are not yet under configuration control, but will eventually be under configuration
control. Uncontrolled work products will not be subject to configuration control. Controllable work products
include both controlled and pre-controlled work products.

Typical controllable work products include the following:

● Requirements specification document

● Design documents

● Tools used to build the system such as compilers, linkers, lexical analysers, parsers, etc.

● Source code for each module

● Test cases

● Problem reports

● Configuration Control

Configuration control is part of a configuration management system that most directly affects the day-to-day
operations of developers. Configuration control allows only authorized changes to the controlled objects and
prevents unauthorized changes. The project manager can give permission to some members to be able to change
or access specific work products.

Configuration management tools allow only one team member to reserve a module at any time. Once a work
product is reserved, it does not allow anyone else to reserve this module until the reserved module is restored.
Thus, by preventing more than one developer to simultaneously reserve a module, the problems associated with
concurrent access are taken care of.

Work product modifications under configuration on management

Modifications to a work product under configuration control

When developers need to change a work product they first make a reserve request. A reserve request by a team
member is honoured only if appropriate authorization has been given by the project manager to that member for
the specific work product. After the reserve command successfully executes, a private copy of the work product
is created in their local directory. Then, they can carry out all necessary changes to the work product on their
private copy. Once they have satisfactorily completed all necessary changes, the changes need to be restored in
configuration management repository. However, restoring the changed work product to the system
configuration requires the permission of a change control board (CCB).

The CCB is usually constituted from among the development team members. For every change that needs to be
carried out, the CCB reviews the changes made to the controlled work product and certifies certain aspects
about the change such as

● Change is well-motivated

● Developer has considered and documented the effects of the change

● Changes interact well with the changes made by other developers

● Appropriate people (CCB) have validated the change, e.g., someone has tested the changed code, and has
verified that the change is consistent with the need

The change control board (CCB) is seldom a group of people. Except for very large projects, the functions of
the change control board are normally discharged solely by the project manager or some senior member of the
development team.

Open source configuration management tools

SCCS and RCS are two popular configuration management tools available on most UNIX systems. SCCS or
RCS can be used for controlling and managing different versions of text files. SCCS and RCS do not handle
binary files (i.e., executable files, documents, files containing diagrams, etc.). SCCS and RCS provide an
efficient way of storing versions that minimize the amount of occupied disk space. Suppose, a module MOD is
present in three versions MOD1.1, MOD1.2 and MOD1.3, then SCCS and RCS stores the original module
MOD1.1 together with changes needed to transform MOD1.1 into MOD1.2, and MOD1.2 to MOD1.3. The
changes needed to transform each baseline file to the next version are stored and are called deltas. The main
reason behind storing the deltas rather than storing the full revision files is to save disk space.

The change control facilities provided by SCCS and RCS include the ability to incorporate restrictions on the
set of individuals who can create new versions, and facilities for checking components in and out (i.e., reserve
and restore operations). Individual developers check out components and modify them. After they have made
all the necessary changes to a component, and after these changes have been reviewed, they check in the
changed module into SCCS or RCS.