Skip to content

Chapter 2 – The Project File

Part 2

First of all…

Project-related documents can be stored in a project file or a project management information system on a central drive in Corporate Intranet or on the Internet. Everybody involved in the project should be provided with information via a reporting system that functions efficiently. A central service point should administer this system (e.g. project office or project management office). This prevents each project manager from operating a system that he has designed himself.
The project file is a document or a collection of files, building the foundation of the project which is to be planned. Beginning by noting, you write down everything concerning the project: the client or customer, the project type and a project description. Then the project is further characterised. The project file needs to be complete and up to date.

Project Organisation

The environment where the project is realised.

  • Project manager
  • Project team
  • Steering Committee
  • Client/Customer
  • Project Partners

Project Definition

The preparation for project planning

  • Tender documentation
  • Quotation
  • Objectives (performance, costs, time)
  • As-is analysis
  • Contract, order, terms & conditions of business
  • Specifications
  • Project report (outline, draft)

Project Planning

The initialisation for the project is noted here.

  • Phase plan, milestone plan
  • Work breakdown structure
  • Network diagram
  • List of activities
  • Preliminary costing
  • Risk analysis
  • Project report, Version 0 (internal, external)
  • Resource planning

Project Control

The implementation for project realisation.

  • Activities list (updated)
  • Work Package Descriptions (approved, in progress, completed)
  • Project reports (updated)
  • Work Reports, activity Reports
  • Calculations (updated)

Project close-out

The evaluation for the project.

  • Invoicing
  • Quality assurance (acceptance)
  • Historical cost calculation
  • Product generation (routine process)
  • Client/Customer evaluation
  • Overall knowledge gained

Project Material

The collection and documentation for the whole project.

  • Concepts
  • Software (CDs, USBs)
  • Accompanying material (scientific materials, articles, literature, reference to other projects, online research, sources)
  • Presentations (transparencies, hand-outs)

How to handle the project file?

Now that you know some possible contents of the project file, you will take a closer look to the requirements of this file.
It is important, that all information provided is centrally located so that all people involved have access to it. The project file hast to be up to date all the time! In the event that project team members become ill, are on vacation or otherwise leave the project, the steps in the project file must be comprehensible for everyone working in the team.

What about other documents and communication tools?

Besides the project file, there are some other documents which play an important role in project management and which are used to improve the communication within and outside the project.

Project report

The project report gives all parties involved in the project an overview about the actual state of the project. If there arose any problems or deviations from the plan, they should be brought up in this report. Together with the team or the stakeholders a solution can be found. For working out this report, there are three different possibilities.

  • Cockpit report: Report with milestone trend analysis. Includes information about deadline adherence and costs, plus information about the quality of the project deliverable
  • Milestone trend analysis (extended milestone technique): Provides an at-a-glance overview of whether key project deadlines will be met or not. It can be used as a derived (from network diagram) or original (estimate) tool
  • Traffic light report: This report provides a simplified overview of the situation. The traffic light colours can be used to denote project status, finished work packages, interim results, materialising problems and counter measures and for significant project activities in the subsequent month

Project progress reporting

The project progress reporting documents the progress of the project since the last report.
How often this report should be carried out is given by your company/your customer etc.


There are two different types of logs – the chronological representation (history log) and the systemised summary (records log). The minute-take in the case of a chronological representation, will write down a situation word by word. This makes sense in sensible situations (e.g. conflicts). In the systemised summary on the other hand just the outcomes of a situation are written down.

Final report

In this report the actual project is evaluated and it is compared to the planned requirements. There are many suggestions about how to structure final reports. The minimum content of this report is as follows

  • Planned and achieved quality, deadline and cost objectives
  • Reasons for deviations
  • All the things that went well and badly for the team
  • Consequences for future projects
  • To-do list

Document requirements matrix

This matrix is helpful in order to ascertain document requirements and prepare handover documentation. It is based on two dimensions – document content and document type. It compiles stakeholder information requirements in a list and specifies report type, frequency, summarisation and distribution. It also ensures that the information recipients are provided with the correct quantity of information. It should be enough information to give them an idea of what is going on but in summarised format to ensure that they can retain an overview.

Project controlling

Document management

Document management describes where and to which progress information is documented. It makes it possible, within reasonable time and effort, to furnish all documents relating to a specific issue. However, the document management team is not responsible for the content of the documents (completeness and correctness). Documents are archive-worthy records that are stored in all kinds of information carriers. A document is archive-worthy if it

  • describes future obligations (e.g. contract)
  • defines work processes (e.g. job orders)
  • contains interim results (e.g. status report with approvals), or
  • serves as verification for results achieved (e.g. completion certificate)

The purpose of project documentation is to set up and keep a system of the project file. Furthermore, it's important for compiling the handover documentation.

Configuration management

A configuration is defined as the

  • functions and physical features of a product or service as described in the supporting documents and implemented in the product
  • detailed and complete compilation and documentation of project results and their systematic updating when project changes are implemented

Configuration management is a management discipline that is applied throughout the entire lifecycle of a product to ensure transparency and guarantee that it incorporates the agreed functional and physical features.
The main objective of configuration management is to document the current configuration of a product, as well as the extent to which it satisfies physical and functional requirements and to ensure absolute transparency in these respects. Documentation transparency can be described as the ability to provide a satisfactory answer to any question within a reasonable time. At all phases of a project, all members of a project team should have access to information about the project deliverable and its creation process (= "what" question) so they can check whether the individual configurations – which are also called design characteristics – can be physically connected to their interfaces. Configuration management also ensures that each project team member uses the correct documentation in all phases of the product's lifecycle.

Change control

Change control is necessary for the monitoring and management of changes that have to be identified, described, classified, assessed, approved, implemented and verified. In some projects, configuration management is not necessary. Change control, however, is an essential aspect of all projects. If data and facts are only contained in one or two documents, an update of one or both of the documents suffices to recognise that a change has been made. Configuration management is only necessary if information is changed in many different documents.
During the change control it's important to figure out which aspect was changed and by whom.

How the story ends…

"So now you know, what a good organised project file could look like" Dr. Rogers ends his sentence. "Only if everything is at its place, you later will find what you are looking for."