The basic project control supporting documentation – By, Dr Dimitris Antoniadis

In chapters 4 and 5 of my book ‘Demystifying Project Control’ and my two previous blogs we looked into the project control as a function and how the department should be structured. In this blog, as I do in chapter 6, I am looking into the documentation that supports the discipline and provide a number of examples from the industry.

The APM and the PMI BoK describe the basic standard project management supporting documentation. These include the: Project Execution Plan (PEP), or Project Management Plan (PMP), the Project Quality Plan (PQP), Stakeholder Management Plan, Risk Management Plan, etc.

In terms of standard documentation on the project control side there has not been much work setting out official standards across the field.

In my opinion, the reason for this is not so much the fault of the professional Institutions but the individual practitioners / companies themselves and how project supporting services are viewed. Just to be clear, this does not currently apply to petrochemical companies, who are seen by many as those that opened the frontiers of project control. And the reason they are there? Well, when your investment is running in the billions of $s and every hour or day of delay is affecting your bottom line (to the tune of $Millions) you have to seriously consider how to control the project from the concept stage.

Ok, let’s not blame everything on us, the project practitioners.

As discussed earlier, there are plenty of variables and several factors that ‘interfere’ with project control and it is not that easy to standardise something to the same extent as that of the PMP. Having said that, at certain levels and in certain areas practitioners have been able to develop specific and clear documentation, and in some cases these have been implemented at a company-wide level.

There is a definite need for standard documentation to be established and this must support the project control function. It has to be something that will allow flexibility but at the same time will set boundaries within which project controllers and the relevant systems will operate. This is what in complexity theory is called 'downward causation' and in our case we can define as 'bottom-up' causation. In practical terms we are talking about putting all project practitioners (that is all project team members) in a 'loose straight jacket'. Later on I will describe in more detail the complexity characteristics.

In the chapter I describe the content and give examples of PMPs, a PMP template that can be used for any project, the Work Package Execution Plan (WPEP) and then looking into the Project Control Plan (PCP) or Project Control Handbook.

In describing the PCP I explain the various topics that need to be included like:

1. The Objective of the PCH
2. What does it address?
3. What is it and what are the different levels?
4. How is it structured?
5. The descriptions of the various project control processes.
6. Where is PCP distributed.
7. How should it be rolled-out?
8. Can / should it be considered as been forever draft?
9. Why it should be considered as a ‘Loose straight jacket'.

In addition to the PCP project controller need to consider what communication tools can be used to cascade the various messages to the project teams and the stakeholders. I also describe how project control can become the centre for managing the processes of lessons learned and knowledge management and give two examples of how the latter can be structured.

Dr Dimitris Antoniadis
PhD, MSc, BEng
CEng FAPM FCMI MIMechE
Website: www.danton-progm.co.uk
Email address: [email protected] or [email protected]