return to model

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 which 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).