3 Part 3: V-Modell Reference Tailoring
3.5 Project Type Variants
3.5.2 Project (Acquirer) with Several Suppliers
|
Extended project type: |
Descriptions
As already described in Part 1: "»Fundamentals of the V-Modell", the V-Model provides specific project type variants, which are adapted to the different »Project Types. The project type variant »Project (Acquirer) with Several Suppliers describes the appropriate procedure for the project type »System Development Project (Acquirer).
The project type variant »Project (Acquirer) with Several Suppliers is based on the fundamental idea that the Acquirer has recognized the requirement for a system development project, but does not want tor develop the project himself/herself and that the realization in several Sub-Projects will probably offer technical, organizational and economic advantages. It is thus necessary to specify the Requirements of the overall system. In addition, it must be possible to reasonably subdivide the Requirements into Sub-Projects based on the overall system architecture. In this context, a Sub-Project must always be defined in such a way that the integration includes the results of the other Sub-Projects. The development of the system (or of individual configuration levels of a system) will be carried out in several Sub-Projects by one or several Suppliers.
However, this project type is only useful if the effort required for integrating the results of the individual Sub-Projects does not exceed the above-mentioned advantages of a development in Sub-Projects.
After completion of a Request for Proposals procedure, the supplies and serviced to be provided in the Sub-Projects will be specified in contracts to be defined between Acquirer and Suppliers. The supplies and services provided by the Suppliers in the Sub-Projects will be subject to acceptance by the Acquirer.
The project type variant »Project (Acquirer) with Several Suppliers should always be employed if a project is intended to have one or several Suppliers develop a system in several Sub-Projectsl.
Process Modules to be used
Due to the project type: Specification of Requirements, Configuration Management, Delivery and Acceptance (Acquirer), Problem and Change Management, Project Management, Quality Assurance, Drafting and Conclusion of Contract (Acquirer)
Due to the project type variant: Management of Multiple Projects
Project characteristics to be determined during tailoring
Due to the project type: Security (Acquirer), Life Cycle Cost Management, Project Measures, Off-the-Shelf Products
Activity Flow
Figure 14: Project type variant Project (Acquirer) with Several Suppliers
The decision gates and the sequence of the project type variant »Project (Acquirer) with Several Suppliers are shown in figure Figure 14. In the following, the sequence will be described by means of the decision gates carried out.
Possible transitions based on 'Projektstart'
From 'Project beginning' to 'Project Approved'
The potential acquirer, operating under the custodianship of a sponsor, prepares a »Project Proposal which includes all information required for deciding on the implementation of the proposal in form of a project. A sponsor is defined as person or department providing a budget for project acquisition. The project proposal is discussed in the decision gate »Project Approved, which ends with the decision as to whether or not the project should be started.
Possible transitions based on 'Project Approved'
From 'Project Approved' to 'Project Defined'
In case of a positive decision, a Project Manual and a QA Manual will be prepared, which will be examined in order to determine if they are suitable for project execution on side of the acquirer. These activities are intended to reach the decision gate »Project Defined.
Possible transitions based on 'Project Defined'
From 'Project Defined' to 'Overall Project Partitioned'
If the overall project is defined in one Project Manual and QA Manual, the product »Requirements Specification Overall Project should include an »Outline of the Life Cycle and the Overall System Architecture, which permits a subdivision of the overall project into feasible sub-projects. If this subidivision is technically, organizationally and economically feasible, the specification of the sub-projects and the sub-project Integration will be incorporated into Project Manual and »Project Plan. A sub-project Integration, which includes the integration of the sub-projects' results, must always be defined. The functional-and non-functional requirements specified in the Requirements Specification Overall Project will be assigned to the sub-projects. These activities are intended to reach the decision gate »Overall Project Partitioned.
Possible transitions based on 'Overall Project Partitioned'
From 'Overall Project Partitioned' to 'Overall Project Progress Revised'
If the overall project is subdivided into sub-projects, the »Overall Project Progress shall be controlled based on the »Project Status Report(Supplier) prepared at the decision gate Overall »Project Progress Revised. The acquirer will integrated these sub-project data into a Project Status Report Overall Project. These activities are intended to reach the decision gate »Overall Project Progress Revised.
From 'Overall Project Partitioned' to 'Requirements Specified'
Based on all Project Status Reports (Supplier) of the individual sub-projects, a »Coming to a Project Progress Decision shall be made as to whether the overall project is still within the planning data specified in the Project Plan and as to whether and how the project shall be continued.
After project definition, the user requirements will be prepared and subjected to a »Requirements Evaluation. The user will examine the requirements for completeness and correctness. In case of a positive assessment, the acquirer specifies and prioritizes the requirements in form of the »Requirements Specification. In addition, an »RFP Concept will be prepared in order to ensure that the contract award law will be observed during the request for proposal. These activities are intended to reach the decision gate »Requirements Specified.
Possible transitions based on 'Overall Project Progress Revised'
From 'Overall Project Progress Revised' to 'Overall Project Progress Revised'
Based on all Project Status Reports (Supplier) of the individual sub-projects, a »Coming to a Project Progress Decision shall be made as to whether the overall project is still within the planning data specified in the Project Plan and as to whether and how the project shall be continued.
From 'Overall Project Progress Revised' to 'Overall Project Partitioned'
If the acceptance of all sub-projects and the results of the decision gate »Overall Project Progress Revised show that the objectives of the overall project cannot be not fulfilled, the overall project shall be subdivided into new sub-projects. However, this decision must stand the most stringent economical tests.
Possible transitions based on 'Requirements Specified'
From 'Requirements Specified' to 'Request for Proposal Released'
Based on the specification of requirements, the »Request for Proposal will be prepared. For this purpose, the RFP documents will be prepared based on the »RFP Concept specified in the decision gate »Requirements Specified, and a »Criteria Catalog for Assessment of Offers will be developed. Afterwards, it will be examined if the request for proposal can be released. In case of a positive decision, the request for proposal will be published in accordance with the procedures specified in the RFP concept. These activities are intended to reach the decision gate »Request for Proposal Released.
Possible transitions based on 'Request for Proposal Released'
From 'Request for Proposal Released' to 'Contract Awarded'
The »Offers received after the »Request for Proposal will be evaluated in accordance with the »Criteria Catalog for Assessment of Offers. A provider with whom negotiations will be conducted will be selected. The acquirer decides - based on the assessment of the offers and the result of the contract negotiations - if the offer of the selected provider should be accepted. In case of a positive decision, a »Contract will be concluded between acquirer and supplier. In case of public acquirers and suppliers, contract negotiations are only possible under strict conditions. The public acquirer employs the »Offer Assessment in order to decide which offer is the most economical offer. The contract award commits the supplier to execute the project for the acquirer in accordance with the contractual agreements. These activities are intended to reach the decision gate »Contract Awarded.
Possible transitions based on 'Contract Awarded'
From 'Contract Awarded' to 'Iteration Scheduled'
After a »Contract has been concluded, the system development process, i.e., the decision gates to be achieved and the extent of the requirements to be implemented, will be planned. In addition, it will be examined if the products »Project Manual and »QA Manual still correctly reflect the project. Otherwise these products will be adapted. These activities are intended to reach the decision gate »Iteration Scheduled.
Possible transitions based on 'Iteration Scheduled'
From 'Iteration Scheduled' to 'Project Progress Revised'
Then the acquirer is then tasked with supporting the execution of the supplier's project at the current »Project Stage in accordance with the specifications made in the contract. This is intended to ensure the success of the project and is a decisive acquirer task in this project execution strategy. The supplier will submit a Project Status Report (Supplier) for controlling the project progress. This report will determine which results have been achieved at the agreed project milestones. For this purpose, the acquirer will prepare a Project Status Report of his/her own. These activities are intended to reach the decision gate »Project Progress Revised.
Possible transitions based on 'Project Progress Revised'
From 'Project Progress Revised' to 'Project Progress Revised'
The supplier will submit the Project Status Report to the acquirer at regular intervals, which may be adapted to the sequence of the supplier's Project Progress Decisions. At these points, the acquirer will also prepare a Project Status Report. These activities are intended to reach the decision gate »Project Progress Revised.
From 'Project Progress Revised' to 'Acceptance Completed'
If the supplier has achieved a specified system development status, the acquirer will receive the contractually agreed deliveries. The acquirer examines whether the »Delivery (Supplier) meets the requirements. This leads to the project progress decision of the decision gate »Acceptance Completed.
Possible transitions based on 'Acceptance Completed'
From 'Acceptance Completed' to 'Iteration Scheduled'
In order to plan a new iteration after the acceptance, the acquirer will check the open change requests of the »Change Status List in cooperation with the supplier. At the decision gate »Iteration Scheduled, this list is used for deciding which change requests will be included into the new iteration and which will be postponed for the time being. In addition, it will be specified, which of the components that have not yet been implemented will be taken into account in the new iteration. The change requests and the open requirements are the basis for a new development cycle. Again, it will be examined if the products »Project Manual and »QA Manual still correctly reflect the project. These activities are intended to reach the decision gate »Iteration Scheduled.
From 'Acceptance Completed' to 'Contract Awarded'
If acquirer and supplier have determined previously that one or a few iterations will first be implemented before the overall scope is fixed contractually, a new »Contract will possibly be concluded after the acceptance has been completed. If necessary, a »Contract Addendum will be agreed with the supplier. These activities are intended to reach the decision gate »Contract Awarded.
From 'Acceptance Completed' to 'Requirements Specified'
If the experiences gained show that the requirements must be modified and the modifications cannot be made within the scope of the contract, a new »Requirements Evaluation will be conducted and new requirements will be specified. These activities are intended to achieve the decision gate »Requirements Specified and to award a new contract to a supplier.
After project definition, the user requirements will be prepared and subjected to a »Requirements Evaluation. The user will examine the requirements for completeness and correctness. In case of a positive assessment, the acquirer specifies and prioritizes the requirements in form of the »Requirements Specification. In addition, an »RFP Concept will be prepared in order to ensure that the contract award law will be observed during the request for proposal. These activities are intended to reach the decision gate »Requirements Specified.
From 'Acceptance Completed' to 'Overall Project Partitioned'
If the acceptance of all sub-projects and the results of the decision gate »Overall Project Progress Revised show that the objectives of the overall project cannot be not fulfilled, the overall project shall be subdivided into new sub-projects. However, this decision must stand the most stringent economical tests.