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
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]
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
|
Elements of a Valid Contract 
