Uɠly Gîrl

Project Management Body of Knowledge CHAPTER 3 #SoftSkill

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