Integrated Project Management
A Project Management Process Area at Maturity Level 3
Purpose
The purpose of Integrated Project Management (IPM) is to establish and manage the project and the involvement of relevant stakeholders according to an integrated and defined process that is tailored from the organization’s set of standard processes.
Introductory Notes
The term “project” refers to a group of people and resources committed to planning, monitoring, and executing defined processes in a shared endeavor to achieve a set of objectives derived from the goals of the business and (current or future) customers. Obtaining business value from the practices in this and related process areas requires, in part, correctly identifying which endeavors are “projects.”
See the introductory notes of the Project Planning process area for more information about the use of the term “project” and the applicability of specific practices that use that term.
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 project
• Ensuring that relevant stakeholders perform their tasks in a coordinated and timely manner (1) to address project 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.
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 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, verification)
• Service activities (e.g., delivery, help desk, operations, customer contact)
• Acquisition activities (e.g., solicitation, agreement monitoring, transition to operations)
• Support activities (e.g., configuration management, documentation, marketing, 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 overall endeavor. 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 that 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.
This process area applies in any organizational structure or approach, 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 Measurement and Analysis process area for more information about specifying measures and analysis procedures.
Refer to the Organizational Process Definition process area for more information about organizational process assets and work environment standards.
Refer to the Project Monitoring and Control process area for more information about monitoring the project against the plan.
Refer to the Project Planning process area for more information about developing a project plan and planning stakeholder involvement.
Specific Practices by Goal
SG 1 Use the Project’s Defined Process
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, develop, maintain, or deliver 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 organizational process assets.
Refer to the Organizational Process Focus process area for more information about deploying organizational process assets and deploying standard processes.
The project’s defined process consists of defined processes that form an integrated, coherent lifecycle for the project.
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:
• Stakeholder requirements
• Commitments
• Organizational process needs and objectives
• The organization’s set of standard processes and tailoring guidelines
• The operational environment
• The business environment
• The service delivery environment
In addition, the description of the project’s defined process should be based on the services that the project will deliver, including both standard services that have been tailored for the project and services that are unique to the project.
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.
Typical Work Products
1. The project’s defined process
Subpractices
1. Select a lifecycle model from those available in organizational process assets.
Examples of project characteristics that could affect the selection of lifecycle models include the following:
• Size of the project
• Project strategy
• Experience and familiarity of staff with implementing the process
• Constraints such as service level and cycle time
2. Select standard processes from the organization’s set of standard processes that best fit the needs of the project.
Organizations that define standard services will normally have standard service systems that enable the delivery of those services. Any processes that are components of an organization’s relevant standard service system(s) are good candidates to consider when selecting standard processes for a project that will be delivering services.
3. Tailor the organization’s set of standard processes and other organizational process assets according to tailoring guidelines to produce the project’s defined process.
Sometimes the available lifecycle models and standard processes are inadequate to meet project needs. In such circumstances, the project must 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 service establishment and delivery activities for the project and its interfaces to relevant stakeholders.
Examples of project activities include the following:
• Project planning
• Project monitoring
• Requirements management
• Supplier management
• Incident management
• Quality assurance
• Risk management
• Decision analysis and resolution
• Service system development and support
6. Conduct peer reviews of the project’s defined process.
7. Revise the project’s defined process as necessary.
SP 1.2 Use Organizational Process Assets for Planning Project Activities
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 establishing organizational process assets.
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 project activities.
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.
2. Use the organization’s measurement repository in estimating the project’s planning parameters.
This estimate typically includes the following:
• Appropriate historical data from this project or similar projects
• Similarities and differences between the current project and those projects whose historical data will be used
• Independently validated historical data
• 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
• Service system and service system components
• Operational or delivery 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
• Quality
• 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 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.
The project’s work environment should encompass all work spaces where the project operates. This work environment includes work spaces not under the direct control or ownership of the organization (e.g., delivering a product or service at a customer site).
Verification and validation of the service system can include both initial and ongoing evaluation of the work environment in which the service is delivered.
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
1. Equipment and tools for the project
2. Installation, operation, and maintenance manuals for the project work environment
3. User surveys and results
4. Use, 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 project.
It may be necessary to make tradeoffs among performance, costs, and risks. The following are examples of each:
• Performance considerations may include timely communication, safety, security, and maintainability.
• Costs may include capital outlays, training, a support structure; disassembly and disposal of existing environments; and the 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
• Incident and request management tools
• Test and 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 maintenance and support
• Training people to perform maintenance and support
• Contracting maintenance and support
• Developing expert users for selected tools
3. Maintain the qualification of components of the project’s work environment.
Components include those necessary to support service delivery, software, databases, hardware, tools, test equipment, and appropriate documentation. Qualification of a service delivery environment includes audits of the environment and its components for compliance with safety requirements and regulations. 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 project 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 other plans that affect the project to describe the project’s defined process.
Refer to the Project Planning process area for more information about developing a project plan.
The project plan should include plans for service system development and service delivery as appropriate.
Refer to the Capacity and Availability Management process area for more information about preparing for capacity and availability management.
Refer to the Incident Resolution and Prevention process area for more information about preparing for incident resolution and prevention.
Refer to the Service Continuity process area for more information about establishing service continuity plans.
Refer to the Measurement and Analysis process area for more information about aligning measurement and analysis activities.
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 Risk Management process area for more information about identifying and analyzing risks.
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.
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 plan may include the following:
• Quality assurance plans
• Risk management strategy
• Communication plans
• Capacity and availability management strategy
• Service continuity plan
• Incident management approach
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
• Unavailability of COTS components
• Inadequate or ineffective team interfaces
• Inadequate product and service interfaces
4. Schedule tasks in a sequence that accounts for critical development and delivery factors and project risks.
Examples of factors considered in scheduling include the following:
• Size and complexity of tasks
• Needs of the customer and end users
• Availability of critical resources
• Availability of key personnel
5. Incorporate plans for performing peer reviews on work products of the project’s defined process.
6. Incorporate the training needed to perform the project’s defined process in the project’s training plans.
This task typically includes negotiating with the organizational training group on the support they will provide.
7. Establish objective entry and exit criteria to authorize the initiation and completion of tasks described in the work breakdown structure (WBS).
Refer to the Project Planning process area for more information about establishing a top-level work breakdown structure (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 Integrated Plans
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.
Refer to the Organizational Process Focus process area for more information about establishing organizational process needs, deploying organizational process assets, and deploying standard processes.
Refer to the Project Monitoring and Control process area for more information about monitoring the project against the plan.
Refer to the Risk Management process area for more information about identifying, analyzing, and mitigating risks.
Typical Work Products
1. Work products created by performing the project’s defined process
2. Collected measures (i.e., actuals) and status 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 activities:
• 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 activities:
• Using the defined entry and exit criteria to authorize the initiation and determine the completion of tasks
• Monitoring activities that could significantly affect actual values of the project’s planning parameters
• Tracking project planning parameters using measurable thresholds that will trigger investigation and appropriate actions
• Monitoring project interface risks
• Managing external and internal commitments based on plans for tasks and work products of the project’s defined process
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.
3. Obtain and analyze selected measurements to manage the project and support organization needs.
Refer to the Measurement and Analysis process area for more information about obtaining and analyzing measurement data.
4. Periodically review and align the project’s performance with current and anticipated needs, objectives, and requirements of the organization, customer, and end users, as appropriate.
This review includes alignment with 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 project risks
• Changing requirements in response to a change in market opportunities or customer and end-user needs
• Terminating the project
SP 1.6 Establish Integrated Teams
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 organizations, the whole organization and relevant external stakeholders can be treated as an integrated team.
Refer to the Establish Rules and Guidelines for Integrated Teams specific practice in the Organizational Process Definition process area for more information about establishing and maintaining organizational rules and guidelines for the structure, formation, and operation of integrated teams.
One of the best ways to ensure coordination and collaboration with relevant stakeholders is to include them on an integrated team.
A project may consist of no integrated teams (e.g., a project having only one individual, in which case that individual may possibly be a member of a higher level integrated team), one integrated team (i.e., the whole project team is the integrated team), or many integrated teams. This specific practice applies possibly in the first two instances and certainly in the last instance. Establishing an integrated team is a best practice when team members having complementary skill sets or from different cultures or backgrounds must work together effectively to accomplish a shared objective. It is important to determine at the organizational level the project work to be conducted in integrated teams.
When a project is a service provider, there may be one integrated team responsible for overall service development and maintenance and another team responsible for service delivery. In the case of multiple critical services each requiring a different skill set, the staff associated with each service may form its own integrated team with an objective to ensure the successful and continuing delivery of that service (or timely response to an ad hoc request or incident resolution as appropriate).
In a customer environment that requires coordination among multiple product development or service delivery organizations, it is important to establish an integrated team with representation from all parties that impact overall success. Such representation helps to ensure effective collaboration across these organizations, including the timely resolution of coordination issues.
Typical Work Products
1. Documented shared vision
2. List of team members assigned to each integrated team
3. Integrated team charters
4. Periodic integrated team status reports
Subpractices
1. Establish and maintain the project’s shared vision.
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 to obtain their agreement and commitment.
2. Establish and maintain the integrated team structure.
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.
3. Establish and maintain each integrated team.
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.
4. Periodically evaluate the integrated team structure and composition.
Integrated teams should be monitored to detect misalignment of work across different teams, mismanaged interfaces, and mismatches of tasks to team members. Take corrective action when performance does not meet expectations.
SP 1.7 Contribute to Organizational Process Assets
Contribute work products, measures, and documented experiences to organizational process assets.
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.
Refer to the Organizational Process Focus process area for more information about incorporating experiences into organizational process assets.
This specific practice addresses collecting information from processes in the project’s defined process.
Typical Work Products
1. Proposed improvements to organizational process assets
2. Actual process and product measures collected from the project
3. Documentation (e.g., exemplary process descriptions, plans, training modules, checklists, 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 organizational process assets.
2. Store process and product measures in the organization’s measurement repository.
Refer to the Project Monitoring and Control process area for more information about monitoring project planning parameters.
Refer to the Project Planning process area for more information about planning data management.
These process and product measures typically include 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 the Implementation specific practice in 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 between the project and relevant stakeholders are conducted.
SP 2.1 Manage Stakeholder Involvement
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, memoranda of understanding, memoranda of agreement) that the project 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 project’s delivered services must be integrated into a larger service delivery context.
Refer to the Project Planning process area for more information about planning stakeholder involvement and obtaining commitment to the plan.
Typical Work Products
1. Agendas and schedules for collaborative activities
2. Documented issues (e.g., issues with stakeholder and service system requirements, architecture, design)
3. Recommendations for resolving relevant stakeholder issues
Subpractices
1. Coordinate with relevant stakeholders who should participate in project activities.
The relevant stakeholders should already be identified in the project plan.
2. Ensure work products that are produced to satisfy commitments meet the requirements of the recipients.
The work products produced to satisfy commitments can be services. 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 actions to resolve misunderstandings and problems with requirements.
SP 2.2 Manage Dependencies
Participate with relevant stakeholders to identify, negotiate, and track critical dependencies.
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 commitments to address each critical dependency with those responsible for providing or receiving the work product or performing or receiving the service.
5. Document 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 monitoring commitments.
Tracking 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 responsible parties whenever possible
• Escalating to the appropriate party the actual and potential problems not resolvable by the responsible individual or group
SP 2.3 Resolve Coordination Issues
Resolve issues with relevant stakeholders.
Examples of coordination issues include the following:
• Late critical dependencies and commitments
• Service system 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 relevant stakeholders.
3. Resolve issues with relevant stakeholders.
4. Escalate to appropriate managers those issues not resolvable with relevant stakeholders.
5. Track issues to closure.
6. Communicate with relevant stakeholders on the status and resolution of issues.