Two-Level Contracting
As we observed in Part I, contracts are very flexible, and this is especially true for software development projects. So a contract agreement really should consist of two levels:
- A "Head Contract" that sets out terms and conditions for an anticipated long-term relationship.
- A system of "Contract Work Orders" (CWOs) that progressively enable the work.
The Head Contract should include most of the required standard boilerplate: administrative and technical provisions such as hourly or unit rates, change management procedures, payment cycles, testing processes, and so on. If the acquiring organization has done its homework, this part can also include a target budget figure based on reasonably accurate conceptual-level estimates. This document spells out a broad framework for an ongoing relationship; it provides the acquirer with the necessary financial control and the supplier with a reasonable expectation on which to base its competitive pricing.
The second level of the contract defines specific deliverables associated with a shorter period of time, and the actual technical work is released as a sequence of CWOs. These CWOs are prepared and awarded to the supplier for each stage of the work, based on the latest information and/or development of the solution, and as a result of technical negotiations between the parties. The initial set of deliverables will be recorded in the first CWO. The earliest CWO or CWOS will be cost reimbursable, just like the architect in our public building example. Then, as successive elements of work are accomplished, the requirements should become sufficiently firm, at least for the next iteration, that a firm price can be agreed upon for the next CWO.
Acquirers who need more convincing about the wisdom of this approach should consider Murray Cantor's observation:[1]
"Computer science shows there is no way to get precise answers to many questions you might want to ask. There is no rigorous formula for determining the size of the code required to carry out a given task. There is no practical way to prove whether a piece of code is correct, that is, whether it does what it is supposed to do, or even whether the code will stop in a finite length of time. Although there are useful methods for estimating the effort required to develop code, the formulas are based on imprecise parameters and human judgment. Finally, there is no widely accepted formula for code quality, only indicators."
As the contract proceeds, the supplier delivers, the acquirer validates delivery, and both sides perform a variety of administrative functions, including change management and payment.
As the conditions related to the first CWO are met, the parties negotiate deliverables for the next phase and record the agreement in another CWO. If the documentation for the next iteration is extensive and/or subject to further negotiation, it may be preferable for the acquirer to initiate the process by issuing a Contemplated Contract Work Order. This represents best practice for delivering value iteratively. This cycle is then repeated under the conditions of the Head Contract until the entire acquisition is complete.
Once the objectives of the full acquisition project have been met, both parties move into final acceptance and closure activities, including final payments and archiving.
1. Murray Cantor, Software Leadership: A Guide to Successful Software Development. Addison-Wesley, 2002, p.170.
|
A Progressive Acquisition Solution for Contracting
