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.
Introduction
 Once work schedules have been published and the project is started, attention must be
focused on progress.
 This requires monitoring of what is happening, comparison of actual achievement
against the schedule and, where necessary, revision of plans and schedules to bring the
project as far as possible back on target.
 In earlier chapters we have stressed the importance of producing plans that can be
monitored
– for example, ensuring that activities have clearly defined and visible completion
points.
 We will discuss how information about project progress is gathered and what actions
must be taken to ensure that a project meets its targets.

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

In practice we are normally concerned with four types of shortfall –

 delays in meeting target dates,
 shortfalls in quality,
 inadequate functionality, and
 costs going over target.

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

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 .

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

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

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 analysing 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 endeavour.
 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.
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.
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.

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).
 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
budgetted 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.

Stages in EVA
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
 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 9.11.
 Notice that she has based her baseline budget on workdays and is using the 0/100
technique for crediting earned value to the project.
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.

Project Tracking
 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.
 This can be done by shortening remaining activity durations or shortening the overall
duration of the remaining project in the ways described in the next section.
 It should be remembered, however, that this might not always be the most appropriate
response to disruptions to a plan.
 There is little point in spending considerable sums in overtime payments in order to speed
up a project if the customer is not overly concerned with the delivery date and there is no
other valuable work for the team members once this project is completed.
 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.

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.

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

Time and materials contracts

With this type of contract, the customer is charged at a fi xed rate per unit of effort, for
example per staff-hour. The supplier may provide an initial estimate of the cost based on
their current understanding of the customer’s requirements, but this is not the basis for the
fi nal payment. The supplier usually invoices the customer for work done at regular
intervals, say each month.
The advantages of this approach are:
● Ease of changing requirements
Where a project has a research orientation and the direction of the project may change as
options are explored, then this may be an appropriate method of payment.
● Lack of price pressure
The lack of price pressure may promote better quality deliverables.

The disadvantages of this approach are:

● Customer liability
The customer absorbs the risks associated with poorly defined or changing requirements.
● Lack of incentives for supplier
The supplier has no incentive to work in a cost-effective manner or to control the scope
of the deliverables.
 Fixed price per unit delivered contracts

 This is often associated with function point (FP) counting.

 The size of the system to be delivered is calculated or estimated at the outset of the
project. The size could be estimated in lines of code, but FPs can be more easily derived
from requirements documents. A price per unit is also quoted.
 The final price is then the unit price multiplied by the number of units.
 Table 10.1 shows a typical schedule of prices.

The advantages of this approach are:

● Customer understanding
The customer can see how the price is calculated and how it will vary with changed requirements.
● Comparability
Pricing schedules can be compared.
● Emerging functionality
The supplier does not bear the risk of increasing functionality.
● Supplier efficiency
The supplier still has an incentive to deliver the required functionality in a cost effective manner
(unlike with time and materials contracts).
● Life-cycle range The requirements do not have to be definitively specified at the outset.
Thus the development contract can cover both the analysis and design stages of the project.
The disadvantages of this approach are:
● Difficulties with software size measurement
Lines of code can easily be inflated by adopting a verbose coding style.
With FPs, there may be disagreements about what the FP count should really be:
in some cases, FP counting rules may be seen as unfairly favouring either the supplier or
customer. Users, in particular, will almost certainly not be familiar with the concept of FPs and
special training may be needed for them.
The solution to these problems may be to employ an independent FP counter.
● Changing requirements
Some requested changes may affect existing code drastically but not increase the overall FP
count. A change made late in the development cycle will usually require more effort to implement
than one made earlier.

Another way of categorizing contracts, at least initially, is according to the approach that is used
in contractor selection, namely
● open
● restricted
● negotiated.

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.