What Does Contracting Involve?
As we have noted, in a traditional acquisition process, the
legal terms of a contract drives the activity in a fairly rigid way. So
typically, a lot of energy goes into reaching agreement on the terms of the
contract. This presents another communication challenge, as contracts
themselves are very flexible. They can be devised to reflect any number of
variables, such as:
- The degree of definition for the thing to be delivered
(i.e., the scope).
- The type of product, whether tangible as in a good, or
intangible, as in a service or a product such as software.
- Safety and liability considerations for the product in
use.
- The urgency or specific timetable for product delivery.
- The price to be paid upon delivery of the product, as
well as financial incentives or penalties tied to specific benchmarks.
- The degree of control to be exercised by either party
to the contract.
- The degree of tolerable risk, internal and external,
and who should assume which risks.
Part III of this series, "Working with Traditional
Contracting Practices," will explore these variables in greater detail.
Modern contracts for software acquisition should reflect the
notion that initial plans for a software system are not monolithic and
ironclad. The RUP focuses on an iterative approach and delivery of value as the
most effective, efficient, and least risky means of developing software.
Similarly, the PA processes developed and articulated by European governments have
shown that iteratively acquiring and implementing system functionality is a
much more effective approach than purchasing a complete system all at once, as
in the "big-bang" model.
Software acquisition contracts should also recognize the
high degree of variability in software "products." In fact, the
actual software deliverable and its corresponding contract can fall anywhere
along a continuum of a number of semi-interdependent variables. Figure 1
displays three major variables that I will discuss, along with several others,
in a later article.
Figure 1: Major Variables Affecting Software Acquisition
Given the highly variable nature of these deliverables,
determining an appropriate form of compensation is a major factor in
formulating the contract -- and hence the relationship between the parties.
The Project Management Institute's PMBOKĻ Guide describes
the following traditional contract/compensation options.[7]
- Fixed Price (or lump-sum) contracts. This
category of contract involves a fixed total price for a well-defined product.
Fixed-price contracts may also include incentives for meeting or exceeding
selected project objectives, such as schedule targets.
- Cost-reimbursable contracts. This category of
contract involves payment (reimbursement) to the contractor for its actual
costs. Costs are usually classified as direct costs (costs incurred directly by
the project, such as wages for members of the project team) and indirect costs
(costs allocated to the project by the performing organization as a cost of
doing business, such as salaries for corporate executives). Indirect costs are
usually calculated as a percentage of direct costs. Cost reimbursable contracts
often include incentives for meeting or exceeding selected project objectives,
such as schedule targets or total cost.
- Time and material contracts. Time and material
contracts are a hybrid type of contractual arrangement that contains aspects of
both cost-reimbursable and fixed-price-type arrangements. Time and material
contracts resemble cost-type arrangements in that they are open ended, because
the full value of the arrangement is not defined at the time of award. Thus,
time and material contracts can grow in contract value as if they were cost-
reimbursable type arrangements. Conversely, time and material arrangements can
also resemble fixed-unit arrangements when, for example, the units rates are
preset by the buyer and seller, as when both parties agree on the rates for the
category of "senior engineers."
The supporting text in the PMBOK Guide also describes six
major procurement management processes: Project Procurement Management,
Procurement Planning, Solicitation Planning, Solicitation, Source Selection,
Contract Administration, and Contract Closeout.
However, these classifications are too limited; they reflect
a traditional procurement paradigm, not a progressive acquisition approach. The
challenge for RUP users is to devise a new approach that speaks to all players
in terms they can understand, while at the same time remaining consistent with
the RUP philosophy and methodology.
Next month, in Part II of this series, we will take a look
at an actual acquisition process and discuss how to make it work in a way that
is compatible with RUP recommendations for software development.
7. A Guide to the Project Management Body of Knowledge, 2000 edition. Project
Management Institute (USA)
|
Keeping It Simple
