Managing Contracts

UNIT – 4
PART - 2
 Introduction
• In the Brightmouth College scenario, the college management have decided to obtain their software
externally. 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.

Potential suppliers are likely to be more accommodating before any contract is signed than afterwards –
especially if the contract is for a fixed price. Thus, as much forethought and planning is needed with an
acquisition project as with internal development.
 Types of Contract
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. 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 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 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.

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