Creating a project manual made easy
The project manual is one of the most important documents in a project. Above all, it defines the process by which the project is worked on. It also describes the tools, programming languages and frameworks used. It is the first document that a new project member should read. Based on V-Modell XT, this article shows how a well-structured project manual should be designed in terms of content
The V-Modell is a generic process standard that must be adapted and concretized for our project. This project manual defines the necessary adaptations and designs (“tailoring”). It describes our project-specific process, so to speak.
If you have never dealt with the V-Modell before: “Products” means everything that is produced within a project, not only the final product, but also all kinds of documents and intermediate results.
The project manual contains
- a short description of the project
- the description of the tailoring result. This includes as essential components a list of the types of products to be created and a description of the roles
- the basic project implementation plan
- the necessary and agreed support of the client
- organization and specifications for the planning and implementation of the project and the upcoming development tasks.
This includes, for example, a list of tools, programming languages and frameworks to be used. The project manager has to develop this central product in coordination with the key people of the project.
The project handbook also specifies the frequency and necessity of generating continuative products that are necessary for planning and implementing the project, for tendering and contracting and for process improvement, for example project status reports, risk lists, contracts and evaluations of process models.
Note to the project manager: Go through all points in this document. If you have no idea what a section in your project manual is good for, even after a long time of consideration, leave it out! Worse than leaving out too much is writing something down without seeing the benefit.
Project overview, project goals and success factors
The project manual is an indispensable source of information and guideline for all project participants. In this section the common project mission statement is presented briefly, concisely and as vividly as possible.
Project specific V-model
System development project (AG/AN)
Project type variant
AG-AN project involving development, enhancement, or migration
|Commercial project management||no|
|Measurement and analysis||no|
|Information security and data protection (AG/AN)||yes|
|functional security (AG/AN)||yes|
|project subject||HW and SW|
|Transfer of operations. (AG/AN)||no|
Selected procedure modules
The following building blocks are mandatory if hardware and software are to be supplied. Otherwise, one of the two building blocks can be omitted.
|Problem and change management|
|Delivery and Acceptance (AG)|
|Delivery and Acceptance (AN)|
The following building blocks for the project manual are optional, depending on the nature of the project.
|Commercial Project Management|
|Measurement and Analysis|
|Information Security and Privacy|
|Information Security and Privacy (AG)|
|Information Security and Privacy (AN)|
|Functional Safety (AG)|
|Functional Safety (AN)|
|Evaluation of finished products|
|Usability and ergonomics|
|Transfer of operations|
|Contract signing (AG)|
|Continuing development and migration of legacy systems|
Deviations from the V-Modell
All deviations from the specifications of the V-Modell, such as deletions of individual products, activities, and deviation from the tailoring process, must be documented with reasons given. The changes must be listed in this section.
Project Implementation Plan
The V-Modell provides guidelines for the rough structuring of the project by defining decision points. This section contains the planning design of these decision points in the form of a project execution plan. At least the beginning of the project, the end of the project and all important decision points during the project must be planned. It must be documented which products are required to bring about a project progress decision, i.e., to reach a decision point.
In addition, other project-specific milestones can be defined, as long as they are relevant to all project participants. Milestones that are only relevant internally to the project are documented in the project plan.
Organization and specifications for project management
In this project manual section, the specifications of the V-model for project management are adapted and concretized. All internal and external project participants are listed. The responsible contact persons are to be named. In addition, the key roles of the V-Modell, such as project manager, QA manager, and system architect, are filled with persons and their tasks and responsibilities are structured according to the V-Modell specifications.
The basic organization and implementation of cooperation between all project participants is defined. For example, meetings, the procedure for coordination rounds, conflict management, escalation strategy, conditions for conducting a formal decision-making process are defined and documented. In addition, threshold values are defined, the exceeding of which leads to the initiation of control measures. An example of this is exceeding target values for planning by more than 15%. Organization-wide guidelines must be taken into account.
For the V-Modell products to be created as part of project management, such as project plan, estimate, work order list, and project diary, it is specified whether and when these are to be created, according to which methods, guidelines, and standards these products are to be prepared, and with which tools they are to be processed (see also chapter Product Structuring and Generating Product Dependencies).
Organization and specifications for risk management
To ensure that the assessments of risks within the project follow the same standards, the risk management already provided for in the V-Modell is fleshed out and specified in this section. The general decision must be made as to whether opportunities should also be considered in addition to risks. The same procedure is used for opportunities as for risks, so no further distinction is made between the terms opportunity and risk below.
Here the definition takes place, when and according to which criteria risks are documented in a risk list. In addition, it must be defined with which methods, guidelines and standards and with which tools risk management is to be carried out.
In detail, the following points are to be determined:
- Risk classes to classify risks
- Criteria for risk acceptance
- Escalation levels based on the defined risk classes, according to the requirements of the section Organization and Requirements for Project Management
- Procedures for documenting identified risks and planned actions
- Times and procedures for risk identification
- Times for reassessment of risks
- Times and procedures for planning and implementing countermeasures
Here you will find a template for a project manual in various formats.