Chapter 2 – The Project File¶
First of all…¶
The project file is a document or a collection of files, building the foundation of the project which is to be planned. You write down everything concerning the project, beginning by noting the client or customer, the project type and a project description. Then the project is further characterised.
The environment where the project is realised.
- Project manager
- Project team
- Steering Committee
- Project Partners
The preparation for project planning.
- Tender documentation
- Objectives (performance, costs, time)
- As-is analysis
- Contract, order, terms & conditions of business
- Project report (outline, draft)
The initialisation of 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)
The implementation for project realisation.
- Activities list (updated)
- Work Package Descriptions (approved, in progress, completed)
- Project reports (updated)
- Work Reports, activity Reports
- Calculations (updated)
The evaluation for the project.
- Quality assurance (acceptance)
- Historical cost calculation
- Product generation (routine process)
- Client/Customer evaluation
- Overall knowledge gained
The collection and documentation for the whole project.
- 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 at 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 has 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 has to 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.
The project report is a communication tool. The report gives all parties involved in the project an overview of the actual state of the project. If any problems or deviations from the plan arose, 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.
In this report the actual project is evaluated and 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 requirement 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.
- Configuration management: Detailed and complete compilation and documentation of project results and their systematic updating when changes in the project take place. Technical and organisational measures for configuration identification, monitoring, accounting and auditing.
- Change management: Assessment of all change requests, especially when they affect project objectives. Initiates, monitors and documents changes to the project result.
- Documentation management: Provision of all necessary documents for every question. Document management is not responsible for the content of the documents (completeness and correctness).
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."