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 August, 2003.

PART II | Recap | Elements of a Valid Contract | Impediments to Successful Contracting
Progressive Contracting Overcomes Impediments
Advantages of Centralized Procurement | PART IV

Impediments to Successful Contracting

Even if all of the essential elements we discussed above are present, it is still true that the traditional contracting process is typically shrouded in traditional practices and attitudes. These can be serious impediments to achieving the type of cooperation necessary for satisfactory software development. Such practices and attitudes are deeply entrenched in the procurement industry, and one contract is not going to change that. The best that we can offer is awareness of these pitfalls, which may empower you to avoid or work around them. The essential message behind this series on progressive acquisition is that, by establishing a progressive acquisition approach, you can create an environment that fosters good cooperation at the working level between parties who might otherwise be pitted against each other.

1.   For most organizations, the main criterion for contracting is "best value for least cost."

The trouble with this approach is, "least cost" can be measured more readily and consistently than "best value," and hence gets greater emphasis. The typical standard contracting approach is not only inconsistent with the cost- and risk-reducing approach embodied in "progressive" software acquisition, as described in our previous articles; it actually conflicts with the progressive approach, especially with respect to custom software.

2.   Although a legal contract spells out the obligations of each party, the environment tends to be adversarial.

It is sometimes said that if both sides understand each other and everything goes right, you don't need a contract. But if all does not go well, then the contract is there to assign responsibilities for fixing the problem. If the problem is serious, and lawyers are brought in to resolve the differences, both parties typically take an adversarial stance from then on.

3.   The terms of the contract agreement are biased in favor of its authors.

This is surely understandable, especially when a lawyer hired to protect that organization's interests does the writing.

4.   Contracts may be written in language that is legally sound, but arcane and obscure to those endeavoring to honor the contract's terms -- especially when disputes arise.

For some reason I have yet to fathom, lawyers are reluctant to use modern, simplified English. They say it is because the arcane English has been truly tested in court. Well, perhaps.

5.   The contract package contains standard contract templates, or "standard conditions" inserted indiscriminately.

Standard templates or contract conditions are often written for obsolete or inappropriate paradigms, by those more concerned with the integrity and defensibility of the procurement process than with the results the contract is intended to produce. If you question them, you may hear the answer: "We've always done it this way!" It could take considerable effort to convince such people to use a different approach.

6.   Software development projects involve three parties, but most contracts are written as two-party agreements between buyer and seller (acquirer and supplier).

The problem here becomes obvious when we look at Figure 1. In software development especially, there are three parties: the acquirer, the supplier, and the user. Although the contractual relationship between the acquirer and the supplier is usually spelled out in the contract, that between the supplier and the user may be unclear. This may well become an area of conflict and risk that should be mitigated in the interests of both parties.

Figure 1: Software Development Involves a Non-Contracting Third Party: The User
Figure 1: Software Development Involves a Non-Contracting Third Party: The User

Software developers recognize that users do not necessarily have the same interests as the official acquirers of the product under contract, and that user interests are not necessarily spelled out in the contract. Yet user satisfaction is a paramount concern in software development, and a critical factor in project success and product acceptance. User satisfaction may well depend on how extensively users were consulted, and how effectively their comments and concerns were integrated into the requirements. It may also depend on how well the product is rolled out into the working environment. All of these variables may well be beyond the actual terms of the contract.

7.   It is difficult to estimate for a "fixed-price" contract.

It is difficult enough to estimate how much code will be required to achieve a given function, let alone how much effort will be required to write and test that code. Also, interacting with people at the acquiring organization requires a major amount of time on the supplier's part, but that is also highly variable.

Suppose you are dealing with one organization that follows the ISO/IEC 12207 Standard, which defines "acquisition" as:

The process of obtaining a system, software product, or software service[4] through contract.[5]

Then, suppose you have another client who goes by the following definition of "acquisition":

The acquiring by contract with appropriated funds of supplies or services (including construction) by and for the use of the organization through purchase or lease, whether the supplies or services are already in existence or must be created, developed, demonstrated, and evaluated.[6]

It is not difficult to imagine that the number of hours you would spend dealing with the second organization will be considerably greater than the number you'd spend dealing with the first organization!

These variations make it very difficult to estimate for a long-term fixed price contract.

8.   Although contracting is very flexible, contract arrangements can be very complex.

Complexity can arise from a number of sources in the contracting process: the manner in which the contract is formulated, the number of stakeholders that must be consulted, and so on. And any increase in complexity is accompanied by an increase in risk.

On large projects, parcels of work may be assigned to different contractors and subcontractors with different areas of expertise. This is a significant source of risk -- and the risk increases exponentially as the number of contracts increases. Why? Because it becomes unclear who will take responsibility for coordinating, integrating, and configuring the various elements. The lack of consistent interface and communication procedures is a frequent source of contractual conflict, delays, and unnecessary expense. Consequently, all parties should take great care to ensure that responsibility for this function is written into one of the contracts, and that corresponding obligations to respond are written into all of the others.[7]

Elements of a Valid Contract   Elements of a Valid Contract

4. ISO/IEC 12207 International Standard, Section 3: Definitions
5. Software Acquisition Capability Maturity Model, 1999: Appendix B: Glossary of Terms
6. US Federal Acquisition Institute, 1998: "A Glossary of Acquisition Terms"
7. Although multiple contracting is increasingly common, this is largely a legal issue; to keep it simple, this article focuses on the processes related to a single contract
Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page