Module-3 PROJECT MANAGEMENT AND CONTROL

• Framework for Management and control –

• Collection of data –
• Visualizing progress –
• Cost monitoring –
• Earned Value Analysis –
• Prioritizing Monitoring –
• Project tracking –
• Change control –
• Software Configuration Management –
• Managing contracts –
• Contract Management.
Explain the project control cycle in Creating the Framework 10 Marks

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 9.1 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.

FIGURE 9.1 The project control cycle

Explain the reporting structure found with medium and large projects. 5 marks

• 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.

FIGURE 9.2 Project reporting structures

Reporting may be oral or written, formal or informal, and regular or ad hoc – see Table 9.1.

Informal communication is necessary and important, but any such informal reporting of
project progress must be complemented by formal reporting procedures .

.
Illustrate monitoring of project progress with a neat diagram 10marks

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.

1. 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.

2. 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.
• At the level of individual developers, however, strong arguments exist for the formal weekly
collection of information.
• This ensures that information is provided while memories are still relatively fresh and
provides a mechanism for individuals to review and reflect upon their progress.
• If reporting is to be weekly then it makes sense to have basic units of work that last about a
week.
• Major, or project-level, progress reviews will generally take place at particular points during
the life of a project – commonly known as review points or control points.
• PRINCE2, for example, designates a series of checkpoints where the status of work in a
project or for a team is reviewed.
• At the end of each project Stage, PRINCE2 provides for an End Stage Assessment where an
assessment of the project and consideration of its future are undertaken.

3. 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.
Explain with examples, how can partially completed data be used effectively 10 marks
during the data collection process?

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,
Ways to Use Partially Completed Data Effectively
1. Data Imputation (Filling Missing Values)

• Use statistical techniques to estimate missing values.

• Example: If 3 out of 5 age entries are filled (25, 30, 27), you can use the mean (27.3) to
fill the remaining two.

2. Trend Analysis

• Even incomplete data can show trends or patterns over time.

• Example: A website traffic report missing 3 days in a month can still reveal weekly
patterns or peak usage times.

3. Segment Analysis

• Use the complete sections of data for focused analysis.

• Example: If survey data is missing demographic info but has full responses to user
satisfaction questions, you can still analyze general satisfaction trends.

4. Triggering Further Collection

• Partially completed forms can help identify areas where users drop off, prompting UI
or UX improvements.
• Example: An online form where most users stop after question 4 signals a usability
issue.

5. Model Training (with Caveats)

• In machine learning, some algorithms can handle missing data (e.g., decision trees,
random forests).
• Example: A model predicting product demand might still be trained on incomplete sales
records using built-in imputation.

6. Cross-Referencing with Other Sources

• Incomplete data can be supplemented with data from other systems.

• Example: Missing email addresses in a CRM can be filled using LinkedIn or third-party
enrichment tools.
Write short note on RAG reporting 5 marks

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.
 • 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.

What is Project Termination Review? Explain reasons for project 5 marks

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.

Illustrate the important activities that are carried out as a part of the project 5 marks
termination review process.

Project termination process

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

1. 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.

2. 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.
3. 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.

4. 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.

5. 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.

Explain the various methods of Visualizing Progress in presenting a picture of 10 marks

the project and its future.

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.
The slip chart

A slip chart (Figure 9.7) 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 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.

• Analysing 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 9.8 shows a timeline chart for Brigette’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.
illustrates the process of Cost Monitoring in project control. 5 marks

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 9.9 provides a simple method
of comparing actual and planned expenditure.
• By itself it is not particularly meaningful –
• Figure 9.9 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.
• 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 9.10 illustrates 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.
 Explain the earned value analysis in detail with an example. 5 marks

Earned Value Analysis

• Earned value analysis has gained in popularity in recent years and may be seen as a
refinement of the cost monitoring discussed in the previous section.
• It originated in the USA’s Department of Defence (DOD) as a part of a set of measures to
control projects being carried out by contractors for the DOD.
• Earned value analysis is based on assigning a ‘value’ to each task or work package (as identifi
ed 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).

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)

• 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.

• 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.
 •

Explain two main strategies to consider when drawing up plans to bring a 10 marks
project back on target in Project Tracking.
Explain the concept of project tracking. Describe its importance and list the 10 marks
tools commonly used for tracking a project's progress.

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.

i) 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.
• Reduce scope
 The amount of work to be done could be reduced by reducing the scope of the
functionality to be delivered.
• Reduce quality
Some quality-related activities such as system testing could be curtailed.

ii) 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 unstarted 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.
• One way to overcome precedence constraints is to subdivide an activity into a
component that can start immediately and one that is still constrained as before.
• For example, a user handbook can be drawn up in a draft form from the system
specification and then be revised later to take account of subsequent changes.

What is change control in project management? Explain its process and 10 marks
significance in ensuring project success.

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 circumstances 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 specifications 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 baselined 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.
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.
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.
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.

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.
 Define Software Configuration Management (SCM). Explain its key activities 10 marks
and importance in software development.

Software Configuration Management (SCM)

• SCM is concerned with tracking and controlling changes to the software.
• various work products (code, design document, code, etc.) associated with the software
continually change during the development as well as the maintenance phase.
• every work product would have to be accessed and modified by several members.

Purpose of SCM
Few terminologies
In the following section we defi ne terms like configuration, version, revision, variant, and baseline.

Configuration
The configuration of software is the state of various work products that are under configuration
control. The work products that are under configuration control are usually referred to as the confi
guration items.

Version
As development and maintenance activities are carried out on a software product, its configuration
(that is, one or more configuration items) keeps changing. It often becomes necessary to refer to the
configuration that existed at certain point of time.

Revision
A revision system is a numbering scheme that is used to identify the state of a configuration item at
any time. Each time a work product is updated its state changes.

Baseline
A baseline is a software confi guration that has been formally reviewed and agreed upon, and serves
as a basis for further development.

Variant
Variants are versions that are intended to coexist. Different variants may be needed to run the
software on different operating systems or on different hardware platforms. For example, one variant
of a mathematical computation package might run on Unix-based machines, another on Microsoft
Windows machines.
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 confi
guration management is to control the access to the different deliverable objects.

● Undoing Changes It becomes easy to undo some part of a revision or even rollback development
to a certain version.

● 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.

● 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

● Accurate Determination of Project Status Normally, a project manager performs the configuration
management activity by using a configuration management tool.

● Preventing Unauthorized Access to the Work Products Configuration management helps

implement a controlled change process.

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.

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. In order to change a
controlled work product such as a code module, a developer can get a private copy of the module
through a reserve operation (see Fig. 9.15). 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.
 What is contract management in project management? Explain the key stages 10 marks
involved in managing contracts effectively.

Managing Contracts
Given their limited capability for developing new and reliable software, this seems sensible.

At IOE, Amanda has a team of software developers employed by IOE.

However, the demand for development effort fluctuates as projects come and go.

The IOE management might therefore decide that it is more cost-effective to employ outside software
developers for new development while a reduced group of in-house software development staff
maintain and support existing systems.

The buying of goods and services, rather than ‘doing it yourself’, is attractive when money is available
but other, less flexible, types of resource, especially staff time, are in short supply.

However, there are risks arising from the considerable staff time and attention still needed to
manage a contracted-out project successfully.

Types of Contracts
• The external resources required could be in the form of services, for example staff on short-
term contracts carrying out some project tasks.
• At Brightmouth College, Brigette could use temporary staff to input employee details needed
for the new payroll system.
• IOE might carry out application-building in-house but augment the permanent staff with
contract developers.
• The contractor might not only supply the new system but also operate it on the customer’s
behalf. For example, Brightmouth College might abandon buying a package and instead get
a payroll services agency to carry out the payroll work.

On the other hand, a contract for a completed software package could be placed.
This could be:
● a bespoke system created specifically for one customer;
● an off-the-shelf package bought ‘as is’ – this is sometimes referred to as shrink wrapped
software;
● customized off-the-shelf (COTS) software – where a core system is modified to meet the
needs of the client.

Where equipment is purchased, in English law, this is normally a contract for the supply of
goods. With the supply of software this may be regarded as supplying a service (i.e. to write
the software) or the granting of a licence (i.e. permission) to use the software which remains
in the ownership of the supplier. These distinctions will have legal implications.
 Another way of classifying contracts is by the way that the payment to suppliers is calculated.
We will look at:

• fixed price contracts;

● time and materials contracts;
● fixed price per delivered unit contracts

Fixed price contracts

In this situation a price is fixed when the contract is signed.
The customer knows that, if there are no changes in the contract terms, this is the price they
pay on completion.
For this to be effective, the customer’s requirement has to be fixed at the outset.

The advantages of this method are:

● Known customer expenditure
As long as the requirements are precise and not changed, the customer has a known cost.
● Supplier motivation
The supplier has a motivation to work in a cost-effective manner

The disadvantages include:

● Higher prices to allow for contingency
The supplier absorbs the risk for any errors in the estimates. To reduce the impact of this risk,
the supplier will add a margin to the price quoted.
● Difficulties in modifying requirements
The need to change the scope of the requirements may become apparent during
development – this may cause friction between the supplier and customer.
● Upward pressure on the cost of changes When competing against other potential
suppliers, the supplier will try to quote as low a price as possible.
Once the contract is signed, if further requirements are put forward, the supplier is in a strong
position to demand a high price for these changes.
● Threat to system quality
The need to meet a fixed price could mean that the quality of the software suffers.

Stages in Contract Placement

Requirements analysis

Evaluation plan

Invitation to tender

Evaluation of proposals

Contract Management
• We have already noted that forms of communication between the supplier and customer
during the project could be specified in the contract.
• It would probably suit all concerned if the contractor is left to get on with the work.
• However, at certain decision points (or milestones) the customer might wish to examine work
already done and make decisions about the future direction of the project.
• The project could require representatives of the supplier and customer to interact at key
points in the development cycle – for example, users may need to provide information to
assist interface design.
• One way of identifying the decision points is to divide a large project into increments.
• For each increment there could be an interface design phase, and the customer might need
to approve the designs before the increment is built.
• There could also be decision points between increments.
• For each decision point, the deliverables from the suppliers, the decisions to be made by the
customer and the possible outcomes need to be defined.
• These decision points have added significance if they are the basis for payment to the
contractor. The customer also has responsibilities at these decision points – for example, the
contractor should not be delayed unnecessarily awaiting customer approval of interim
deliverables.
• There will be concerns about the quality of contracted work.
• The ISO 12207 standard envisages the possibility of there being agents, independent of both
the supplier and customer, who will carry out verifi cation, validation and quality assurance.
• It also allows for joint reviews of project processes and products to be agreed when the
contract is negotiated.
• We saw earlier that changes to requirements will vary the contract terms.
• Oral evidence is not normally admissible to contradict, add to, or vary the terms of a written
contract, so that agreed changes need to be documented.
• A change control procedure must record requests for changes, the supplier’s agreement to
them and the cost for additional work.
• The supplier might not meet a legal obligation.