Chapter 14
Project Management Plan
Abstract
The project management plan (PMP) described in this chapter is often referred to as the ‘bible of the project’. This document encapsulates a summary of all the essential requirements, methods and procedures needed to deliver the benefits of the project. The constituents of the Why, What, When, Who, Where and How are listed for each of these major sections of the PMP. The way a PMP should be organized for easy and quick reference is described. Also included is a list of company procedures and standards that must be followed.
Keywords
Methods; Procedures; Project bible; Project management plan (PMP); Requirements; Standards
As soon as the project manager has received his or her brief or project instructions, he or she must produce a document that distils what is generally a vast amount of information into a concise, informative and well-organized form that can be distributed to all members of the project team and indeed all the stakeholders in the project. This document is called a project management plan (PMP). It is also sometimes just called a project plan, or in some organizations a coordination procedure.
The PMP is one of the key documents required by the project manager and his or her team. It lists the phases and encapsulates all the main parameters, standards and requirements of the project in terms of time, cost and quality/performance by setting out the ‘Why’, ‘What’, ‘When’, ‘Who’, ‘Where’ and ‘How’ of the project. In some organizations the PMP also includes the ‘How much’, that is, the cost of the project. There may, however, be good commercial reasons for restricting this information to key members of the project team.
The contents of a PMP vary depending on the type of project. While it can run to several volumes for a large petrochemical project, it need not be more than a slim binder for a small, unsophisticated project.
There are, however, a number of areas and aspects that should always feature in such a document. These are set out very clearly in Table 1 of BS 6079-1-2002. With the permission of the British Standards Institution, the main headings of the model project plan are given in the following, but augmented and rearranged in the sections given below.
General
1. Foreword
2. Contents, distribution and amendment record
3. Introduction
3.1 Project diary
3.2 Project history
The Why
4. Project aims and objectives
4.1 Business case
The What
5. General description
5.1 Scope
5.2 Project requirement
5.3 Project security and privacy
5.4 Project management philosophy
5.5 Management reporting system
The When
6. Programme management
6.1 Programme method
6.2 Program software
6.3 Project life cycle
6.4 Key dates
6.5 Milestones and milestone slip chart
6.6 Bar chart and network if available
The Who
7. Project organization
8. Project resource management
9. Project team organization
9.1 Project staff directory
9.2 Organizational chart
9.3 Terms of reference (TOR)
(a) For staff
(b) For the project manager
(c) For the committees and working group
The Where
10. Delivery requirements
10.1 Site requirements and conditions
10.2 Shipping requirements
10.3 Major restrictions
The How
11. Project approvals required and authorization limits
13. Project implementation strategy
13.1 Implementation plans
13.2 System integration
13.3 Completed project work
14. Acceptance procedure
15. Procurement strategy
15.1 Cultural and environmental restraints
15.2 Political restraints
16. Contract management
17. Communications management
18. Configuration management
18.1 Configuration control requirements
18.2 Configuration management system
19. Financial management
20. Risk management
20.1 Major perceived risks
21. Technical management
22. Tests and evaluations
22.1 Warranties and guarantees
23. Reliability management (see also BS 5760: Part 1)
23.1 Availability, reliability and maintainability (ARM)
23.2 Quality management
24. Health and safety management
25. Environmental issues
26. Integrated logistic support (ILS) management
27. Close-out procedure
The numbering of the main headings should be standardized for all projects in the organization. In this way the reader will quickly learn to associate a clause number with a subject. This will not only enable him or her to find the required information quickly but will also help the project manager when he or she has to write the PMP. The numbering system will in effect serve as a convenient checklist. If a particular item or heading is not required, it is best to simply enter ‘not applicable’ (or NA), leaving the standardized numbering system intact.
In addition to giving all the essential information about the project between two covers, for quick reference, the PMP serves another very useful function. In many organizations, the scope, and technical and contractual terms of the project are agreed on in the initial stages by the proposals or sales department. It is only when the project becomes a reality that the project manager is appointed. By having to assimilate all these data and write such a PMP (usually within 2 weeks of the handover meeting), the project manager will inevitably obtain a thorough understanding of the project requirements as he or she digests the often voluminous documentation agreed on with the client or sponsor.
Clearly, not every project requires the exact breakdown given in this list, and each organization can augment or expand this list to suit the project. If there are any subsequent changes, it is essential that the PMP is amended as soon as the changes become apparent, so that every member of the project team is immediately aware of the latest revision. These changes must be numbered on the amendment record in the beginning of the PMP, and annotated on the relevant page and clause with the same amendment number or letter.
The contents of the project management plan are neatly summarized in the first verse of the little poem from The Elephant’s Child by Rudyard Kipling:
I keep six honest serving-men
(They taught me all I knew);
Their names are What and Why and When,
And How and Where and Who.
Methods and Procedures
Methods and procedures are the very framework of project management and are necessary throughout the life cycle of the project. All the relevant procedures and processes are set out in the project management plan, where they are customized to suit the particular project.
Methods and procedures should be standardized within an organization to ensure that project managers do not employ their own pet methods or ‘reinvent the wheel’.
All the organization’s standard methods and procedures as well as some of the major systems and processes should be enshrined in a company project manual. This should then be read and signed by every project manager who will then be familiar with the company systems, and thus avoid wasteful and costly duplication. The main contents of such a manual are the methods and procedures covering:
• Company policy and mission statement
• Company organization and organization chart
• Accountability and responsibilities
• Estimating
• Risk analysis
• Cost control
• Planning and network analysis
• Earned value management
• Resource management
• Change management (change control)
• Configuration management
• Procurement (bid preparation, purchasing, expediting, inspection, shipping)
• Quality management and control
• Value management and value engineering
• Issue management
• Design standards
• Information management and document distribution
• Communication
• Health and safety
• Conflict management
• Close-out requirements and reviews
It will be seen that this list is very comprehensive, but in every case a large proportion of the documentation required can be standardized. There are always situations where a particular method or procedure has to be tailored to suit the circumstances or where a system has to be simplified, but the standards set out in the manual form a baseline that acts as a guide for any necessary modification.
Certain UK government departments, a number of local authorities and other public bodies have adopted a project management methodology called PRINCE 2 (an acronym for projects in a controlled environment). This was developed by the Central Computer and Telecommunications Agency (CCTA) for IT and government contracts, but has not found favour in the construction industry due to a number of differences in approach to reporting procedures, management responsibilities and assessing durations with respect to resources.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.