The nature of a contract between a customer and a provider should be determined by their business relationship.

When someone purchases packaged software, they do not expect to have a close business relationship with the software developer. They purchase the package because it performs a function. They select the package in a highly objective process: the selected package best meets a list of functional requirements.

As the nature of the services moves through the spectrum from custom development to outsourcing, so the nature of the relationship moves through a spectrum.

This "relationship spectrum" has a number of features.

Subjectivity

The subjectivity of the acquisition process increases. This increase begins as a gradual rise. As the spectrum moves from custom development through packages, the objectivity remains roughly the same, although there is an increasing tendency to select on the basis of "look-and-feel". With the move to a service orientation, the subjectivity of the acquisition process increases with facilities management and with contracting out, and undergoes a major increase with outsourcing.

For the selection of providers, the process is predominantly subjective.

Rigour

The rigour of the acquisition process similarly rises.

To many people, this is paradoxical. As the selection process becomes more subjective, they expect it to become less rigorous. In fact, as subjectivity increases, so rigour has to increase, to ensure that the process remains competitive and equitable.

When the selection of a service provider depends increasingly on the provider's ability to work with its customers, the selection process has to include more rigorous reference checking than a less subjective process. With selection of an provider, it is not only usual for the customer's staff to visit other customers, but for them to spend days with those other customers, learning how the interactions with the provider actually work.

Ongoing relationship

There are some misconceptions that accompany thinking about the existence and nature of an ongoing relationship.

With a customer development, for example, there is practically no ongoing relationship of the kind that this paper describes. Communication between the customer and the developer may be regular and constructive during software development. Once the software has settled into "maturity", the developer's role is to provide ongoing maintenance and occasional upgrades and extensions. Sometimes, the developer may be reluctant to continue to communicate with the customer, although this is often caused by the pricing of the development and the developer's need to keep maintenance costs as low as possible.

It is really only in the area of facilities management that any real relationship between the customer and the provider develops. Even then, it may still be minimal, especially if there is little opportunity for the provider to expand its service delivery to the customer.

With contracting out, the provider may have more opportunities for increased business with the customer, and so a real ongoing business relationship may develop.

With outsourcing, such a relationship is essential to both the provider and the customer.

User involvement

Across the spectrum, the frequency of user involvement tends to decline, experiencing a gradual drop in moving from customer developments to packages, and a faster drop across the services of facilities management, contracting out and outsourcing.

While the frequency of user involvement tends to drop, the level of user involvement tends to rise. This means that, across the spectrum, there is a rise in the involvement of users in the issues of the outcomes that the customer's business needs, with less involvement in the definition of the individual tasks needed to achieve those outcomes.

The decline in frequency may be related to the rise in the level of involvement.

An example of how user involvement changes is illustrated by acceptance testing. For customer developments, users usually get involved at a low level (designing and preparing test data) and frequently (planning, designing, running and analysing tests). For outsourcing, users usually get involved at a high level (designing and monitoring service levels) and infrequently (conducting service reviews).

Specification

As with user involvement, so the level of specification rises and the detail of specification falls across the spectrum.

For a custom development, the specification needs to be a low level and detailed.

For outsourcing, the specification should be at a high level (outcomes) and with little detail (service levels).