Project Management Processes
Project management is an integrative
endeavor—an action, or failure to take action, in one area will usually affect
other areas. The interactions may be straightforward and well understood, or
they may be subtle and uncertain. For example, a scope change will almost
always affect project cost, but it may or may not affect team morale or product
quality.
These interactions often require
tradeoffs among project objectives—performance in one area may be enhanced only
by sacrificing performance in another.
The specific performance tradeoffs
may vary from project to project and organization to organization. Successful
project management requires actively man- aging these interactions. Many
project management practitioners refer to the project triple constraint as a
framework for evaluating competing demands. The project triple constraint is
often depicted as a triangle where either the sides or corners represent one of
the parameters being managed by the project team.
To help in understanding the
integrative nature of project management, and to emphasize the importance of
integration, this document describes project management in terms of its
component processes and their interactions. This chapter provides an
introduction to the concept of project management as a number of interlinked
processes, and thus provides an essential foundation for understanding the
process descriptions in Chapters 4 through 12. It includes the following major
sections:
3.1 Project Processes
3.2 Process Groups
3.3 Process Interactions
3.4 Customizing Process Interactions
3.5 Mapping of Project Management
Processes\
3.1 PROJECT PROCESSES
Projects are composed of processes.
A process is “a series of actions bringing about a result” (1). Project
processes are performed by people and generally fall into one of two major
categories:
Project management processes
describe, organize, and complete the work of the project. The project
management processes that are applicable to most projects, most of the time,
are described briefly in this chapter and in detail in Chapters 4 through 12.
Product-oriented processes specify
and create the project’s product. Product-oriented processes are typically
defined by the project life cycle (discussed in Section 2.1) and vary by
application area (discussed in Appendix E).
Project management processes and
product-oriented processes overlap and interact throughout the
project. For example, the scope of the project cannot be defined in the absence
of some basic understanding of how to create the product.
3.2 PROCESS GROUPS
Project management processes can be
organized into five groups of one or more processes each: Initiating
processes—authorizing the project or phase.
Planning processes—defining and
refining objectives and selecting the best of the alternative courses of action
to attain the objectives that the project was undertaken to address. Executing
processes—coordinating people and other resources to carry out the plan.
Controlling processes—ensuring that
project objectives are met by monitoring and measuring progress
regularly to identify variances from plan so that corrective action can be
taken when necessary.
Closing processes—formalizing
acceptance of the project or phase and bringing it to an orderly end.
The process groups are linked by the
results they produce—the result or out- come of one often becomes an input to
another. Among the central process groups, the links are
iterated—planning provides executing with a documented project plan early on,
and then provides documented updates to the plan as the project progresses.
These connections are illustrated in Figure 3-1. In addition, the project
management process groups are not discrete, one-time events; they are
overlapping activities that occur at varying levels of intensity throughout
each phase of the project. Figure 3-2 illustrates how the process groups
overlap and vary within a phase.
Finally, the process group
interactions also cross phases such that closing one phase provides an input to
initiating the next. For example, closing a design phase requires customer
acceptance of the design document. Simultaneously, the design document defines
the product description for the ensuing implementation phase. This interaction
is illustrated in Figure 3-3. Repeating the initiation processes at the start
of each phase helps to keep the project focused on the business need
that it was undertaken to address. It should also help ensure that the project
is halted if the business need no longer exists, or if the project is unlikely
to satisfy that need. Business needs are discussed more detail in the
introduction to Section 5.1, Initiation.
It is important to note that the
actual inputs and outputs of the processes depend upon the phase in which they
are carried out. Although Figure 3-3 is drawn with discrete phases
and discrete processes, in an actual project there will be many overlaps. The
planning process, for example, must not only provide details
of the
work to be done to bring the current phase of the project to successful completion,
but must also provide some preliminary description of work to be done in later
phases. This progressive detailing of the project plan is often called rolling wave
planning , indicating that planning is an iterative and ongoing process. Involving
stakeholders in the project phases generally improves the probability of
satisfying customer requirements and realizes the buy-in or shared ownership of
the project by the stakeholders, which is often critical to project success.
3.3 PROCESS INTERACTIONS
Within each process group, the
individual processes are linked by their inputs and outputs. By focusing on
these links, we can describe each process in terms of its: Inputs—documents or
documentable items that will be acted upon.
Tools and techniques—mechanisms
applied to the inputs to create the outputs.
Outputs—documents or documentable
items that are a result of the process
The project management processes
common to most projects in most application areas are listed here and described
in detail in Chapters 4 through 12. The numbers in parentheses after the
process names identify the chapter and section where each is described. The
process interactions illustrated here are also typical of most projects in most
application areas. Section 3.4 discusses customizing both process descriptions
and interactions.
3.3.1 Initiating Processes
Figure 3-4 illustrates the single
process in this process group.
Initiation (5.1)—authorizing the
project or phase is part of project scope management.
3.3.2 Planning Processes
Planning is of major importance to a
project because the project involves doing something that has not been done
before. As a result, there are relatively more processes in this section.
However, the number of processes does not mean that project management is
primarily planning—the amount of planning performed should be commensurate with
the scope of the project and the usefulness of the information developed.
Planning is an ongoing effort throughout the life of the project.
The relationships among the project
planning processes are shown in Figure
3-5 (this chart is an explosion of
the ellipse labeled “Planning Processes” in Figure 3-1). These processes are
subject to frequent iterations prior to completing the project plan. For
example, if the initial completion date is unacceptable, project resources,
cost, or even scope may need to be redefined. In addition, planning is not an
exact science—two different teams could generate very different plans for the
same project.
Core processes. Some planning
processes have clear dependencies that require them to be performed in essentially the same order on most projects. For
example, activities must be defined before they can be scheduled or coasted.
These core planning processes may be iterated several times during any one phase
of a project. They include: Scope Planning (5.2)—developing
a written scope statement as the basis for future project decisions. Scope
Definition (5.3)—subdividing the major project deliverables into smaller more
manageable components. Activity Definition (6.1)—identifying the specific
activities that must be performed to produce the various project deliverables. Activity
Sequencing (6.2)—identifying and documenting interactivity dependencies.
Activity Duration Estimating (6.3)—estimating the number of work periods that
will be needed to complete individual activities. Schedule Development
(6.4)—analyzing activity sequences, activity durations and resource
requirements to create the project schedule. Risk Management Planning
(11.1)—deciding how to approach and plan for risk management in a project. Resource
Planning (7.1)—determining what resources (people, equipment, materials, etc.)
and what quantities of each should be used to perform project activities. Cost
Estimating (7.2)—developing an approximation (estimate) of the costs nof the
resources required to complete project activities. Cost Budgeting
(7.3)—allocating the overall cost estimate to individual work packages.
Project
Plan Development (4.1)—taking the results of other planning processes and
putting them into a consistent, coherent document Facilitating processes.
Interactions among the other planning processes are more dependent on the
nature of the project. For example, on some projects, there may be little or no
identifiable risk until after most of the planning has been done and the team
recognizes that the cost and schedule targets are extremely aggressive and thus
involve considerable risk. Although these facilitating processes are performed
intermittently and as needed during project planning, they are not optional.
They include: Quality Planning (8.1)—identifying which quality standards are
relevant to the project and determining how to satisfy them. Organizational
Planning (9.1)—identifying, documenting, and assigning project roles,
responsibilities, and reporting relationships. Staff Acquisition (9.2)—getting
the human resources needed assigned to and working on the project.
Communications Planning (10.1)—determining the information and communications
needs of the stakeholders: who needs what information, when will they need it,
and how will it be given to them. Risk Identification (11.2)—determining which
risks are likely to affect the project and documenting the characteristics of
each.
Qualitative
Risk Analysis (11.3)—performing a qualitative analysis of risks and conditions
to prioritize their effects on project objectives. Quantitative Risk Analysis
(11.4)—measuring the probability and impact of risks and estimating their implications
for project objectives. Risk Response Planning (11.5)—developing procedures and
techniques to enhance opportunities and to reduce threats to the project’s
objectives from risk.
Procurement
Planning (12.1)—determining what to procure, how much to procure, and when.
Solicitation
Planning (12.2)—documenting product requirements and identifying potential
sources.
3.3.3
Executing Processes
The
executing processes include core processes and facilitating processes. Figure
3-6
illustrates how the following core and facilitating processes interact:
Project
Plan Execution (4.2)—carrying out the project plan by performing the activities
included therein.
Quality Assurance (8.2)—evaluating overall project
performance on a regular basis to provide confidence that the project will
satisfy the relevant quality standards.
Team
Development (9.3)—developing individual and group skills/competencies to
enhance project performance.
Information
Distribution (10.2)—making needed information available to project stakeholders
in a timely manner.
Solicitation
(12.3)—obtaining quotations, bids, offers, or proposals as appropriate.
Source
Selection (12.4)—choosing from among potential sellers.
Contract
Administration (12.5)—managing the relationship with the seller.
3.3.4
Controlling Processes
Project
performance must be monitored and measured regularly to identify variances from
the plan. Variances are fed into the control processes in the various knowledge
areas. To the extent that significant variances are observed (i.e., those that
jeopardize the project objectives), adjustments to the plan are made by repeating
the appropriate project planning processes. For example, a missed activity
finish date may require adjustments to the current staffing plan overtime, or
tradeoffs between budget and schedule objectives. Controlling also includes
taking preventive action in anticipation of possible problems.
The
controlling process group contains core processes and facilitating processes.
Figure
3-7 illustrates how the following core and facilitating processes interact: Integrated
Change Control (4.3)—coordinating changes across the entire project. Scope
Verification (5.4)—formalizing acceptance of the project scope. Scope Change
Control (5.5)—controlling changes to project scope. Schedule Control (6.5)— controlling
changes to the project schedule. Cost Control (7.4)—controlling changes to the
project budget. Quality Control (8.3)—monitoring specific project results to
determine if they comply with relevant quality standards and identifying ways
to eliminate causes of unsatisfactory performance. Performance Reporting
(10.3)— collecting and disseminating performance information. This includes
status reporting, progress measurement, and forecasting.
Risk
Monitoring and Control (11.6)—keeping track of identified risks, monitoring
residual risks and identifying new risks, ensuring the execution of risk plans,
and evaluating their effectiveness in reducing risk.
3.3.5
Closing Processes
Figure
3-8 illustrates how the following core processes interact: Contract Closeout
(12.6)—completion and settlement of the contract, including resolution of any
open items.
Administrative
Closure (10.4)—generating, gathering, and disseminating information to
formalize phase or project completion, including evaluating the project and
compiling lessons learned for use in planning future projects or phases.
3.4 CUSTOMIZING PROCESS INTERACTIONS
The
processes and interactions in Section 3.3 meet the test of general
acceptance—they apply to most projects most of the time. However, not all of
the processes will be needed on all projects, and not all of the interactions
will apply to all projects. For example:
An
organization that makes extensive use of contractors may explicitly describe
where in the planning process each procurement process occurs.
The
absence of a process does not mean that it should not be performed. The project
management team should identify and manage all the processes that are needed to
ensure a successful project.
Projects
that are dependent on unique resources (commercial software development,
biopharmaceuticals, etc.) may define roles and responsibilities prior to scope
definition, since what can be done may be a function of who will be available
to do it. Some process outputs may be predefined as constraints. For example,
management may specify a target completion date, rather than allowing it to be
determined by the planning process. An imposed completion date may increase
project risk, add cost, and compromise quality. Larger projects may need
relatively more detail. For example, risk identification might be further
subdivided to focus separately on identifying cost risks, schedule risks,
technical risks, and quality risks.
On
subprojects and smaller projects, relatively little effort will be spent on
processes whose outputs have been defined at the project level (e.g., a
subcontractor may ignore risks explicitly assumed by the prime contractor), or
on processes that provide only marginal utility (e.g., there may be no formal
communications plan on a four-person project).
3.5 MAPPING OF PROJECT MANAGEMENT PROCESSES
Figure
3-9 reflects the mapping of the thirty-nine project management processes to the
five project management process groups of initiating, planning, executing,
controlling, and closing and the nine project management knowledge areas in
Chapters
4–12.
This
diagram is not meant to be exclusive, but to indicate generally where the
project management processes fit into both the project management process
groups and the project management knowledge areas.
