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
