This article originally appeared in the December 2002 issue of The Rational Edge E-zine on-line magazine, copyright 2002-2003 IBM and Max Wideman.

The Rational Unified Process (RUP) is a rigorous software development process advocated by the Rational Software Corporation.

The downloadable PDF file of the paper on this site is the one prepared by the Rational Edge editorial staff with the special assistance of Ms Marlene Ellin.

Published here June, 2003.

Introduction | Problems with the Traditional Acquisition Process | Keeping It Simple
What Does Contracting Involve? | The Vocabulary of Acquistion | PART II

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  Problems with the Traditional Acquisition Process

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page