Project Management Ninth Edition doc

Project
Management
Ninth Edition
DENNIS LOCK
1
Introduction to Project
Management
P
roject management has evolved to plan, coordinate and control the complex and diverse
activities of modern industrial, commercial and management change and IT projects. All
projects share one common characteristic – the projection of ideas and activities into new
endeavours. The ever-present element of risk and uncertainty means that the events and tasks
leading to completion can never be foretold with absolute accuracy. Examples abound of projects
that have exceeded their costs by enormous amounts, nishing late or even being abandoned before
completion. Such failures are far too common, seen in all kinds of projects in industry, commerce
and (especially, it seems) the public sector.
The purpose of project management is to foresee or predict as many of the dangers and problems
as possible and to plan, organize and control activities so that projects are completed successfully
in spite of all the risks. This process should start well before any resource is committed, and must
continue until all work is nished. The primary aim of the project manager is for the result to satisfy
the project sponsor or purchaser and all the other principal stakeholders, within the promised
timescale and without using more money and other resources than those that were originally set
aside or budgeted.
BRIEF HISTORY OF PROJECT MANAGEMENT
Clearly, man-made projects are not new: monuments surviving from the earliest civilizations testify
to the incredible achievements of our forebears and still evoke our wonder and admiration. Modern
projects, for all their technological sophistication, are not necessarily greater in scale than some
of those early mammoth works. But economic pressures of the industrialized world, competition
between rival companies, and greater regard for the value, well-being and hence the employment
costs of working people have all contributed to the development of new project management ideas
and techniques. Figure 1.1 is a cursory, rather light-hearted romp through the history of project

management. It makes generalizations and the dates are approximate, but the story is interesting
and an appropriate introduction to the fascinating subject of project management. Those with the
time available to study an authoritative and comprehensive account of project management history
should read Morris (1994).
Projects from prehistory to Victorian times (before 1900)
Projects from ancient times have left impressive legacies on our architectural and industrial culture.
We wonder how some of those early masters managed without the technology that is readily and
cheaply available today. However, with the exception of a few notable philanthropic employers,
project management
2
concern for the welfare and safety of workers was generally lacking and many early project workers
actually lost their lives through injuries, disease and sheer physical exhaustion. People were often
regarded as a cheap and expendable resource.
Formal management organization structures have existed from early times, but these ourished
in military, church and civil administrations rather than in industry. Industrial organization came
much later. I have an organization chart showing a Chinese bridge-building team that is reputed to
date back to the Ming dynasty (1368–1644) but that was an army team.
Projects before 1900 were generally managed by the creative architects and engineers themselves.
Many of us are familiar with stories of the giants who ourished in the latter part of this historical
period; people such as Sir Christopher Wren (1632–1723), Thomas Telford (1757–1834) and
Isambard Kingdom Brunel (1806–59). You can read about Brunel in Vaughan (1991). There was no
separately recognized profession of project management. Commonsense, determination, hard work
(sometimes at the expense of neglecting personal health) usually got the job done. The time had
not yet come for the industrial engineers and behavioural scientists who would eventually study
working practices, organization theory and people at work.
Before 1900
Wonderful projects
People cheap, even expendable
Urgency not driven by the rat-race
Management organization structures

seen in the church and the military
No management scientists
No project management profession
•
•
•
•
•
•
1900 – 1949
Emergence of management
science
People begin to study work and
people at work
Henry Gantt introduces his famous
planning charts
Early development of critical path
networks
•
•
•
•
1950 – 1969
US defense projects exploit critical
path network analysis
Mainframe computers can run
project management software in
batch mode
Project management becomes a
recognized profession

More concern for people at work
•
•
•
•
1970 – 1979
Project management has two
meanings:
- industrial project management
- IT project management
Creation of professional associations
More project management software
Legislation for health and safety
Anti-discrimination laws introduced
•
•
•
•
•
1980 – 1989
Desktop computers can run powerful
project management software
Better graphics, with colour
Managers less dependent on IT
experts
Computers cannot now run arrow
networks and precedence becomes
the norm
•
•

•
•
1990 – 2000+
PCs and notebooks can run all
applications
More interest in project risk
IT and industrial project
management no longer considered
so differently
Project management is a respected
profession, with flourishing
associations
•
•
•
•
• Wider acceptance of
project management as
a profession
• Worldwide
communication by
satellite and the
Internet
Figure 1.1 Whistle-stop journey through project management history
introduction
3
1900 to 1949
Rapid industrialization and the demands of munitions production in World War 1 saw the emergence
of management scientists and industrial engineers such as Elton Mayo and Frederick Winslow Taylor,
who studied people and productivity in factories (Kanigel, 1997). Henry Ford made production-line

manufacture famous with his Model T automobile and, especially important for project managers,
Henry Gantt (1861-1919), who worked for Taylor, developed his now-famous charts which are still
popular and used universally today.
It is not generally appreciated that early examples of critical path networks were developed
before 1950, although their value was not widely appreciated at the time. Without the existence
of computers, they were inexible to change, tedious to translate into working schedules and
thus impracticable and difcult to use. Gantt’s bar charts were generally preferred, often set up on
proprietary charts that allowed rescheduling using movable magnetic or plug-in strips or cards.
Everything from the allocation of work to people and machines to holiday schedules was controlled
by charts, usually prominently displayed on ofce walls.
1950 to 1969
The emergence of mainframe digital computers made the processing and updating of critical path
networks faster and easier. The American defence industry and Du Pont were among the organizations
quick to exploit this powerful planning and scheduling tool in the 1950s. The manufacturing and
construction industries soon came to recognize the benets of these new methods.
Computers were large, extremely expensive, and required their own dedicated air-conditioned
clean rooms. Their capital and operating costs were beyond the budgets of all but the biggest
organizations, so that many planners in smaller companies bought their computing time from
bureaux, where project schedules were processed in batch mode. These bureau facilities were
provided both by computer manufacturers and by large companies whose computers had free time.
It was at this time that I cut my project management teeth, and I have fond memories of being
able to plan and control projects and programmes of multiple projects very successfully, although
processing time was measured in days rather than in today’s nanoseconds.
Project management became a recognized job description, if not yet a respected profession.
Companies were showing more concern for the welfare of people at work, although discrimination
because of race, sex and age was still too common. The year 1968 saw publication of the rst edition
of this book, at a time when most other publications dealt with planning and scheduling as separate
techniques rather than treating project management holistically as a management discipline.
1970 to 1979
This period saw rapid growth in information technology, or ‘IT’ (as it soon became known). Industrial

project management continued as before, but with more project management software available and
wider recognition of the role. However, the spread of IT brought another, different kind of project
manager on the scene. These were the IT project managers: people who had no project planning or
scheduling experience and no interest or desire to learn those methods. They possessed instead the
technical and mental skills needed to lead teams developing IT projects. These IT project managers
were usually senior systems analysts, and one of their characteristics was their scarcity. High demand
for their services led them to make frequent career jumps, moving rapidly up a generous salary scale.
Development of the professional project management associations grew during this period,
which also saw the development of legislation to protect workers’ health and safety. Other new laws
were intended to discourage unfair discrimination of people because of their race, religious beliefs
or sex.
project management
4
Although project management software became more widely available, processing continued
to be carried out on big expensive mainframe computers in batch mode. Graphics were primitive
compared with modern equipment. Data input was still accomplished by copying data from network
diagrams on to coding sheets from which cards had to be punched and veried, sometimes needing
two cards for every network activity. After sorting, these punched cards had to be taken to trained
computer operators, who worked in clean air-conditioned rooms where entry was usually forbidden
to project managers. The rst process results always seemed to produce a large pile of print-out
listing a crop of errors that needed considerable detective work before the faults could be identied,
and then corrected by punching several new cards before the computer could produce its practical
working schedules.
All the output reports in those early computing days came as text from line printers, so that
graphics such as bar charts were crudely formed from patterns of alphanumeric characters. Yet
the process was stimulating, exciting and fun. We had our mishaps, for example when over 2000
pre-sorted punched cards were accidentally scattered over the oor of the London taxicab that
was transporting them to the computer bureau. But we got our schedules calculated, managed our
projects and enjoyed ourselves in the process.
1980 to 1989

During this decade project managers became far less dependent upon IT experts. They now had their
own desktop computers that could run most project management software. Graphics were greatly
improved, with smaller printers available locally in the ofce that could produce complex charts in
many colours. However, productivity did not match this growth in technology as quickly as one
might have expected because managers became more interested in the technology itself than in
the work that it was intended to manage. People were frequently seen grouped round each other’s
screens asking questions such as ‘What happens if you do this?’ and ‘Have you tried that?’ or ‘Why
has it crashed and lost all my data?’ In other words, managers had to learn to become ‘computer
literate’ and be far less dependent on IT experts.
Software that could run activity-on-arrow networks became obsolete. All planners have since
had to use activity-on-node (precedence) networks in their computers and adapt to the relatively
small areas of network visible on the small screen. However, processing times were cut dramatically,
so that schedules could be up and running much faster for new projects. Schedules could now be
updated almost immediately from the planner’s own keyboard to cope with progress information
and project changes.
1990 to the present day
Practically all software suppliers recognized the need to make their products compatible with
Microsoft Windows. Microsoft themselves introduced Microsoft Project into their Ofce suite of
programs. One or two operating and plotting faults in very early versions of Microsoft Project were
eliminated in later versions, and the program is now by far the most widely used, especially among
students who appreciate its user-friendly features (www.microsoft.com/ofce/project). However,
many professionals continue to use programs at the high end of the software market, preferring
their greater power, versatility and adaptability for particular project applications.
Project risk is taken seriously and people pay more attention to predicting risk events so that
contingencies and risk mitigation strategies can be planned.
Of immense importance is the power of communication made possible by satellites and the
Internet, effectively shrinking the world and making it possible to transmit drawings, reports and
other documents almost instantaneously to almost anywhere.
introduction
5

Project management is no longer considered as two separate branches (one for industrial projects
and another for IT projects). There is wider and welcome acceptance that managing company
changes as projects can bring faster and better results.
Many good books dealing comprehensively with all aspects of project management (except
purchasing) are now available in most languages, and there is no shortage of training courses.
Well-regarded professional qualications awarded by universities, management schools and the
professional organizations can be gained by those who follow the appropriate training and can
demonstrate competence. With this wealth of knowledge and experience we might ask why so many
modern projects fail so dramatically. Eurotunnel, for example, operates at the time of writing with
an unmanageable debt burden exceeding £6.5 billion. The new Wembley Stadium project nished
late and cost twice its original budget. Government IT projects are not exempt from spectacular
failure. We hear of projects that suffer ‘soaring costs’, yet the UK annual cost ination is at the very
low rate of around 2 per cent.
In spite of the failures, we should be proud of the many successful modern projects, in aviation,
aerospace, construction, medicine and all other branches of human industry. Apart from the threat
of hostilities and terrorism, it seems certain that climate change and the exhaustion of natural
fossil fuel resources will provide the biggest challenges in the future. We shall need effective project
managers to deal with these challenges if humankind is to survive.
DIFFERENT TYPES OF PROJECTS
The principal identifying characteristic of a project is its novelty. It is a step into the unknown,
fraught with risk and uncertainty. No two projects are ever exactly alike: even a repeated project will
differ from its predecessor in one or more commercial, administrative or physical aspects. However,
I have found it possible and convenient to classify projects as four different general types. These are
shown in Figure 1.2.
Figure 1.2 Four project types
project management
6
Type 1 projects: civil engineering, construction, petrochemical, mining
and quarrying
Projects in this category are those which spring most readily to mind whenever industrial projects are

mentioned. One common feature is that the actual work (the fullment phase) must be conducted
on a site that is exposed to the elements, and usually remote from the contractor’s head ofce. As
such they are often open to the public gaze.
These projects incur special risks and problems of organization. They may require massive capital
investment, and they deserve (but do not always get) rigorous management of progress, nance and
quality. Operations are often hazardous so that health and safety aspects demand special attention,
particularly in heavy work such as construction, tunnelling and mining.
For very large industrial projects the funding and resources needed can be too great for one
contractor to risk or even nd. The organization and communications are therefore likely to be
complicated by the participation of many different specialists and contractors, possibly with the
main players acting together through a consortium or joint venture company established specically
for the project.
Type 2 projects: manufacturing
Manufacturing projects result in the production of a piece of mechanical or electronic equipment, a
machine, ship, aircraft, land vehicle, or some other product or item of specially designed hardware.
The nished product might be purpose-built for a single customer but internal research and
development projects for products to be sold in all market sectors also fall into this manufacturing
category.
Manufacturing projects are usually conducted in a laboratory, factory or other home-based
environment, where the company should easily be able to exercise on-the-spot management and
provide an optimum environment in which to do and manage the work. Of course, these ideal
conditions do not always apply. Some manufacturing projects involve work away from the home
base, for example in installing and commissioning a machine or equipment on a customer’s premises,
customer training and post-project service and maintenance.
More difcult is the case of a complex product that is developed and manufactured by a
consortium of companies, sometimes with members based in different countries. A common example
is aircraft production, where the engines might be developed and manufactured in one country,
the wings in another and the nal assembly taking place in a third country. Such international
manufacturing projects are prone to higher risk and difculties in control and coordination arising
through organizational complexity, national rivalries, contracts, long-distance communications,

multiple languages and conicting technical standards.
Type 3 projects: IT projects and projects associated with management
change
This class of project proves the point that every company, whatever its size, can expect to need
project management expertise at least once in its lifetime. These are the projects that arise when
companies relocate their headquarters, develop and introduce a new computer system, launch a
marketing campaign, prepare for a trade exhibition, produce a feasibility or other study report,
restructure the organization, mount a stage show, or generally engage in any operation that involves
the management and coordination of activities to produce an end result that is not identiable
principally as an item of hardware or construction.
introduction
7
Not all projects are conducted commercially or for prot. Most not-for-prot organizations,
including national and local government departments, professional associations, charities and
disaster relief agencies conduct projects that fall into this category of management projects.
Although management projects do not usually result in a visible, tangible creation such as a
piece of hardware, much often depends on their successful outcome and they can require enormous
investment. There are several well-known cases where, for instance, failure to implement a new
computer system correctly has caused serious operational breakdown, exposing the managers
responsible to public discredit. Effective project management is at least as important for these
projects as it is for the largest construction or manufacturing project.
Type 3 projects may be associated with or even depend upon Type 1 or Type 2 projects. For
example, if a company decides to relocate to a new, purpose-built ofce, the overall relocation
project is itself a Type 3 management project but its success will depend also on the Type 1 project
needed to construct the new building. Thus projects of different types may be associated with each
other in a company’s project programme or project portfolio.
Type 4 projects: projects for pure scientic research
Pure scientic research projects (not to be confused with research and development projects) are
truly a special case. They occasionally result in dramatically protable discoveries. On the other
hand, they can consume vast amounts of money over many years, yet yield no practical or economic

result. Research projects carry the highest risk because they attempt to extend the boundaries of
current human knowledge. The project objectives are usually difcult or impossible to dene and
there may be no awareness of the possible outcome. Therefore, pure research projects are not usually
amenable to the project management methods that can be applied to industrial, manufacturing or
management projects.
Some form of control over pure research projects must, however, be attempted. Money and
other resources cannot be spent without any form of monitoring or restraint. Budgets have to be set
in line with available funding.
A sensible method for controlling a pure scientic research project is to conduct regular
management reviews and reassessments of the potential value of the project. At each of these reviews,
a decision can be taken to stop the project (known colloquially as pulling the plug) or release new
funding to allow it to continue at least until the next review. Although this can be unsettling for the
scientists involved, the project sponsor is not expected to pour money for ever into a vast hole. This
procedure, where continued project funding is dependent upon the outcome of regular reviews, is
known as stage-gate control.
Although the research activities might themselves lie outside the scope of familiar project
management methods, the provision of accommodation, communications, equipment and research
materials might well constitute Type 1, 2 or 3 capital investment projects to which proper project
management can and must be applied.
PROJECT LIFE CYCLES AND LIFE HISTORIES
Some projects come into being gradually, and others fade out slowly, so that their precise beginning
and end dates can be difcult to recognize. However, most projects have not only actual beginning
and end dates but also one or more signicant dates between these can be identied as key events
or ‘milestones’.
The period between the beginning and end of a project is usually referred to as the project life
cycle. It is convenient and necessary here to introduce three key players in the project life cycle:
project management
8
The customer (in some projects known as the client) is the person or organization that
wants to buy the project and put the end product to use in its own business or sell (or lease)

it on to a third party.
The contractor is the organization principally responsible to the customer for carrying out
the project work.
The project manager is a person employed by the contractor (or occasionally by the customer)
to plan and manage all the project activities so that the project is nished on time, within
budget and within its specication.
These denitions do not apply strictly to all projects, but they are adequate for the purposes of
this introductory chapter. In a Type 3 management project, the customer and the contractor might
reside within the same company, so that the company’s executives (who represent the customer in
this case) instruct a departmental manager (the contractor) to carry out a project for the company’s
own use. However, such complexities can be disregarded for the moment: organization patterns and
roles will be discussed more exhaustively in Chapters 9, 10 and 11.
Life cycle of small projects
Consider, rst, the typical life cycle of small projects: projects that have relatively short duration,
do not involve large amounts of capital expenditure and are relatively straightforward to manage.
Most authorities and writers, when they talk about the life cycle of a project, refer to the period that
begins with the authorization of work on the project (or signing of a customer-contractor contract)
up to the handover of the desired product to the customer. This can be a view that is too simplistic,
but it is the part of projects that is of most concern to their project managers. Figure 1.3 shows that
the activities which take place during this period do form a true cycle, because they begin and end
with the customer.
Travelling clockwise round the cycle reveals a number of steps or phases, each of which is
represented by a circle in the diagram. The boundaries between these phases are usually blurred in
•
•
•
Figure 1.3 Project life cycle
introduction
9
practice, because the phases tend to overlap. For example, some project purchasing and fullment

work can usually start before well before design is complete.
This view of a project life cycle is, in very many cases, too simplistic because it ignores everything
that happens before the start of actual work, and also takes no account of what happens to the
project after its delivery to the customer. For a more complete picture, we really have to consider
not only the project life cycle as seen by the project manager, but also the entire life history of the
project from its conception to death and disposal.
More comprehensive view of the project life cycle or history
The simple life cycle shown in Figure 1.3 holds good for small, relatively simple projects but for most
capital projects many more phases can usually be identied. For example, the six phases of Figure
1.3 have grown to 15 separately identiable phases in Figure 1.4, which represents the life history
of a fairly large capital project. Projects differ so greatly that there is no such thing as a typical life
history pattern but the sequence in Figure 1.4 is broadly applicable to capital projects that involve
many stakeholders and public interests (stakeholders are discussed in Chapter 2).
Figure 1.4 More comprehensive view of a project life history
project management
10
Explanation of the life history phases
The upper portion of Figure 1.4 is a Gantt chart setting out the phases of a large capital project
against the total life history timescale (for more on Gantt charts see Chapter 14). In this case, the
total period spanned by the project is about 27.5 years, but remember that this is only an example:
actual cases might be anything from one or two years to several decades.
All projects begin as a concept, a gleam in the eye of their progenitor. An entrepreneur or
organization recognizes the need for a project and forms an initial idea that justies further
investigation. Phases 1 to 4 comprise this formative period, which should end in proposals and a
business plan that describes the project, sets out the nancial requirements, the intended benets
and the principal milestones. Taken together, these early phases form the initial project denition.
Projects in the public eye, or which have signicant potential environmental or social impact,
might have to be subjected to one or more public enquiries and prolonged planning applications
(Phase 5), which can seriously delay or even prevent the start of the actual project.
Once everyone has agreed the project denition, all permissions have been granted, and the

funds are available, the project can be authorized (Phase 6). Authorization should really be almost
an instantaneous event or milestone rather that a time-consuming phase, but some organizations
are very cautious about this process and can drag their feet for several months before agreeing to
release the funds and other resources required for the project to start.
When the project has been authorized, the organization has to be put in place. This is Phase 7
in our example and, together with Phase 8, constitutes the project start-up period. Phase 7 includes
the appointment of the project manager and the setting aside or provision of ofce space and other
accommodation. Only then can real work on the project start, which is signalled by the project
manager arranging for detailed planning and mobilization of the workforce (Phase 8).
Phases 9, 10 and 11 cover the overlapping periods of design, procurement and manufacture or
construction (or, for Type 3 projects, management change). The project is nished when it is handed
over to the customer to be put into operational use (Phase 13) but this cannot usually be done before
the contractor has carried out commissioning and tests or trials (Phase 12) to ensure that the project
will be t for its intended purpose.
Many project management publications limit their account of the project life cycle or life history
to Phases 6 through 13. The reason for this is that these are the phases that most directly involve
the control of the project manager, who might not actually come on to the scene until Phase 6 or 7.
They constitute the most active or fullment period of the project life history and can be compared
loosely with the life cycle in Figure 1.3.
Another glance at Figure 1.4 shows that our version of the project life history not only begins
much earlier than some published versions, but also does not nish until very much later, when the
outcome of the original project has come to the end of its useful economic life and is scrapped or
otherwise disposed of.
Expenditure in relation to the project life history
The graph in the lower portion of Figure 1.4 sets out a pattern of expenditure that might be expected
throughout the life history of a project. It is drawn on the same timescale as the Gantt chart above
and indicates general patterns of expenditure rather than actual monetary levels (since total costs
obviously vary enormously between different projects).
Some expenditure must be made by the project owner or sponsor during the formative, denition
phases. In our example I have shown this expenditure to be at a modest level but some projects

require considerable investigation before they can actually start. A feasibility study costing many
millions of pounds might have to be commissioned to explore the risks, benets and best strategy
introduction
11
for the proposed project. Public enquiries and wrangling over the specication can delay the project
start and soak up yet more money. The new Wembley Stadium project, for example, underwent a
prolonged denition period that consumed some of the time and money that had originally been set
aside for the actual construction. Some large projects might even be preceded by pilot projects that
themselves demand substantial investment.
The portion of the expenditure curve drawn with a bold line corresponds to the project fullment
period when the project manager is actively involved. Almost all the money spent during this time
should be built into the real project, to add value as well as cost. This is one area of the life history
where we can be reasonably condent that the pattern will be similar from one project to the next.
Expenditure usually builds up very slowly as people are gradually assigned to work on the project,
with only a relatively few staff involved in the early stages to carry out initial design and planning.
Later, as working drawings or specications begin to emerge from the designers or technologists,
money has to be committed in buying materials and equipment so that the main workforce can be
engaged to use these purchases to full the project. Nearer the end of the fullment phase (Phase 11
in our example) most purchasing costs are over, and people begin to leave the workforce, so that the
rate of expenditure falls. This expenditure pattern (although not the vertical scale) can be claimed
as typical of most projects and is commonly known as the S-curve. It is the time when the project
manager has most direct inuence over control of the project’s capital costs.
Phase 14 marks the end of expenditure on the project’s capital cost and the project moves
into a completely different mode. This is the useful operating life of the project, when all the
expenditure involved is incurred by the project customer (the project owner) in operating,
maintenance, repairs and consumable materials. This is the period, for example, during which
a building can be occupied, an IT system remains accurate and efcient, a special machine
continues to perform its designed task, a mine or quarry produces minerals on an economic scale
or a drug continues to be dispensed to patients before a new, improved drug is developed by the
pharmaceutical industry.

When the project nears the end of its economic life, either the owner has no further use for it
or the costs of operating, maintenance and repair begin to rise to uneconomic proportions. So the
time comes to dispose of the project. In the case of a building this might be centuries after it was
originally built, with ownership having been transferred many times as different occupants come
and go. On the other hand, a modern high technology project might be rendered obsolete after
only a few years of successful operation. In some cases the redundant project can be sold on to a
third party for scrap, yielding a small cash inow. At the other extreme, disposal costs for a nuclear
power generating station can rival or even exceed the original capital costs, owing to difculties in
handling and storing materials that are dangerously radioactive. For that reason, I have shown a
question mark at the end of the project life history costs, because the disposal costs (or cash returns)
are so very different from one project to the next.
Chapters of this book in relation to the project life history
Figure 1.5 sets out the life history of a large project again, but this time it is presented as a ow
chart instead of the Gantt chart seen in Figure 1.4. A ow chart such as this is an elementary
form of the activity-on-node network planning method described in Chapter 15. In practice the
sequence can be slightly more complicated because some tasks have to be repeated at different
stages in the life of the project as more detailed information becomes available. For example, cost
estimating (Chapter 4) requires a simple version of the coded work breakdown structures that must
be developed later in the project (described in Chapters 12 and 13). However, Figure 1.5 shows that
the chapters in this book have been arranged as far as possible in line with the life history phases
of a large project.
project management
12
CUSTOMERS, CLIENTS, CONTRACTORS AND END USERS
Throughout this book I have used the following expressions to represent the three principal parties
in a project contract:
Customer – the person or organization for which the project is being conducted. I have also
used the terms client and project owner in this context, although these are not always true
synonyms. The project customer is traditionally a person or organization that pays another
organization money in return for a project. However, in many management change

projects the company is, in effect, both customer and contractor, with the board or senior
management of the company acting as the customer, whilst the manager or department
instructed to carry out the project assumes the role of contractor.
Contractor – the organization that is principally responsible for executing the project work
to the customer’s requirements. I have not restricted this term to its more common use
(in the contracting industry for construction projects). So, again purely for convenience, I
use the term contractor in my text to describe any organization or group that carries out a
project, whether or not the project is carried out against a formal sales contract. I use this
term, for example, in the context of manufacturing projects, for projects in the not-for-
prot sector and for management change projects.
End user – the individual or organization that will ultimately own and operate the project. This
is not always the same person or organization that paid for the original project. Consider, for
example, a research and development project carried out by the Whitewash Company PLC to
develop washing machines for sale in the retail sector. The customer for this project would be
Whitewash PLC, the main contractor would be the design engineering department of Whitewash
PLC, and members of the public who bought the machines would be the end users.
•
•
•
Figure 1.5 Demonstration of how the chapters in this book broadly follow a project life
history
introduction
13
Projects are very diverse in their natures and the common notion that every project is carried
out by one organization or contractor for one customer is really too simplistic. Figure 1.6 gives a
taste of this diversity, with examples given for each of the four project types identied earlier in this
chapter. For convenience and simplicity, however, I have conned most of the illustrations and case
studies throughout this book to the simple customer-contractor relationship.
ASSOCIATIONS REPRESENTING THE PROFESSION OF
PROJECT MANAGEMENT

International Project Management Association (IPMA)
The profession of project management is represented by the International Project Management
Association. Originally known by the initials INTERNET, the Association was eventually forced to
switch to the abbreviation IPMA, for very obvious reasons.
Figure 1.6 Examples of project relationships
A few simplied examples to illustrate that project relationships can extend well beyond the boundaries of customer and
contractor.
project management
14
Association for Project Management (APM)
The corporate member of the IPMA in the UK is the Association for Project Management (APM) and
further information is available from their secretariat at:
Association for Project Management
150 West Wycombe Road
High Wycombe
Buckinghamshire, HP12 3AE
Telephone: 0845 458 1944; Email: ; Website: www.apm.org.uk
APM arranges seminars and meetings through a network of local branches and, ten times year,
publishes the journal Project. It also produces other publications, foremost among which is its APM
Body of Knowledge. Personal or corporate membership of APM is an excellent way for project managers
and all others involved in project management to meet and to maintain current awareness of all
aspects of project management.
Membership starts at student level and rises through various grades to full member (MAPM) and
fellow (FAPM). APM’s basic professional qualication, which depends on suitable experience and
written examinations, is APMP. This qualication recognizes an individual’s baseline knowledge
and experience in project management. It is regarded by APM as the benchmark qualication in the
project management profession and is the rst step towards certication.
APM has a well-established certication procedure for project managers, who must already be full
members. To quote from APM’s own literature, ‘the certicated project manager is at the pinnacle of
the profession, possessing extensive knowledge and having carried responsibility for the delivery of

at least one signicant project’. As evidence of competence, certication has obvious advantages for
the project manager, and will increasingly be demanded as mandatory by some project purchasers.
Certication provides employers with a useful measure when recruiting or assessing staff and the
company that can claim to employ certicated project managers will benet from an enhanced
professional image. Certication has relevance also for project clients. It helps them to assess a
project manager’s competence by providing clear proof that the individual concerned has gained
peer recognition of their ability to manage projects.
Project Management Institute (PMI)
Founded in the US in 1969, PMI is the world’s leading not-for-prot organization for individuals
around the globe who work in, or are interested in, project management. PMI develops recognized
standards, not least of which is the widely respected project management body of knowledge guide,
commonly known by its abbreviated title the PMBOK Guide.
PMI publications include the monthly professional magazine PM Network, the monthly newsletter
PMI Today and the quarterly Project Management Journal. In addition to its many research and
education activities, PMI is dedicated to developing and maintaining a rigorous, examination-based
professional certication program to advance the project management profession and recognize
the achievements of individual professionals. PMI claims that its Project Management Professional
(PMP) certication is the world’s most recognized professional credential for project management
practitioners and others in the profession. For more information, contact PMI at:
PMI Headquarters
Four Campus Boulevard
Newtown Square
PA 19073-3299, USA
Telephone: +610-356-4600; Email: ; Website: www.pmi.org
introduction
15
REFERENCES AND FURTHER READING
APM (2006), APM Body of Knowledge, 5th Edition (High Wycombe: Association for Project
Management) (also available on CD-ROM).
Barnes, M. (2002), A Long Term View of Project Management – Its Past and its Likely Future, Keynote

speech to the IPMA 16th World Congress on Project Management, Berlin.
Kanigel, R. (1997), The One Best Way: Frederick Winslow Taylor and the Enigma of Efciency (London:
Little, Brown and Company).
Morris, P. (1994), The Management of Projects (London, Thomas Telford).
PMI (2004), A Guide to the Project Management Body of Knowledge, 3rd Edition (Newtown Square, PA:
Project Management Institute).
Vaughan, A. (1991), Isambard Kingdom Brunel: Engineering Knight-Errant (Cambridge: Cambridge
University Press).