Project Management with the IBM Rational Unified Process: Lessons From The Trenches

The Rational Unified Process incorporates iterative development as the core of the process. Why? As discussed in Chapter 2, "Overview of the Rational Unified Process," you can best solve a large problem by breaking it into smaller, more easily understood parts. As you learn more through the execution of iterations, risks are resolved early, and the subsequent iterations can be adjusted. Why not apply these ideas to the procurement process?

A Proposed Progressive Acquisition Model for Small Projects

For small projects, the question is how to implement an iterative, progressive model without so much procurement-related overhead that the Return on Investment (ROI) becomes poor.

A two-phase acquisition process solves this problem. The first RFP, referred to as a System Specification Contract, is issued strictly for the project's Inception and Elaboration phases. The second RFP, called the System Realization Contract, covers the project's Construction and Transition phases, as shown in Figure 3-1. Note that the RFP for the System Realization Contract can be prepared before the completion of the Elaboration phase to minimize delays in the project.

The key to this model is the tremendous amount of information that is learned during a project's Inception and Elaboration phases. Yet, the bulk of the cost to implement a project occurs in Construction and Transition. Splitting the project into two separate procurements has the following advantages:

• The project team can conduct the requirements elicitation by interacting directly with the stakeholders.

• You can estimate the portions of the project that use the most time and resources from useful artifacts produced during Inception and Elaboration.

• The project estimation is performed outside of a competitively charged environment.

• The project estimation can be accomplished over a reasonable period of time, instead of during the hectic period during a proposal.

• The contractor is motivated to produce high-quality artifacts, because it can potentially win the System Realization Contract if it performs well.

• The outsourcing organization has more flexibility. It can retain the existing contractor or hire a different one for the System Realization Contract.

• If the size, schedule, and budget needed for the System Realization Contract are much larger than the outsourcing organization anticipated, the subsequent RFP for the System Realization Contract can be canceled, rescoped, or modified before the majority of the overall project schedule and funding are consumed.

Outsourcing organizations should be aware of some issues with this model:

• Careful planning is needed to avoid delays between the System Specification and System Realization portions of the contract. The deliverables produced in the System Specification portion of the project that are needed for the System Realization Contract must be completed, at least in draft form, early enough so that the RFP for System Realization can be produced.

• If the outsourcing organization decides to award the System Realization Contract to a contractor different from the one performing the System Specification portion of the contract, a significant amount of "ramp-up" time is needed. The new contractor needs time to review the deliverables and understand the project's business processes.

Several examples of projects that have used this model exist. On August 29, 2003, the Department of Commerce, National Oceanic and Atmospheric Administration (NOAA) awarded a contract for a project known as Grants Online. The purpose of the NOAA Grants Online project is to provide a fast, coherent, flexible, and robust application to support the Grants evaluation, award, and long-term management and operations process. Grants Online will deliver a standardized set of capabilities for viewing, retrieving, modifying, and deleting application- and award-related information, including (but not limited to) applications, awards, amendments, audits, proposal scoring and commentary, budget and finance information, and technical and panel reviewer information.

This award was for the equivalent of the System Specification portion of the project. The contractor for the System Specification portion of the contract produced the following deliverables:

• A complete set of business and system use cases

• An architecture road map, which provided an overview of the key architectural attributes and decisions that would be made to develop the system

• An initial draft of the project's Configuration Management Plan

• A Development Case, illustrating which artifacts should be created and developed from the Rational Unified Process

• A draft of the Requirements Management Plan

• A Reference Architecture document, containing a proposed reference architecture for the Grants Online system

• A Unified Modeling Language (UML) model

• A list of key project risks with suggested mitigation steps

• A Supplementary Requirements Specification

• A Vision document explaining why the system is needed, who the stakeholders are, the environment, and other key information

It is far easier to produce a proposal (with realistic schedule and budget estimates) with this accompanying information. Accordingly, RFPs with this accompanying information are more likely to receive accurate bids, and they have a better chance of concluding successfully.

Organizations that are considering implementing a two-stage acquisition model (with one contract for Inception/Elaboration and another for Construction/Transition) should consult Appendix B, "Implementing a Two-Stage Procurement Process." It discusses the artifacts that should be produced by the system specification contract and included in the RFP for the System Realization Contract.

A Progressive Acquisition Model for Medium to Large Projects

For larger, long-term projects, the two-phase acquisition model described in the preceding section is too simplistic. Although it's better than a single, one-shot award for an entire project, it is still insufficient. Large, long-term projects have these additional challenges:

• The project's long-term nature means that the technologies available at the beginning of the project are likely to change during the project.

• The organization's business processes may change during the project.

• The stakeholders themselves are likely to change. New stakeholders may not agree with the needs of previous stakeholders or with the project's current direction.

• Larger projects involve more people and often multiple contractors. The lines of communication, therefore, are much more complex and take considerably longer to traverse.

The end result is that multiple adjustments may need to be made throughout the project.

In a series of articles written for The Rational Edge e-zine, R. Max Wideman defines a progressive acquisition solution for contracting that addresses these issues. In one of these articles, he states, "a contract agreement should consist of two levels":

• A Head Contract that sets out terms and conditions for an anticipated long-term relationship.

• A system of Contract Work Orders (CWOs) that progressively enable the work.^[1]

  ^[1] From "Progressive Acquisition and the RUP, Part II: Contracts that Work," copyright R. Max Wideman and IBM Corporation 20022003. All rights reserved. Used with permission.

More specifically, in the article "Progressive Acquisition and the RUP, Part II: Contracts that Work," published in the January 2003 issue of The Rational Edge, Wideman says the following:

The Head contract should include most of the required standard boilerplate: administrative and technical provisions such as hourly or unit rates, change management procedures, payment cycles, testing processes, and so on. If the acquiring organization has done its homework, this part can also include a target budget figure based on reasonably accurate conceptual-level estimates. This document spells out a broad framework for an ongoing relationship; it provides the acquirer with the necessary financial control and the supplier with a reasonable expectation on which to base its competitive pricing.

The second level of the contract defines specific deliverables associated with a shorter period of time, and the actual technical work is released as a sequence of CWOs. These CWOs are prepared and awarded to the supplier for each stage of work, based on the latest information and development of the solution, and as a result of technical negotiations between the parties. The initial set of deliverables will be recorded in the first CWO. The earliest CWO or CWOs will be cost reimbursable . . . then, as successive elements of work are accomplished, the requirements should become sufficiently firm, at least for the next iteration that a firm price can be agreed upon for the next CWO.^[2]

^[2] Ibid

Figure 3-2 illustrates this process.

As Wideman states:

Note that a first small contract might be issued to help define the first deliverypart of the Elaboration Phase for the first increment... The second CWO would cover completion of the Delivery 1 and include the technical discussion necessary for setting up Delivery 2in other words, the Inception Phase of the second increment. Depending on the confidence level of the parties regarding the extent or effort required for this second CWO, the payment arrangement could be either cost reimbursable or fixed price.

By the time we get to Delivery 2 (i.e., the third CWO), both the relationship between the parties and their understanding of the work should be solid enough to let them arrive at a satisfactory fixed price for the scope of work in this CWO. Specifications should include not only the amount, but also a payment schedule and end date. The acquirer should avoid imposing unreasonable time constraints so that the work can be done properly.^[3]

^[3] Ibid

The pattern repeats until the final CWO is reached and the full functionality of the product becomes available. Figure 3-2 shows eight CWOs. Although there is no specific recommendation for the number of CWOs that are needed for a long-term project, Figure 3-2 represents a project that might take several years to accomplish.

This model provides many advantages over traditional procurement models. But the outsourcing organization must be closely involved when using such a model. In particular, the following are true:

• The progressive model is more than a simple series of mini-contracts. For it to work, deliverables and goals must be clearly defined in the beginning of each CWO. Government contract professionals may notice that this model appears similar to an Indefinite Delivery, Indefinite Quantity (IDIQ) model. In fact, there are some similarities, but there are important differences as well. The key difference is that the progressive model is a series of steps in the lifecycle of a single project. Each step is based on what was accomplished in the previous step, similar to the iterative development model. A careful evaluation is conducted near the end of one step before the RFP is developed for the next step.

• Near the end of a CWO, its deliverables are examined and its goals are evaluated to determine the proper goals for the next CWO. This requires periodic involvement from the contracting professionals in the outsourcing organization, as well as the project stakeholders.

• The outsourcing organization must pay especially close attention to the results of the first two or three CWOs. If the work in the first CWO is not advancing significantly toward the project's final goals, work should be stopped and the situation evaluated to determine whether the project can continue or if it needs to be rethought.

Advantages of the Progressive Acquisition Model for Larger Contracts

A progressive acquisition model solves many problems inherent in the traditional "single RFP" model. In particular, the following are true:

• The estimates for the subsequent phases of the project can be adjusted as more information is learned during the earlier phases. The estimates have the potential to be much more accurate because they are based on useful information obtained through actual hands-on experience with the project.

• As the needs (requirements) change over time, through either changes in the business process or changes in technology, the contracts for the subsequent phases can be adjusted accordingly.

• Contractors have a strong incentive to perform well and maintain good relations with the outsourcing organization. This ensures that they will be invited to bid on subsequent phases of the project.

• The next contract is not established until performance on the current phase has been determined to be successful.

• If performance at the conclusion of a phase is unsuccessful, the situation can be analyzed to determine the cause of the failure and correct it before subsequent time and resources are spent.

If these advantages sound strangely familiar, it is because many of them are very similar to those of iterative development. The underlying principle of the progressive procurement model is identical to that of iterative development: Attack risky areas first, apply lessons learned to subsequent iterations, and establish and enforce entry and exit criteria for each phase.

Potential Weaknesses of the Progressive Acquisition Model

Any process for procuring large, complex systems has risks, even the progressive acquisition model. These risks can be managed, but the results can still be disastrous through lack of attention.

• Continuity is lost if contractors are changed between phases. Presumably, this should not happen unless there is a serious issue with the contractor's performance.

• The progressive acquisition model requires strict monitoring of the project's success, particularly at the end of each phase. This cannot be a "rubber stamp" process. It requires the stakeholders to carefully examine the artifacts and released product at the end of the phase. Planning on the subsequent phases is then based on these artifacts. Without this involvement, many of the advantages of the progressive model are lost.

• The progressive acquisition model requires a significantly higher level of involvement from the outsourcing organization. This is also true of the contracts organization, which may be unaccustomed to multiple RFPs and contracts for a single project.