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

Introduction

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

Project type

System development project (AG/AN)

Project type variant

AG-AN project involving development, enhancement, or migration

Application profile

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
Subcontract	no
Prototype development	yes
Finished products	yes
User interface	yes
Old system	no
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.

Project management
Quality assurance
Configuration management
Problem and change management
Requirement definition
System design
HW development
SW development
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 Security
Functional Safety (AG)
Functional Safety (AN)
Logistics design
Evaluation of finished products
Usability and ergonomics
Transfer of operations
Betriebsübergabe (AG)
Betriebsübergabe (AN)
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.