Process Improvement Essentials: CMMI, Six SIGMA, and ISO 9001

6.7. Project Management Process Areas

The following sections detail the Process Areas specific to project management.

6.7.1. Project Planning

In my opinion, the Project Planning Process Area is the single most important PA in the entire CMMI model. Others might dispute that point (and validly), but what's generally accepted is that a reliable quality result can only come from up-front planning: the more, the better. That's why CMMI places such a strong emphasis on planning (just as ISO 9001 and Six Sigma do).

The structure of the Project Planning PA helps an organization resist the temptation to hurry up and go. Today we have ample data on what happens when pressure to begin pushes a project into premature action. Issues with resource allocation, budgeting, scheduling, scope, and functionality crop up early and plague a project across its life cycle.

Planning is a way to reduce these kinds of problems (and the risks they bring). A well-designed planning program provides two key benefits to any project effort: it provides a road map for thinking a project through prior to making commitments, and it delivers a medium for agreement between parties as to how the project will be managed.

6.7.1.1. Three specific goals

There are three goals in the Project Planning PA, each designed to strengthen your position in meeting a project's objectives:

1. Establish estimates of what it will take to see a project through from start to finish. These estimates include such things as the size and scope of the end product, the number of resources required, special skill sets needed, types of computing resources required, and so on. These estimates can be derived from formal models, from similar projects from the past, or from consensus of experienced opinion. However you approach it, the idea is to estimate intelligently using as much data as is available to you.

2. Create (and document) a plan based on the estimates. Since a complete project plan will typically contain a good bit of data to support the estimates, it's a good idea to document the plan using a standardized template. The use of a template helps different project managers in the same organization plan in a consistent manner from project to project. It also helps ensure that a core set of planning data will be addressed in each plan. The plan will contain all the detail necessary to carry forth the estimated scope and activities. And, just as important, it will serve as the chief control mechanism for managing the project across its life cycle.

3. Obtain commitment to the plan. This step is essential to smooth execution. Here you circulate the plan among team members and relevant stakeholders to elicit feedback and approval. Once agreed upon, the plan can serve as a contract of agreement between you and the team (and the customer) as to the scope of the project and how it will be managed.

6.7.1.2. Core Project Planning actions

Document a project plan using the best estimates and information at your disposal. Then involve team members and stakeholders in reviewing and approving the plan in order to establish a contract of agreement among parties as to how the project will be managed.

Applies to Project Management:

• Systems Engineering

• Software Engineering

• Integrated Product and Process Development

Figure 6-1 illustrates the Project Planning PA.

6.7.2. Project Monitoring and Control

The Project Monitoring and Control Process Area is a logical extension of Project Planning. In planning, you document the resources, activities, and constraints anticipated for a project. You then use the plan as the chief reference tool for monitoring the project's progress. Effective monitoring includes the use of regular status meetings, stakeholder communications, product inspections, and audits. Control is the proactive counterpoint to monitoring. When the actuals on a projectthe details of what is actually transpiringbegin to vary significantly from what was planned, you should take corrective action to bring the plan back into sync with the project, either by reversioning the plan or adjusting the scope of the project.

6.7.2.1. Two specific goals

CMMI assigns two goals to Project Monitoring and Control:

1. The project manager should monitor the project against the plan. This includes monitoring the planning parameters (resources, costs, schedule), tracking project commitments and risks, and ensuring stakeholder involvement. These moves can be accomplished through regular formal status meetings, through informal status check-ups, and through other available communication channels.

2. The project manager should track risks and emerging variances across all phases of the project life cycle, following the issues to closure. When variances begin to become significant, the project manager should initiate some form of corrective action to bring the plan and the project back into alignment. To do this effectively, the project manager will typically identify variances as they begin to rise, monitor their rate of escalation, and then move to mitigate their influence at preset "take action" points.

6.7.2.2. Core Project Monitoring and Control actions

Project management tracks the actual progress of the project against documented projections in the plan. When significant variance occurs between what was planned for and what is actually happening, the PM takes corrective action to realign the plan with project activity.

Applies to Project Management:

• Systems Engineering

• Software Engineering

• Integrated Product and Process Development

Figure 6-2 illustrates the Project Monitoring and Oversight PA.

6.7.3. Integrated Project Management

Integrated Project Management supports the coordination of disparate work groups and elements within a project. It combines the facets of Project Planning and Project Monitoring and Control with activities to focus these elements for enhanced project control. This Process Area includes practices that help project management identify and select the right processes for a particular project from the organization's process repository (see "Organizational Process Definition," later in this chapter). Also included are activities to tailor the processes to the needs of the project, managing the project objectives with the active involvement of designated stakeholders, creating and communicating a shared project vision with the stakeholders, and creating integrated teams based on the specific technical and production needs of the project.

6.7.3.1. Three specific goals

CMMI defines three goals for Integrated Project Management:

1. Project planning and execution should be based on the use of the organization's defined processes. This goal sets in place recommendations for selecting process sets from the organization's process repository and tailoring those to the needs of the project as part of integrated planning activity.

2. Project activities should be coordinated with relevant stakeholders, allowing for ample collaboration and exchange. This involves forging a broad team partnership by identifying relevant stakeholders and then ensuring that project communications and activities are continually coordinated with these parties over the life of the project.

The third goal is for use when you are using CMMI for Integrated Product and Process Development:

3. Apply IPPD principles to the project activities and structures. This goalexclusively for IPPD efforts but useful wherever you might see fitputs forth practices to help align multiple project teams, often with disparate charges. Practices deal with establishing shared vision statements and creating integrated teams.

6.7.3.2. Core Integrated Project Management actions

Project management coordinates the use of organizational process sets, integrates plans and teams, and ensures stakeholder involvement across the life of the project.

Applies to Project Management:

• Systems Engineering

• Software Engineering

• Integrated Product and Process Development

Figure 6-3 illustrates the Integrated Project Management PA.

6.7.4. Quantitative Project Management

Quantitative Project Management is an advanced technique used by mature organizations to plan for and gauge project success. This Process Area extends the reach of Project Monitoring and Control and Integrated Project Management. The basic modus operandi of PM&C is to track actual values against planned values. The values here are usually snapshots of substantial project components, such as the schedule, the budget, the number of resources, the risks, and so on. When one or more of these values begins to vary significantly from what was planned, the project manager takes corrective action. The concept of "significant variance," however, is not really tangibly defined with PM&C; that call is left to the experience and intuition of the project manager. The corrective action is likewise a discretionary move.

Quantitative Project Management adds a layer of engineering granularity to this process. To begin with, under QPM, progress is mapped numerically. For example, a measure that shows the design phase as being three days ahead of schedule might be calculated as being 109 percent on target. That percentage is more meaningful (for analysis and reporting) than, say, "+3 days." With such measures, project management also monitors the efficiencies of subprocesses within the project. Quantitative measures are taken to assess the performance of these processes against anticipated or expected goals. As another example, a requirements review process that was executed with 4 missed steps out of 20 might receive a performance score of 80. That hard score can then be compared against other projects or a preset scorecard to determine the success of the process for that project.

Effective Quantitative Project Management relies on a backlog of accumulated project performance data, thoughtful and analytical project planning, and firm control over the execution of a project.

6.7.4.1. Two specific goals

CMMI defines two goals for this Process Area:

1. The project is managed, in part, by using quantitative measures of quality and process performance objectives. Meeting this goal requires that the organization capture enough history from prior projects so that it can effectively quantify benchmarks that indicate quality and progress baselines and targets. Quantitative measures can be defined in the absence of history, but these benchmarks add maximum value when they are derived from the organization's typical production flow. The use of predictive tools (such as Earned Value Management) is also appropriate in support of quantitative project management.

2. The performance of selected project subprocesses is statistically measured against preset goals for efficiency and effectiveness. This goal provides a method for measuring the engine that drives the project, which comprises the various processes and their subcomponents as employed. Here, processes are tracked by their constituent steps. The organization's experience with its process set should be such that it can estimate the duration of each within a project. By tracking the duration and success of each process substep, project management can accrue measures on the efficiency of the processes. This leads to greater and more accurate project control and provides data for future process improvement considerations.

6.7.4.2. Core Quantitative Project Management actions

In addition to the basic monitoring of schedule, funding, and resource attributes, project management performs oversight on the project by regularly comparing quantitative measures of quality, performance, and process efficiencies to preset goals around process performance.

Applies to Project Management:

• Systems Engineering

• Software Engineering

• Integrated Product and Process Development

Figure 6-4 illustrates the Quantitative Project Management PA.

6.7.5. Risk Management

The Risk Management Process Area extends the capabilities of Project Planning and Project Monitoring and Control. Basic project planning calls for the identification of potential risks. And basic project monitoring calls for tracking risks that could threaten a project. Risk Management introduces an organized and planned approach for continuously dealing with risks, one that uses a proactive organizational methodology. This methodology takes what could be thought of as free-range risks and corrals them into categories. The organization then develops strategies to address the inherent traits of the different risk categories. These strategies are then applied at the project level, where potential risks are explicitly identified and their impacts assessed as early as possible. The mitigation steps that emerge from this activity are then encompassed in a Risk Management Plan that becomes part of the overall project plan.

The Risk Management Process Area represents a step to quantify (to a degree) something that we typically regard as a hazy intangible or, at best, as a distinct but removed potential. It helps an organization forge a set of tools useful in circumventing the pitfalls that come from avoiding the issue of risks or from dealing with them in a reactive, half-considered manner.

6.7.5.1. Three specific goals

CMMI defines three goals for Risk Management:

1. The organization should prepare a risk-management program. This includes defining typical sources and categories of risk, determining risk parameters, and establishing a general strategy for managing risk that can be applied to all organizational projects.

2. For each project, the project manager (with assistance from selected members of the project team) should identify and analyze risks. This includes defining potential risks as part of the planning process, assessing the potential impact of each risk, and then prioritizing risks according to impact, likelihood, and complexity.

3. The project manager should document a series of mitigation steps that can be employed to deal with the risks, should they materialize.

The risk planrisks identified and prioritized, with mitigation actionscan then become a component of the overall project plan.

6.7.5.2. Core Risk Management actions

The organization defines the types of risks its projects typically encounter, identifies specific risks for each project, and develops a management plan for each project, which details how risks will be mitigated should they materialize.

Applies to Project Management:

• Systems Engineering

• Software Engineering

• Integrated Product and Process Development

Figure 6-5 illustrates the Risk Management PA.

6.7.6. Supplier Agreement Management

The Supplier Agreement Management Process Area addresses the need to acquire outside products or services that are required to fulfill the expectations or scope of a development project. As an example, a project intended to create an online e-store might seek to acquire a piece of finished code that processes Visa and MasterCard transactions. To ensure that this acquisition process is structured with adequate quality controls, the organization should establish a program that manages interplay and agreements between suppliers and the organization. The Supplier Agreement Management Process Area provides the framework for such a program.

This Process Area helps organizations establish standards for determining the type of acquisition required, criteria for selecting qualified suppliers, considerations for executing and managing supplier agreements, protocols for product inspection, and guidelines for transitioning acquired products into the organization.

6.7.6.1. Two specific goals

CMMI defines two goals for Supplier Agreement:

1. Establish formal agreements with your suppliers. This goal helps objectify the process of selecting and managing vendors whose products you wish to acquire. Here the organization should begin by categorizing, in some manner, the type of acquisitions it makes and then apply those criteria when amassing a potential supplier base. The organization should also develop some type of supplier selection criteria, a checklist to provide consistency when evaluating potential vendors and their products. Then, in anticipation of a purchasing choice, formal agreements should be drawn up (governing interactions, legal rights, product distribution, etc.) that can be used to establish an understanding between the organization and the supplier.

2. Satisfy the executed agreements. To meet this goal, the organization should work to meet the tenets of the executed supplier agreement. These tenets typically include stipulations to monitor select supplier processes and product development activities, examine the product (or product suite) for suitability, establish terms for acquisition, provide for the transfer of the product into the organization (with appropriate documentation, support, and other necessary materials), and then describe the steps needed to integrate the product into the organization or project team.

6.7.6.2. Core Supplier Agreement actions

The organization defines the methods for acceptable selection and use of third-party products and services, detailing supplier selection criteria, product suitability requirements, and boilerplate supplier agreements. Also promoted is the monitoring of selected supplier processes and iterative work products.

Applies to Project Management:

• Supplier Sourcing across all disciplines

Figure 6-6 illustrates the Supplier Agreement Management PA.