The project documentation includes all relevant documents that are created during and for the project itself. The project documentation acts as a memory container for the course of the project, decisions made, changes in content and for managing the level of detail of the project.
The documentation is also a part of the risk minimisation in the project. Properly done, project documentation enables the parties involved to focus on different parts of the project at different times without having to keep in mind the entire detailed status of the project.
Project documentation – why?
Project documentation is usually not the main focus of project implementation and is often neglected. Due to the time pressure to which almost all projects are exposed, the project team focuses on the professional and technical topics for the implementation. The project documentation is usually neglected.
In many projects the documentation is often produced late, poorly or not at all because it is perceived as of little or no value. This is certainly the case if the documents are only produced later or as a necessary evil. Even documents with adequate content lose value if they are created at the wrong time during the project or are not used in the project management process.
Common mistakes that should be avoided in your project
- It is documented randomly or not at all
- Nobody feels responsible for this task
- Too many different people „tampering“ with the documentation
- There are no clear rules for documentation and filing structure
- In stressful project phases, project documentation is neglected because it does not seem to be relevant to success and can be tackled later, which experience shows is never done again.
The project documentation must therefore not be neglected. Nevertheless, it is possible to reduce the effort to a minimum and maximise the „outcome“ if a few basic rules are followed.
Planning the project documentation
Project documentation is better and more efficient if it is approached „right“ from the beginning. In order to achieve this – as so often in a project – thorough planning is necessary. This means that the planning of the project documentation must be carried out as part of the overall planning process for the project at the start of the project – so to speak, a small project within the project. It must therefore also be provided with goals and intermediate objectives.
The beginning of the project documentation is usually the project order, the end is represented by the handover and acceptance documents.
The responsibility for creating project documentation remains with the project manager!
Of course, this does not mean that he creates or compiles the documentation himself, but rather that he is responsible for ensuring that there are clear guidelines, rules and responsibilities and that these are observed.
In retrospect, documentation is sometimes the most important – and often only – tool for an evaluation in terms of meaningful project reporting.
Tip: Ideally, the project documentation is included in the work breakdown structure in the explicit form of work packages. This automatically ensures ongoing controlling.
The following procedure has proven to be an efficient way to collect the „right“ data in the project in order to carry out a „complete“ project documentation.
Define documentation contents
It is important to define the „documentation-worthy“ project contents, i.e. what exactly should be documented – and what not. In this way, the amount of information and also the personnel effort can be reduced without losing any relevant information.
Examples of documentation content:
- defined requirements, specification sheet
- specialist concepts
- technical concepts
- Process and workflow documentation
- Design specifications
- Software used
- system environment,
- Documentation of test cases
- Project planning documents (project order, work breakdown structure, milestone planning, risk analysis, environment analysis, ….)
- Project reports / status reports
- Rollout plan
- Minutes (meetings, workshops, steering committee, ….)
- etc.
Which data is available and which must ultimately be documented always depends on the individual case. However, it is important to determine what is and what is not documented at the beginning of each project. In case of doubt, the project manager has the final decision authority.
If a project is well structured and planned, the project documentation usually runs „on the fly“ without too much effort.
Tip: Concepts, plans, protocols, etc. are created for the project implementation anyway and are included in the project documentation without additional effort. The following guiding principle applies: „as is“. If a document is suitable for project implementation, then it does not need to be additionally formatted or „pretty“ for the project documentation.
Define filing structure and filing location
In order to be able to derive a concrete benefit from the documents & Co., the project documentation must be findable and viewable at any time by the project participants. It is therefore important to agree on a filing structure that all project members adhere to. On the one hand, the employees know where they have to deliver or file important documents. On the other hand, they can access the current documentation as needed and draw the desired information from it.
Digital storage, Cloud, Tools
The ideal place for project documentation is a shared network drive on a company server. Alternatively, a cloud service can be used. With a cloud solution, it must be ensured in any case that all data protection regulations are observed. Public cloud services are therefore often ruled out. However, company-internal clouds are already almost standard today.
Of course, there are also tools for document storage, archiving and searching …… This is certainly a good solution if such a tool is known and established among all employees. If the training or conversion effort required to use the tool is too high for the employees, then the project documentation will be negligent.
The handling of a simple directory structure is generally internalised for all employees.
Folder structure
The directory structure for filing is best kept very simple and flat. For smaller projects a 1-level hierarchy is often sufficient. For complex projects you can create a multi-level hierarchy of the project documentation.
The fastest and simplest way is to represent the work breakdown structure (WBS) with its phases and work packages 1:1 in the folder structure. All documents and records for a work package then end up in the corresponding work package folder. The advantage of this procedure: the person responsible for the WP is also responsible for the correct documentation.
As a project manager, you can involve the employees in the development of the filing structure. It is always advisable to enter the discussion with a concrete proposal. If there is no consensus, then the project manager decides, that is his job. There are usually more important things in a project than discussing filing structures over a long period of time.
Access rights
We recommend that every project member has at least read access to the entire project documentation. This is important because absolute transparency should prevail in the project. Restricting access for project members to a few selected documents contradicts the goal of completing the project quickly in a flat structure.
Of course, there are sensitive documents which are not intended for the general public. These could be contracts, for example, and also all documents dealing with personal data. The project manager should separate these documents completely from the project document in a different filing structure (e.g. his personal one) to which only he and selected employees have access, then nothing can go wrong with the access rights.
Naming conventions
Three simple rules are usually enough here:
1) As prefix the date: YYYY-MM-DD
2) Meaningful document designation: e.g. Test_Concept_Module-A
3) A version number of the document: v01
The result looks like this: 2020-04-17_Test_Concept_Module-A_v01.doc
These 3 rules are easy to understand and are usually followed. Because of the date in the file name you can see immediately what the last version is. The save date is not always reliable, because it often happens that employees close the document after they have looked at it for a short time by clicking on save. In combination with the defined filing structure, these rules are usually absolutely sufficient.
Of course you can specify much more in name conventions. Here often very complex rules are given, which you cannot keep in mind. But you shouldn’t be surprised if a large part of the project team doesn’t follow them.
File Formats
All created documents must of course be stored in the original file format. This is the only way to ensure that this file can be used and edited in the future.
The final version and important intermediate versions should also be saved as PDF. Especially with large amounts of data, it is important to convert each file directly into a small PDF file and to archive it correctly or to store documents correctly – such activities, on the other hand, hardly need any time and thus ensure more efficient evaluation after the project is completed.
Adobe’s cross-platform PDF format has become the de facto standard worldwide and greatly simplifies data exchange. This ensures that documents can also be read without the need for the original software, which is often only installed by experts.
Analog storage
It is also important to consider whether you need an analog filing system (=paper filing) and which documents should also be available in paper. Such a decision depends on many factors (corporate culture, company standards, personal preferences). If there are company-wide rules for this, the issue can be resolved quite quickly.
As a project manager at meetings, having a slim folder containing the most important and up-to-date documents can often radically shorten lengthy discussions by taking a quick look at a discussed document.
Contracts with suppliers, subcontractors, etc. often have to be kept in paper form as well. However, it is always advisable to store all documents digitally.
Photo documentation
The quality of project documentation increases considerably if photos are also used for documentation. These can be, for example, before-and-after comparisons, but also customer pictures, test documentation and much more. Photo documentation is child’s play due to the fact that every smartphone today is also a digital camera.
If the photo documentation is implemented and archived correctly, similar to teaching content, it hardly takes more time than the pure written documentation, often it is also much faster.
Define responsibilities
Once the filing structure for the project documentation has been determined, it is important to appoint at least one employee who is responsible for the project documentation. For large projects, it is advisable to divide the responsibility into subject areas or work packages.
Archiving of the project documentation after project end
All project documentation must of course be archived as soon as it is no longer needed in the project after project completion. This does not mean that it might not be important again in the future. So what every company needs is a sensible system for archiving completed projects.
Using their filing location and labeling, individual documents can then be retrieved and reopened at any time, for example, if a similar project is pending. The project documentation can then serve as a kind of „guideline“ – or as a „best-case“ or „worst-case“ example… depending on how the project and its documentation finally went.
It is also important that the project documentation remains completely archived in case of subsequent audits (e.g. internal audit, Court of Auditors, etc.). These audits often start years after the project has been completed.
