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.
No comments:
Post a Comment