3 Part 3: V-Modell Reference Tailoring
3.5 Project Type Variants
3.5.1 Project (Acquirer) with One Supplier
|
Extended project type: |
Descriptions
As already described in Part1: "»Fundamentals of the V-Modell", the V-Modell provides specific project type variants, which are adapted to different »Project Types. The project type variant »Project (Acquirer) with One Supplier describes the appropriate procedure for the project type »System Development Project (Acquirer).
The award and execution of system development projects is based on the fundamental idea that the Acquirer has recognized the necessitiy for a system development project, but does not want to develop the project himself. Thus, he must specify the Requirements for the system. The development of the system (or of individual configuration levels of a system) will be carried out by a Supplier. After completing a Request for Proposal procedure, the supplies and services to be provided will be specified in a »Contract between the Acquirer and the Supplier. The supplies and services provided by the Supplier will be subject to acceptance by the Acquirer.
The project type variant »Project (Acquirer) with One Supplier should always be employed if a project is intended to have a Supplier develop a system.
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)
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 13: Project type variant Project (Acquirer) with One Supplier
The decision gates and the sequence of the project type variant »Project (Acquirer) with One Supplier are shown in figure Figure 13. In the following, the award and execution of the project 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 'Requirements Specified'
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 '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.