Course Title:

BIT401: Software Project Management

Unit 9: Managing Contracts

Unit 9: Managing Contracts (3 Hrs.)

Introduction; Types of Contract; Stages in Contract Placement; Typical Terms of a

Contract; Contract Management, Acceptance
 Unit 9: Managing Contracts
Unit 9: Managing Contracts (3 Hrs.)

Introduction;
Types of Contract;
Stages in Contract Placement;
Typical Terms of a Contract;
Contract Management, Acceptance

Unit 9: Managing Contracts

Introduction
The management's decision to acquire software externally instead of developing it in-house.
The rationale behind this decision is the limited capability of the in-house software
development team and the fluctuating demand for their services. To adapt to these challenges,
the management is considering outsourcing new development projects while maintaining a
smaller in-house staff for existing systems.
The decision to acquire goods and services externally is influenced by the availability of funds
and the scarcity of certain resources, such as staff time. While external acquisition provides
flexibility, it also comes with risks, particularly in managing contracted-out projects. The
importance of investing time upfront to clarify requirements and ensure satisfactory delivery is
highlighted. So, planning are crucial in external acquisition projects, similar to internal
development efforts.
The chapter explores different types of contracts that can be used, outlines general steps in
placing a contract, examines issues in drafting a contract, and describes activities during
contract execution. The bargaining position of the customer is highlighted, emphasizing that a
stronger business relationship can lead to better negotiation terms. Additionally, potential
suppliers are more likely to be accommodating before a contract is signed, especially in fixed-
price contracts. The importance of assessing the time and resources required to respond to
customer requests is underscored, as there is no guarantee of securing the final contract.
 Unit 9: Managing Contracts
Types of Contract
Contracts are of two type services and goods. Supply of software may be regarded as
supplying a service (i.e. to write the software) or the granting of a license (i.e.
permission) to use the software which remains in the ownership of the supplier. These
distinctions will have legal implications.
The contractor might not only supply the new system but also operate it on the
customer’s behalf. For example, organization 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.

Unit 9: Managing Contracts

Types of Contract
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.

Further, another way of categorizing contracts, at least initially, is according to the

approach that is used in contractor selection, namely
 Open tendering process
 Restricted tendering process
 Negotiated procedure
 Unit 9: Managing Contracts
Types of Contract:
Fixed price contracts - 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. In other words, when the contract is to construct a software system, the
detailed requirements analysis must already have been carried out. Once the
development is under way the customer cannot change their requirements without
renegotiating the price of the contract.

The key points:

Fixed Price: In a fixed-price contract, the agreed-upon price for the project is determined and fixed when
the contract is signed. This means that both parties, the service provider (e.g., a software development
company) and the customer, agree on a specific amount that the customer will pay for the completion of
the project.
No Changes in Contract Terms: The fixed price is applicable as long as there are no changes in the
contract terms. Once the contract is signed, both parties are bound by the terms and conditions outlined
in the contract. If there are no alterations or modifications to the project scope or requirements, the
agreed-upon price remains constant.

Unit 9: Managing Contracts

Types of Contract:
Fixed price contracts
The key points:
Requirement Fixation: The effectiveness of a fixed-price contract relies on the fixation of customer
requirements at the outset. This means that, especially in the context of software development, a detailed
requirements analysis must be completed before the contract is signed. The customer's needs and
expectations should be well-defined and documented.
Limitations on Requirement Changes: Once the development of the software system is underway, the
customer is generally not allowed to change their requirements without renegotiating the contract's price.
This is a key aspect of fixed-price contracts – they provide a degree of certainty and stability for both
parties, but this comes at the cost of flexibility. If the customer wishes to make changes to the project
scope, it may necessitate a reevaluation and adjustment of the contract price.
 Unit 9: Managing Contracts
Types of Contract -Fixed price contracts
Advantages 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.

Disadvantages are:
 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 fi xed price could mean that the quality of the
software suffers.

Unit 9: Managing Contracts

Types of Contract - Time and materials contracts
With this type of contract, the customer is charged at a fixed 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 final payment. The supplier usually invoices the customer for work done at
regular intervals, say each month.
Advantages 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.
 Unit 9: Managing Contracts
Types of Contract - Time and materials contracts
Disadvantages 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.

Because the supplier appears to be given a blank cheque, this approach does not find
favour with customers. However, the employment of contract development staff may
in effect involve this type of contract.

Unit 9: Managing Contracts

Types of Contract - 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 shows a typical schedule of prices.

The company that produced this table

in fact charge a higher fee per FP for
larger systems. For example, a system
to be implemented contains 2600
FPs. The overall charge would be
2000 x $967, plus 500 x $1,019, plus
100 x $1,058.
 Unit 9: Managing Contracts
Types of Contract - Fixed price per unit delivered contracts
Advantages 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.
Disadvantages are:
 Difficulties with software size measurement - Lines of code can easily be infl ated 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

Unit 9: Managing Contracts

Types of Contract - Fixed price per unit delivered contracts
To reduce the last difficulty, one suggestion from Australia has been to vary the charge
depending on the point at which they have been requested – see Table 10.2.

There are other options and permutations of options for payments. The implementation of a
specification could be at a fixed price, with any additions or changes to the requirements to be
charged per FP. Where the contractor has buy in equipment, the price of which may fluctuate,
it is possible to negotiate a contract where the final price contains a fixed portion for labour
plus an amount that depends on the actual cost of purchased components.
 Unit 9: Managing Contracts
Types of Contract - Fixed price per unit delivered contracts
EXERCISE:
A contract stipulates that a computer application is to be designed, constructed and delivered
at a cost of $600 per FP. After acceptance testing, the customer asks for changes to some of the
functions in the system amounting to 500 FPs and some new functions which amount to 200
additional FPs. Using Table 10.2, calculate the additional charge.

Unit 9: Managing Contracts

Types of Contract:

Another way of categorizing contracts, at least initially, is

according to the approach that is used in contractor selection,
namely

 Open tendering process

 Restricted tendering process
 Negotiated procedure
 Unit 9: Managing Contracts
Open tendering process - In this case, any supplier can bid to supply the goods and
services. All bids compliant with the original conditions in the invitation to tender
must be considered and evaluated in the same way. With a major project this
evaluation process can be time consuming and expensive.
There has been a global movement towards removing barriers to businesses in one
country supplying goods and services in another. Examples of this are efforts by the
World Trade Organization (WTO) and the European Union to ensure that public
bodies do not unfairly favour local businesses. Among the agreements overseen by
the WTO is one on government procurement which lays down rules on tendering
processes. Where the client is a public body, an open tendering process may be
compulsory.

Unit 9: Managing Contracts

Restricted tendering process - In this case, there are bids only from suppliers who
have been invited by the customer. Unlike the open tendering process, the customer
may at any point reduce the number of potential suppliers being considered. This is
usually the best approach to adopt.
Negotiated procedure - There may, however, be some good reasons why the
restricted tendering process may not be the most suitable in some particular sets of
circumstances. Say, for example, that there is a fi re that destroys some ICT
equipment. The key concern here may be to get replacement equipment up and
running as quickly as possible and there may simply not be the time to embark on a
lengthy tendering process. Another situation might be where a new software
application had been successfully built by an outside supplier, but some extensions
are required to the system. As the original supplier has staff familiar with the existing
system, it might be inconvenient to approach other potential suppliers via a full
tendering process. In these cases, an approach to a single supplier may be justified.
However, approaching a single supplier could expose the customer to charges of
favouritism and should only be done with a clear justification.
 Unit 9: Managing Contracts
Stages in Contract Placement

1. Requirements analysis
2. Evaluation plan
3. Invitation to tender
4. Evaluation of proposals

Unit 9: Managing Contracts

Stages in Contract Placement
Requirements analysis - Before potential suppliers can be approached, we need to
have a clear set of requirements. The requirements document might typically have
sections with the headings shown in Table 10.3.

Evaluation plan - Having drawn up a list of requirements, we now need a plan of how
the proposals are to be evaluated.
 Unit 9: Managing Contracts
Stages in Contract Placement
Invitation to tender - Having produced the requirements and the evaluation plan, it
is now possible to issue the invitation to tender to prospective suppliers. Essentially,
this will be the requirement document with a supporting letter containing information
about how responses to the invitation are to be lodged. A deadline will be specifi ed
and it is hoped that by then a number of proposals with price quotations will have
been received.
Evaluation of proposals – Based on an evaluation plan describing how each proposal
will be checked against the selection criteria. This reduces risks of requirements being
missed and ensures that all proposals are treated consistently. It would be unfair to
favour a proposal because of the presence of a feature not requested in the original
requirement.
The process of evaluation may include:
 Scrutiny of the proposal documents;
 Interviewing suppliers’ representatives;
 Demonstrations;
 Site visits;
 Practical tests.

Unit 9: Managing Contracts

Typical Terms of a Contract
It is not possible to describe the all necessary content of contracts for ICT goods or
services. However, to outline some of the major areas of concern are. Please read the
text book:
 Definitions
 Form of agreement
 Goods and services to be supplied
 Ownership of the software
 Environment
 Customer commitments
 Acceptance procedures
 Standards
 Project and quality management
 Timetable
 Price and payment method
 Miscellaneous legal requirements
 Unit 9: Managing Contracts
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 verification, 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. This might not be their fault, if, for example, the customer causes the delay by lateness
in giving the necessary approvals for intermediate products. If no action is taken when the default occurs, this might imply that the
customer in fact condones the failure and could lead to the loss of legal rights. The customer should protect their legal rights by
officially notifying the supplier that the failure has been recognized. It will be recalled that under English law any claim for liquidated
damages should be based on actual losses, so the customer needs to keep an accurate record of the actual losses incurred as a result of
the default

Unit 9: Managing Contracts

Acceptance
When the work has been completed, the customer needs to arrange acceptance testing.
The contract may limit how long acceptance testing can take, so the customer must be
organized to carry out this testing before the time limit for requesting corrections expires.
We have already noted that some software suppliers are rather cursory with their pre-
acceptance testing. It seems that they would rather the users spent their time on testing
than them. This imposition can be reduced by asking to approve the supplier’s internal
test plans. An associated pitfall is that once the main development work is completed, the
supplier not unnaturally wants to reallocate their most productive staff to other projects.
The customer could find that all their problem reports are being dealt with by relatively
junior members of the supplier’s staff, who may not be familiar with all aspects of the
delivered system.
Part or all of the payment to the supplier should depend on this acceptance testing.
Sometimes part of the final payment is retained for a period of operational running and is
paid if the levels of performance are as contracted for. There may also be a period of
warranty during which the supplier should fi x any errors found for no charge. The
supplier might suggest a very short warranty period of, say, 30 days. It may be in the
customer’s interests to negotiate a more realistic period of, say, at least 120 days.
 Unit 9: Managing Contracts
CONCLUSION:
Some of the key points:
 The successful contracting out of work requires considerable amounts of
management time;
 It is easier to gain concessions from a supplier before a contract is signed rather than
afterwards;
 Alternative proposals need to be evaluated as far as possible by comparing costs over
the whole lifetime of the system rather than just the acquisition costs;
 A contract will place obligations on the customer as well as the supplier;
 Contract negotiation should include reaching agreement on the management of the
supplier–customer relationship during the execution of the project.