The process of project management

PROJECT MANAGEMENT JOURNAL

Number 3 September 1993 Volume XXIV

INTRODUCTION

This is the second in a series of articles being developed under the auspices of the PMI Standards Committee to generate discussion about project management standards in general and the Project Management Body of Knowledge (PMBOK) document in particular. The first article (Project Management Journal, June 1993) discussed the rationale behind the major changes being made to the PMBOK document. This article provides a detailed look at one of those changes— the restructuring of the eight knowledge areas into their component processes. It includes two sections from the most recent draft (version 2.1):

• The entire text of Chapter 3, which introduces the concept of project management processes and process interactions. It is at the core of the proposed update since it defines a structure for doing project management as well as a lexicon for talking about it.

• A sample process description to help readers understand how the knowledge areas are being restructured.

UPDATING THE PMBOK DOCUMENT

In the spring of 1991, the PMI Standards Committee began work on an update to the 1987 version of the Project Management Body of Knowledge (PMBOK) document. One of the major objectives of the update was to present the eight knowledge areas in a more consistent fashion. After careful consideration of many alternatives, the Committee decided to describe the knowledge areas in terms of their component processes.

One of the key factors in this decision was the opportunity to emphasize the integrative nature of project management by explicitly defining how the various processes interact with one another. Chapter 3 of the proposed update is entitled “The Process of Project Management” and introduces the concept of project management processes and process interactions. This article consists primarily of the most recent draft of Chapter 3.

We hope that this approach will be as successful in guiding standards development over the next ten years as the Ethics, Standards and Accreditation Report (Project Management Quarterly, August 1983) has been for the past ten. Your comments are both welcome and requested:

William R. Duncan

Duncan. Nevison

114 Waltham Street

Lexington, MA 02173-5409

FAX (617) 861-2006

Draft PMBOK Document Update – Chapter 3

The process of project management is an integrative one—an action (or failure to take action) in one area will usually affect other areas. For example, a scope change will almost always affect cost and schedule estimates, but it may also have an impact on other factors as diverse as team morale and product quality. These interactions often require trade-offs among project objectives— performance in one area may be enhanced only by sacrificing performance in another. Successful project management requires actively managing these interactions.

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.

3.1 BASIC PROJECT MANAGEMENT PROCESSES

Most management models identify three basic management processes that serve to organize the ongoing activity of the enterprise:

• Planning-devising a workable scheme to accomplish an objective

• Executing-carrying out the plan

• Controlling—measuring progress and taking corrective action when necessary

These processes occur at all levels of the enterprise, in many different forms, and under many different names. For example, planning is a constant, not a onetime event.

. A senior manager may develop a strategic plan that looks out 5-10 years, or a crisis response plan that addresses 5-10 days.

. A line manager may develop an organization plan and execute it with the aid of an annual staffing plan.

. Major corrective action may require a plan of its own.

Although there are many variations on this basic model, all view management as an ongoing activity with neither a clear beginning nor an expected end (except as an event to be avoided). Projects, however, are temporary; they have both an identifiable starting point and an emphasis on timely future termination. Projects thus include two additional basic management processes:

• Initiating—setting overall project direction and defining project objectives

• Closing—formalizing acceptance of the product of the project and bringing the project itself to an end

These additional processes also occur at all levels of the project, in many different forms, and under many different names. For example, the initiating process may be called feasibility analysis while the closing process may be called turnover or start-up.

Basic Project Management Processes

Figure 3.1. Basic Project Management Processes

Basic Project Management Processes Over Time

Figure 3.2. Basic Project Management Processes Over Time

3.2 BASIC PROJECT MANAGEMENT PROCESS INTERACTIONS

A process is “a series of actions bringing about a result” while a result is a “concrete outcome” (American Heritage Dictionary). The major (but by no means the only) concrete outcomes of the five basic project management processes are as follows:

• Initiating—a description of the product of the project, initial documentation of project objectives, and assignment of a project manager

• Planning—a documented project plan and documented updates to the plan as the project progresses

• Executing—verifiably completed project deliverables

• Controlling—periodic measurements of progress vs. plan, corrective action when needed, and identification of when the project is done

• Closing-documented acceptance of the results of the project

These outcomes provide a direct link between the processes—the output from one becomes an input to another as illustrated in Figure 3.1. Each project management process can then be described in terms of its:

• Inputs—documents (e.g., a scope statement) or documentable items (e.g., task dependencies) that will be acted upon

• Tools and techniques—mechanisms (e.g., earned value computations) applied to the inputs (e.g., task results) to create the outputs (e.g., a progress report)

• Outputs—documents or documentable items that are the result of the process

In addition, these processes are not discrete, one-time events; they are iterative and repetitive and occur at varying levels of intensity throughout the project as illustrated in Figure 3.2.

Finally, each of the mechanisms is a process in its own right. For example, cost budgeting is a technique used to develop a project plan. It uses the Work Breakdown Structure (an output of task definition) and preliminary cost estimates (an output of cost estimating) and provides detail task budgets as an input to plan integration. These detail process interactions are described in the next section.

3.3 DETAIL PROCESS INTERACTIONS

The detail process interactions described here reflect generally accepted project management practices. They do not reflect project-specific or application area-specific practices, nor do they include general management processes. For example:

• Most projects will produce a written scope statement—scope statements are generally accepted.

• Expediting is a process that occurs on many but not most projects—expediting is not a generally accepted practice.

• The process of negotiating is not significantly different on a project—it is a general management process and is not included here.

The detail processes listed here are described more fully in the appropriate knowledge area (Chapters 4 through 11).

Detail Planning Process Relationships

Figure 3.3. Detail Planning Process Relationships

3.3.1 Initiating

This basic process includes only one detail process:

• Concept development—describing the product of the project, documenting initial project objectives, and assigning a project manager.

3.3.2 Planning

Planning is of major importance on a project—you are doing something unique and you only get one chance to get it right. As a result, there are relatively more detail processes in this section. However, the number of processes does not mean that project management is primarily planning—the amount of planning should always be commensurate with the scope of the project.

The relationships among the project planning processes are shown in Figure 3.3 (note that this chart is an explosion of the ellipse labeled “planning” in Figure 3.1 ). These processes are subject to frequent iterations prior to completing the plan. For example, if the initial completion date is too late, project scope may need to be reduced or costs increased.

Some detail planning processes have clear dependencies that require them to be performed in sequence. For example, tasks must be defined before they can be scheduled or costed. The dependent planning processes include:

• Scope definition-developing a written scope statement that includes the project justification, the major deliverables, and the project objectives

• Project definition—decomposing the major deliverables into more granular deliverables to provide better control (the top levels of the Work Breakdown Structure)

• Task definition—identifying the tasks that will be performed in order to produce the project's deliverables (the lower levels of the WBS)

• Task sequencing—identifying dependencies among tasks

• Duration estimating—estimating the probable duration of individually scheduleable tasks and activities

• Schedule development—determining and documenting specific dates for tasks

• Cost estimating—developing initial estimates of the overall project cost

• Cost budgeting—developing detail estimates of the cost of individual tasks

• Plan integration—creating and documenting a coherent project plan from the outputs of the other planning processes

Basic Project Management Processes and the Project Life Cycle

Figure 3.4. Basic Project Management Processes and the Project Life Cycle

Interactions among 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 involve considerable risk. These facilitating processes are performed sporadically throughout the course of project planning. They include:

• Quality planning—determining how to ensure that the project quality objectives will be met

• Role and responsibility definition—determining the broad outlines of project responsibilities

• Organization planning—deciding how the project will be organized, establishing reporting relationships

• Project staffing—deciding who will fill what positions and assume which roles and responsibilities over time

• Communications planning—determinng who needs what information, when they will need it, and how it will be given to them

• Risk identification—determining which risks are likely to affect the project

• Risk assessment—quantifying and evaluating the probability of risk occurrence and risk impact

• Solution development—defining deflection and mitigation steps for downside risk and enhancement steps for opportunities

• Procurement planning—deciding what items will be obtained under contract and how such contracts will be defined and awarded

• Solicitation—identifying possible sources for contractual services and obtaining responses from them

• Procurement—negotiating and contracting for outside products and services

3.3.3 Executing

This basic process includes the following detail processes:

• Plan execution—carrying out the project plan by performing the tasks identified therein and managing the various technical and organizational interfaces

• Contract administration—managing the contractual aspects of the procured products and services

3.3.4 Controlling

Project progress must be measured regularly to identify variances from the plan as well as to determine when the project is finished. Variances are fed into the control processes in the various knowledge areas. To the extent that significant variances are observed (e.g., those that jeopardize the project objectives), adjustments to the plan are made by repeating the appropriate project planning processes. For example, a missed task finish date may require adjustments to the current staffing plan, reliance on overtime, or trade-offs between budget and schedule objectives.

• Progress measurement and reporting—collecting and disseminating progress information

• Scope change management—documenting and controlling changes to project scope

• Quality control—measuring project deliverables and activities to assess whether quality objectives are being met

• Quality improvement—evaluating project performance on a regular basis to determine how to improve project quality

• Time/schedule control—controlling and responding to schedule changes

• Cost control—controlling and responding to cost changes

• Risk control—responding to changes in risk over the course of the project

3.3.5 Closing

This basic process includes the following detail processes:

• Scope verification-ensuring that the project deliverables have been completed satisfactorily

• Contract close-out—resolution of any outstanding administrative matters and archiving of contract documentation

• Project closure—gathering and disseminating information to formalize project completion

3.4 PROJECT PROCESSES AND THE PROJECT LIFE CYCLE

Most projects are done as a collection of phases (called the project life cycle) whose number and names are determined by the control needs of the performing organization. The basic process interactions repeat within each phase as illustrated in Figure 3.4. In addition:

• Scope definition has an added dimension. In addition to considering the overall scope of the project (the product of the project), scope definition must also focus on what specifically must be done to bring the current phase of the project to successful completion.

• The tools and techniques applied when executing the plan vary considerably. For example, the architect's tools will be vastly different from those of the constructor even through they are both involved in the same project.

• Initiating and closing are closely linked. For example, closing a “design” phase requires customer acceptance of the design document. Simultaneously, the design document defines the broad conceptual outlines for the ensuing implementation phase.

3.5 CUSTOMIZING THE INTERACTIONS

The interactions described above meet the test of general acceptance— they apply to most projects most of the time. However, they may be modified when necessary to meet project-specific or application area-specific needs. For example:

• An organization that makes extensive use of contractors may explicitly describe where in the planning process each of the contract/procurement processes occurs.

• Projects which are dependent on unique resources (software development, biopharmaceuticals, etc.) may define roles and responsibilities prior to scope definition since the resources available to do the work will have an effect on what can be done.

• 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 (there may be no formal communications management plan on a four-person project).

The interactions described here should be followed except when there is a cogent reason to do otherwise. When there is a need to modify the interactions, the change should be clearly identified, carefully evaluated, and actively managed.

Chapter 3 ends here.

The following section is extracted from Chapter 4, Project Scope Management, to illustrate how the various detail project processes are described in the proposed PMBOK document update.

Scope Definition is the process name: it is Section 4.2 because it is the second process in Chapter 4 (Concept Development is first). The inputs listed here are those that were judged to be generally accepted—they are used in most projects most of the time. This process corresponds to A.2 Scope Statement in the current PMBOK document. Although the Work Breakdown Structure is listed there, it is not shown here since it was judged to be the output of another process.

4.2 SCOPE DEFINITION

Scope definition is the process of developing a written scope statement as a foundation for future project activities. The scope statement forms the basis for an agreement between the project team and the project customer by (1) defining the major project deliverables and (2) formally documenting the project objectives.

Proper scope definition is critical to project success. “When there is poor scope definition, final project costs can be expected to be higher because of the inevitable changes which disrupt project rhythm, cause rework, increase project time and lower the productivity and morale of the workforce.” (CII, 1986)

Although closely related, scope definition should not be confused with product definition. When the product of the project is unknown or uncertain (e.g., when developing a product that relies on innovative technology), the scope of the project can still be properly defined by documenting known areas of uncertainty and acknowledging that project scope may need to be modified as these areas are clarified.

4.2.1 Inputs to Scope Definition

1. Product description. The product description is an output of concept development. The initial product description will be regularly updated as part of the progressive elaboration of the product attributes.

2. Justification. An explanation of why the project has been undertaken (to form the basis for evaluating future trade-offs).

3. Project objectives. A list of criteria that must be met for the project to be considered successful. Project objectives typically include at least cost, schedule, and quality constraints.

4.2.2 Tools and Techniques For Scope Definition

1. Systems analysis. Systems analysis in this context is a generic term for any type of structured analysis of alternatives. It includes techniques such as systems engineering and value analysis.

2. Cost/benefit analysis. Cost/benefit analysis involves estimating tangible costs (outlays) and benefits (returns) of various project alternatives, and then using financial measures such as return on investment to assess the relative desirability of the identified alternatives.

3. Alternative identification. This is a catch-all term for any technique used to generate new ideas. There are a variety of general management techniques often used here, the most common of which are brainstorming and lateral thinking.

4. Subject matter experts. Subject matter experts may be used to generate alternatives or assess them. Any group or individual with specialized training or knowledge may be considered a subject matter expert.

4.2.3 Outputs From Scope Definition

1. Scope statement. The scope statement forms the basis for establishing a summary agreement between the project team and the project customer (the project plan will provide a more detailed agreement). It should include the project justification, an updated set of project objectives, and a list of the deliverables (measurable, tangible and verifiable items) whose full and satisfactory delivery marks completion of the project. This implies as well that anything not explicitly included is explicitly excluded.

2. Scope management plan. This document describes how project scope will be managed, and how scope changes will be integrated into the project.

img

William R. Duncan is a principal of Duncan • Nevison, a project management training and consulting firm headquartered in Lexington, MA. Mr. Duncan has been a member of PMI's Standards Committee since October 1989 and has been Director of Standards since January 1992. He is a certifiedProject Management Professional and has been a member of the Editorial Review Board of the Project Management Journal since 1982.

Mr. Duncan has over 20 years of management and consulting experience. He has managed several major software development projects and spent five years with the consulting group of one of the Big Six accounting firms managing organizational change projects. Since founding Duncan Associates (now Duncan • Nevison) in 1981, he has trained project managers in a variety of application areas, including aerospace, architecture, biosciences, construction, electronics and software development. He is a 1970 graduate of Brown University and has done postgraduate work at Boston University and Northeastern University.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI.

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.