This article originally appeared in the January 2003 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 Published here July, 2003.

PART I | Recap | A Simplified Overview of Traditional Contracting
The Acquisition Process with RUP | A Progressive Acquisition Solution for Contracting
Two-Level Contracting | Progressive Acquisition and the RUP Lifecycle
The Contractual Perspective | Advantages for Both Parties | PART III

The Acquisition Process with RUP

Although the typical contract process we have just described works reasonably well in the construction arena as well as many others, practices in the software development world are different. First, few acquirers hire an architect to define the system before issuing a Request For Proposal (RFP). And they typically expect to negotiate a fixed price for the entire development project right at the outset. Unfortunately, as we noted in Part I, such practices and objectives run counter to best practices that lead to successful software development.

If the acquiring organization is a RUP user, it will have guidance for applying some of these best practices to the acquisition process. There are standard RUP processes for arriving at, capturing, and managing requirements. Artifacts in which requirements are embedded include Stakeholder Requests, the Vision document, the Software Architecture document, and use cases and supplementary specifications.

The acquirer would first analyze the market, decide upon the set of potential vendors to receive solicitations, establish the selection process and criteria, and decide which contract type to employ. Then, the acquirer would prepare a Request for Proposal (RFP) that articulates the organization's needs as clearly as possible, based on requirements contained in the artifacts we mentioned above. The RFP is typically a highly standardized document that contains much "boilerplate" language specific to the organization, and it is usually under the purchasing department's control. Before distribution, the draft RFP would be reviewed by the organization's legal department or service. It would then be distributed to potential vendors, and the acquiring organization would supply clarification if necessary.

The vendors would review the RFP and decide if they want to respond by creating a proposal that describes their approach and pricing options for meeting the requirements. The acquirer would then review the responses and select a particular supplier to work with, possibly through progressive eliminations or pilot implementations.

A Simplified Overview of Traditional Contracting  A Simplified Overview of Traditional Contracting

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