The Vocabulary of Acquistion
One effective way to bridge communication gaps is to
establish a common vocabulary among all the players. Interpreting terminology
is often a problem within a business unit whose members are spread far apart,
but it can become a serious obstacle when you begin to mix people with totally
different business backgrounds. Not only do some terms mean different things to
different people, but also the same meaning may be expressed in entirely
different terms. Because I hope that both developers and managers - and both
acquirers and suppliers of software development resources - will read this
article, it is important to establish shared definitions for the following key
terms.
Acquisition - The process of obtaining a system,
software product, or software service through contract.[2] Also known as
procurement. Although not specifically stated in the ISO/IEC 12207 Standard,
the term refers to purchases made through legal contract. Sometimes acquisition
is applied in a narrower sense, to refer to buying an off-theshelf, or pre-existing,
system or software, with or without some degree of customization. While this is
not correct usage, Figure 1 shows "off the shelf software" at
the far end of the customization spectrum as an example of zero customization.
Acquirer - An organization that acquires or procures
a system, software, or software service from a supplier. The acquirer may also
be referred to as a purchaser, buyer, customer, or owner. The acquirer may or
may not also be the "user." Generally, users are a subgroup interested
primarily in the software's capability and ease of use, whereas the acquirer is
more concerned with cost and delivery schedule, given agreement on the
functionality.
Contract - A binding agreement between two parties,
especially enforceable by law, for the supply of software service or the
supply, development, production, operation, or maintenance of a software
product.[3]
This is a binding agreement that establishes the requirements for the products
and services to be acquired.[4]
The ISO/IEC 12207 Standard definition also suggests that a
contract may be "a similar agreement wholly within an organization."
Generally, no form of agreement is enforceable by law unless the parties are
operating "at arm's length" - in other words, they are entirely independent
of one another. However, large corporations may wish to establish internal
agreements similar to legal ones as a matter of operational policy, and the
extent to which they are enforceable by law depends on the relationship between
the parties. Note that contract law labels the parties to a contract as buyer
and seller.
Progressive Acquisition (PA) - A strategy to acquire
a large and complex system that is expected to change over its lifecycle. The
objective of PA is to minimize many of the risks for both parties associated
with the length and size of software projects. The final system is obtained by
upgrades of the system capability through a series of evolutionary, operational
increments.[5]
Subcontractor - A second and distinct party to which
a primary contractor passes some portion of work described in the contract.
This term is sometimes used incorrectly to describe the awarding of several
contracts by the acquiring organization.
Supplier - Any organization that supplies services
or goods to the customer.[6] Also known as a contractor, seller, subcontractor, or
vendor.
2. "Software Acquisition Capability Maturity Model," Appendix B:
Glossary of Terms. Software Engineering Institute, 1999
3. ISO/IEC 12207 International Standard, Section 3, "Definitions"
4. "Software Acquisition Capability Maturity Model," Op.Cit.
5. Giles Pitette, "Progressive Acquisition and the RUP: Comparing and
Combining Iterative Process for Acquisition and Software Development," The
Rational Edge, November 2001
6. "An Abridged Glossary of Project Management Terms" (Rev.4) in the Association of Project Management (UK) APMP Syllabus, second edition, 2000
|
What Does Contracting Involve?
