V-Model

Developed by Gaëtan Garnotel

The V-Model is a project management method for project planning and execution. It comes from the “Waterfall methods” and has begun to be widely used in the eighties. Nowadays, the method is still widely used in industries that launch complex, long and costly projects, such as the Defense industry, the Construction and Transport industry, or the Software industry. The process is divided into three main phases: the development phase when the system and components requirements are expressed and the system design is specified; the implementation phase when the simplest part of the system are built; and the test phase when all the parts are put together step by step so they form the complete system at the end. Moreover, the management methods related to the V-cycle offers project managers the opportunity to monitor and minimize the risks efficiently, to manager their costs effectively, to ensure a high-quality system, and to create a good relationship with all the project’s stakeholders through a documented and clear collaboration. The standardization and transparency of the V-model are particularly appreciated. Nevertheless, the V-Model has some drawbacks, especially in terms of cross-department collaboration or flexibility. That is why new project management methods have been created, such as the Agile methods in the nineties. Nevertheless, the V-Model is still widely used and is an interesting method to approach project management in a very structured way. In what follows, many information, and especially the industrial example, come from the experience of the author in the industry.

V-Model presentation: process & artefacts

The V-Model takes into account the entire system lifecycle, from the requirements analysis to the system acceptance. This model provides a process to follow, roles to distribute to stakeholders, artefacts to document the project, and management mechanism to ensure a relevant management style. The first three elements are tackled in this paragraph.

Formulation of the V-Modell

The V-Model has been created in the eighties and has been adapted since then. Thus, you may find several and different versions of it. The following one reaches a global consensus.

The general version of the V-Model

In order to avoid misunderstanding, some definitions are needed. Concerning the process, a step is one of the box on the chart, and a phase is a collection of steps. Moreover, the whole product to be built is called the system. It can be an aircraft, a building etc. Products are the different parts of the system. For an aircraft, products can be a yoke, the pilot cabin, the reactors… Lastly, a component is the simplest part of a product. For the yoke of an aircraft, it can be the electronics and the mechanical elements. The cycle is split into three phases : the system development phase, the system implementation phase and the testing phases, each one after the other. The development and the testing phases are divided into four steps each. Last but not least, the testing steps are linked to the development steps so the project manager can ensure a complete appropriateness between the system requirements specified during the development phase and the system characteristics verified during the testing phase. In what follows, each step is described: its goal, stakeholders and artefacts are specified.

The development phase

The development phase corresponds to the specification of the system’s, products’ and components’ characteristics. The development phase begins when the company has signed the contract with the customer. Then, a kick-off meeting is organized and a “kick-off report” is written. It contains the scope of the project, the expected outcomes, the planning and the allocated resources, and the main terms of the contract for the least. The development phase is then split into four steps: Needs & Feasibility Analysis, Requirements & Specifications Analysis, System Analysis & Design and System Components Analysis and Design. Each of them is specified in what follows.

Needs & Feasibility Analysis

At this step, the only document available for the project manager is the contract signed with the customer. He has to translate it in formal needs and requirements. The project ownership team (project manager + company’s executives) is in charge of writing the Scope Statement. This document should contain at least:

• The project charter
• The project owner, sponsor and stakeholders.
• The problem statement.
• The project goals and objectives.
• The project requirements.
• The project deliverables.
• The project non-goals (what is out of the scope).
• Milestones.
• Cost estimates.

Thanks to this document, the project is clearly structured.

Example: Project management is a very concrete matter. Thus, the example of a fighter aircraft will be run throughout the V-Model description so it becomes understandable. Imagine that you are a project manager for the Defense industry at Dassault Aviation. During this first step, you have to plan the project, understand your customer’s needs and requirements. For instance, you have to take into account that your customer wants a fighter aircraft capable of escaping existing fighter aircrafts or being able to carry pilots up to 1m90 tall. All those information are documented in the Scope Statement.

Requirements & Specifications Analysis

This steps aims to translate the needs of the customer into specifications that can be understood by the technical teams which will tackle the development of the system. Thus, two documents have to be written by the Project Leadership (the project manager and his/her close collaborators – often Head of Departments): the General Specifications and the Technical Specifications. Those documents contain an operational view of the system to build.

Example: At this step, the project manager and his/her close colleagues focus on the size of the pilots for instance. One of the needs of the customer is to have pilots up to 1m90 tall. In this case, it means that a cabin should be 5m3 in volume, has at least one meter to insert the pilot’s legs etc… In other words, the needs of the customers become more concrete in terms of design and engineering.

System Analysis and Design

This step goes one level deeper in the system’s description and split the different expertise. The project manager and his/her design team writes two documents: the Software Design Document and the Hardware Design Document. In both of them, the products to be designed and built are specified. The different departments and specialized teams are assigned particular products to develop (electronics, mechanics, etc…). Most of the time, the two documents are different but sometimes merged depending on the company’s organization. Moreover, the design teams work together to define a Testing Plan, which is a collection of tests to be led in the steps to come in order to ensure high-quality products and system.

Example: As a project manager, you know that the pilot’s cabin is to be adapted because of the maximum size of the pilot required by the customer. At this step, you specify the consequences for the cabin design. Those can be the design of the yoke (bigger than currently), the power of the ejection seat etc… In the two documents, the design teams specify that the ejection system is built by the fluid mechanics teams, that the electronics of the yoke is built by the electronics teams, and that the seat itself is to be built by the mechanical teams.

System Components Analysis and Design

The final step of the development phase aims to specify the requirements for the components of each products. Each development teams from each expertise build its own part and write a Detailed Design Report. Sometimes, tests are led according to the Testing Plan.

Example: For the fighter aircraft, the electronics team develops the electrical networks among other elements, the mechanical team develops each component of the seat etc…

The System Implementation Phase

Once the development phase is finished, the components are put together within each development team. It is the beginning of the integration phase. Instead of a real step in the project, the system implementation phase can be seen as a milestone. It is often the opportunity for all the stakeholders to review the projects from the beginning to the middle of the process.

The testing phase

This new phase aims to test the aggregation of components, integrates those aggregates with each other to build the system, and then test the system as a whole. Like the previous phase, this one is well documented.

Products integration and test

Since the components have been integrated during the implementation phase, the aggregates have to be tested according the Testing Plan. This is tackled by the development teams within their own departments or in multidisciplinary teams. A Unit Testing Report is written to follow the performance of the components and the products. It contains the description of the tests, the results and the potential observations. At the end of this step, all the products to build the system should be ready to be assembled.

Example: To make the yoke of the fighter aircraft, electronic and mechanical components were needed. During the implementation phase, they have been put together to form the yoke. This phase tests if the yoke works by itself as expected. At the end of this step, the cabin should be ready to be assembled with the rest of the aircraft.

System Integration and tests

This step aims to assemble all the products to form the system. This is tackled by the project manager and the design teams. When assembled, the system is tested as a whole or on different part of it. An Integration Testing Report is written. The content is similar to the one of the Unit Testing Report. The tests should check if the elements decided during the “System Analysis and Design” step are validated.

Example: The cabin, the engines and the other products of the fighter aircraft has to be put together. Then, tests are led on the aircraft as a whole (does it behave as expected in the laboratory?) and on the different parts (do the engine start? Do they disturb other systems within the aircraft?). At the end of this step, the aircraft is completely assembled.

System Validation

This step should be a testing one only. The Project Leadership (and sometimes the Project Ownership for strategic projects) join to test the system in real use conditions, without the customer. At that moment, the system should behave exactly as expected and specified in the General Specifications and in the Technical Specifications determined during the “Requirements & Specifications Analysis” step. A System Validation Report must be written.

Example: At this step, the stakeholders of the project join to test the fighter aircraft in real conditions. You would go to an airfield next to the factory where the aircraft has been built, and you would test it flying according to the Testing Plan to verify that all the functionalities are operational.

System Acceptance

The final step is close to the last one except that the customer is present for the tests. The aim of this step is to show the customer that all the needs it has expressed in the contract and in the Scope Statement have been fulfilled. At the end of this step, the customer should agree on validating the system without condition. A Customer Validation Report must be signed. Once it is done, the project is officially finished. If any problem occurs on the system, the after-sales department of the company shall deal with it.

Example: You would spend one week with an aircraft pilot hired by your customer so the latter can test all the requirements it has specified at the very beginning of the project. All the contextual elements are similar to the previous step.

V-Model management mechanisms

Once the global mechanisms of the V-Model are specified, it is important to go into more details on the project management part. Some projects using the V-Model can last several years. Thus, the four following topics are key: the project organization, the risk management, the quality control and the problem management.

Project Organization

The V-Model is a very structured planning and execution tool to manage a project. Thus, the organization of the project and the project’s environment have to be extremely clear. First, the roles and responsibilities of each stakeholders have to be clearly stated and known by everyone so the project manager is able to create the right teams for the right system’s parts to develop and is able to manage the stakeholders correctly. When talking about stakeholders, it implies the employees who have a direct involvement into the project, but also the people who can have an impact on it. Secondly, the scope, the timing and the allocated resources (money, people, materials …) must be clear and defined from the very beginning of the project. On this matter, the Scope Statement is fundamental. Some customers may leave details undecided on purpose. As a project manager and in relationship with the Project Ownership, you have to take actions since this kind of situation must not happen. Making this documentation clear and strait enables the project manager to avoid this kind of problem.

Risk Management

Alike any other project, risks have to be monitored, reviewed and tackled. This risk management process must be continuous. For the V-Model, the Project Execution Strategies is the key document, since it must contain a preliminary and up-to-date analysis of the project’s risks. Moreover, it contains a detailed planning for risk-related meetings. If not necessary, those meetings may be canceled. But most of the time, they are very useful. In most companies, decisions are made in a Steering Committee. This Committee is composed of all the key people of the projects, especially the company’s executives who are responsible for the project (even though not managing it directly). In this kind of Steering Committee, the project manager explains the current state of the project. He reviews the risks and launches a discussion on the current issues. It is for the executives to make the final decisions. All the decisions of all the Steering Committees are formulated in a document that is often called Project Progress Decision.

Quality Assurance

The quality assurance issue is essential for projects, especially when they are long. The cost of non-quality or the cost of lateness due to a product reprocessing can skyrocket. In order to manage the quality issue, two documents are important: the Scope Statement, which has already been mentioned, and the V-Model Reference Work Product. This document describes the standards for every products of the system. It has to be continuously completed during the development part. Thanks to this documentation, the project managers and the technical experts know the expected outcomes for each parts of the system. Thus, the following process can be applied to review the product’s quality.

The general version of the V-Model

The quality control process is divided into two steps. The first one aims to verify that the product works well without any technical malfunctioning. If everything is correct, it goes to the second step to check if the product fits the expected outcomes based on the V-Model Reference Work Product. If so, then the product passes the test. If at any moment, the product fails to pass the test, then it is reprocessed and has to be submitted to another test when ready. Last but not least, the quality controls should control the performance of single elementary parts of the final system, but also the quality of the connection between two parts which are supposed to work together within the final system. The tests are led according to the Testing Plan.

For the simplest product, the evaluations are self-conducted. But for bigger products, it is sometimes necessary to be call for external experts. In this case, controls are often longer but can stress unnoticed issues. It is for the project manager to decide whether the self-conducted control tests or the external experts are needed.

Problem Management

All along the project, needs for change or reaction to problems will occur. Thus, parts of the final system will have to be modified. If a certain degree of completeness has been reached, then the change must be followed up closely and documented.

Most of the time, two rules apply:

• All the problems and change suggestions are documented and assessed. The decision for the change belongs to the Steering Committee.
• Formally speaking, the problems and changes are documented within the Change Status List. This list should at least contain the information about the nature of the change, its type, its current state, the decision made and the planned schedule. This document should be up-to-date at any time during the projects.

Problems and changes are time-consuming and budget-consuming. That is why it is key for the project manager to adopt a structured way to tackle these issues.

Summary of the V-Model

In order to manage a project well, it is important to have a clear and synthetic view of how the model works. In particular, the V-model may be confusing sometimes because of numerous roles and documentations. The following figure summarizes the phases, the steps, the roles and the documents.

A summary of the phases, steps, stakeholders and documentation of the V-Model

V-Model application

V-Model’s advantages

The V-Model is a standardized and structured way of planning and executing a project. Even though it may be a bit difficult to implement for short projects, it becomes key for complex and long projects that involve a great deal of stakeholders and investments. Four main reasons can be pointed out to determine if the V-Model is relevant to manage a project.

• Minimizing the risks

The V-Model ensures an effective and efficient transparency and plannability so the risks of planning deviations as well as the other types of risks can be noticed early in the project course. Thus, it enables a fast reaction and adaptability to uncertainty. By this way, the different stakeholders stay confident in the project teams and it avoids potential frictions.

• Improving and guaranteeing quality

As noticed in the “Quality Assurance” part, the V-Model and its management mechanisms ensure that the final system fits the expected requirements as much as possible.

• Cost Mastering

The V-Model goes into the simplest details possible of the system to build. Thus, the cost calculation which depends on the resources to allocate for each part of the final system, is quite easy. The cost control is also simplified by this method of project management since the cost deviation are spotted rapidly on the reporting from each step. Last but not least, the calculations made for one project are replicable for another one. Thus, experienced project managers who know about the previous projects of their company can save lots of precious time by referring to previous projects.

• Improved communication between stakeholders

Since the V-Model is a structure, standardized and documented approach, the stakeholders share a common understanding of the project at each step. This understanding minimizes the potential frictions that can occur all along a project.

The V-Model use in the industry

The V-Model has inherited from the “Waterfall model”, which has been described for the first time in 1956 by Herbert D. Benington. This model specified a way of managing project as a five-step process: requirements – design – implementation – verification – maintenance. This model has been particularly used for software development in the seventies and in the construction industry.

But in the eighties, the systems and the projects became more complex. The V-Model is an adaptation of the “Waterfall model”, for which the different steps of the previous model are joined. From this time, almost all the industries adopted the V-Model as the main project management tool. It is particularly the case for the Defense, Pharmaceutical and Construction industries whose projects are long (at least one year) and very costly (at least millions of dollars). The software industry also used the V-Model but the creation of the Agile methods tend to decrease the use of the V-Model in the nineties. The Dassault Rafale from Dassault Aviation, the Rejsekort for Thales and Accenture, and the Millau Viaduc are famous projects for which the V-Model has been used to specified the requirements from the global picture to the components.

Limitations

Even though the V-Model is still a widely used method for project managers, several drawbacks have to be taken into account when choosing it. Those can be divided into three categories: the lack of flexibility, the lack of interconnections between all the steps and the lack of collaboration between the technical teams and the management teams.

The issue of flexibility

For some projects, especially in software engineering and mobile app development, all the documentation that is required for the V-Model seems to be useless and time-consuming. That is one of the reasons why the Agile Method, such as the Scrum method, have been created. Those require less documentation and are based on a hands-on approach of the system by most of the project’s stakeholders.

Interconnections between all steps

First, the system validation begins after the implementation in the V-model. Even though functioning tests may have been led during the development and the implementation steps, the main steps are supposed to be led during the test period. If a malfunctioning occurs during this test phase, then the design and the implementation may be questioned. Since re-designing and re-building part of a system is costly and time-consuming, the project may be endangered by this process.

Second, it is sometimes hard to make the difference between the conception phase (the development phase) and the implementation phase since the workers and scientists at the implementation phase often notices that the initial requirements were unrealistic or uncompleted. In this case, they have to re-write the requirements and decide the changes with the project manager who may have to refer to the Steering Committee. Again, the lack of interconnections between certain steps may lead to a waste of time and money. If this case impacts the project critical path, it could be a disaster for the project.

Collaboration between management and technical teams

Depending on the phase and the step the project currently is, the management and multidisciplinary teams may work on the technical requirements; or it may be the technical teams. For instance, at the very beginning of the V-Model, the project manager and the company’s executives will negotiate the global design of the system with their customer. But the technical teams will have no view on those negotiations. Nevertheless, this could lead to unfeasible system or expensive adaptations. In this way, a close work relationship between the multidisciplinary and management teams and between the technical teams could lead to a more efficient project management.

Conclusion

The V-Model is a structured and standardized way of planning and executing projects which eases risk minimization, cost mastering, system quality controlling and confidence between the project’s stakeholders. For those main reasons, it has been widely used in the industry that lead complex and long projects such as the construction industry, the pharmaceutical industry and some software development companies. For some reasons, the Agile methods tended to replace it in the software industry from the nineties. Even though the V-Model can lead to a lack of collaboration between the management and technical teams or can lead to extra-costs because of too differentiated steps, it is still used in industry today and is worth considering it when starting a project.