Home

 

Supplementary information is available at http://www.oskarsson.se/useful_info/innehall.html.

 

TUTORIAL
ACQUISITION AND SUPPLY OF SOFTWARE DEVELOPMENT

Östen Oskarsson

 

Why this tutorial

Subcontracting and outsourcing are becoming popular in the manufacturing industry. From manufacturing, subcontracting is now spreading to development; the customer orders equipment or components to be developed by a subcontractor. Company management normally do not have much experience in the special aspects of acquisition of development, and especially not the development of very complex items, e.g. software.

Also, the suppliers tend to be unaware of the customerís need to monitor the development process in order establish confidence in the eventual appearance of the ordered item.

Readers

This is a tutorial mainly for practitioners, not for academia. The intended readership consists of two separate groups:

The first group should get information about how to handle a supplier and an acquisition, especially how to control the supplier.

The second group should understand why the customer insists on different requirements, and how to fulfil them.

Contents

Introduction

Why is software special?

General about acquisition of software

The quotation phase

The contract phase

Monitoring the development

Delivery

The maintenance phase

Introduction

When purchasing components and subsystems to their own product, industries often spend much effort to see that the quality assurance of the supplier's production is sufficient. In my experience, customers spend much less effort on the quality assurance of the supplier's software development, when this is part of the contract. But they should.

It is very common that the supplier runs into problems with the software development. In numerous cases, the customer has suddenly, in a late stage, been told that the delivery date can not be met. A new date is promised, but when it gets closer, a further delay is announced, e.t.c. In other cases, a software product is delivered, but it does not fulfill the customer's expectations. Long and bitter arguments may follow about what is said in the contract, who had what responsibility, and so on. A development project is subject to risks, and normally one can not guarantee that an acquisition will be successful. As a customer, one can, however, safeguard against surprises. By formulating the contract in the right way, and by monitoring the supplier's work, the customer can

Why is software special?

Why do we need this tutorial? Why can't we treat software as any other items to be acquired? The answer is threefold:

The figure above illustrates the difference between ordinary manufacturing industry, and software industry in these respects. The sizes of the boxes indicate cost or work amount.

In the manufacturing industry, design is a relatively small activity, and the production cost for each produced unit is high. Control and management in manufacturing industry is largely a question about controlling the production.

In the software industry, on the other hand, design is everything. Production is just a matter of copying electronically from one medium to another, and this is done automatically. Control and management in the software industry is about controlling the design.

I intend the circles to illustrate the complexity of the product. Mechanical items have a low complexity (e.g. in number of moving parts), while the complexity of software is enormous. Many problems with software development come from lack of respect for this complexity.

Acquisition of software - general

As with most other contracts of this kind, software acquisition can be seen from the customer side as several activities or processes:

Request for quotation from one or several suppliers.
During this activity, the specification of the product is prepared. Requirements necessary for ensuring management of the development are formulated.

Evaluation of quotations and suppliers.
First the best offers are identified, and then those suppliers are evaluated with respect to their ability to sucessfully deliver what will be contracted.

Contract formulation and negotiation.
The contract contains very much the same information as the request for quotation, plus commercial conditions. It is negotiated with one, and sometimes two, suppliers, and one is selected.

Monitoring and cooperation during development
The customer must monitor the supplier's activities to ensure against unpleasant surprises. Also, the customer must support the supplier with any information needed. New and changed requirements from the customer must be negotiated, and some of them introduced in the design.

Acceptance of the delivered software.
The customer and the supplier must have agreed on the criteria for customer acceptance, i.e. when the supplier's commitment is finished.

Maintenance and enhancement done by the supplier.
If the supplier is to handle maintenance and future enhancements, this must be well controlled and managed from the customer side.

The level of formality can differ considerably, depending on the size of the contract, the importance of the software, and the relation between customer and supplier. Not very important software, contracted to an old supplier with excellent record, may be handled quite informally. A large control system for a nuclear reactor is something completely different.

Notice that there is one kind of acquisition, which is not covered in this tutorial. That is when the contractor only supplies staff and expertise, but the customer is responsible for running the development project. In this case, the contract is about consultancy and not about a product. From a management and control point of view, this is not much different from the customer developing the software with his own staff only.

The quotation phase

During the quotation phase, the customer does the following:

In some branches of the software industry, suppliers tend to press each other to offer too low prices and too early delivery dates. The manager of a software company once said to me: "If we presented realistic quotations, we would never get any contracts. We would always be underbidden by less inhibited competitors."

This can become a real problem for the customer when selecting contractor. One might be convinced that the lowest bid is unrealistic, but it is difficult to prove to one's own management. Thus, the persons handling the acquisition may be forced to select a supplier which they are certain will fail.

The method to avoid this dilemma was described to me by another aquiaintance: "We only invite quotations from serious suppliers, who we know will offer realistic prices and delivery dates." Thus, avoiding problems later depends on important decisions early in the acquisition process.

Request for quotation

Request for quotation is a document which is sent to potential suppliers for the contract. It should contain at least the following information:

The request is an important document, and mistakes in it can create problems and costs later. It is very important to realize that most of the contents in the request will be directly incorporated in the contract. For example, if a supplier has quoted price and other conditions based on a requirements specification in the request for quotation, using a different requirements specification in the contract means new negotiations.

Quotation evaluation

The evaluation must be planned in advance. When the quotations start to arrive, it is too late to begin the discussion about how to evaluate and compare them.

The result from the evaluation should be a short-list of about three suppliers, who should then be evaluated regarding their ability to fulfill the quotation.

Supplier evaluation

Each short-listed supplier should be evaluated regarding such things as financial strength and ability to develop software. Part of the evaluation can be done based on the information in the quotation, especially if it contains references to previous customers, who can be contacted.

However, to ensure that each supplier is a capable software developer, the prospective customer should conduct an audit of each supplier's software development. This can be done for example in a two-day visit, when the auditors check e.g. staffing, development procedures and practices, and the performance of previous development projects.

The result from the supplier evaluation should include the following information:

Supplier selection

To select one of the short-listed suppliers is a complicated process. Some questions the buyers should ask themselves are:

The contract phase

A contract is then prepared based on the quotation from the selected supplier and any negotiated deviations from the quotation

The following issues may be covered in the contract:

It is not possible to ensure the success of an acquisition by making the contract watertight. Apart from contract negotiation, customer and supplier should work to establish good relationships, so that they are open to each other's problems, and can work together in a fruitful way.

Monitoring the development

So, the contract is signed and the supplier starts the development work. Unfortunately, this does not mean that the customer can now lean back and do nothing, waiting for the contracted software to materialize.

In practice, the pressure on the supplier is not that hard at this point in the acquisition. If the supplier's staff choose to give the project low priority now, it will take a long time before the customer has evidence of this and may be in a position to threaten to cancel the contract. And then he will still be in a weak position, since a lot of time has passed, and cancelling the contract would mean starting the whole acquisition process again, which will take still more time. And the next supplier might not be any better than the current one.

Thus, the customer must start monitoring the supplier's activities immediately when the contract starts. A story might help to explain: Once I was involved in the evaluation and selection of software suppliers for a large project. One month after contract signing, we wanted to visit the selected supplier and check on progress. However, the time was not really suitable for the supplier, so we suggested a new date one month further in the project. The date was accepted by the supplier, but when it came closer, there were important reasons why the supplier needed to postpone the visit again. This time, we specified a third date, and said that this time we would come whether it suited the supplier or not. So, we arrived three months into the project and immediately realised that it was six months late. Before contract, we had checked that sufficient staff was available for the project. However, the supplier had reorganized, and now the poor project manager had almost no staff available. The rest had been moved to another company in the group to work with a really important project.

Although the customer does not have much clout in the beginning of the contract, this is the time when it is most important to force the supplier to staff, plan, and organize the development project in a manner that ensures success. The customer has two tools for this purpose: Project follow-up and project audits.

Project follow-up

The contract should specify that within a certain time, e.g. one month after contract signing, the supplier must deliver a software development plan to the customer. This development plan should contain a time-schedule, but also other information about how the project is to be conducted.

The time-schedule should specify a number of activities to be finished at different times. This information can be used for follow-up. If an activity is not finished on time, there is a delay in the project. One single delay is perhaps not a major problem, but the trend should be followed closely. Several delays indicate a problem in the project, which the supplier should be asked to do something about.

The way for the customer to follow the progress of the project is by studying progress reports delivered regularly from the supplier. Never allow progress to be reported in percentages. A task, which is 99% finished is unfinished! If the Software Development Plan is clear enough, there need be no discussion whether an activity is finished or not; there should be a clear criterion specified in the plan.

Project audit

Progress reports from the supplier are taken at face value. We assume that the infomation in the reports is complete and correct. This is not always the case. From the supplier's point of view, it is often desirable to hide problems from the customer. The supplier's staff may optimistically hope that the problems will go away later (they never do). Or, by delaying information about problems, the supplier hopes that when the customer finds out, it will be too late to go to another supplier.

To ensure accurate information about the situation in the supplier's project, the customer should conduct project audits. A project audit is an unscheduled visit at the supplier's premises. Unschedueld means that the date for the visit does not depend of any specific activities in the project. However, the visit must be announced a couple of weeks in advance.

During the audit, the customer talks to project staff and reads documents. The auditors look for answers to the following questions and others:

Usually, the result from the audit consists of requirements on the supplier to amend weaknesses and oversights.

If you can afford only one project audit, do it in the beginning of the project. If you can afford two, do the other during the final phase of the project, when final testing is done. This way you can ensure that what will be delivered will be complete and well tested.

Delivery

What happens during delivery should be well specified in the contract.

The maintenance phase

After delivery, the customer can keep up some pressure on the supplier through a contract clause which delays the final payment until all warranty issues have been satisfactory dealt with. However, after this the customer's position is normally quite weak.

The customer will need error corrections, modifications and possibly further development of the software product. However, the possibility to use a second contractor for this work is small; the original contractor normally retains the ownership of the source code and specifications. If possible, include in the contract a right for the customer to use and modify the source code, and include specifications in the delivery. This may prove expensive, since software suppliers tend to veiw such items as important parts of their substance.

Thus, the supplier has a virtual monopoly on maintenance of his product. The customer's way to control the maintenance is to agree a maintenance contract. This contract should cover e.g.

Larger modifications should be contracted as ordinary development projects.