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 develop and maintain the product. The product-related life-cycle processes, such as the manufacturing and support processes, are developed concurrently with the product. SP 1.1-1 Establish the Project's Defined Process Establish and maintain 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. The project's defined process consists of defined processes that form an integrated, coherent life cycle for the project. The project's defined process covers all of the processes needed by the project, including those processes that are addressed by the process areas at maturity level 2. For Integrated Product and Process Development The project's defined process includes all life-cycle processes including the IPPD processes that will be applied by the project (tailored from the organization's IPPD processes). Processes to select the team structure, allocate limited personnel resources, implement cross-integrated team communication, and conduct issue-resolution processes are part of the project's defined process. |
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 section: Typical Work Products The project's defined process Subpractices Select a life-cycle model from those available from the organizational process assets. Select the standard processes from the organization's set of standard processes that best fit the needs of the project. 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 life-cycle 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. Use other artifacts from the organization's process asset library as appropriate. Other artifacts may include the following: Document the project's defined process. The project's defined process covers all the engineering, management, and support activities for the project and its interfaces to relevant stakeholders. Examples of project activities include the following: Project planning Project monitoring and controlling Requirements development Requirements management Design and implementation Verification and validation Product integration Supplier agreement management Configuration management Quality assurance |
Conduct peer reviews of the project's defined process. Refer to the Verification process area for more information about conducting peer reviews. Revise the project's defined process as necessary. SP 1.2-1 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 Subpractices Base the activities for estimating and planning on 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, is a basis for developing a realistic plan. 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: |
Examples of data contained in the organization's measurement repository include the following: |
SP 1.3-1 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 stake holders, 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, and end users, as appropriate. For Integrated Product and Process Development 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. |
For Supplier Sourcing The plans for integrated supplier management are included in this integration of plans. Plans for integrated supplier management must be coordinated with other related plans. |
Typical Work Products Integrated plans Subpractices Integrate other plans that affect the project with the project plan. Other plans that affect the project may include the following: 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: |
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 |
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 |
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. 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. 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. 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. For Supplier Sourcing Ensure that the plans for the integrated supplier management process are compatible with related plans. |
Identify how conflicts will be resolved that arise among relevant stakeholders. SP 1.4-1 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 Subpractices Implement the project's defined process using the organization's process asset library. This task typically includes the following: 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 implementing 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. 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. Periodically review the adequacy of the environment to meet the project's needs and to support coordination. Examples of actions that might be taken include the following: |
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.5-1 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) Subpractices Propose improvements to the organizational process assets. 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 |
Submit documentation for possible inclusion in the organization's process asset library. Examples of documentation include the following: |
Document lessons learned from the project for inclusion in the organization's process asset library. SG 2 Coordinate and Collaborate with Relevant Stakeholders Coordination and collaboration of the project with relevant stakeholders is conducted. SP 2.1-1 Manage Stakeholder Involvement Manage the involvement of the relevant stakeholders in the project. 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 Coordinate with the relevant stakeholders who should participate in the project's activities. The relevant stakeholders should already be identified in the project plan. 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 determining acceptability of work products. 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 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-1 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 Conduct reviews with relevant stakeholders. Identify each critical dependency. Establish need dates and plan dates for each critical dependency based on the project schedule. 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. 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 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-1 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 Subpractices Identify and document issues. Communicate issues to the relevant stakeholders. Resolve issues with the relevant stakeholders. Escalate to the appropriate managers those issues not resolvable with the relevant stakeholders. Track the issues to closure. Communicate with the relevant stakeholders on the status and resolution of the issues. The following two specific goals, Use the Project's Shared Vision for IPPD and Organize Integrated Teams for IPPD, are only required for IPPD. SG 3 Use the Project's Shared Vision for IPPD The project is conducted using the project's shared vision. The purpose of creating a shared vision is to achieve a unity of purpose. Creating a shared vision requires that all people in the project have an opportunity to speak and be heard about what really matters to them. The project's shared vision captures the project's guiding principles, including mission, objectives, expected behavior, and values. The project's guiding principles should be consistent with those of the organization. The implementation of the project's shared vision in work can become part of the project's process for doing that work. As a result, it is subject to the same requirements for measurement, review, and corrective action as other processes. The value of a shared vision is that people understand and can adopt its principles to guide their actions and decisions. Shared visions tend to focus on an end state while leaving room for personal and team innovation, creativity, and enthusiasm. The activities of the individuals, teams, and project are aligned with the shared vision (i.e., the activities contribute to the achievement of the objectives expressed in the shared vision). SP 3.1-1 Define Project's Shared-Vision Context Identify expectations, constraints, interfaces, and operational conditions applicable to the project's shared vision. Refer to the Organizational Environment for Integration process area for more information about the organization's shared vision. A project does not operate in isolation. Understanding organizational expectations and constraints allows for alignment of the project's direction, activities, and shared vision with the organization's and helps create a common purpose within which project activities can be coordinated. To enable this, it is critical to understand (1) the interfaces between the project and stakeholders external to the project, (2) the objectives and expectations of all relevant stakeholders (internal and external), and (3) conditions within which the project must operate. Gaining awareness in these three areas ensures that the project's direction and activities are consistent with the broader objectives of the organization. The project's shared-vision context has both an external and internal aspect. The external aspect has to do with the overlying vision and objectives as well as interfaces outside of the project. The internal aspect is about aligning project members' personal aspirations and objectives with the project's vision and purpose. Typical Work Products Organizational expectations and constraints that apply to the project Summary of project members' personal aspirations for the project External interfaces that the project is required to observe Operational conditions that affect the project's activities Project's shared-vision context Subpractices Identify expectations, constraints, interfaces, and operational conditions about the organization and the project that affect the project's shared vision. Elicit project members' perspectives and aspirations for the project. Create a description of the project's shared-vision context. SP 3.2-1 Establish the Project's Shared Vision Establish and maintain a shared vision for the project. A shared vision is created by the project and for the project, in alignment with the organization's shared vision. Refer to the Organizational Environment for Integration process area for more information about the organization's shared vision. When creating a shared vision, consider: external stakeholder expectations and requirements the aspirations and expectations of the leader and project members the project's objectives the conditions and outcomes the project will create interfaces the project needs to maintain the visions created by the organization and 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 Meeting minutes for team-building exercises Shared vision and objective statements Statement of values and principles Communications strategy Handbook for new members of the project Presentations to relevant stakeholders Published principles, shared vision statement, mission statement, and objectives (e.g., posters, wallet cards) Subpractices Hold meetings or workshops to create the project's shared vision. Articulate the project's shared vision in terms of purpose or mission, vision, values, and objectives. Reach consensus on the project's shared vision. Establish a strategy to communicate the project's shared vision both externally and internally. Make presentations suitable for the various audiences that need to be informed about the project's shared vision. Check that project and individual activities and tasks are aligned with the project's shared vision. SG 4 Organize Integrated Teams for IPPD The integrated teams needed to execute the project are identified, defined, structured, and tasked. The purpose of this specific goal and its specific practices is to create an integrated team structure that will efficiently meet the project's requirements and produce a quality product. The integrated team structure partitions responsibilities, requirements, and resources to teams so that the right expertise and abilities are available to produce the assigned products. The integrated teams are organized to facilitate communications among teams and to honor interfaces between product components. Organizing integrated teams to realize IPPD requires care and deliberation. As the project evolves, integrated team structures are reevaluated for continued applicability. For example, once the product-component requirements are established, it may be appropriate to replace a leader having expertise in design with one having more expertise in manufacturing or in verification. The teams in the structure must be appropriately integrated with each other. The interface between two integrated teams should be specified when one team has responsibility for a work product that has an interface requirement referring to a work product of the other team. An interface between teams should be specified when one team produces a work product that will be used by another. An interface should exist when two teams share responsibility for a general requirement of the product. Each of these types of interfaces between integrated teams may require a different type of collaboration as appropriate. SP 4.1-1 Determine Integrated Team Structure for the Project Determine the integrated team structure that will best meet the project objectives and constraints. 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. The simplest integrated team structure from an IPPD perspective evolves when the WBS is a work-product-oriented hierarchy, and resources are available to staff a team with the expertise needed to adequately address the entire life of the product for each work product in that hierarchy. More complex structuring occurs when the WBS is not product oriented, product risks are not uniform, and resources are constrained. Structuring integrated teams is dependent on: 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 can include the whole project as an integrated team. In this case, the project team would need to satisfy the requirements of the Integrated Teaming process area (e.g., it would need a shared vision [created in the Use the Project's Shared Vision for IPPD specific goal of this process area], a charter, clearly defined responsibilities, operating principles, and collaborative interfaces with other teams outside of the project). If a project team has too many members for effective collaboration, the project team should be divided into subteams of appropriate size. Typical Work Products Assessments of the product and product architectures, including risk and complexity Integrated team structures based on the WBS and adaptations Alternative concepts for integrated team structures that include responsibilities, scope, and interfaces Selected integrated team structure Subpractices Determine the risks in the products and product suite. Refer to the Risk Management process area for more information about practices associated with risk determination. Determine likely resource requirements and availability. Refer to the Project Planning process area for more information about resource assignments. Constraints on the available assets impact which teams are formed and how the teams are structured. Establish work-product-based responsibilities. Each team in the team structure should be responsible for specific tasks and work products. The team structure should tie to the WBS used by the project. Consider organizational process assets for opportunities, constraints, and other factors that might influence integrated team structure. Organizational process assets can provide guidance to assist the project in structuring and implementing integrated teams. Such assets may include: Team formation and structures eam authority guidelines Implementation techniques for IPPD Guidelines for managing risks in IPPD Guidelines for establishing lines of communication and authority Team leader selection criteria Team responsibility guidelines Develop an understanding of the organization's shared vision, the project's shared vision, and the organization's standard processes and organizational process assets applicable to teams and team structures. The shared visions for the organization and project are examined. These visions help the planners focus on attributes critical to the organization and the project. Organizational processes provide information to streamline the planning process. These may be particularly useful when establishing reporting mechanisms for integrated teams and when integrated team structures are constructed in hybrid situations, such as project teams consisting of both functional and product teams. Identify alternative integrated team structures. Alternative integrated team structures are frequently developed for collaborative evaluation prior to selection of the structure to be employed. Much like any other set of design alternatives, extreme cases should be included to test the adequacy of the solution set. Innovative concepts in integrated team structure that promote integration as well as efficiency can be overlooked if planning is limited to devising a single team structure. Evaluate alternatives and select an integrated team structure. Refer to the Decision Analysis and Resolution process area for more information about a formal evaluation process for selecting the team structure. The integrated team structure that meets the objectives, subject to the constraints of time, money, and people, is collaboratively evaluated and selected from the alternative integrated team structures. From the perspective of team-structure maintenance, this activity would include assessments of the teams already deployed and candidate alternative structures. SP 4.2-1 Develop a Preliminary Distribution of Requirements to Integrated Teams Develop a preliminary distribution of requirements, responsibilities, authorities, tasks, and interfaces to teams in the selected integrated team structure. This preliminary distribution of requirements to integrated teams is done before any teams are formed to verify that the selected team structure is workable and covers all the necessary requirements, responsibilities, authorities, tasks, and interfaces. If this check is not satisfied, it is necessary to repeat the selection of team structure to meet this check. This preliminary distribution is a useful compendium of information that the integrated teams must know to effectively carry out their tasks in an integrated way. Typical Work Products Preliminary distribution of integrated team authorities and responsibilities Preliminary distribution of the work product requirements, technical interfaces, and business (e.g., cost accounting, project management) interfaces each integrated team will be responsible for satisfying Subpractices Assemble requirements and interfaces for integrated teams. Assemble the tasks and work products, and the associated requirements and interfaces. Assign these to the appropriate integrated teams. Check that the preliminary 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. Define responsibilities and authorities for integrated teams. Business, management, and other nontechnical responsibilities and authorities for the 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. Such factors include: 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 Designate the sponsor for each integrated team. An integrated team sponsor is a manager (individual or team) who is responsible for establishing an integrated team, monitoring its activities and progress, and taking corrective action when needed. A manager may sponsor one or many teams. SP 4.3-1 Establish Integrated Teams Establish and maintain teams in the integrated team structure. The teams within the selected and satisfactory integrated team structure are established. This process encompasses the choosing of team leaders and the assignment of planned responsibilities and requirements for each team. It also involves providing the resources required to accomplish the tasks assigned to the team. The integrated team structure is a dynamic entity that must be able to adjust to changes in people, requirements, and the nature of tasks, and to tackle many difficulties. 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. Typical Work Products A list of project integrated teams List of team leaders Responsibilities and authorities for each integrated team Requirements allocated to each integrated team Measures for evaluating the performance of integrated teams Quality assurance reports Periodic status reports New integrated team structures Subpractices Choose integrated team leaders. Integrated team leaders are selected who can achieve the expectations of the product in the context of organizational limitations (project priority and the needs of other projects). Integrated teams need a great deal of autonomy to faithfully implement IPPD. That autonomy is at risk if project or organizational leadership does not have confidence in the leader. The extent of organizational and project direction in selecting the leader is often a function of product risk and complexity. It can also be related to an organization's need to "grow" new leaders. Allocate responsibilities and requirements to each integrated team. The planned responsibilities and requirements are issued to the integrated team. These items are discussed with the team to encourage collaborative buy-in. Some adjustments may be made at this time. 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. Create each integrated team. Refer to the Integrated Teaming process area for more information about forming and sustaining each of the integrated teams in the team structure. For each integrated team in the selected structure, create a team that has a shared vision, charter, and operating principles as described in the Integrated Teaming process area. Creating the integrated team is a collaborative effort of the team sponsor and the members of the team. Other relevant stakeholders may be involved in accordance with the plan for stakeholder involvement. The teams that interface with the target team should be involved to ensure that the specified interfaces are honored. Integrated team composition and structures are periodically evaluated and modified to best reflect project needs. Changes in team structure could include: 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 When a change of team leader or a significant change of membership of the team occurs, review the integrated team composition and its place in the integrated team structure. 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. One complication of changed responsibility is that other teams may have to adjust and add tasks to cover the change. This fact may cause a domino effect in the team structure. Such a change should be undertaken carefully. When a change in team responsibility occurs, review the team composition and its tasking. These changes 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. Manage the overall performance of the teams. |
