Who Bids on the Second Phase?
On some government projects, contractors who win and perform work on the first phase are not permitted to bid on the second phase. This is done so that the contractors bidding on the second phase all start from the same knowledge base. But if the right artifacts are built during the first phase and are made available to potential bidders for the second phase, this negates most of the competitive disadvantage. I believe contractors who perform the first phase well should be permitted to bid on the second phase. This gives them additional incentive to perform. If you allow this, you must also consider what to do if the bid from the first-phase contractor is significantly different (higher or lower) from those of the other bidders. Does that contractor know about risks in the artifacts that are not available to the other contractors? Does that contractor possess knowledge of risks that is unavailable to the other bidders? Be prepared to consider these scenarios.
What Artifacts Should Be Produced and Made Available During the First Phase?
This section identifies and discusses the artifacts that should be produced during the system spec-ification contract. These artifacts should be made available to contractors bidding on the system realization contract.
Every project brings a plethora of terms and phrases. A project glossary defining these terms should be produced and made available to bidders for the system realization phase. This will greatly aid contractors in the frenzy of activity that occurs during the proposal generation process.
The Vision Statement (sometimes called a Concept of Operations [CONOPS]) is vital. It should be written from the perspective of the project stakeholders. The reason for supplying this with the RFP for the second phase is to quickly communicate the project's motivation to prospective bidders. This helps set the context for the project. The vision statement is discussed further in Chapter 7, "Inception: Kicking Off the Project."
Software Architecture Document
The Software Architecture Document is another vital set of information. It describes the architectural decisions that were made during the Elaboration phase. It should also describe how the architecture meets the system's supplementary requirements covering response time, throughput, reliability, scalability, and so on. This helps the bidders understand the system's complexities.
Set of Business and System Use Cases
This information helps the bidders understand the complexity of interactions (as well as the number of interactions) actors can have with the system. The actors should be clearly identified, especially those who have an interface to other (external) systems. If possible, an estimation of the completeness of the use cases should be given. (Usually requirements are not 100% complete by the end of the Elaboration phase.)
Models illustrating the system's analysis and design should be provided.
Set of Supplementary Requirements
The supplementary requirements describe the nonfunctional requirements to which the system must conform. Supplementary requirements describe areas such as scalability, reliability, response time, and the number of users the system must support. These requirements can be significant cost drivers. Usually, the supplementary requirements are 100% complete by the end of the Elaboration phase. If they aren't, an estimate of their completeness should be given.
Executables Produced by Iterations
Since the Elaboration phase produces some early releases of the system, potential bidders should be given these releases. Accompanying these releases should be the list of requirements that the releases satisfy, and a list of risks that the iteration was designed to address. The source code should be provided or be available for inspection. Build instructions to perform a build of the releases should be included.
List of Risks and Risk History
An important aspect of the Elaboration phase is to directly address project risks. A risk history, containing risks identified in the Inception and Elaboration phases, should be provided. The history should include which risks have been successfully retired and how they were retired. If risks remain, they should be identified, and a suggested course of action to address the risk provided.
The contractor supporting the system specification phase will have other information that can assist those bidding on the second phase. For example, what software tools will be used to build the executable releases? The tools (and their version numbers) should be identified. Also, the contractor may have a sense of the size of team that will be needed to develop the system in the customer's time frame. If possible, the initial contractor should be made available for a period of time (perhaps 2 months) for questions after the second phase is awarded to the new contractor.