Project Management Bodies of Knowledge

E.I Introduction

The standards and guidelines we have looked at in the preceding appendixes have, to a greater or lesser extent, concentrated on procedure - the actions to he taken in specified circumstances. As we have noted before, one way of looking at the software development process is as an information system in its own right: processes take information from various sources, then manipulate and process it to create new information products that are used by other processes. It is clearly in the interests of the managers of a project, especially a larger one, to ensure that this is done in an accurate and structured way and standards such as ISO 12207 and PRINCE 2 focus on this aspect.

Correct procedure needs to be supported by professional competence. Administratively, a procedure can be carried out correctly so that the correct documents have been completed recording the decisions made, but if the project manager is not competent, the decision that has been conscientiously recorded can still be misjudged and damaging. Competence will stem partly from the innate ability of practitioners, their use of past experience and formal learning. In this Appendix, we are going to look at some attempts that have been made to define what knowledge and skills the good project manager should have. In the examples we will look at. this has been done in order to form the basis for some kind of practitioner certification. This will be of some assistance to readers who arc considering acquiring a formal qualification in project management.

The reader should be warned that the information given in this appendix is very much subject to change. We know of at least two cases (APM and ISEB) where particular bodies of knowledge are under review and will certainly be revised. Readers are directed to our website at where we will endeavour to keep details up to date.

As noted in Appendix A. it is possible to be assessed as a PRINCE 2 practitioner - we have treated this as a specialized qualification in a particular technique rather than a general PM qualification.

E.2 Project Management Institute

William R. Duncan s Developing a project-management body-of-knowledge: the US Project Management Institute's approach 1983-94" in the International Journal ot Protect Management 13(2) pp89-94.

The Project Management Institute (PMI) was founded in 1969 in the United States and currently has a membership in the region of 34,000 members world-wide. In 1983 it published a 'Project Management Body of Knowledge* (PMBOK). Since then the PMBOK has been extensively revised and expanded - it now totals over 150 pages with appendixes - so that the 19% release, which has the more realistic title of 'A guide to the Project Management Body of Knowledge' is a mature product. One enormous advantage that it possesses is that it is possible to download it over the World Wide Web from the PMI site.

The document is based on the concept of there being bodies of knowledge upon which various professions, such as medicine or law. base their practice. The PMBOK is an attempt to delineate such a body of knowledge for the project management professional. Clearly this could be an enormous undertaking and the PMI has tried to make it more manageable by attempting only that subset which is generally accepted. Even with this restriction, the potential scope is extensive and the fact that the document cannot hope to be all-inclusive is reflected in the word 'guide' in the title.

The objectives of the PMI in producing the PMBOK have been to:

• identify generally accepted project management practice;

• produce a basic reference document:

• identify a common set of terms;

• act as a basis for training and accreditation.

The compilers of the body of knowledge have therefore had to draw the body of 'project management' with some care. On the one hand, there are general management principles and practice, some aspects of which have a bearing on projects while others do not. On the other hand, there are other aspects of project management which are only relevant to some technical applications. An example of this would be software project management where some material is peculiar to software development, for example the use of function points for effort estimation.

The starting point of PMBOK is a definition of a project as 'a temporary endeavour undertaken to create a unique product or service* and of project management as 'the application of knowledge, skills, tools and techniques to project activities in order to meet or exceed stakeholder needs and expectations from a project*. This last definition seems to us to be a little too w idely drawn as one can imagine technical activities that could fall within this definition.

The PMBOK is organized into nine key knowledge areas, which have further subdivisions as shown in Table E.I. Notice how every topic section name is prefixed by 'project' to make clear that, for example, 'human resources management* does not cover all the topics that might come under that heading -only those that relate specifically to project management

The compilers of PMBOK have experienced the same problem that we experienced in structuring this book: the same subject topic can apply to several

Table K. I PMBOK contents



Project integration management

Project plan development

Project plan execution

Overall change control

Project scope management


Scope planning

Scope definition

Scope verification

Scope change control

Project time management

Activity definition

Activity sequencing

Activity duration estimating

Schedule development

Schedule control

Project cost management

Resource planning

Cost estimating

Cost budgeting

Cost control

Project quality management

Quality planning

Quality assurance

Quality control

Project human resource management

Organizational planning

Staff acquisition

Team development

Project communications management

Communications planning

Information distribution

Performance reporting

Administrative closure

Project risk management

Risk identification

Risk quantification

Risk response development

Risk response control

Project procurement management

Procurement planning

Solicitation planning


Source selection

Contract administration

Contract close-out

points of (he project life cycle. This means that the time sequence of concerns that a project manager has while planning and executing a project does not map neatly onto the organization of the subject matter. For example, risk management as a set of techniques will be exercised in several places throughout the progress of the project.

The problem has been tackled in PMBOK by identifying a set of processes for each phase of a project. A 'process* is defined as 'a set of actions bringing about a result'. Five groups of process have been identified: initiating; planning; executing; controlling; closing.

Within each group there are core processes. These are often inter-connected so that the output from one process is input by others. In common with most of the approaches that have been discussed in previous appendixes, there are a number of supporting processes (or facilitating processes in PMBOK terminology) such as quality planning and risk identification.

For each of the processes, PMBOK defines inputs, techniques that may be used and outputs.

This might seem to be similar to the way PRINCE 2 is organized, but such a comparison would be misleading, as the PMBOK describes the components of processes at a much higher and more abstract level.

In our view. PMBOK represents a remarkable achievement and has the great merit of being freely available via the PMI Web site. Inevitably, it is possible to disagree over some of the details, but that would be the case with any 'body of knowledge'. Our only real reservation (and perhaps this is because we come from an academic background) is the lack of supporting references to the authoritative works upon which a body of knowledge is based. This seems to be particularly a shame as the document does refer to itself as a 'guide' which, it might have been assumed, would mean that it directs readers to relevant material. Mark Becker. 'The time of The PMI administer a certification examination (which it is possible to sit. not the project manager'. only in the US. but also in the UK). Once the written examination has been passed.

Project Manager Today. candidates may apply to be assessed for full 'Project Management Professional* January 1998 (PMP) status. However in 1998 it was reported that because of the strict practical experience requirements and the stringent assessment process, the growth in members achieving full PMP status has not been high compared to those taking the examination.

The address of the PMI in the United States is:

Project Management Institute

130 South State Road

Upper Darby

PA 19082

T he PMI have a website at There are some chapters of the PMI outside the USA. including in the UK. but local contact points are best obtained from the PMI centre (or our website at hughes).

E.3 Australian Institute of Project Management

The roots of the Australian Institute of Project Management go back to the establishment of a Project Managers' Forum in Sydney. New South Wales, in 1976. In 1989. the organization was transformed into the Australian Institute of Project Management which, among other activities to support the professionalism of project management has undertaken the certification of competent project managers and the accreditation of project management courses.

The organization has developed sets of competency standards to support the certification of project managers which are recognized as the Australian national standards. These are generic so that they are not necessarily appropriate for direct use in all industries. An industrial sector or indiv idual enterprise may establish their own standards suitable for their own environment, but these must Inconsistent with and as least as rigorous as the generic standard.

The AIPM has adopted a definition of a project as 'a unique set of inter-related activities, with defined start and finish times, designed to achieve a common objective*. Project management is defined as 'the integration of project activity through the project life cycle to achieve the deliv ery of a defined product or service within prescribed constraints of time, budget, scope and quality'. The nine functions where competence needs to be shown are:

1. integration of project activities;

2. project scope management;

3. project quality management;

4. project time management;

5. project cost management;

6. project risk management:

7. project human resources management:

8. project contracting/procurement management;

9. project communications management.

The Australian Institute of Project Management are the custodians of the Australian National Competency Standards for Pmject Management. This has a structure similar to the NVQ/SVQ qualification in the United Kingdom (described later in this appendix).

T he documentation for these standards is available via the world wide web and is of outstanding quality.

Enquiries can be addressed to: The Secretary

Australian Institute of Project Management PO Box 83


See Alan Stretton: Australian competency standards' in International Journal of Projet Management. 13(2) pp119-123.

How To Accomplish More In A Fraction Of The Time

How To Accomplish More In A Fraction Of The Time

The pace and intensity of our lives, both at work and at home, leave several of us feeling like a person riding a frantically galloping horse. Our day-to-day incessant busyness too much to do and not enough time; the pressure to produce and check off items on our to-do list by each day’s end seems to decide the direction and quality of our existence for us.

Get My Free Ebook

Post a comment