This article originally appeared in the January 2003 issue of The Rational Edge E-zine on-line magazine, copyright 2002-2003 IBM and Max Wideman.

The Rational Unified Process (RUP) is a rigorous software development process advocated by the Rational Software Corporation.

The downloadable PDF file of the paper on this site is the one prepared by the Rational Edge editorial staff with the special assistance of Ms Marlene Ellin.

Published here September, 2003.

PART III | Recap | Variables Involved in Forming a Contract
Selecting the Optimum Form and Type for Your Contract
Negotiating a Warranty | PART V

Variables Involved in Forming a Contract

As we've noted in previous articles, the notion of contracting -- the acquisition of goods and services through contract -- is a very flexible one. A contract can be devised to reflect requirements of any number of variables, and the acquirer's contracting strategy should be designed to optimize overall project results with regard to associated risks.

To determine the best type of contract for your project, you will want to consider the ten variables we discuss below. They are all interdependent to a greater or lesser extent, and all can be depicted on a continuum. In the figures below, the left side of the continuum represents the best interests of the acquirer; the right side represents the supplier's best interests.

Variable One: Product Type

As shown in Figure 1, the product type may range from standard off-the-shelf software to off-the-shelf software with some degree of customization (i.e., "COTS") to fully developed software. Standard "off-the-shelf" software is normally obtained by direct purchase order rather than through contract, since less risk is involved. The more customized the software, the greater the risk; this risk should be managed by adopting strategies recommended in the Rational Unified Process® (RUP®).

Figure 1: Product Type
Figure 1: Product Type

Variable Two: Product Scope of Work

Figure 2 shows the range of requirements definition, which determines the degree of certainty for the scope of work and the extent and timing of expected changes. The better defined the requirements, the lower the risks to both acquirer and supplier, and the greater the opportunity to establish fixed time and cost parameters.

Figure 2: Product Scope of Work
Figure 2: Product Scope of Work

Variable Three: Product Safety and Liability

Figure 3 reflects the extent to which the software product will be used in a safety-regulated environment and the liability in case of failure. For example, an airplane traffic controller system has a much higher safety requirement -- and therefore needs more thorough testing -- than, say, a stock control system. The higher the concern about risk of failure, the higher the level of integrity required. This will be reflected in cost and schedule increases.

Figure 3: Product Safety and Liability
Figure 3: Product Safety and Liability

Variable Four: Acquirer's Level of Control

Figure 4 shows the extent to which the acquirer wishes to exercise control over the software development work. Typically, for a fixed-price contract, the acquirer's control is minimal; if they try to exert more control, they risk a contract claim on the supplier's part for "interference." Fixed-price contracts place the risk of software development on the shoulders of the supplier. To mitigate this risk, the supplier must either ensure that the requirements are well defined or insist upon a "time-and-materials" basis for compensation. With progressive acquisition, you can begin with a time-and- materials approach for early phases of the project and then agree on progressively firmer terms for time and costs as the project progresses. This represents an essential advantage over traditional fixed-price contracts.

Figure 4: Acquirer's Level of Control
Figure 4: Acquirer's Level of Control

Variable Five: Supplier's Level of Control

Figure 5 displays the converse of Figure 4: the extent to which the supplier has control over the development process, and hence responsibility for the product's performance. As we have noted, the supplier has primary control in a fixed-price scenario; but the supplier's control (and desire for control) is minimal in the case of a "cost-plus" or "time and material" form of contract. These types of contracts place the risk and responsibility on the acquirer's shoulders.

Figure 5: Supplier's Level of Control
Figure 5: Supplier's Level of Control

Variable Six: Acquirer's Involvement in Quality Control

Figure 6 shows the range of options for the acquirer's involvement in quality control. In a fixed-price contract, quality control rests almost entirely with the supplier, although inspection and testing may be conditions for interim progress payments.

Figure 6: Acquirer's Involvement in Quality Control
Figure 6: Acquirer's Involvement in Quality Control

Variable Seven: Timing for Delivery and Pace of Work

Figure 7 shows the practical range of delivery timing. If the target delivery date is earlier than the normal pace of work would allow, then the work must be accelerated by some means that incurs additional costs, such as overtime or extra resources. This may also entail additional risk because it is more difficult to coordinate the work.

Figure 7: Timing for Delivery and Pace of Work
Figure 7: Timing for Delivery and Pace of Work

Variable Eight: Form of Compensation

A fixed price, as suggested in Figure 8, appears to be in the best interests of the acquirer. However, if the conditions of such a contract are not met, then the contracted work may well end up being more costly, taking longer, and even ending in failure. The software industry is rife with examples of fixed-price contracts that worked to the detriment of both acquirer and supplier. For this reason, parties often adopt a modified form of fixed-price contract with provision for scope variations and with or without incentives. Time and materials compensation is most appropriate if the extent of the requirements is either not yet known or highly uncertain. As we noted in discussing Variable Four, Acquirer's Level of Control, progressive acquisition allows you to use a time and materials approach up front when there is great uncertainty, and then firm up terms for time and cost later on, when the risk of doing so is lower for both sides.

Figure 8: Form of Compensation
Figure 8: Form of Compensation

Variable Nine: Supplier's Cost-Risk Position

Figure 9 reflects the supplier's cost-risk position vis a vis customization. Supplying standard, off-the-shelf software provides the lowest-cost, safest, and quickest return to the supplier. However, standard software may or may not meet the acquirer's needs and typically requires some degree of customizing. Even so, COTS is usually less risky to both parties than an all-custom developed solution.

Figure 9: Supplier's Cost-Risk Position
Figure 9: Supplier's Cost-Risk Position

Variable 10: Cost-Risk for Acquirer versus Supplier

Figure 10 broadly summarizes the respective positions of acquirer and supplier for all nine variables we have just discussed: The acquirer's cost-risk is inversely proportional to the supplier's risk. As we have seen, the degree of technological risk is the driving concern for both parties, especially in the case of fully custom-built software. The best contractual relationship should be heavily dependent upon the nature of the technology being acquired, how much is known about the solution, and how the parties want to allocate risk. In principle, each specific risk should be allocated to the party best able to control that risk.

Figure 10: Cost-Risk for Acquirer versus Supplier
Figure 10: Cost-Risk for Acquirer versus Supplier
Recap  Recap

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page