The Project Manual: Tips for Creating One, Plus a Template

Introduction

The project manual is one of the most important documents in a project. There are different views on what it should contain. Here we follow the understanding of the V-Modell XT. The V-Modell is a generic process standard that can be adapted and tailored for any project. The project manual defines the necessary adaptations and customizations (“tailoring”). It describes, in effect, the project-specific process and establishes the names and content for all elements of the project documentation.

If you have never worked with the V-Modell before: “products” in this context means everything produced in the course of a project — not just the final product, but all types of documents and interim results as well.

Contents of the Project Manual

The project manual includes

• a brief description of the project with an outlined project scope

• the description of the tailoring result. Its key components are

  • a list of the types of products to be created
  • as well as a description of the roles

• a rough project plan

• the necessary and agreed-upon support from the client

• organization and guidelines for planning and executing the project and the upcoming development tasks. This includes, for example, a list of the project management tools to be used, programming languages, and frameworks. The project manager must develop this central document in coordination with the key stakeholders in the project.

The project manual also specifies the frequency and necessity of producing additional documents required for project planning and execution, tendering and contract management, and process improvement — for example, project status reports, risk registers, contracts, and assessments of process models.

Note to the project manager: Go through every point in this document. If, even after careful consideration, you cannot see what purpose a section serves in your project, leave it out. Adding something without value is worse than omitting something useful.

Project Overview, Project Goals, and Success Factors

The project manual is an indispensable source of information and a guide for all project participants. This section presents the shared project vision concisely and as vividly as possible — including the project goals and the project management triangle (schedule, cost, performance).

Project-Specific V-Modell

Project Type

System development project (client/contractor)

Project Type Variant

Client-contractor project with development, further development, or migration

Application Profile

Selected Process Building Blocks

The following building blocks are mandatory when both hardware and software are to be delivered. Otherwise, one of the two building blocks may be omitted.

The following building blocks are optional, depending on the nature of the project.

Deviations from the V-Modell

All deviations from the V-Modell requirements — such as the removal of individual products or activities, or deviations from the tailoring procedure — must be documented with reasons given. The changes are to be listed in this section.

Project Execution Plan

The V-Modell provides guidelines for the rough structuring of the project by defining decision points. This section contains the planned design of these decision points in the form of a project schedule. At a minimum, the project start, project end, 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 — that is, to reach a decision point.

In addition, further project-specific milestones may be defined, to the extent that they are relevant to all project participants. Milestones that are only relevant internally are documented in the project plan.

Organization and Guidelines for Project Management

This section of the project manual adapts and concretizes the V-Modell’s requirements for project management. All internal and external project participants are listed, with responsible contacts named explicitly. In addition, the key V-Modell roles — such as project manager, quality assurance manager, and system architect — are assigned to individuals, and their tasks and responsibilities are defined in accordance with the V-Modell specifications.

The fundamental project organization and the conduct of collaboration among all project participants are defined. This includes, for example, meetings, the procedure for coordination rounds, conflict management, the escalation strategy, and the conditions for initiating a formal decision-making process — all of which are established and documented. In addition, threshold values are defined whose breach triggers the initiation of control measures. One example is a deviation of more than 15% from planned values. Organization-wide requirements must also be taken into account.

For the V-Modell products to be created as part of project management — such as the project plan, effort estimation, work order list, and project diary — it is specified whether and when these are to be created, according to which methods, guidelines, and project management standards these products are to be developed, and which tools are to be used (see also the chapters on Product Structuring and Generative Product Dependencies).

Organization and Guidelines for Risk Management

To ensure that risk assessments within the project are made according to consistent criteria, the risk management already provided for in the V-Modell is detailed and concretized in this section. A general decision must be made as to whether opportunities, in addition to risks, should also be considered. Since the same procedure applies to opportunities as to risks, no further distinction between the two terms is made below.

This section specifies when and according to which criteria risks are to be documented in a risk register. In addition, it must be defined which methods, guidelines, and standards — and which tools — are to be used for risk management.

The following points are to be specified individually:

• Risk categories for classifying risks
• Criteria for risk acceptance
• Escalation levels based on the defined risk categories, in accordance with the guidelines in the Organization and Guidelines for Project Management section
• Procedure for documenting identified risks and planned measures
• Timing and approach for risk identification
• Timing for reassessment of risks
• Timing and procedure for planning and implementing countermeasures

Template

You can find a template for a project manual in various formats here.