Specifying the Work
In general contracting practice, the information that defines or specifies the work of the contract can take one of several forms:
- Functional Specification
- Performance Specification
- Technical Specification
- Some combination of all three types of specifications -- provided that the instructions are not in conflict.
Please note that we are using these terms as they are used in the contracting industry; the terms functional, performance, and technical have a different meaning within the context of the Rational Unified Process. To avoid confusion, and to understand the general application of these three terms, here is a brief explanation of each.
Functional Specification. This is a document that describes how users will employ
the product and the functional capabilities it must have. It stimulates suppliers to propose
creative responses, possibly at lower cost. The supplier has the risk of performance, but as
an acquirer, you may find it difficult to establish or enforce acceptance criteria.
Performance Specification. This document specifies measurable capabilities the product must achieve in terms of operation (sometimes referred to as "form, fit, and function"). As an acquirer, you can spell out acceptance criteria as objective tests the product must satisfy; otherwise you will reject the product. The supplier carries the risk of performance.
Technical Specification. This document describes in detail the elements and commercial products contained within the final product for delivery -- in other words, the programming language, platform, configuration or architecture, methodology if applicable, and so forth. It should include charts, diagrams, and tables that specify how to construct the product and prescribe the tests and observations that you, as the acquirer, intend to conduct to verify or ensure compliance. In this case, you -- as the acquirer -- take the risk of performance. However, if you demand a fixed price contract, then the supplier assumes the cost risk.
On the face of it, this may seem like a winning solution and, indeed, in the absence of contrary instructions it is the type most often chosen by procurement departments. Unfortunately, in the real world of software development, it is practically impossible to develop technical specifications with sufficient accuracy to enable a controversy-free basis for a fixed price contract. This is true even if you assume that the acquirers know exactly what they want, are technically knowledgeable, and are proficient in the RUP. For this reason, fixed-price contracts are also the type that lead most often to serious disagreements, unsettled claims, expensive legal actions -- and less
than successful projects!
|
Progressive
Acquisition Workflow
