Integrated Project Management +IPPD (IPM + IPPD)
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 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 Practices by Goal
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
The project’s defined process
Subpractice 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
Subpractice 2: Select the standard processes from the organization's set of standard processes that best fit the needs of the project.
Subpractice 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.
Subpractice 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
Subpractice 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
Subpractice 6: Conduct peer reviews of the project's defined process.
Refer to the Verification process area for more information about conducting peer reviews.
Subpractice 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
Project estimates
Project plans
Subpractice 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.
Subpractice 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
Equipment and tools for the project
Installation, operation, and maintenance manuals for the project work environment
User surveys and results
Usage, performance, and maintenance records
Support services for the project’s work environment
Subpractice 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
Subpractice 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
Subpractice 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.
Subpractice 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
Integrated plans
Subpractice 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
Subpractice 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
Subpractice 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
Subpractice 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
Subpractice 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.
Subpractice 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.
Subpractice 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.
Subpractice 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.
Subpractice 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
Work products created by performing the project’s defined process
Collected measures (“actuals”) and progress records or reports
Revised requirements, plans, and commitments
Integrated plans
Subpractice 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
Subpractice 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.
Subpractice 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.
Subpractice 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
Proposed improvements to the organizational process assets
Actual process and product measures collected from the project
Documentation (e.g., exemplary process descriptions, plans, training modules, checklists, and lessons learned)
Process artifacts associated with tailoring and implementing the organization’s set of standard processes on the project
Subpractice 1: Propose improvements to the organizational process assets.
Subpractice 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
Subpractice 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
Subpractice 4: Document lessons learned from the project for inclusion in the organization's process asset library.
Subpractice 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
Agendas and schedules for collaborative activities
Documented issues (e.g., issues with customer requirements, product and product component requirements, product architecture, and product design)
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.
Subpractices 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
Subpractices 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
Defects, issues, and action items resulting from reviews with relevant stakeholders
Critical dependencies
Commitments to address critical dependencies
Status of critical dependencies
Subpractices 1: Conduct reviews with relevant stakeholders.
Subpractices 2: Identify each critical dependency.
Subpractices 3: Establish need dates and plan dates for each critical dependency based on the project schedule.
Subpractices 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.
Subpractices 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
Subpractices 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
Relevant stakeholder coordination issues
Status of relevant stakeholder coordination issues
Subpractice 1: Identify and document issues.
Subpractice 2: Communicate issues to the relevant stakeholders.
Subpractice 3: Resolve issues with the relevant stakeholders.
Subpractice 4: Escalate to the appropriate managers those issues not resolvable with the relevant stakeholders.
Subpractice 5: Track the issues to closure.
Subpractice 6: Communicate with the relevant stakeholders on the status and resolution of the issues.
SG 3 Apply IPPD Principles - IPPD Addition
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
Documented shared vision
Communications strategy
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.
Subpractices 2: Reach consensus on the project’s shared vision.
Subpractices 3: Establish a strategy to communicate the project’s shared vision both externally and internally.
Subpractices 4: Create presentations suitable for the various audiences that need to be informed about the project’s shared vision.
Subpractices 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
Assessments of the product and product architectures, including risk and complexity
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.
Subpractices 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
Adding teams as new product components are identified for development
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
Responsibilities allocated to each integrated team
Work product requirements, technical interfaces, and business (e.g., cost accounting and project management) interfaces each integrated team will be responsible for satisfying
List of integrated team sponsors
Subpractice 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
Subpractice 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.
Subpractice 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
List of team leaders
List of team members assigned to each integrated team
Integrated team charters
Measures for evaluating the performance of integrated teams
Periodic integrated team status reports
Subpractice 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.
Subpractice 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.
Subpractice 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
Subpractice 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.
Subpractice 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.
Subpractice 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
Work product ownership agreements
Team work plans
Commitment lists
Subpractice: 1 Establish and maintain the boundaries of work product ownership among interfacing teams within the project or organization.
Subpractice: 2 Establish and maintain interfaces and processes among interfacing teams for the exchange of inputs, outputs, or work products.
Subpractice: 3 Develop, communicate, and distribute among interfacing teams the commitment lists and work plans that are related to work product or team interfaces.
Generic Practices by Goal
GG 1 Achieve Specific Goals
The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.
GP 1.1 Perform Specific Practices
Perform the specific practices of the integrated project management process to develop work products and provide services to achieve the specific goals of the process area.
GG 2 Institutionalize a Managed Process
The process is institutionalized as a managed process.
GP 2.1 Establish an Organizational Policy
Establish and maintain an organizational policy for planning and performing the integrated project management process.
Elaboration:
This policy establishes organizational expectations for establishing and maintaining the project’s defined process from project startup through the life of the project, using the project’s defined process in managing the project, and coordinating and collaborating with relevant stakeholders.
IPPD Addition
This policy also establishes organizational expectations for applying IPPD principles.
GP 2.2 Plan the Process
Establish and maintain the plan for performing the integrated project management process.
Elaboration:
This plan for the integrated project management process unites the planning for the project planning and monitor and control processes. The planning for performing the planning-related practices in Integrated Project Management is addressed as part of planning the project planning process. This plan for performing the monitor-and-control-related practices in Integrated Project Management can be included in (or referenced by) the project plan, which is described in the Project Planning process area.
GP 2.3 Provide Resources
Provide adequate resources for performing the integrated project management process, developing the work products, and providing the services of the process.
Elaboration:
Examples of resources provided include the following tools:
Problem-tracking and trouble-reporting packages
Groupware
Video conferencing
Integrated decision database
Integrated product support environments
GP 2.4 Assign Responsibility
Assign responsibility and authority for performing the process, developing the work products, and providing the services of the integrated project management process.
GP 2.5 Train People
Train the people performing or supporting the integrated project management process as needed.
Elaboration:
Examples of training topics include the following:
Tailoring the organization’s set of standard processes to meet the needs of the project
Procedures for managing the project based on the project’s defined process
Using the organization’s measurement repository
Using the organizational process assets
Integrated management
Group problem solving
IPPD Addition
Examples of training topics also include the following:
Building the project's shared vision
Team building
GP 2.6 Manage Configurations
Place designated work products of the integrated project management process under appropriate levels of control.
Elaboration:
Examples of work products placed under control include the following:
The project’s defined process
Project plans
Other plans that affect the project
Integrated plans
Actual process and product measures collected from the project
IPPD Addition
Examples of work products placed under control also include the following:
Project's shared vision
Integrated team structure
Integrated team charters
GP 2.7 Identify and Involve Relevant Stakeholders
Identify and involve the relevant stakeholders of the integrated project management process as planned.
Elaboration:
Examples of activities for stakeholder involvement include the following:
Resolving issues about the tailoring of the organizational process assets
Resolving issues among the project plan and the other plans that affect the project
Reviewing project performance to align with current and projected needs, objectives, and requirements
IPPD Addition
Examples of activities for stakeholder involvement also include the following:
Creating the project's shared vision
Defining the integrated team structure for the project
Populating the integrated teams
GP 2.8 Monitor and Control the Process
Monitor and control the integrated project management process against the plan for performing the process and take appropriate corrective action.
Elaboration:
Examples of measures and work products used in monitoring and controlling include the following:
Number of changes to the project’s defined process
Schedule and effort to tailor the organization’s set of standard processes
Interface coordination issue trends (i.e., number identified and number closed)
Schedule for project tailoring activities
IPPD Addition
Examples of measures and work products used in monitoring and controlling also include the following:
Project's shared vision usage and effectiveness
Integrated team-structure usage and effectiveness
Integrated team charters usage and effectiveness
GP 2.9 Objectively Evaluate Adherence
Objectively evaluate adherence of the integrated project management process against its process description, standards, and procedures, and address noncompliance.
Elaboration:
Examples of activities reviewed include the following:
Establishing, maintaining, and using the project’s defined process
Coordinating and collaborating with relevant stakeholders
IPPD Addition
Examples of activities reviewed also include the following:
Using the project's shared vision
Organizing integrated teams
Examples of work products reviewed include the following:
Project’s defined process
Project plans
Other plans that affect the project
IPPD Addition
Examples of work products reviewed also include the following:
Integrated team structure
Integrated team charters
Shared vision statements
GP 2.10 Review Status with Higher Level Management
Review the activities, status, and results of the integrated project management process with higher level management and resolve issues.
GG 3 Institutionalize a Defined Process
The process is institutionalized as a defined process.
This generic goal's appearance here reflects its location in the continuous representation.
GP 3.1 Establish a Defined Process
Establish and maintain the description of a defined integrated project management process.
GP 3.2 Collect Improvement Information
Collect work products, measures, measurement results, and improvement information derived from planning and performing the integrated project management process to support the future use and improvement of the organization’s processes and process assets.
Elaboration:
Examples of work products, measures, measurement results, and improvement information include the following:
Project’s defined process
Number of tailoring options exercised by the project to create its defined process
Interface coordination issue trends (i.e., number identified and number closed)
Number of times the PAL is accessed for assets related to project planning by project personnel
Records of expenses related to holding face-to-face meetings versus holding meetings using collaborative equipment such as teleconferencing and videoconferencing
IPPD Addition
Examples of work products, measures, measurement results, and improvement information also include the following:
Integrated team charters
Project shared vision
GG 4 Institutionalize a Quantitatively Managed Process
The process is institutionalized as a quantitatively managed process.
GP 4.1 Establish Quantitative Objectives for the Process
Establish and maintain quantitative objectives for the integrated project management process, which address quality and process performance, based on customer needs and business objectives.
GP 4.2 Stabilize Subprocess Performance
Stabilize the performance of one or more subprocesses to determine the ability of the integrated project management process to achieve the established quantitative quality and process-performance objectives.
The process is institutionalized as a quantitatively managed process.
GG 5 Institutionalize an Optimizing Process
The process is institutionalized as an optimizing process.
GP 5.1 Ensure Continuous Process Improvement
Ensure continuous improvement of the integrated project management process in fulfilling the relevant business objectives of the organization.
GP 5.2 Correct Root Causes of Problems
Identify and correct the root causes of defects and other problems in the integrated project management process.
|