Problems with the Traditional Acquisition Process
From a RUP perspective, the business of acquisition by
contract (i.e., "contracting") introduces a whole new process unto
itself, complete with roles and artifacts. This can be problematic for a
typical software development organization because the traditional acquisition
process is contract driven; and the specialists who direct it focus on
activities, practices, and objectives that run counter to the best interests of
successful software development.
What happens in a traditional acquisition process? Simply
put, you figure out what you want, describe it in a Request for Proposal,
solicit bids, pick a competent vendor with the lowest price and fastest
delivery, enter into a standard legal contract, wait for the work to be
finished, and come back when you can "pick up the keys to the front
door." Unfortunately, as often as not, when you walk through that front
door, the entrance hall is not what you expected, and it might lead directly to
the back door!
Until recently, this was the process European countries[1] used to
acquire large Defense Information Systems (DISs), and, as Pitette notes:
"... there are many sad stories to tell about large DIS projects
procured under classic, strictly sequential, "big-bang" model (also
termed "grand-design" or "one-shot") -- stories about late
deliveries, cost overruns, and failures to meet users' real needs. The problems
stem from the big bang's inherent inability to deal with a few stark
realities."
These "realities" include the following:
- You can't express all your needs up front. It is
usually not feasible to define in detail (that is, before starting full-scale
development) the operational capabilities and functional characteristics of the
entire system.
- Technology changes over time. Acquisition
lifecycles for very large systems (such as DISs) span a long period of time,
during which significant technology shifts may occur.
- Large systems are also complex systems. This
means it is difficult to cope with them adequately unless you have an approach
for mastering complexity.
Actually, based on my experience in software development,
the system does not have to be all that large, or the acquisition lifecycle all
that long, to suffer from exactly the same difficulties. In fact, Pitette might
have added:
- The acquiring authority often fails to stay involved
with the ongoing delivery of work. Typically, this is because fixed pricing
discourages them from doing so. Conversely, some purchasers breach their
contracts by "interfering" too much.
- The acquiring authority is not prepared for the
unwieldy changes that typify software projects.
- The authority may fall short in managing and
coordinating large, parallel acquisition efforts involving multiple
hardware/software suppliers.
Despite all of these shortcomings, the big-bang contract
model remains very popular with executive and senior managers on the
acquisition side. Why? Because they have a responsibility to maintain the financial
viability of their organization. This applies whether the enterprise is
government, private sector, or even non-profit. In assessing the needs of their
organization, and in prioritizing opportunities (even if some system upgrades
are mandated by legislation), managers must know "how much" in order
to budget, estimate return on investment, and select among competing needs. And
for commercial organizations, the question of "how soon" is usually
more important than for those in the public sector.
Unfortunately, senior managers often have little
understanding of how software development is best conducted, and (I hesitate to
suggest), software developers often have little understanding of senior
management's needs. So, there is potential for a serious communication gap
between these two groups within the acquiring organization ö and often between
managers in the acquiring organization and developers on the supply side as
well.
1. ISO/IEC 12207 International Standard, Section 3: "Definitions"
|
Introduction
