4.2. CAUSAL ANALYSIS AND RESOLUTION

Purpose

The purpose of Causal Analysis and Resolution (CAR) is to identify causes of defects and other problems and take action to prevent them from occurring in the future.

Introductory Notes

The Causal Analysis and Resolution process area involves the following:
· Identifying and analyzing causes of defects and other problems
· Taking specific actions to remove the causes and prevent the occurrence of those types of defects and problems in the future
Causal analysis and resolution improves quality and productivity by preventing the introduction of defects into a product. Reliance on detecting defects after they have been introduced is not cost effective. It is more effective to prevent defects from being introduced by integrating causal analysis and resolution activities into each phase of the project.
Since defects and problems may have been previously encountered on other projects or in earlier phases or tasks of the current project, causal analysis and resolution activities are a mechanism for communicating lessons learned among projects.
The types of defects and other problems encountered are analyzed to identify any trends. Based on an understanding of the defined process and how it is implemented, the root causes of the defects and the future implications of the defects are determined.
Causal analysis may also be performed on problems unrelated to defects. For example, causal analysis may be used to improve quality attributes such as cycle time. Improvement proposals, simulations, dynamic systems models, engineering analyses, new business directives, or other items may initiate such analysis.
When it is impractical to perform causal analysis on all defects, defect targets are selected by tradeoffs on estimated investments and estimated returns of quality, productivity and cycle time.
A measurement process should already be in place. The defined measures can be used, though in some instances new measures may be needed to analyze the effects of the process change.
Refer to the Measurement and Analysis process area for more information about establishing objectives for measurement and analysis, specifying the measures and analyses to be performed, obtaining and analyzing measures, and reporting results.
Causal Analysis and Resolution activities provide a mechanism for projects to evaluate their processes at the local level and look for improvements that can be implemented.
When improvements are judged to be effective, the information is extended to the organizational level.
Refer to the Organizational Innovation and Deployment process area for more information about improving organizational level processes through proposed improvements and action proposals.
The informative material in this process area is written with the assumption that the specific practices are applied to a quantitatively managed process. The specific practices of this process area may be applicable, but with reduced value, if this assumption is not met.
See the definitions of “stable process” and “common cause of process variation” in the glossary.
Related Process Areas
Refer to the Quantitative Project Management process area for more information about the analysis of process performance and the creation of process capability measures for selected project processes.
Refer to the Organizational Innovation and Deployment process area for more information about the selection and deployment of improvements to organizational processes and technologies.
Refer to the Measurement and Analysis process area for more information about establishing objectives for measurement and analysis, specifying the measures and analyses to be performed, obtaining and analyzing measures, and reporting results.

Specific Goal and Practice Summary

SG 1 Determine Causes of Defects
SP 1.1 Select Defect Data for Analysis
SP 1.2 Analyze Causes

SG 2 Address Causes of Defects
SP 2.1 Implement the Action Proposals
SP 2.2 Evaluate the Effect of Changes
SP 2.3 Record Data

SG 1 Determine Causes of Defects

Root causes of defects and other problems are systematically determined.

A root cause is a source of a defect such that, if it is removed, the defect is decreased or removed.

SP 1.1 Select Defect Data for Analysis

Select the defects and other problems for analysis.

Typical Work Products

1. Defect and problem data selected for further analysis
Subpractices
1. Gather relevant defect or problem data.
Examples of relevant defect data may include the following:
· Defects reported by the customer
· Defects reported by end users
· Defects found in peer reviews
· Defects found in testing

Examples of relevant problem data may include the following:
· Project management problem reports requiring corrective action
· Process capability problems
· Process duration measurements
· Earned value measurements by process (e.g., cost performance index)
· Resource throughput, utilization, or response time measurements

Refer to the Verification process area for more information about work product verification.
Refer to the Quantitative Project Management process area for more information about statistical management.

2. Determine which defects and other problems will be analyzed further.
When determining which defects to analyze further, consider the impact of the defects, their frequency of occurrence, the similarity between defects, the cost of analysis, the time and resources needed, the safety considerations, etc.
Examples of methods for selecting defects and other problems include the following:
· Pareto analysis
· Histograms
· Process capability analysis

SP 1.2 Analyze Causes

Perform causal analysis of selected defects and other problems and propose actions to address them.

The purpose of this analysis is to develop solutions to the identified problems by analyzing the relevant data and producing action proposals for implementation.

Typical Work Products

1. Action proposal

Subpractices

1. Conduct causal analysis with the people who are responsible for performing the task.
Causal analysis is performed, typically in meetings, with those people who have an understanding of the selected defect or problem under study. The people who have the best understanding of the selected defect are typically those responsible for performing the task.
Examples of when to perform causal analysis include the following:
· When a stable process does not meet its specified quality and process-performance objectives
· During the task, if and when problems warrant a causal analysis meeting
· When a work product exhibits an unexpected deviation from its requirements

Refer to the Quantitative Project Management process area for more information about achieving the project’s quality and process-performance objectives.

2. Analyze selected defects and other problems to determine their root causes.
Depending on the type and number of defects, it may make sense to first group the defects before identifying their root causes.
Examples of methods to determine root causes include the following:
· Cause-and-effect (fishbone) diagrams
· Check sheets

3. Group the selected defects and other problems based on their root causes.
Examples of cause groups, or categories, include the following:
· Inadequate training
· Breakdown of communications
· Not accounting for all details of a task
· Making mistakes in manual procedures (e.g., typing)
· Process deficiency

4. Propose and document actions that need to be taken to prevent the future occurrence of similar defects or other problems.
Examples of proposed actions include changes to the following:
· The process in question
· Training
· Tools
· Methods
· Communications
· Work products

Examples of specific actions include the following:
· Providing training in common problems and techniques for preventing them
· Changing a process so that error-prone steps do not occur
· Automating all or part of a process
· Reordering process activities
· Adding process steps to prevent defects, such as task kickoff meetings to review common defects and actions to prevent them

An action proposal usually documents the following:
· Originator of the action proposal
· Description of the problem
· Description of the defect cause
· Defect cause category
· Phase when the problem was introduced
· Phase when the defect was identified
· Description of the action proposal
· Action proposal category

SG 2 Address Causes of Defects

Root causes of defects and other problems are systematically addressed to prevent their future occurrence.

Projects operating according to a well-defined process will systematically analyze the operation where problems still occur and implement process changes to eliminate root causes of selected problems.

SP 2.1 Implement the Action Proposals

Implement the selected action proposals that were developed in causal analysis.

Action proposals describe the tasks necessary to remove the root causes of the analyzed defects or problems and avoid their reoccurrence.
Only changes that prove to be of value should be considered for broad implementation.

Typical Work Products

1. Action proposals selected for implementation
2. Improvement proposals

Subpractices

1. Analyze the action proposals and determine their priorities.
Criteria for prioritizing action proposals include the following:
· Implications of not addressing the defects
· Cost to implement process improvements to prevent the defects
· Expected impact on quality
2. Select the action proposals that will be implemented.
3. Create action items for implementing the action proposals.

Examples of information provided in an action item include the following:
· Person responsible for implementing it
· Description of the areas affected by it
· People who are to be kept informed of its status
· Next date that status will be reviewed
· Rationale for key decisions
· Description of implementation actions
· Time and cost for identifying the defect and correcting it
· Estimated cost of not fixing the problem

To implement the action proposals, the following tasks must be done:
· Make assignments
· Coordinate the persons doing the work
· Review the results
· Track the action items to closure

Experiments may be conducted for particularly complex changes.

Examples of experiments include the following:
· Using a temporarily modified process
· Using a new tool

Action items may be assigned to members of the causal analysis team, members of the project team, or other members of the organization.
4. Identify and remove similar defects that may exist in other processes and work products.
5. Identify and document improvement proposals for the organization’s set of standard processes.
Refer to the Organizational Innovation and Deployment process area for more information about the selection and deployment of improvement proposals for the organization’s set of standard processes.

SP 2.2 Evaluate the Effect of Changes

Evaluate the effect of changes on process performance.
Refer to the Quantitative Project Management process area for more information about analyzing process performance and creating process capability measures for selected processes.
Once the changed process is deployed across the project, the effect of the changes must be checked to gather evidence that the process change has corrected the problem and improved performance.

Typical Work Products

1. Measures of performance and performance change

Subpractices

1. Measure the change in the performance of the project's defined process as appropriate.
This subpractice determines whether the selected change has positively influenced the process performance and by how much.
An example of a change in the performance of the project’s defined design process would be the change in the defect density of the design documentation, as statistically measured through peer reviews before and after the improvement has been made. On a statistical process control chart, this would be represented by a change in the mean.

2. Measure the capability of the project's defined process as appropriate.
This subpractice determines whether the selected change has positively influenced the ability of the process to meet its quality and process-performance objectives, as determined by relevant stakeholders.
An example of a change in the capability of the project’s defined design process would be a change in the ability of the process to stay within its process-specification boundaries. This can be statistically measured by calculating the range of the defect density of design documentation, as collected in peer reviews before and after the improvement has been made. On a statistical process control chart, this would be represented by lowered control limits.

SP 2.3 Record Data

Record causal analysis and resolution data for use across the project and organization.

Data are recorded so that other projects and organizations can make appropriate process changes and achieve similar results.
Record the following:
· Data on defects and other problems that were analyzed
· Rationale for decisions
· Action proposals from causal analysis meetings
· Action items resulting from action proposals
· Cost of the analysis and resolution activities
· Measures of changes to the performance of the defined process resulting from resolutions

Typical Work Products

1. Causal analysis and resolution records

4.3. CONFIGURATION MANAGEMENT

Purpose

The purpose of Configuration Management (CM) is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits.

Introductory Notes

The Configuration Management process area involves the following:
· Identifying the configuration of selected work products that compose the baselines at given points in time
· Controlling changes to configuration items
· Building or providing specifications to build work products from the configuration management system
· Maintaining the integrity of baselines
· Providing accurate status and current configuration data to developers, end users, and customers
The work products placed under configuration management include the products that are delivered to the customer, designated internal work products, acquired products, tools, and other items that are used in creating and describing these work products. (See the definition of “configuration management” in the glossary.)
Acquired products may need to be placed under configuration management by both the supplier and the project. Provisions for conducting configuration management should be established in supplier agreements. Methods to ensure that the data is complete and consistent should be established and maintained.
Refer to the Supplier Agreement Management process area for more information about establishing and maintaining agreements with suppliers.
Examples of work products that may be placed under configuration management include the following:
· Plans
· Process descriptions
· Requirements
· Design data
· Drawings
· Product specifications
· Code
· Compilers
· Product data files
· Product technical publications
Configuration management of work products may be performed at several levels of granularity. Configuration items can be decomposed into configuration components and configuration units. Only the term “configuration item” is used in this process area. Therefore, in these practices, “configuration item” may be interpreted as “configuration component” or “configuration unit” as appropriate. (See the definition of “configuration item” in the glossary.)
Baselines provide a stable basis for continuing evolution of configuration items.
An example of a baseline is an approved description of a product that includes internally consistent versions of requirements, requirement traceability matrices, design, discipline-specific items, and end-user documentation.
Baselines are added to the configuration management system as they are developed. Changes to baselines and the release of work products built from the configuration management system are systematically controlled and monitored via the configuration control, change management, and configuration auditing functions of configuration management.
This process area applies not only to configuration management on projects, but also to configuration management on organizational work products such as standards, procedures, and reuse libraries.
Configuration management is focused on the rigorous control of the managerial and technical aspects of work products, including the delivered system.
This process area covers the practices for performing the configuration management function and is applicable to all work products that are placed under configuration management.
Related Process Areas
Refer to the Project Planning process area for information on developing plans and work breakdown structures, which may be useful for determining configuration items.
Refer to the Project Monitoring and Control process area for more information about performance analyses and corrective actions.

Specific Goal and Practice Summary

SG 1 Establish Baselines
SP 1.1 Identify Configuration Items
SP 1.2 Establish a Configuration Management System
SP 1.3 Create or Release Baselines

SG 2 Track and Control Changes
SP 2.1 Track Change Requests
SP 2.2 Control Configuration Items
SG 3 Establish Integrity
SP 3.1 Establish Configuration Management Records
SP 3.2 Perform Configuration Audits

SG 1 Establish Baselines

Baselines of identified work products are established.

Specific practices to establish baselines are covered by this specific goal. The specific practices under the Track and Control Changes specific goal serve to maintain the baselines. The specific practices of the Establish Integrity specific goal document and audit the integrity of the baselines.

SP 1.1 Identify Configuration Items

Identify the configuration items, components, and related work products that will be placed under configuration management.

Configuration identification is the selection, creation, and specification of the following:
· Products that are delivered to the customer
· Designated internal work products
· Acquired products
· Tools and other capital assets of the project's work environment
· Other items that are used in creating and describing these work products
Items under configuration management will include specifications and interface documents that define the requirements for the product. Other documents, such as test results, may also be included, depending on their criticality to defining the product.
A “configuration item” is an entity designated for configuration management, which may consist of multiple related work products that form a baseline. This logical grouping provides ease of identification and controlled access. The selection of work products for configuration management should be based on criteria established during planning.

Typical Work Products

1. Identified configuration items
Subpractices
1. Select the configuration items and the work products that compose them based on documented criteria.
Example criteria for selecting configuration items at the appropriate work product level include the following:
· Work products that may be used by two or more groups
· Work products that are expected to change over time either because of errors or change of requirements
· Work products that are dependent on each other in that a change in one mandates a change in the others
· Work products that are critical for the project

Examples of work products that may be part of a configuration item include the following:
· Process descriptions
· Requirements
· Design
· Test plans and procedures
· Test results
· Interface descriptions
· Drawings
· Source code
· Tools (e.g., compilers)

2. Assign unique identifiers to configuration items.
3. Specify the important characteristics of each configuration item.
Example characteristics of configuration items include author, document or file type, and programming language for software code files.

4. Specify when each configuration item is placed under configuration management.
Example criteria for determining when to place work products under configuration management include the following:
· Stage of the project lifecycle
· When the work product is ready for test
· Degree of control desired on the work product
· Cost and schedule limitations
· Customer requirements

5. Identify the owner responsible for each configuration item.

SP 1.2 Establish a Configuration Management System

Establish and maintain a configuration management and change management system for controlling work products.

A configuration management system includes the storage media, the procedures, and the tools for accessing the configuration system.
A change management system includes the storage media, the procedures, and tools for recording and accessing change requests.

Typical Work Products

1. Configuration management system with controlled work products
2. Configuration management system access control procedures
3. Change request database
Subpractices
1. Establish a mechanism to manage multiple control levels of configuration management.
The level of control is typically selected based on project objectives, risk, and/or resources. Control levels may vary in relation to the project lifecycle, type of system under development, and specific project requirements.
Example levels of control include the following:
· Create – controlled by author
· Engineering – notification to relevant stakeholders when changes are made
· Development – lower level CCB control
· Formal – higher level CCB control with customer involvement

Levels of control can range from informal control that simply tracks changes made when the configuration items are being developed to formal configuration control using baselines that can only be changed as part of a formal configuration management process.
2. Store and retrieve configuration items in a configuration management system.
Examples of configuration management systems include the following:
· Dynamic (or author’s) systems contain components currently being created or revised. They are in the author’s workspace and are controlled by the author. Configuration items in a dynamic system are under version control.
· Master (or controlled) systems contain current baselines and changes to them. Configuration items in a master system are under full configuration management as described in this process area.
· Static systems contain archives of various baselines released for use. Static systems are under full configuration management as described in this process area.

3. Share and transfer configuration items between control levels within the configuration management system.
4. Store and recover archived versions of configuration items.
5. Store, update, and retrieve configuration management records.
6. Create configuration management reports from the configuration management system.
7. Preserve the contents of the configuration management system.
Examples of preservation functions of the configuration management system include the following:
· Backups and restoration of configuration management files
· Archiving of configuration management files
· Recovery from configuration management errors

8. Revise the configuration management structure as necessary.

SP 1.3 Create or Release Baselines

Create or release baselines for internal use and for delivery to the customer.

A baseline is a set of specifications or work products that has been formally reviewed and agreed on, that thereafter serves as the basis for further development or delivery, and that can be changed only through change control procedures. A baseline represents the assignment of an identifier to a configuration item or a collection of configuration items and associated entities. As a product evolves, several baselines may be used to control its development and testing.

For Systems Engineering
One common set of baselines includes the system-level requirements, system-element-level design requirements, and the product definition at the end of development/beginning of production. These are typically referred to as the “functional baseline,” “allocated baseline,” and “product baseline.”


For Software Engineering
A software baseline can be a set of requirements, design, source code files and the associated executable code, build files, and user documentation (associated entities) that have been assigned a unique identifier.

Typical Work Products

1. Baselines
2. Description of baselines
Subpractices
1. Obtain authorization from the configuration control board (CCB) before creating or releasing baselines of configuration items.
2. Create or release baselines only from configuration items in the configuration management system.
3. Document the set of configuration items that are contained in a baseline.
4. Make the current set of baselines readily available.

SG 2 Track and Control Changes

Changes to the work products under configuration management are tracked and controlled.

The specific practices under this specific goal serve to maintain the baselines after they are established by the specific practices under the Establish Baselines specific goal.

SP 2.1 Track Change Requests

Track change requests for the configuration items.

Change requests address not only new or changed requirements, but also failures and defects in the work products.
Change requests are analyzed to determine the impact that the change will have on the work product, related work products, budget, and schedule.

Typical Work Products

1. Change requests
Subpractices
1. Initiate and record change requests in the change request database.
2. Analyze the impact of changes and fixes proposed in the change requests.
Changes are evaluated through activities that ensure that they are consistent with all technical and project requirements.
Changes are evaluated for their impact beyond immediate project or contract requirements. Changes to an item used in multiple products can resolve an immediate issue while causing a problem in other applications.
3. Review change requests that will be addressed in the next baseline with the relevant stakeholders and get their agreement.
Conduct the change request review with appropriate participants. Record the disposition of each change request and the rationale for the decision, including success criteria, a brief action plan if appropriate, and needs met or unmet by the change. Perform the actions required in the disposition, and report the results to relevant stakeholders.
4. Track the status of change requests to closure.
Change requests brought into the system need to be handled in an efficient and timely manner. Once a change request has been processed, it is critical to close the request with the appropriate approved action as soon as it is practical. Actions left open result in larger than necessary status lists, which in turn result in added costs and confusion.

SP 2.2 Control Configuration Items

Control changes to the configuration items.

Control is maintained over the configuration of the work product baseline. This control includes tracking the configuration of each of the configuration items, approving a new configuration if necessary, and updating the baseline.

Typical Work Products

1. Revision history of configuration items
2. Archives of the baselines
Subpractices
1. Control changes to configuration items throughout the life of the product.
2. Obtain appropriate authorization before changed configuration items are entered into the configuration management system.
For example, authorization may come from the CCB, the project manager, or the customer.

3. Check in and check out configuration items from the configuration management system for incorporation of changes in a manner that maintains the correctness and integrity of the configuration items.
Examples of check-in and check-out steps include the following:
· Confirming that the revisions are authorized
· Updating the configuration items
· Archiving the replaced baseline and retrieving the new baseline

4. Perform reviews to ensure that changes have not caused unintended effects on the baselines (e.g., ensure that the changes have not compromised the safety and/or security of the system).
5. Record changes to configuration items and the reasons for the changes as appropriate.
If a proposed change to the work product is accepted, a schedule is identified for incorporating the change into the work product and other affected areas.
Configuration control mechanisms can be tailored to categories of changes. For example, the approval considerations could be less stringent for component changes that do not affect other components.
Changed configuration items are released after review and approval of configuration changes. Changes are not official until they are released.

SG 3 Establish Integrity

Integrity of baselines is established and maintained.

The integrity of the baselines, established by processes associated with the Establish Baselines specific goal, and maintained by processes associated with the Track and Control Changes specific goal, is provided by the specific practices under this specific goal.

SP 3.1 Establish Configuration Management Records

Establish and maintain records describing configuration items.

Typical Work Products

1. Revision history of configuration items
2. Change log
3. Copy of the change requests
4. Status of configuration items
5. Differences between baselines
Subpractices
1. Record configuration management actions in sufficient detail so the content and status of each configuration item is known and previous versions can be recovered.
2. Ensure that relevant stakeholders have access to and knowledge of the configuration status of the configuration items.
Examples of activities for communicating configuration status include the following:
· Providing access permissions to authorized end users
· Making baseline copies readily available to authorized end users

3. Specify the latest version of the baselines.
4. Identify the version of configuration items that constitute a particular baseline.
5. Describe the differences between successive baselines.
6. Revise the status and history (i.e., changes and other actions) of each configuration item as necessary.

SP 3.2 Perform Configuration Audits

Perform configuration audits to maintain integrity of the configuration baselines.

Configuration audits confirm that the resulting baselines and documentation conform to a specified standard or requirement. Audit results should be recorded as appropriate. (See the glossary for a definition of “configuration audit.”)
Examples of audit types include the following:
· Functional Configuration Audits (FCA) – Audits conducted to verify that the as-tested functional characteristics of a configuration item have achieved the requirements specified in its functional baseline documentation and that the operational and support documentation is complete and satisfactory.
· Physical Configuration Audit (PCA) – Audits conducted to verify that the as-built configuration item conforms to the technical documentation that defines it.
· Configuration management audits – Audits conducted to confirm that configuration management records and configuration items are complete, consistent, and accurate.

Typical Work Products

1. Configuration audit results
2. Action items
Subpractices
1. Assess the integrity of the baselines.
2. Confirm that the configuration management records correctly identify the configuration items.
3. Review the structure and integrity of the items in the configuration management system.
4. Confirm the completeness and correctness of the items in the configuration management system.
Completeness and correctness of the content is based on the requirements as stated in the plan and the disposition of approved change requests.
5. Confirm compliance with applicable configuration management standards and procedures.
6. Track action items from the audit to closure.

4.4. DECISION ANALYSIS AND RESOLUTION

Purpose

The purpose of Decision Analysis and Resolution (DAR) is to analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria.

Introductory Notes

The Decision Analysis and Resolution process area involves establishing guidelines to determine which issues should be subjected to a formal evaluation process and then applying formal evaluation processes to these issues.
A formal evaluation process is a structured approach to evaluating alternative solutions against established criteria to determine a recommended solution to address an issue. A formal evaluation process involves the following actions:
· Establishing the criteria for evaluating alternatives
· Identifying alternative solutions
· Selecting methods for evaluating alternatives
· Evaluating the alternative solutions using the established criteria and methods
· Selecting recommended solutions from the alternatives based on the evaluation criteria
Rather than using the phrase “alternative solutions to address issues” each time it is needed, we will use one of two shorter phrases: “alternative solutions” or “alternatives.”
A formal evaluation process reduces the subjective nature of the decision and has a higher probability of selecting a solution that meets the multiple demands of relevant stakeholders.
While the primary application of this process area is to technical concerns, formal evaluation processes can also be applied to many nontechnical issues, particularly when a project is being planned. Issues that have multiple alternative solutions and evaluation criteria lend themselves to a formal evaluation process.
Trade studies of equipment or software are typical examples of formal evaluation processes.
During planning, specific issues requiring a formal evaluation process are identified. Typical issues include selection among architectural or design alternatives, use of reusable or commercial off-the-shelf (COTS) components, supplier selection, engineering support environments or associated tools, test environments, delivery alternatives, and logistics and production. A formal evaluation process can also be used to address a make-or-buy decision, the development of manufacturing processes, the selection of distribution locations, and other decisions.
Guidelines are created for deciding when to use formal evaluation processes to address unplanned issues. Guidelines often suggest using formal evaluation processes when issues are associated with medium to high risks or when issues affect the ability to achieve project objectives.
Formal evaluation processes can vary in formality, type of criteria, and methods employed. Less formal decisions can be analyzed in a few hours, use only a few criteria (e.g., effectiveness and cost to implement), and result in a one- or two-page report. More formal decisions may require separate plans, months of effort, meetings to develop and approve criteria, simulations, prototypes, piloting, and extensive documentation.
Both numeric and non-numeric criteria can be used in a formal evaluation process. Numeric criteria use weights to reflect the relative importance of the criteria. Non-numeric criteria use a more subjective ranking scale (e.g., high, medium, or low). More formal decisions may require a full trade study.
A formal evaluation process identifies and evaluates alternative solutions. The eventual selection of a solution may involve iterative activities of identification and evaluation. Portions of identified alternatives may be combined, emerging technologies may change alternatives, and the business situation of vendors may change during the evaluation period.
A recommended alternative is accompanied by documentation of the selected methods, criteria, alternatives, and rationale for the recommendation. The documentation is distributed to relevant stakeholders; it provides a record of the formal evaluation process and rationale that are useful to other projects that encounter a similar issue.
While some of the decisions made throughout the life of the project involve the use of a formal evaluation process, others do not. As mentioned earlier, guidelines should be established to determine which issues should be subjected to a formal evaluation process.
Related Process Areas
Refer to the Project Planning process area for more information about general planning for projects.
Refer to the Integrated Project Management process area for more information about establishing the project’s defined process. The project’s defined process includes a formal evaluation process for each selected issue and incorporates the use of guidelines for applying a formal evaluation process to unforeseen issues.
Refer to the Risk Management process area for more information about identifying and mitigating risks. A formal evaluation process is often used to address issues with identified medium or high risks. Selected solutions typically affect risk mitigation plans.

Specific Goal and Practice Summary

SG 1 Evaluate Alternatives
SP 1.1 Establish Guidelines for Decision Analysis
SP 1.2 Establish Evaluation Criteria
SP 1.3 Identify Alternative Solutions
SP 1.4 Select Evaluation Methods
SP 1.5 Evaluate Alternatives
SP 1.6 Select Solutions

SG 1 Evaluate Alternatives

Decisions are based on an evaluation of alternatives using established criteria.

Issues requiring a formal evaluation process may be identified at any time. The objective should be to identify issues as early as possible to maximize the time available to resolve them.

SP 1.1 Establish Guidelines for Decision Analysis

Establish and maintain guidelines to determine which issues are subject to a formal evaluation process.

Not every decision is significant enough to require a formal evaluation process. The choice between the trivial and the truly important will be unclear without explicit guidance. Whether a decision is significant or not is dependent on the project and circumstances, and is determined by the established guidelines.
Typical guidelines for determining when to require a formal evaluation process include the following:
· When a decision is directly related to topics assessed as being of medium or high risk
· When a decision is related to changing work products under configuration management
· When a decision would cause schedule delays over a certain percentage or specific amount of time
· When a decision affects the ability to achieve project objectives
· When the costs of the formal evaluation process are reasonable when compared to the decision’s impact
· When a legal obligation exists during a solicitation
Refer to the Risk Management process area for more information about determining which issues are medium or high risk.
Examples of when to use a formal evaluation process include the following:
· On decisions involving the procurement of material when 20 percent of the material parts constitute 80 percent of the total material costs
· On design-implementation decisions when technical performance failure may cause a catastrophic failure (e.g., safety of flight item)
· On decisions with the potential to significantly reduce design risk, engineering changes, cycle time, response time, and production costs (e.g., to use lithography models to assess form and fit capability before releasing engineering drawings and production builds)

Typical Work Products

1. Guidelines for when to apply a formal evaluation process
Subpractices
1. Establish guidelines.
2. Incorporate the use of the guidelines into the defined process where appropriate.
Refer to the Integrated Project Management process area for more information about establishing the project’s defined process.

SP 1.2 Establish Evaluation Criteria

Establish and maintain the criteria for evaluating alternatives, and the relative ranking of these criteria.

The evaluation criteria provide the basis for evaluating alternative solutions. The criteria are ranked so that the highest ranked criteria exert the most influence on the evaluation.
This process area is referenced by many other process areas in the model, and there are many contexts in which a formal evaluation process can be used. Therefore, in some situations you may find that criteria have already been defined as part of another process. This specific practice does not suggest that a second development of criteria be conducted.
Document the evaluation criteria to minimize the possibility that decisions will be second-guessed, or that the reason for making the decision will be forgotten. Decisions based on criteria that are explicitly defined and established remove barriers to stakeholder buy-in.

Typical Work Products

1. Documented evaluation criteria
2. Rankings of criteria importance
Subpractices
1. Define the criteria for evaluating alternative solutions.
Criteria should be traceable to requirements, scenarios, business case assumptions, business objectives, or other documented sources. Types of criteria to consider include the following:
· Technology limitations
· Environmental impact
· Risks
· Total ownership and lifecycle costs
2. Define the range and scale for ranking the evaluation criteria.
Scales of relative importance for evaluation criteria can be established with non-numeric values or with formulas that relate the evaluation parameter to a numeric weight.
3. Rank the criteria.
The criteria are ranked according to the defined range and scale to reflect the needs, objectives, and priorities of the relevant stakeholders.
4. Assess the criteria and their relative importance.
5. Evolve the evaluation criteria to improve their validity.
6. Document the rationale for the selection and rejection of evaluation criteria.
Documentation of selection criteria and rationale may be needed to justify solutions or for future reference and use.

SP 1.3 Identify Alternative Solutions

Identify alternative solutions to address issues.

A wider range of alternatives can surface by soliciting as many stakeholders as practical for input. Input from stakeholders with diverse skills and backgrounds can help teams identify and address assumptions, constraints, and biases. Brainstorming sessions may stimulate innovative alternatives through rapid interaction and feedback. Sufficient candidate solutions may not be furnished for analysis. As the analysis proceeds, other alternatives should be added to the list of potential candidate solutions. The generation and consideration of multiple alternatives early in a decision analysis and resolution process increases the likelihood that an acceptable decision will be made, and that consequences of the decision will be understood.

Typical Work Products

1. Identified alternatives
Subpractices
1. Perform a literature search.
A literature search can uncover what others have done both inside and outside the organization. It may provide a deeper understanding of the problem, alternatives to consider, barriers to implementation, existing trade studies, and lessons learned from similar decisions.
2. Identify alternatives for consideration in addition to those that may be provided with the issue.
Evaluation criteria are an effective starting point for identifying alternatives. The evaluation criteria identify the priorities of the relevant stakeholders and the importance of technical, logistical, or other challenges.
Combining key attributes of existing alternatives can generate additional and sometimes stronger alternatives.
Solicit alternatives from relevant stakeholders. Brainstorming sessions, interviews, and working groups can be used effectively to uncover alternatives.
3. Document the proposed alternatives.

SP 1.4 Select Evaluation Methods

Select the evaluation methods.

Methods for evaluating alternative solutions against established criteria can range from simulations to the use of probabilistic models and decision theory. These methods need to be carefully selected. The level of detail of a method should be commensurate with cost, schedule, performance, and risk impacts.
While many problems may need only one evaluation method, some problems may require multiple methods. For instance, simulations may augment a trade study to determine which design alternative best meets a given criterion.

Typical Work Products

1. Selected evaluation methods
Subpractices
1. Select the methods based on the purpose for analyzing a decision and on the availability of the information used to support the method.
For example, the methods used for evaluating a solution when requirements are weakly defined may be different from the methods used when the requirements are well defined.

Typical evaluation methods include the following:
· Modeling and simulation
· Engineering studies
· Manufacturing studies
· Cost studies
· Business opportunity studies
· Surveys
· Extrapolations based on field experience and prototypes
· User review and comment
· Testing
· Judgment provided by an expert or group of experts (e.g., Delphi Method)
2. Select evaluation methods based on their ability to focus on the issues at hand without being overly influenced by side issues.
Results of simulations can be skewed by random activities in the solution that are not directly related to the issues at hand.
3. Determine the measures needed to support the evaluation method.
Consider the impact on cost, schedule, performance, and risks.

SP 1.5 Evaluate Alternatives

Evaluate alternative solutions using the established criteria and methods.

Evaluating alternative solutions involves analysis, discussion, and review. Iterative cycles of analysis are sometimes necessary. Supporting analyses, experimentation, prototyping, piloting, or simulations may be needed to substantiate scoring and conclusions.
Often, the relative importance of criteria is imprecise and the total effect on a solution is not apparent until after the analysis is performed. In cases where the resulting scores differ by relatively small amounts, the best selection among alternative solutions may not be clear cut. Challenges to criteria and assumptions should be encouraged.

Typical Work Products

1. Evaluation results
Subpractices
1. Evaluate the proposed alternative solutions using the established evaluation criteria and selected methods.
2. Evaluate the assumptions related to the evaluation criteria and the evidence that supports the assumptions.
3. Evaluate whether uncertainty in the values for alternative solutions affects the evaluation and address as appropriate.
For instance, if the score can vary between two values, is the difference significant enough to make a difference in the final solution set? Does the variation in score represent a high risk? To address these concerns, simulations may be run, further studies may be performed, or evaluation criteria may be modified, among other things.
4. Perform simulations, modeling, prototypes, and pilots as necessary to exercise the evaluation criteria, methods, and alternative solutions.
Untested criteria, their relative importance, and supporting data or functions may cause the validity of solutions to be questioned. Criteria and their relative priorities and scales can be tested with trial runs against a set of alternatives. These trial runs of a select set of criteria allow for the evaluation of the cumulative impact of the criteria on a solution. If the trials reveal problems, different criteria or alternatives might be considered to avoid biases.
5. Consider new alternative solutions, criteria, or methods if the proposed alternatives do not test well; repeat the evaluations until alternatives do test well.
6. Document the results of the evaluation.
Document the rationale for the addition of new alternatives or methods and changes to criteria, as well as the results of interim evaluations.

SP 1.6 Select Solutions

Select solutions from the alternatives based on the evaluation criteria.

Selecting solutions involves weighing the results from the evaluation of alternatives. Risks associated with implementation of the solutions must be assessed.

Typical Work Products

1. Recommended solutions to address significant issues
Subpractices
1. Assess the risks associated with implementing the recommended solution.
Refer to the Risk Management process area for more information about identifying and managing risks.
Decisions must often be made with incomplete information. There can be substantial risk associated with the decision because of having incomplete information.
When decisions must be made according to a specific schedule, time and resources may not be available for gathering complete information. Consequently, risky decisions made with incomplete information may require re-analysis later. Identified risks should be monitored.
2. Document the results and rationale for the recommended solution.
It is important to record both why a solution is selected and why another solution was rejected.

4.5. INTEGRATED PROJECT MANAGEMENT + IPPD

Purpose

The purpose of Integrated Project Management (IPM) is to establish and manage the project and the involvement of the relevant stakeholders according to an integrated and defined process that is tailored from the organization’s set of standard processes.

IPPD Addition
For IPPD, Integrated Project Management + IPPD also covers the establishment of a shared vision for the project and the establishment of integrated teams that will carry out objectives of the project.
Introductory Notes
Integrated Project Management involves the following:
· Establishing the project’s defined process at project startup by tailoring the organization’s set of standard processes
· Managing the project using the project’s defined process
· Establishing the work environment for the project based on the organization's work environment standards
· Using and contributing to the organizational process assets
· Enabling relevant stakeholders’ concerns to be identified, considered, and, when appropriate, addressed during the development of the product
· Ensuring that the relevant stakeholders perform their tasks in a coordinated and timely manner (1) to address product and product component requirements, plans, objectives, problems, and risks; (2) to fulfill their commitments; and (3) to identify, track, and resolve coordination issues
IPPD Addition
Integrated Project Management + IPPD also involves the following:
· Establishing a shared vision for the project
· Establishing integrated teams that are tasked to accomplish project objectives
The integrated and defined process that is tailored from the organization’s set of standard processes is called the project’s defined process.
Managing the project’s effort, cost, schedule, staffing, risks, and other factors is tied to the tasks of the project’s defined process. The implementation and management of the project’s defined process are typically described in the project plan. Certain activities may be covered in other plans that affect the project, such as the quality assurance plan, risk management strategy, and the configuration management plan.
Since the defined process for each project is tailored from the organization’s set of standard processes, variability among projects is typically reduced and projects can more easily share process assets, data, and lessons learned.
This process area also addresses the coordination of all activities associated with the project such as the following:
· Development activities (e.g., requirements development, design, and verification)
· Service activities (e.g., delivery, help desk, operations, and customer contact)
· Acquisition activities (e.g., solicitation, contract monitoring, and transition to operation)
· Support activities (e.g., configuration management, documentation, marketing, and training)
The working interfaces and interactions among relevant stakeholders internal and external to the project are planned and managed to ensure the quality and integrity of the entire product. Relevant stakeholders participate, as appropriate, in defining the project’s defined process and the project plan. Reviews and exchanges are regularly conducted with the relevant stakeholders to ensure that coordination issues receive appropriate attention and everyone involved with the project is appropriately aware of the status, plans, and activities. (See the definition of “relevant stakeholder” in the glossary.) In defining the project’s defined process, formal interfaces are created as necessary to ensure that appropriate coordination and collaboration occurs.
This process area applies in any organizational structure, including projects that are structured as line organizations, matrix organizations, or integrated teams. The terminology should be appropriately interpreted for the organizational structure in place.
Related Process Areas
Refer to the Project Planning process area for more information about planning the project, which includes identifying relevant stakeholders and their appropriate involvement in the project.
Refer to the Project Monitoring and Control process area for more information about monitoring and controlling the project.
Refer to the Verification process area for more information about peer reviews.
Refer to the Organizational Process Definition process area for more information about organizational process assets and work environment standards.
Refer to the Measurement and Analysis process area for more information about defining a process for measuring and analyzing processes.
IPPD Addition
Refer to the Organizational Process Definition +IPPD process area for more information about creating the organizational rules and guidelines for IPPD.
Specific Goal and Practice Summary

SG 1 Use the Project’s Defined Process
SP 1.1 Establish the Project’s Defined Process
SP 1.2 Use Organizational Process Assets for Planning Project Activities
SP 1.3 Establish the Project's Work Environment
SP 1.4 Integrate Plans
SP 1.5 Manage the Project Using the Integrated Plans
SP 1.6 Contribute to the Organizational Process Assets

SG 2 Coordinate and Collaborate with Relevant Stakeholders
SP 2.1 Manage Stakeholder Involvement
SP 2.2 Manage Dependencies
SP 2.3 Resolve Coordination Issues

IPPD Addition

SG 3 Apply IPPD Principles
SP 3.1 Establish the Project’s Shared Vision
SP 3.2 Establish the Integrated Team Structure
SP 3.3 Allocate Requirements to Integrated Teams
SP 3.4 Establish Integrated Teams
SP 3.5 Ensure Collaboration among Interfacing Teams

SG 1 Use the Project's Defined Process

The project is conducted using a defined process that is tailored from the organization's set of standard processes.

The project’s defined process must include those processes from the organization’s set of standard processes that address all processes necessary to acquire or develop and maintain the product. The product-related lifecycle processes, such as the manufacturing and support processes, are developed concurrently with the product.

SP 1.1 Establish the Project's Defined Process

Establish and maintain the project's defined process from project startup through the life of the project.

Refer to the Organizational Process Definition process area for more information about the organizational process assets.
Refer to the Organizational Process Focus process area for more information about organizational process needs and objectives and deploying the organization’s set of standard processes on projects.
The project’s defined process consists of defined processes that form an integrated, coherent lifecycle for the project.

IPPD Addition
The project’s defined process supports IPPD with processes that
· Make the integrated project management environment more amenable to collocated or distributed teams
· Select the project's integrated team structure
· Allocate limited personnel resources
· Implement cross-integrated team communication

The project's defined process should satisfy the project's contractual and operational needs, opportunities, and constraints. It is designed to provide a best fit for the project’s needs. A project's defined process is based on the following factors:
· Customer requirements
· Product and product component requirements
· Commitments
· Organizational process needs and objectives
· Organization’s set of standard processes and tailoring guidelines
· Operational environment
· Business environment
Establishing the project’s defined process at project startup helps to ensure that project staff and stakeholders implement a set of activities needed to efficiently establish an initial set of requirements and plans for the project. As the project progresses, the description of the project’s defined process is elaborated and revised to better meet the project’s requirements and the organization’s process needs and objectives. Also, as the organization’s set of standard processes change, the project’s defined process may need to be revised.
Typical Work Products
1. The project’s defined process
Subpractices
1. Select a lifecycle model from those available from the organizational process assets.
Examples of project characteristics that could affect the selection of lifecycle models include the following:
· Size of the project
· Experience and familiarity of staff in implementing the process
· Constraints such as cycle time and acceptable defect levels

2. Select the standard processes from the organization's set of standard processes that best fit the needs of the project.
3. Tailor the organization’s set of standard processes and other organizational process assets according to the tailoring guidelines to produce the project’s defined process.
Sometimes the available lifecycle models and standard processes are inadequate to meet a specific project’s needs. Sometimes the project will be unable to produce required work products or measures. In such circumstances, the project will need to seek approval to deviate from what is required by the organization. Waivers are provided for this purpose.
4. Use other artifacts from the organization's process asset library as appropriate.
Other artifacts may include the following:
· Lessons-learned documents
· Templates
· Example documents
· Estimating models
5. Document the project's defined process.
The project's defined process covers all of the activities for the project and its interfaces to relevant stakeholders.
Examples of project activities include the following:
· Project planning
· Project monitoring
· Requirements development
· Requirements management
· Supplier management
· Configuration management
· Quality assurance
· Risk management
· Decision analysis and resolution
· Product development and support
· Solicitation

6. Conduct peer reviews of the project's defined process.
Refer to the Verification process area for more information about conducting peer reviews.
7. Revise the project's defined process as necessary.

SP 1.2 Use Organizational Process Assets for Planning Project Activities

Use the organizational process assets and measurement repository for estimating and planning the project’s activities.

Refer to the Organizational Process Definition process area for more information about organizational process assets and the organization’s measurement repository.
Typical Work Products
1. Project estimates
2. Project plans
Subpractices
1. Use the tasks and work products of the project's defined process as a basis for estimating and planning the project's activities.
An understanding of the relationships among the various tasks and work products of the project's defined process, and of the roles to be performed by the relevant stakeholders, is a basis for developing a realistic plan.
2. Use the organization’s measurement repository in estimating the project’s planning parameters.
This estimate typically includes the following:
· Using appropriate historical data from this project or similar projects
· Accounting for and recording similarities and differences between the current project and those projects whose historical data will be used
· Independently validating the historical data
· Recording the reasoning, assumptions, and rationale used to select the historical data
Examples of parameters that are considered for similarities and differences include the following:
· Work product and task attributes
· Application domain
· Design approach
· Operational environment
· Experience of the people

Examples of data contained in the organization’s measurement repository include the following:
· Size of work products or other work product attributes
· Effort
· Cost
· Schedule
· Staffing
· Defects
· Response time
· Service capacity
· Supplier performance

SP 1.3 Establish the Project's Work Environment

Establish and maintain the project's work environment based on the organization's work environment standards.
An appropriate work environment for a project comprises an infrastructure of facilities, tools, and equipment that people need to perform their jobs effectively in support of business and project objectives. The work environment and its components are maintained at a level of performance and reliability indicated by the organizational work environment standards. As required, the project’s work environment or some of its components can be developed internally or acquired from external sources.

IPPD Addition
An effective work environment helps projects employing IPPD to conduct work using collocated or distributed integrated teams. Two-way communications media should be readily accessible by all relevant stakeholders in the project.

The project’s work environment might encompass environments for product integration, verification, and validation or they might be separate environments.
Refer to the Establish Work Environment Standards specific practice in the Organizational Process Definition process area for more information about work environment standards.
Refer to the Establish the Product Integration Environment specific practice of the Product Integration process area for more information about establishing and maintaining the product integration environment for the project.
Refer to the Establish the Verification Environment specific practice of the Verification process area for more information about establishing and maintaining the verification environment for the project.
Refer to the Establish the Validation Environment specific practice of the Validation process area for more information about establishing and maintaining the validation environment for the project.
Typical Work Products
1. Equipment and tools for the project
2. Installation, operation, and maintenance manuals for the project work environment
3. User surveys and results
4. Usage, performance, and maintenance records
5. Support services for the project’s work environment
Subpractices
1. Plan, design, and install a work environment for the project.
The critical aspects of the project work environment are, like any other product, requirements driven. Work environment functionality and operations are explored with the same rigor as is done for any other product development.
It may be necessary to make tradeoffs among performance, costs, and risks. The following are examples of each:
· Performance considerations may include timely interoperable communications, safety, security, and maintainability.
· Costs may include capital outlays, training, support structure, disassembly and disposal of existing environments, and operation and maintenance of the environment.
· Risks may include workflow and project disruptions.

Examples of equipment and tools include the following:
· Office software
· Decision support software
· Project management tools
· Requirements management tools, design tools
· Configuration management tools
· Evaluation tools
· Test and/or evaluation equipment

2. Provide ongoing maintenance and operational support for the project’s work environment.
Maintenance and support of the work environment can be accomplished either with capabilities found inside the organization or hired from outside the organization.
Examples of maintenance and support approaches include the following:
· Hiring people to perform the maintenance and support
· Training people to perform the maintenance and support
· Contracting the maintenance and support
· Developing expert users for selected tools

3. Maintain the qualification of the components of the project’s work environment.
Components include software, databases, hardware, tools, test equipment, and appropriate documentation. Qualification of software includes appropriate certifications. Hardware and test equipment qualification includes calibration and adjustment records and traceability to calibration standards.
4. Periodically review how well the work environment is meeting the project’s needs and supporting collaboration, and take action as appropriate.
Examples of actions that might be taken include the following:
· Adding new tools
· Acquiring additional networks, equipment, training, and support

SP 1.4 Integrate Plans

Integrate the project plan and the other plans that affect the project to describe the project’s defined process.

Refer to the Project Planning process area for more information about establishing and maintaining a project plan.
Refer to the Organizational Process Definition process area for more information about organizational process assets and, in particular, the organization’s measurement repository.
Refer to the Measurement and Analysis process area for more information about defining measures and measurement activities and using analytic techniques.
Refer to the Risk Management process area for more information about identifying and analyzing risks.
Refer to the Organizational Process Focus process area for more information about organizational process needs and objectives.
This specific practice extends the specific practices for establishing and maintaining a project plan to address additional planning activities such as incorporating the project’s defined process, coordinating with relevant stakeholders, using organizational process assets, incorporating plans for peer reviews, and establishing objective entry and exit criteria for tasks.
The development of the project plan should account for current and projected needs, objectives, and requirements of the organization, customer, suppliers, and end users, as appropriate.

IPPD Addition
The plans of the integrated teams are included in this integration. Developing a complete project plan and the project’s defined process may require an iterative effort if a complex, multi-layered, integrated team structure is being deployed.

Typical Work Products
1. Integrated plans
Subpractices
1. Integrate other plans that affect the project with the project plan.
Other plans that affect the project may include the following:
· Quality assurance plans
· Configuration management plans
· Risk management strategy
· Documentation plans
2. Incorporate into the project plan the definitions of measures and measurement activities for managing the project.
Examples of measures that would be incorporated include the following:
· Organization’s common set of measures
· Additional project-specific measures

3. Identify and analyze product and project interface risks.
Examples of product and project interface risks include the following:
· Incomplete interface descriptions
· Unavailability of tools or test equipment
· Availability of COTS components
· Inadequate or ineffective team interfaces

4. Schedule the tasks in a sequence that accounts for critical development factors and project risks.
Examples of factors considered in scheduling include the following:
· Size and complexity of the tasks
· Integration and test issues
· Needs of the customer and end users
· Availability of critical resources
· Availability of key personnel

5. Incorporate the plans for performing peer reviews on the work products of the project's defined process.
Refer to the Verification process area for more information about peer reviews.
6. Incorporate the training needed to perform the project’s defined process in the project’s training plans.
This task typically involves negotiating with the organizational training group the support they will provide.
7. Establish objective entry and exit criteria to authorize the initiation and completion of the tasks described in the work breakdown structure (WBS).
Refer to the Project Planning process area for more information about the WBS.
8. Ensure that the project plan is appropriately compatible with the plans of relevant stakeholders.
Typically the plan and changes to the plan will be reviewed for compatibility.
9. Identify how conflicts will be resolved that arise among relevant stakeholders.

SP 1.5 Manage the Project Using the Integrated Plans

Manage the project using the project plan, the other plans that affect the project, and the project’s defined process.
Refer to the Organizational Process Definition process area for more information about the organizational process assets.
Refer to the Organizational Process Focus process area for more information about organizational process needs and objectives and coordinating process improvement activities with the rest of the organization.
Refer to the Risk Management process area for more information about managing risks.
Refer to the Project Monitoring and Control process area for more information about monitoring and controlling the project.
Typical Work Products
1. Work products created by performing the project’s defined process
2. Collected measures (“actuals”) and progress records or reports
3. Revised requirements, plans, and commitments
4. Integrated plans
Subpractices
1. Implement the project’s defined process using the organization's process asset library.
This task typically includes the following:
· Incorporating artifacts from the organization’s process asset library into the project as appropriate
· Using lessons learned from the organization’s process asset library to manage the project
2. Monitor and control the project’s activities and work products using the project’s defined process, project plan, and other plans that affect the project.
This task typically includes the following:
· Using the defined entry and exit criteria to authorize the initiation and determine the completion of the tasks
· Monitoring the activities that could significantly affect the actual values of the project’s planning parameters
· Tracking the project’s planning parameters using measurable thresholds that will trigger investigation and appropriate actions
· Monitoring product and project interface risks
· Managing external and internal commitments based on the plans for the tasks and work products of the project’s defined process
An understanding of the relationships among the various tasks and work products of the project’s defined process, and of the roles to be performed by the relevant stakeholders, along with well-defined control mechanisms (e.g., peer reviews) achieves better visibility into the project’s performance and better control of the project.
3. Obtain and analyze the selected measures to manage the project and support the organization’s needs.
Refer to the Measurement and Analysis process area for more information about defining a process for obtaining and analyzing measures.
4. Periodically review and align the project’s performance with the current and anticipated needs, objectives, and requirements of the organization, customer, and end users, as appropriate.
This review includes alignment with the organizational process needs and objectives.
Examples of actions that achieve alignment include the following:
· Accelerating the schedule, with appropriate adjustments to other planning parameters and the project risks
· Changing the requirements in response to a change in market opportunities or customer and end-user needs
· Terminating the project

SP 1.6 Contribute to the Organizational Process Assets

Contribute work products, measures, and documented experiences to the organizational process assets.

Refer to the Organizational Process Focus process area for more information about process improvement proposals.
Refer to the Organizational Process Definition process area for more information about the organizational process assets, the organization’s measurement repository, and the organization’s process asset library.
This specific practice addresses collecting information from processes in the project’s defined process.
Typical Work Products
1. Proposed improvements to the organizational process assets
2. Actual process and product measures collected from the project
3. Documentation (e.g., exemplary process descriptions, plans, training modules, checklists, and lessons learned)
4. Process artifacts associated with tailoring and implementing the organization’s set of standard processes on the project
Subpractices
1. Propose improvements to the organizational process assets.
2. Store process and product measures in the organization’s measurement repository.
Refer to the Project Planning process area for more information about recording planning and replanning data.
Refer to the Project Monitoring and Control process area for more information about recording measures.
This typically includes the following:
· Planning data
· Replanning data
· Measures
Examples of data recorded by the project include the following:
· Task descriptions
· Assumptions
· Estimates
· Revised estimates
· Definitions of recorded data and measures
· Measures
· Context information that relates the measures to the activities performed and work products produced
· Associated information needed to reconstruct the estimates, assess their reasonableness, and derive estimates for new work

3. Submit documentation for possible inclusion in the organization's process asset library.
Examples of documentation include the following:
· Exemplary process descriptions
· Training modules
· Exemplary plans
· Checklists

4. Document lessons learned from the project for inclusion in the organization's process asset library.
5. Provide process artifacts associated with tailoring and implementing the organization’s set of standard processes in support of the organization’s process monitoring activities.
Refer to the Monitor Implementation specific practice of the Organization Process Focus process area for more information about the organization’s activities to understand the extent of deployment of standard processes on new and existing projects.

SG 2 Coordinate and Collaborate with Relevant Stakeholders

Coordination and collaboration of the project with relevant stakeholders is conducted.

SP 2.1 Manage Stakeholder Involvement

Manage the involvement of the relevant stakeholders in the project.

Stakeholder involvement is managed according to the project’s integrated and defined process.
Refer to the Project Planning process area for more information about identifying stakeholders and their appropriate involvement and about establishing and maintaining commitments.
Typical Work Products
1. Agendas and schedules for collaborative activities
2. Documented issues (e.g., issues with customer requirements, product and product component requirements, product architecture, and product design)
3. Recommendations for resolving relevant stakeholder issues
Subpractices
1. Coordinate with the relevant stakeholders who should participate in the project’s activities.
The relevant stakeholders should already be identified in the project plan.
2. Ensure that work products that are produced to satisfy commitments meet the requirements of the recipient projects.
Refer to the Verification process area for more information about verifying work products against their requirements.
This task typically includes the following:
· Reviewing, demonstrating, or testing, as appropriate, each work product produced by relevant stakeholders
· Reviewing, demonstrating, or testing, as appropriate, each work product produced by the project for other projects with representatives of the projects receiving the work product
· Resolving issues related to the acceptance of the work products
3. Develop recommendations and coordinate the actions to resolve misunderstandings and problems with the product and product component requirements, product and product component architecture, and product and product component design.

SP 2.2 Manage Dependencies

Participate with relevant stakeholders to identify, negotiate, and track critical dependencies.

Refer to the Project Planning process area for more information about identifying stakeholders and their appropriate involvement and about establishing and maintaining commitments.
Typical Work Products
1. Defects, issues, and action items resulting from reviews with relevant stakeholders
2. Critical dependencies
3. Commitments to address critical dependencies
4. Status of critical dependencies
Subpractices
1. Conduct reviews with relevant stakeholders.
2. Identify each critical dependency.
3. Establish need dates and plan dates for each critical dependency based on the project schedule.
4. Review and get agreement on the commitments to address each critical dependency with the people responsible for providing the work product and the people receiving the work product.
5. Document the critical dependencies and commitments.
Documentation of commitments typically includes the following:
· Describing the commitment
· Identifying who made the commitment
· Identifying who is responsible for satisfying the commitment
· Specifying when the commitment will be satisfied
· Specifying the criteria for determining if the commitment has been satisfied
6. Track the critical dependencies and commitments and take corrective action as appropriate.
Refer to the Project Monitoring and Control process area for more information about tracking commitments.
Tracking the critical dependencies typically includes the following:
· Evaluating the effects of late and early completion for impacts on future activities and milestones
· Resolving actual and potential problems with the responsible people whenever possible
· Escalating to the appropriate managers the actual and potential problems not resolvable with the responsible people

SP 2.3 Resolve Coordination Issues

Resolve issues with relevant stakeholders.

Examples of coordination issues include the following:
· Late critical dependencies and commitments
· Product and product component requirements and design defects
· Product-level problems
· Unavailability of critical resources or personnel

Typical Work Products
1. Relevant stakeholder coordination issues
2. Status of relevant stakeholder coordination issues
Subpractices
1. Identify and document issues.
2. Communicate issues to the relevant stakeholders.
3. Resolve issues with the relevant stakeholders.
4. Escalate to the appropriate managers those issues not resolvable with the relevant stakeholders.
5. Track the issues to closure.
6. Communicate with the relevant stakeholders on the status and resolution of the issues.

SG 3 Apply IPPD Principles

The project is managed using IPPD principles.

The purpose of this specific goal and its practices is to create an IPPD environment that enables integrated teams to efficiently meet the project’s requirements and produce a quality product.

SP 3.1 Establish the Project's Shared Vision

Establish and maintain a shared vision for the project.

A project does not operate in isolation. Understanding organizational mission, goals, expectations and constraints allows the project to align its direction, activities, and shared vision with the organization and helps create a common purpose within which project activities can be coordinated. To enable this, it is critical to understand the interfaces between the project and stakeholders external to the project and the objectives and expectations of all relevant stakeholders (internal and external).
When creating a shared vision, consider:
· external stakeholder expectations and requirements
· the aspirations and expectations of the project leader, team leaders, and team members
· the project’s objectives
· the conditions and outcomes the project will create
· interfaces the project needs to maintain
· the visions created by interfacing groups
· the constraints imposed by outside authorities (e.g., environmental regulations)
· project operation while working to achieve its objectives (both principles and behaviors)
When creating a shared vision, all people in the project should be invited to participate. Although there may be a draft proposal, the larger population must have an opportunity to speak and be heard about what really matters to them. The shared vision is articulated in terms of both the core ideology (values, principles, and behaviors) and the desired future to which each member of the project can commit.
An effective communications strategy is key to implementing and focusing the shared vision throughout the project. Promulgation of the shared vision is a public declaration of the commitment of the project to their shared vision and provides the opportunity for others to examine, understand, and align their activities in a common direction. The shared vision should be communicated, and agreement and commitment of the relevant stakeholders should be obtained.


Effective communications are also especially important when incorporating new project members. New members of the project often need more or special attention to ensure that they understand the shared vision, have a stake in it, and are prepared to follow it in doing their work.
Typical Work Products
1. Documented shared vision
2. Communications strategy
3. Published principles, shared vision statement, mission statement, and objectives (e.g., posters, wallet cards, and presentations)
Subpractices
1. Articulate the project’s shared vision in terms of purpose or mission, vision, values, and objectives.
2. Reach consensus on the project’s shared vision.
3. Establish a strategy to communicate the project’s shared vision both externally and internally.
4. Create presentations suitable for the various audiences that need to be informed about the project’s shared vision.
5. Ensure that project and individual activities and tasks are aligned with the project’s shared vision.

SP 3.2 Establish the Integrated Team Structure

Establish and maintain the integrated team structure for the project.
Product requirements, cost, schedule, risk, resource projections, business processes, the project’s defined process, and organizational guidelines are evaluated to establish the basis for defining integrated teams and their responsibilities, authorities, and interrelationships.
A typical integrated team structure may be based on the product-oriented hierarchy found in the WBS. More complex structuring occurs when the WBS is not product oriented, product risks are not uniform, and resources are constrained.

The integrated team structure is a dynamic entity that is adjusted to changes in people, requirements, and the nature of tasks, and to tackle many difficulties. For small projects, the integrated team structure can treat the whole project as an integrated team. The integrated team structure should be continuously monitored to detect malfunctions, mismanaged interfaces, and mismatches of the work to the staff. Corrective action should be taken when performance does not meet expectations.
Refer to the Establish Rules and Guidelines for Integrated Teams specific practice in the Organizational Process Definition +IPPD process area for more information about establishing organizational rules and guidelines for structuring and forming integrated teams.
Typical Work Products
1. Assessments of the product and product architectures, including risk and complexity
2. Integrated team structure
Subpractices
1. Establish an integrated team structure.
An integrated team structure is dependent on:
· An assessment of product risk and complexity
· Location and types of risks
· Integration risks, including product component interfaces and inter-team communication
· Resources, including availability of appropriately skilled people
· Limitations on team size for effective collaboration
· Need for team membership of stakeholders external to the project
· Business processes
· Organizational structure
The integrated team structure should be based on an understanding of the project’s defined process and shared vision, the organization’s standard processes, and the organizational process assets applicable to teams and team structures.
2. Periodically evaluate and modify the integrated team structure to best meet project needs.
Changes to the product requirements or architecture could affect the team structure.


Continuously monitor the integrated team structure to detect problems such as mismanaged interfaces, and mismatches between the work assigned and the staff performing the work. Take corrective action, including assessing the deployed teams and structures, when performance does not meet expectations.
Changes in team structure can include the following:
· Retiring a team for a period of time (e.g., while long-duration manufacturing or verifications are done)
· Disbanding a team when it is no longer cost effective in serving the project
· Combining teams to achieve operating efficiencies

SP 3.3 Allocate Requirements to Integrated Teams

Allocate requirements, responsibilities, tasks, and interfaces to teams in the integrated team structure.

This allocation of requirements to integrated teams is done before any teams are formed to verify that the integrated team structure is workable and covers all the necessary requirements, responsibilities, authorities, tasks, and interfaces. Once the structure is confirmed, integrated team sponsors are chosen to establish the individual teams in the structure.
Typical Work Products
1. Responsibilities allocated to each integrated team
2. Work product requirements, technical interfaces, and business (e.g., cost accounting and project management) interfaces each integrated team will be responsible for satisfying
3. List of integrated team sponsors
Subpractices
1. Allocate the tasks, responsibilities, and work products to be delivered, and the associated requirements and interfaces to the appropriate integrated teams.
Business, management, and other nontechnical responsibilities and authorities for each integrated team are necessary elements to proper team function. Integrated team responsibilities and authorities are normally developed by the project and are consistent with established organization practices.


Example responsibilities and authorities, include the following:
· Authority of teams to pick their own leader
· Authority of teams to implement subteams (e.g., a product team forming an integration subteam)
· Reporting chains
· Reporting requirements (cost, schedule, and performance status)
· Progress reporting measures and methods

2. Check that the distribution of requirements and interfaces covers all specified product requirements and other requirements.
In the event that complete coverage of requirements is not achieved, corrective action should be taken to redistribute requirements or to alter the integrated team structure.
3. Designate the sponsor for each integrated team.
An integrated team sponsor is a manager (individual or team) who is responsible for establishing and providing resources to an integrated team, monitoring its activities and progress, and taking corrective action when needed. A sponsor may manage one or many teams. Team sponsors can be project managers.

SP 3.4 Establish Integrated Teams

Establish and maintain integrated teams in the structure.

The integrated teams within the integrated team structure are established by the team sponsors. This process encompasses choosing team leaders and team members, and establishing the team charter for each integrated team based on the allocation of requirements. It also involves providing the resources required to accomplish the tasks assigned to the team.
Refer to the Establish Rules and Guidelines for Integrated Teams specific practice in the Organizational Process Definition +IPPD process area for more information about establishing organizational rules and guidelines for structuring and forming integrated teams.
Typical Work Products
1. List of team leaders
2. List of team members assigned to each integrated team
3. Integrated team charters
4. Measures for evaluating the performance of integrated teams
5. Periodic integrated team status reports
Subpractices
1. Choose a leader for each integrated team.
The extent of organizational and project direction in selecting the leader is often a function of product risk and complexity or an organization’s need to “grow” new leaders. Team sponsors may select the team leader or team members may vote on a leader from within the team, depending on organizational policies.
2. Allocate resources to each integrated team.
The people and other resources are allocated to each integrated team. These items are discussed with the team to ensure that the resources are adequate and that the people are adequate to carry out the tasks and are compatible with other members of the team.
3. Charter each integrated team.
The team charter is the contract among the team members and between the team and its sponsor for the expected work and level of performance. Charters establish the rights, guarantees, privileges, and permissions for organizing and performing the team’s assigned requirements and interfaces, responsibilities and tasks. The integrated team and its sponsor develop the team charter as a negotiation activity. When both approve it, the team charter constitutes a recognized agreement with management authority.
Charters can include the following aspects:
· How assignments are accepted
· How resources and input are accessed
· How work gets done
· Who checks and reviews work
· How work is approved
· How work is delivered and communicated
4. Review the composition of an integrated team and its place in the integrated team structure when its team leader changes or another significant change of membership occurs.
A change of this kind may significantly affect the ability of the team to accomplish its objectives. A review of the match between the new composition and the current responsibilities should be made. If the match is not satisfactory, the team composition should be changed or the team’s responsibility should be modified.
5. Review the composition of a team and its tasking when a change in team responsibility occurs.
Changes in responsibilities often occur as the project moves from one phase to the next. For example, less design expertise on teams may be needed when detailed design is completed and fabrication and integration of product components begins.
6. Manage the overall performance of the teams.
The charter should specify how both team and individual performance will be measured and should include the critical success factors for the team within the project.

SP 3.5 Ensure Collaboration among Interfacing Teams

Ensure collaboration among interfacing teams.

The success of an integrated team-based project is a function of how effectively and successfully the integrated teams collaborate with one another to achieve project objectives. This collaboration may be accomplished using interface control working groups.
See the Coordinate and Collaborate with Relevant Stakeholders specific goal of this process area for more information about managing stakeholder involvement, critical dependencies, and resolving coordination issues.
Refer to the Establish Rules and Guidelines for Integrated Teams specific practice in the Organizational Process Definition +IPPD process area for more information about establishing organizational expectations and rules that will guide how the integrated teams work collectively.
Typical Work Products
1. Work product ownership agreements
2. Team work plans
3. Commitment lists
Subpractices
1. Establish and maintain the boundaries of work product ownership among interfacing teams within the project or organization.
2. Establish and maintain interfaces and processes among interfacing teams for the exchange of inputs, outputs, or work products.