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.

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 are concerned with describing and organizing 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 are concerned with specifying and creating the pro-ject 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 F).

 

Project management processes and product-oriented processes overlap and in-teract throughout the project. For example, the scope of the project cannot be de-fined 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—recognizing that a project or phase should begin and committing to do so.
  • Planning processes—devising and maintaining a workable scheme to accomplish the business need 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 and taking corrective action 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 outcome of one 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 con-nections are illustrated in Figure 3–1. In addition, the project management process groups are not discrete, one-time events; they are overlapping activities which occur at varying levels of intensity throughout each phase of the project. Figure 3–2 illus-trates 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.

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.

 

  •  
    • Initiating Processes
    • Planning Processes
    • Executing Processes
    • Controlling Processes
    • Closing Processes

 

3.4 Customizing Process Interactions

The processes identified and the interactions illustrated 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 which are dependent on unique resources (commercial software de-velopment, biopharmaceuticals, etc.) may define roles and responsibilities pri-or 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.
  • Larger projects may need relatively more detail. For example, risk identifica-tion 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 subcon-tractor may ignore risks explicitly assumed by the prime contractor) or on processes that provide only marginal utility (there may be no formal commu-nications plan on a four-person project).

When there is a need to make a change, the change should be clearly identified, carefully evaluated, and actively managed.