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.
Integrated Project Management involves the following activities:
• 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
• Establishing integrated teams that are tasked to accomplish project objectives
• Using and contributing to organizational process assets
• Enabling relevant stakeholders’ concerns to be identified, considered, and, when appropriate, addressed during the development of the product
• Ensuring that 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
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.
Using IPM to guide project management activities enables project plans to be consistent with project activities because they are both derived from standard processes created by the organization. Further, plans tend to be more reliable and are developed more quickly, and new projects learn more quickly.
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.
It is also easier to share resources (e.g., training and software tools) and to “load-balance” staff members across projects.
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 relevant stakeholders to ensure that coordination issues receive appropriate attention and everyone involved with the project is appropriately aware of 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 occur.
The acquirer must involve and integrate all relevant acquisition, technical, support, and operational stakeholders. Depending on the scope and risk of the project, coordination efforts with the supplier can be significant.
A proactive approach to integrating plans and coordinating with relevant stakeholders outside the project is a key activity. This is particularly important when multiple projects must work together to provide needed capabilities.
Formal interfaces among relevant stakeholders take the form of memorandums of understanding, memorandums of agreement, contractual commitments, associated supplier agreements, and similar documents, depending on the nature of the interfaces and involved stakeholders.
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.
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 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.
Refer to the Agreement Management process area for more information about managing supplier agreements.
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 Integrated Plans
SP 1.6 Establish Integrated Teams
SP 1.7 Contribute to 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
In developing the acquisition model, what was the IPM IPPD addition in the CMMI-DEV model was consolidated into IPM SP 1.6 in the CMMI-ACQ model. Establishing integrated teams is an expected activity for conducting successful acquisitions. These teams often require participation beyond the project and may include customers and suppliers.
The project is conducted using a defined process 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 manufacturing and support processes, are developed concurrently with the product.
All projects that use IPM use the organization’s set of standard processes as a basis to begin planning all project activities.
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 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.
The project’s defined process logically sequences acquirer activities and supplier deliverables (as identified in the supplier agreement) to deliver a product that meets the requirements. The acquirer may require the supplier to align selected processes with the acquirer’s defined process.
The project’s defined process should satisfy the project’s contractual requirements, operational needs, opportunities, and constraints. It is designed to provide a best fit for project 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
• The organization’s set of standard processes and tailoring guidelines
• The operational environment
• The 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 project requirements and the organization’s process needs and objectives. Also, as the organization’s set of standard processes changes, the project’s defined process may need to be revised.
The project’s defined process is driven by the acquisition strategy. The acquirer’s defined process is affected, for example, by whether the acquisition strategy is to introduce new technology to the organization or to consolidate acquired products or services in use by the acquirer.
Typical Work Products
Typical Supplier Deliverables
Subpractices
Sometimes the available lifecycle models and standard processes are inadequate to meet project needs. Sometimes the project is unable to produce required work products or measures. In such circumstances, the project must seek approval to deviate from what is required by the organization. Waivers are provided for this purpose.
Tailor the organization’s set of standard processes to address the project’s specific needs and situation. Some questions to ask to determine specific needs include the following: Are stringent quality, safety, or security requirements in place? Are the customer’s needs still evolving? Is the team working with a new customer, a new acquisition strategy, or a new supplier? Are there stringent schedule constraints?
Use organizational process assets and the measurement repository for estimating and planning project activities.
Refer to the Organizational Process Definition process area for more information about organizational process assets and the organization’s measurement repository.
These activities may be similar to what you were doing to address PP, but because data and experiences from other projects are now available and applicable, the accuracy of project planning improves.
When available, use results of previous planning and execution activities as predictors of the relative scope and risk of the effort being estimated for the current acquisition.
Typical Work Products
Subpractices
An understanding of the relationships among tasks and work products of the project’s defined process and of the roles to be performed by relevant stakeholders is a basis for developing a realistic plan.
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 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.
Often, the project’s work environment contains components that are common to the organization’s overall work environment. Many of these components may be provided by information technology (IT) or a facilities group.
The supplier’s work environment should be compatible with the acquirer’s work environment to enable efficient and effective transfer of work products.
The work environment might encompass environments for both verification and validation or these 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.
Typical Work Products
Subpractices
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.
Maintenance and support of the work environment can be accomplished either with capabilities found inside the organization or hired from outside the organization.
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.
Integrate the project plan and other plans that affect the project to describe the project’s defined process.
One of the main differences between IPM and PP is that IPM is more proactive in coordinating with relevant stakeholders, both internal (different teams) and external (organizational functions, support groups, customers, and suppliers) to the project, and is concerned with the integration of plans.
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 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.
To formulate estimates, data should be available from the organization’s measurement repository. Additionally, templates, examples, and lessons-learned documents should be available from the organization’s process asset library.
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.
Typical Work Products
Typical Supplier Deliverables
Subpractices
Refer to the Measurement and Analysis process area for more information about defining measures and measurement activities and analyzing measurement data.
Refer to the Risk Management process area for more information about identifying and analyzing risks.
Refer to the Project Planning process area for more information about the WBS.
Because of the organizational inputs from the organization’s set of standard processes, many of the activities in PP are performed in IPM in more detail; and because of the historical data and experiences captured in other organizational process assets, the detail is more reliable.
Because of the historical data and experience captured in organizational process assets, IPM allows a more detailed and more reliable approach to planning.
Refer to the Agreement Management process area for more information about resolving supplier agreement issues.
Manage the project using the project plan, other plans that affect the project, and the project’s defined process.
Refer to the Organizational Process Definition process area for more information about organizational process assets.
The prior specific practices established the plan—this specific practice implements and manages the project against that plan.
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
Typical Supplier Deliverables
Subpractices
An understanding of the relationships among tasks and work products of the project’s defined process and of the roles to be performed by relevant stakeholders, along with well-defined control mechanisms (e.g., peer reviews), achieves better visibility into project performance and better control of the project.
Refer to the Measurement and Analysis process area for more information about obtaining and analyzing measures.
This review includes alignment with organizational process needs and objectives.
This specific practice should prove useful to any project that needs to bring individuals of differing views, cultures, and expertise together as a team. This practice is performed concurrently with the first five specific practices.
This specific practice is included to ensure that integrated teams are used for the purposes of addressing integration issues. Often, these occur across boundaries with customers, suppliers, and other critical acquisition efforts.
This specific practice addresses the tendency of team members to become insular in outlook and not feel responsible for larger project issues. This specific practice complements the specific practices of SG 2.
Establish and maintain integrated teams.
The project is managed using integrated teams that reflect the organizational rules and guidelines for team structuring and forming. The project’s shared vision is established prior to establishing the team structure, which may be based on the WBS. For small acquirer organizations, the whole organization and relevant external stakeholders can be treated as an integrated team.
When a supplier is integrated into the project team, pick the best process for the situation and be sure it is covered in the supplier agreement.
Refer to the Establish Rules and Guidelines for Integrated Teams specific practice in the Organizational Process Definition process area for more information about establishing organizational rules and guidelines for structuring and forming integrated teams.
One of the best ways to ensure coordination and collaboration with relevant stakeholders, specific goal 2 of this process area, is to include them on an integrated team. For projects within a system of systems framework, the most important integrated team may be with stakeholders representing other systems.
Establishing the right team structure aids in planning, coordinating, and managing risk. Acquisition projects sometimes choose a single, top-level, integrated team that is in place for the duration of the acquisition project, but the rest of the project work is performed within traditional organizational boundaries. Such an approach can improve efficiency and be pursued if the product architecture aligns well with existing organizational boundaries.
Achieve the right allocation of requirements to each integrated team in the team structure before teams are formed because deciding which requirements to allocate to which team determines how the teams are staffed.
Subpractices
When creating a shared vision, it is critical to understand the interfaces between the project and stakeholders external to the project. The vision should be shared among relevant stakeholders through their agreement and commitment.
The development of the CMMI Product Suite is an example of a project that uses integrated teams. The CMMI project communicated its shared vision broadly so that the management team guiding CMMI activities, the home organizations that sponsored project team members, and the broad community had a clear understanding of the project’s objectives, values, and intended outcomes.
Cost, schedule, project risks, resources, interfaces, the project’s defined process, and organizational guidelines are evaluated to establish the basis for defining integrated teams and their responsibilities, authorities, and interrelationships.
Each member of the integrated team should have dual aspirations and expectations: those specific to the project and those related to their home organization.
Although the integrated team sponsor helps to form the team, he or she is usually not involved in daily activities. The sponsor may be part of the management team.
The leader of an integrated team is often a member of the integrated team one layer up in the team structure.
The charter is reviewed by all members of the team to ensure buy-in.
Establishing and maintaining integrated teams encompasses choosing team leaders and team members and establishing team charters for each team. It also involves providing resources required to accomplish tasks assigned to the team.
Integrated teams should be monitored to detect malfunctions, mismanaged interfaces, and mismatches of tasks to team members. Take corrective action when performance does not meet expectations.
Contribute work products, measures, and documented experiences to organizational process assets.
This specific practice provides feedback to the organization so that the organizational assets can be improved, and data and experiences can be shared with other projects.
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 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
Subpractices
Improvements are proposed using “process improvement proposals.” For more information, see OPF SP 2.4.
Refer to the Project Planning process area for more information about recording planning and replanning data.
Refer to the Measurement and Analysis process area for more information about recording measurement data.
Refer to the Monitor the Implementation specific practice of the Organizational Process Focus process area for more information about monitoring the implementation of the organization’s set of standard processes and use of process assets on all projects.
Coordination and collaboration between the project and relevant stakeholders are conducted.
Manage the involvement of relevant stakeholders in the project.
Stakeholder involvement is managed according to the project’s integrated and defined process.
The supplier agreement provides the basis for managing supplier involvement in the project. Supplier agreements (e.g., interagency and intercompany agreements, memorandums of understanding, memorandums of agreement) that the acquirer makes with stakeholder organizations, which may be product or service providers or recipients, provide the basis for their involvement. These agreements are particularly important when the acquirer’s project produces a system that must be integrated into a larger system of systems.
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
Subpractices
Participate with relevant stakeholders to identify, negotiate, and track critical dependencies.
Too often, project members assume that critical dependencies identified at the beginning of a project will not change or are someone else’s responsibility.
Ironically, when time and money are limited, integration, coordination, and collaboration activities become more critical. Coordination helps to ensure that all involved parties contribute to the product in a timely way to minimize rework and delays.
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
Typical Supplier Deliverables
Subpractices
It is particularly important that acquirers or owners of systems that interact with the project in a system of systems be involved in these reviews to manage critical dependencies these types of systems create.
The acquirer documents supplier commitments to meet critical dependencies in the supplier agreement. Supplier dependencies and acquirer dependencies are documented in an integrated plan.
Refer to the Project Monitoring and Control process area for more information about tracking commitments.
Resolve issues with relevant stakeholders.
These issues are typically resolved at the project level. However, since stakeholders may be from outside the project, issues may need to be escalated to the appropriate level of management to be resolved.
Typical Work Products
Subpractices
3.129.70.113