Recap
In Part I of this series, we identified the gap between the expectations
of traditional procurement specialists and the realistic needs of the software development community
and introduced a new "progressive acquisition" approach that can help bridge this gap.
Part II provided a high-level description of how to modify the
traditional contracting process to fit a progressive acquisition model that meets the needs
of both acquirers and suppliers in a simplified scenario. We walked through the process of obtaining
a system, software product, or software service,[1] through
legal contract[2] from an independent supplier.
In Part III we began looking at what actually goes into a contract,
examining basic elements required for an effective contract and hurdles that tend to get in
the way of constructing such a contract. We also looked at specific content required for the
contracting approach we suggested in Part II, and the reasons most companies
use a centralized acquisitions approach. Now, in Part IV, we will
describe the variables that govern contract formulation[3]
and then discuss how to choose the best form and type of contract to accommodate particular
contract conditions.
1. ISO/IEC 12207 International Standard, Section 3: Definitions.
2. Software Acquisition Capability Maturity Model, 1999: Appendix B: Glossary of Terms.
3. NOTE: This article is not intended to offer definitive legal recommendations and advice, since these vary from country to country and jurisdiction to jurisdiction. In practice, all contract wording, whether "boiler plate" or specific to a contract, should be reviewed by competent acquisition personnel or legal advisors. For a detailed discussion of contract law refer to appropriate legal texts on the subject that are relevant to the governing jurisdiction.
|
Part
III 
