Keeping It Simple
A modern, progressive acquisition process can help bridge
these communication gaps. As I mentioned earlier, the purpose of this series of
articles is to suggest basic tenets of progressive acquisition that integrate
with the software engineering methods and lifecycles of the Rational Unified
Process. Of course, neither suppliers nor acquirers are likely to take to these
suggestions seriously at first, because they run counter to current practices.
But if you keep on doing what you've been doing all along, then you'll keep
getting the same kind of suboptimal results.
In laying out these tenets of progressive acquisition in
future articles, we will assume an uncomplicated scenario that meets the
following conditions:
- The system is "complex"; in other words, it
can be developed progressively and begin delivering value early on.
- Only one supplier is involved in delivering the
complete system.
- Both the acquirer and the software system supplier are
using the RUP.
- The main issue is how best to set up a contract that
meets the needs of both parties.
Yes, I know, there will be a howl from those who must deal
with multiple suppliers. That certainly adds risk and complexity, and it is
frequently a source of conflict and grief. However, from a project management
perspective, what that boils down to is simply assigning responsibility for
coordinating, integrating, and configuring the various parts of the system in a
legal and competent way.
In this first article, we'll define common terms and
concepts that enable better communication for all parties involved in
acquisition. Then, future articles will go on to define an effective core
process for acquisition as well as likely deviations from it. My hope is that
this series will help organizations to integrate their software development and
acquisition processes more effectively -- and also help suppliers who market to
software organizations.
|
Problems with the Traditional Acquisition Process
