4

PROJECT INTEGRATION MANAGEMENT

Project Integration Management includes the processes and activities to identify, define, combine, unify, and coordinate the various processes and project management activities within the Project Management Process Groups. In the project management context, integration includes characteristics of unification, consolidation, communication, and interrelationship. These actions should be applied from the start of the project through completion. Project Integration Management includes making choices about:

• Resource allocation,
• Balancing competing demands,
• Examining any alternative approaches,
• Tailoring the processes to meet the project objectives, and
• Managing the interdependencies among the Project Management Knowledge Areas.

The Project Integration Management processes are:

4.1 Develop Project Charter—The process of developing a document that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities.

4.2 Develop Project Management Plan—The process of defining, preparing, and coordinating all plan components and consolidating them into an integrated project management plan.

4.3 Direct and Manage Project Work—The process of leading and performing the work defined in the project management plan and implementing approved changes to achieve the project's objectives.

4.4 Manage Project Knowledge—The process of using existing knowledge and creating new knowledge to achieve the project's objectives and contribute to organizational learning.

4.5 Monitor and Control Project Work—The process of tracking, reviewing, and reporting overall progress to meet the performance objectives defined in the project management plan.

4.6 Perform Integrated Change Control—The process of reviewing all change requests; approving changes and managing changes to deliverables, organizational process assets, project documents, and the project management plan; and communicating the decisions.

4.7 Close Project or Phase—The process of finalizing all activities for the project, phase, or contract.

Figure 4-1 provides an overview of the Project Integration Management processes. The Project Integration Management processes are presented as discrete processes with defined interfaces while, in practice, they overlap and interact in ways that cannot be completely detailed in the PMBOK® Guide.

KEY CONCEPTS FOR PROJECT INTEGRATION MANAGEMENT

Project Integration Management is specific to project managers. Whereas other Knowledge Areas may be managed by specialists (e.g., cost analysis, scheduling specialists, risk management experts), the accountability of Project Integration Management cannot be delegated or transferred. The project manager is the one who combines the results in all the other Knowledge Areas and has the overall view of the project. The project manager is ultimately responsible for the project as a whole.

Projects and project management are integrative by nature. For example, a cost estimate needed for a contingency plan involves integrating the processes in the Project Cost Management, Project Schedule Management, and Project Risk Management Knowledge Areas. When additional risks associated with various staffing alternatives are identified, then one or more of those processes may be revisited.

The links among the processes in the Project Management Process Groups are often iterative. For example, the Planning Process Group provides the Executing Process Group with a documented project management plan early in the project and then updates the project management plan if changes occur as the project progresses.

Project Integration Management is about:

• Ensuring that the deliverable due dates of the product, service, or result; project life cycle; and the benefits management plan are aligned;
• Providing a project management plan to achieve the project objectives;
• Ensuring the creation and the use of the appropriate knowledge to and from the project as necessary;
• Managing the performance and changes of the activities in the project management plan;
• Making integrated decisions regarding key changes impacting the project;
• Measuring and monitoring the project's progress and taking appropriate action to meet project objectives;
• Collecting data on the results achieved, analyzing the data to obtain information, and communicating this information to relevant stakeholders;
• Completing all the work of the project and formally closing each phase, contract, and the project as a whole; and
• Managing phase transitions when necessary.

The more complex the project and the more varied the expectations of the stakeholders, the more a sophisticated approach to integration is needed.

TRENDS AND EMERGING PRACTICES IN PROJECT INTEGRATION MANAGEMENT

The Project Integration Management Knowledge Area requires combining the results from all the other Knowledge Areas. Evolving trends in integration processes include but are not limited to:

• Use of automated tools. The volume of data and information that project managers need to integrate makes it necessary to use a project management information system (PMIS) and automated tools to collect, analyze, and use information to meet project objectives and realize project benefits.
• Use of visual management tools. Some project teams use visual management tools, rather than written plans and other documents, to capture and oversee critical project elements. Making key project elements visible to the entire team provides a real-time overview of the project status, facilitates knowledge transfer, and empowers team members and other stakeholders to help identify and solve issues.
• Project knowledge management. The increasingly mobile and transitory work force requires a more rigorous process of identifying knowledge throughout the project life cycle and transferring it to the target audience so that the knowledge is not lost.
• Expanding the project manager's responsibilities. Project managers are being called on to initiate and finalize the project, such as project business case development and benefits management. Historically, these activities have been the responsibility of management and the project management office, but project managers are more frequently collaborating with them to better meet project objectives and deliver benefits. Project managers are also engaging in more comprehensive identification and engagement of stakeholders. This includes managing the interfaces with various functional and operational departments and senior management personnel.
• Hybrid methodologies. Some project management methodologies are evolving to incorporate successfully applied new practices. Examples include the use of agile and other iterative practices; business analysis techniques for requirements management; tools for identifying complex elements in projects; and organizational change management methods to prepare for transitioning the project outputs into the organization.

TAILORING CONSIDERATIONS

Because each project is unique, the project manager may need to tailor the way that Project Integration Management processes are applied. Considerations for tailoring include but are not limited to:

• Project life cycle. What is an appropriate project life cycle? What phases should comprise the project life cycle?
• Development life cycle. What development life cycle and approach are appropriate for the product, service, or result? Is a predictive or adaptive approach appropriate? If adaptive, should the product be developed incrementally or iteratively? Is a hybrid approach best?
• Management approaches. What management processes are most effective based on the organizational culture and the complexity of the project?
• Knowledge management. How will knowledge be managed in the project to foster a collaborative working environment?
• Change. How will change be managed in the project?
• Governance. What control boards, committees, and other stakeholders are part of the project? What are the project status reporting requirements?
• Lessons learned. What information should be collected throughout and at the end of the project? How will historical information and lessons learned be made available to future projects?
• Benefits. When and how should benefits be reported: at the end of the project or at the end of each iteration or phase?

CONSIDERATIONS FOR AGILE/ADAPTIVE ENVIRONMENTS

Iterative and agile approaches promote the engagement of team members as local domain experts in integration management. The team members determine how plans and components should integrate.

The expectations of the project manager as noted in the Key Concepts for Integration Management do not change in an adaptive environment, but control of the detailed product planning and delivery is delegated to the team. The project manager's focus is on building a collaborative decision-making environment and ensuring the team has the ability to respond to changes. This collaborative approach can be further enhanced when team members possess a broad skill base rather than a narrow specialization.

4.1 DEVELOP PROJECT CHARTER

Develop Project Charter is the process of developing a document that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities. The key benefits of this process are that it provides a direct link between the project and the strategic objectives of the organization, creates a formal record of the project, and shows the organizational commitment to the project. This process is performed once or at predefined points in the project. The inputs, tools and techniques, and outputs of the process are depicted in Figure 4-2. Figure 4-3 depicts the data flow diagram for the process.

The project charter establishes a partnership between the performing and requesting organizations. In the case of external projects, a formal contract is typically the preferred way to establish an agreement. A project charter may still be used to establish internal agreements within an organization to ensure proper delivery under the contract. The approved project charter formally initiates the project. A project manager is identified and assigned as early in the project as is feasible, preferably while the project charter is being developed and always prior to the start of planning. The project charter can be developed by the sponsor or the project manager in collaboration with the initiating entity. This collaboration allows the project manager to have a better understanding of the project purpose, objectives, and expected benefits. This understanding will better allow for efficient resource allocation to project activities. The project charter provides the project manager with the authority to plan, execute, and control the project.

Projects are initiated by an entity external to the project such as a sponsor, program, or project management office (PMO), or a portfolio governing body chairperson or authorized representative. The project initiator or sponsor should be at a level that is appropriate to procure funding and commit resources to the project. Projects are initiated due to internal business needs or external influences. These needs or influences often trigger the creation of a needs analysis, feasibility study, business case, or description of the situation that the project will address. Chartering a project validates alignment of the project to the strategy and ongoing work of the organization. A project charter is not considered to be a contract because there is no consideration or money promised or exchanged in its creation.

4.1.1 DEVELOP PROJECT CHARTER: INPUTS

4.1.1.1 BUSINESS DOCUMENTS

The business case (described in Section 1.2.6.1) and the benefits management plan (described in Section 1.2.6.2) are sources of information about the project´s objectives and how the project will contribute to the business goals. Although the business documents are developed prior to the project, they are reviewed periodically.

• Business case. The approved business case, or similar, is the business document most commonly used to create the project charter. The business case describes the necessary information from a business standpoint to determine whether the expected outcomes of the project justify the required investment. It is commonly used for decision making by managers or executives above the project level. Typically, the business need and the cost-benefit analysis are contained in the business case to justify and establish boundaries for the project. For more information on the business case, see Section 1.2.6.1. The business case is created as a result of one or more of the following:

• Market demand (e.g., an automobile manufacturer authorizing a project to build more fuel-efficient cars in response to gasoline shortages),
• Organizational need (e.g., due to high overhead costs, a company may combine staff functions and streamline processes to reduce costs),
• Customer request (e.g., an electric utility authorizing a project to build a new substation to serve a new industrial park),
• Technological advance (e.g., an airline authorizing a new project to develop electronic tickets instead of paper tickets based on technological advances),
• Legal requirement (e.g., a paint manufacturer authorizing a project to establish guidelines for handling toxic materials),
• Ecological impacts (e.g., a company authorizing a project to lessen its environmental impact), or
• Social need (e.g., a nongovernmental organization in a developing country authorizing a project to provide potable water systems, latrines, and sanitation education to communities suffering from high rates of cholera).

The project charter incorporates the appropriate information for the project from the business documents. The project manager does not update or modify the business documents since they are not project documents; however, the project manager may make recommendations.

4.1.1.2 AGREEMENTS

Described in Section 12.2.3.2. Agreements are used to define initial intentions for a project. Agreements may take the form of contracts, memorandums of understanding (MOUs), service level agreements (SLA), letters of agreement, letters of intent, verbal agreements, email, or other written agreements. Typically, a contract is used when a project is being performed for an external customer.

4.1.1.3 ENTERPRISE ENVIRONMENTAL FACTORS

The enterprise environmental factors that can influence the Develop Project Charter process include but are not limited to:

• Government or industry standards (e.g., product standards, quality standards, safety standards, and workmanship standards),
• Legal and regulatory requirements and/or constraints,
• Marketplace conditions,
• Organizational culture and political climate,
• Organizational governance framework (a structured way to provide control, direction, and coordination through people, policies, and processes to meet organizational strategic and operational goals), and
• Stakeholders’ expectations and risk thresholds.

4.1.1.4 ORGANIZATIONAL PROCESS ASSETS

The organizational process assets that can influence the Develop Project Charter process include but are not limited to:

• Organizational standard policies, processes, and procedures;
• Portfolio, program, and project governance framework (governance functions and processes to provide guidance and decision making);
• Monitoring and reporting methods;
• Templates (e.g., project charter template); and
• Historical information and lessons learned repository (e.g., project records and documents, information about the results of previous project selection decisions, and information about previous project performance).

4.1.2 DEVELOP PROJECT CHARTER: TOOLS AND TECHNIQUES

4.1.2.1 EXPERT JUDGMENT

Expert judgment is defined as judgment provided based upon expertise in an application area, Knowledge Area, discipline, industry, etc., as appropriate for the activity being performed. Such expertise may be provided by any group or person with specialized education, knowledge, skill, experience, or training.

For this process, expertise should be considered from individuals or groups with specialized knowledge of or training in the following topics:

• Organizational strategy,
• Benefits management,
• Technical knowledge of the industry and focus area of the project,
• Duration and budget estimation, and
• Risk identification.

4.1.2.2 DATA GATHERING

Data-gathering techniques that can be used for this process include but are not limited to:

• Brainstorming. This technique is used to identify a list of ideas in a short period of time. It is conducted in a group environment and is led by a facilitator. Brainstorming comprises two parts: idea generation and analysis. Brainstorming can be used to gather data and solutions or ideas from stakeholders, subject matter experts, and team members when developing the project charter.
• Focus groups. Described in Section 5.2.2.2. Focus groups bring together stakeholders and subject matter experts to learn about the perceived project risk, success criteria, and other topics in a more conversational way than a one-on-one interview.
• Interviews. Described in Section 5.2.2.2. Interviews are used to obtain information on high-level requirements, assumptions or constraints, approval criteria, and other information from stakeholders by talking directly to them.

4.1.2.3 INTERPERSONAL AND TEAM SKILLS

Interpersonal and team skills that can be used for this process include but are not limited to:

• Conflict management. Described in Section 9.5.2.1. Conflict management can be used to help bring stakeholders into alignment on the objectives, success criteria, high-level requirements, project description, summary milestones, and other elements of the charter.
• Facilitation. Facilitation is the ability to effectively guide a group event to a successful decision, solution, or conclusion. A facilitator ensures that there is effective participation, that participants achieve a mutual understanding, that all contributions are considered, that conclusions or results have full buy-in according to the decision process established for the project, and that the actions and agreements achieved are appropriately dealt with afterward.
• Meeting management. Described in Section 10.2.2.6. Meeting management includes preparing the agenda, ensuring that a representative for each key stakeholder group is invited, and preparing and sending the follow-up minutes and actions.

4.1.2.4 MEETINGS

For this process, meetings are held with key stakeholders to identify the project objectives, success criteria, key deliverables, high-level requirements, summary milestones, and other summary information.

4.1.3 DEVELOP PROJECT CHARTER: OUTPUTS

4.1.3.1 PROJECT CHARTER

The project charter is the document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities. It documents the high-level information on the project and on the product, service, or result the project is intended to satisfy, such as:

• Project purpose;
• Measurable project objectives and related success criteria;
• High-level requirements;
• High-level project description, boundaries, and key deliverables;
• Overall project risk;
• Summary milestone schedule;
• Preapproved financial resources;
• Key stakeholder list;
• Project approval requirements (i.e., what constitutes project success, who decides the project is successful, and who signs off on the project);
• Project exit criteria (i.e., what are the conditions to be met in order to close or to cancel the project or phase);
• Assigned project manager, responsibility, and authority level; and
• Name and authority of the sponsor or other person(s) authorizing the project charter.

At a high level, the project charter ensures a common understanding by the stakeholders of the key deliverables, milestones, and the roles and responsibilities of everyone involved in the project.

4.1.3.2 ASSUMPTION LOG

High-level strategic and operational assumptions and constraints are normally identified in the business case before the project is initiated and will flow into the project charter. Lower-level activity and task assumptions are generated throughout the project such as defining technical specifications, estimates, the schedule, risks, etc. The assumption log is used to record all assumptions and constraints throughout the project life cycle.

4.2 DEVELOP PROJECT MANAGEMENT PLAN

Develop Project Management Plan is the process of defining, preparing, and coordinating all plan components and consolidating them into an integrated project management plan. The key benefit of this process is the production of a comprehensive document that defines the basis of all project work and how the work will be performed. This process is performed once or at predefined points in the project. The inputs, tools and techniques, and outputs of the process are depicted in Figure 4-4. Figure 4-5 depicts the data flow diagram for the process.

The project management plan defines how the project is executed, monitored and controlled, and closed. The project management plan's content varies depending on the application area and complexity of the project.

The project management plan may be either summary level or detailed. Each component plan is described to the extent required by the specific project. The project management plan should be robust enough to respond to an ever-changing project environment. This agility may result in more accurate information as the project progresses.

The project management plan should be baselined; that is, it is necessary to define at least the project references for scope, time, and cost, so that the project execution can be measured and compared to those references and performance can be managed. Before the baselines are defined, the project management plan may be updated as many times as necessary. No formal process is required at that time. But, once it is baselined, it may only be changed through the Perform Integrated Change Control process. Consequently, change requests will be generated and decided upon whenever a change is requested. This results in a project management plan that is progressively elaborated by controlled and approved updates extending through project closure.

Projects that exist in the context of a program or portfolio should develop a project management plan that is consistent with the program or portfolio management plan. For example, if the program management plan indicates all changes exceeding a specified cost need to be reviewed by the change control board (CCB), then this process and cost threshold need to be defined in the project management plan.

4.2.1 DEVELOP PROJECT MANAGEMENT PLAN: INPUTS

4.2.1.1 PROJECT CHARTER

Described in Section 4.1.3.1. The project team uses the project charter as a starting point for initial project planning. The type and amount of information in the project charter varies depending on the complexity of the project and the information known at the time of its creation. At a minimum, the project charter should define the high-level information about the project that will be elaborated in the various components of the project management plan.

4.2.1.2 OUTPUTS FROM OTHER PROCESSES

Outputs from many of the other processes described in Sections 5 through 13 are integrated to create the project management plan. Subsidiary plans and baselines that are an output from other planning processes are inputs to this process. In addition, changes to these documents may necessitate updates to the project management plan.

4.2.1.3 ENTERPRISE ENVIRONMENTAL FACTORS

The enterprise environmental factors that can influence the Develop Project Management Plan process include but are not limited to:

• Government or industry standards (e.g., product standards, quality standards, safety standards, and workmanship standards);
• Legal and regulatory requirements and/or constraints;
• Project management body of knowledge for vertical market (e.g., construction) and/or focus area (e.g., environmental, safety, risk, or agile software development);
• Organizational structure, culture, management practices, and sustainability;
• Organizational governance framework (a structured way to provide control, direction, and coordination through people, policies, and processes to meet organizational strategic and operational goals); and
• Infrastructure (e.g., existing facilities and capital equipment).

4.2.1.4 ORGANIZATIONAL PROCESS ASSETS

The organizational process assets that can influence the Develop Project Management Plan process include but are not limited to:

• Organizational standard policies, processes, and procedures;
• Project management plan template, including:

• Guidelines and criteria for tailoring the organization's set of standard processes to satisfy the specific needs of the project, and
• Project closure guidelines or requirements such as the product validation and acceptance criteria.

• Change control procedures, including the steps by which official organizational standards, policies, plans, procedures, or any project documents will be modified and how any changes will be approved and validated;
• Monitoring and reporting methods, risk control procedures, and communication requirements;
• Project information from previous similar projects (e.g., scope, cost, schedule and performance measurement baselines, project calendars, project schedule network diagrams, and risk registers); and
• Historical information and lessons learned repository.

4.2.2 DEVELOP PROJECT MANAGEMENT PLAN: TOOLS AND TECHNIQUES

4.2.2.1 EXPERT JUDGMENT

Described in Section 4.1.2.1. Expertise should be considered from individuals or groups with specialized knowledge of or training in the following topics:

• Tailoring the project management process to meet the project needs, including the dependencies and interactions among those processes and the essential inputs and outputs;
• Developing additional components of the project management plan if needed;
• Determining the tools and techniques to be used for accomplishing those processes;
• Developing technical and management details to be included in the project management plan;
• Determining resources and skill levels needed to perform project work;
• Defining the level of configuration management to apply on the project;
• Determining which project documents will be subject to the formal change control process; and
• Prioritizing the work on the project to ensure the project resources are allocated to the appropriate work at the appropriate time.

4.2.2.2 DATA GATHERING

Data-gathering techniques that can be used for this process include but are not limited to:

• Brainstorming. Described in Section 4.1.2.2. Brainstorming is frequently used when developing the project management plan to gather ideas and solutions about the project approach. Attendees include the project team members although other subject matter experts (SMEs) or stakeholders may also participate.
• Checklists. Described in Section 11.2.2.2. Many organizations have standardized checklists available based in their own experience or use checklists from the industry. A checklist may guide the project manager to develop the plan or may help to verify that all the required information is included in the project management plan.
• Focus groups. Described in Section 5.2.2.2. Focus groups bring together stakeholders to discuss the project management approach and the integration of the different components of the project management plan.
• Interviews. Described in Section 5.2.2.2. Interviews are used to obtain specific information from stakeholders to develop the project management plan or any component plan or project document.

4.2.2.3 INTERPERSONAL AND TEAM SKILLS

The interpersonal and team skills used when developing the project management plan include:

• Conflict management. Described in Section 9.5.2.1. Conflict management may be necessary to bring diverse stakeholders into alignment on all aspects of the project management plan.
• Facilitation. Described in Section 4.1.2.3. Facilitation ensures that there is effective participation, that participants achieve a mutual understanding, that all contributions are considered, and that conclusions or results have full buy-in according to the decision process established for the project.
• Meeting management. Described in Section 10.2.2.6. Meeting management is necessary to ensure that the numerous meetings that are necessary to develop, unify, and agree on the project management plan are well run.

4.2.2.4 MEETINGS

For this process, meetings are used to discuss the project approach, determine how work will be executed to accomplish the project objectives, and establish the way the project will be monitored and controlled.

The project kick-off meeting is usually associated with the end of planning and the start of executing. Its purpose is to communicate the objectives of the project, gain the commitment of the team for the project, and explain the roles and responsibilities of each stakeholder. The kick-off may occur at different points in time depending on the characteristics of the project:

• For small projects, there is usually only one team that performs the planning and the execution. In this case, the kick-off occurs shortly after initiation, in the Planning Process Group, because the team is involved in planning.
• In large projects, a project management team normally does the majority of the planning, and the remainder of the project team is brought on when the initial planning is complete, at the start of the development/implementation. In this instance, the kick-off meeting takes place with processes in the Executing Process Group.

Multiphase projects will typically include a kick-off meeting at the beginning of each phase.

4.2.3 DEVELOP PROJECT MANAGEMENT PLAN: OUTPUTS

4.2.3.1 PROJECT MANAGEMENT PLAN

The project management plan is the document that describes how the project will be executed, monitored and controlled, and closed. It integrates and consolidates all of the subsidiary management plans and baselines, and other information necessary to manage the project. The needs of the project determine which components of the project management plan are needed.

Project management plan components include but are not limited to:

• Subsidiary management plans:

• Scope management plan. Described in Section 5.1.3.1. Establishes how the scope will be defined, developed, monitored, controlled, and validated.
• Requirements management plan. Described in Section 5.1.3.2. Establishes how the requirements will be analyzed, documented, and managed.
• Schedule management plan. Described in Section 6.1.3.1. Establishes the criteria and the activities for developing, monitoring, and controlling the schedule.
• Cost management plan. Described in Section 7.1.3.1. Establishes how the costs will be planned, structured, and controlled.
• Quality management plan. Described in Section 8.1.3.1. Establishes how an organization´s quality policies, methodologies, and standards will be implemented in the project.
• Resource management plan. Described in Section 9.1.3.1 Provides guidance on how project resources should be categorized, allocated, managed, and released.
• Communications management plan. Described in Section 10.1.3.1. Establishes how, when, and by whom information about the project will be administered and disseminated.
• Risk management plan. Described in Section 11.1.3.1. Establishes how the risk management activities will be structured and performed.
• Procurement management plan. Described in Section 12.1.3.1. Establishes how the project team will acquire goods and services from outside of the performing organization.
• Stakeholder engagement plan. Described in Section 13.2.3.1. Establishes how stakeholders will be engaged in project decisions and execution, according to their needs, interests, and impact.

• Baselines:

• Scope baseline. Described in Section 5.4.3.1. The approved version of a scope statement, work breakdown structure (WBS), and its associated WBS dictionary, which is used as a basis for comparison.
• Schedule baseline. Described in Section 6.5.3.1. The approved version of the schedule model that is used as a basis for comparison to the actual results.
• Cost baseline. Described in Section 7.3.3.1. The approved version of the time-phased project budget that is used as a basis for comparison to the actual results.

• Additional components. Most components of the project management plan are produced as outputs from other processes, though some are produced during this process. Those components developed as part of this process will be dependent on the project; however, they often include but are not limited to:

• Change management plan. Describes how the change requests throughout the project will be formally authorized and incorporated.
• Configuration management plan. Describes how the information about the items of the project (and which items) will be recorded and updated so that the product, service, or result of the project remains consistent and/or operative.
• Performance measurement baseline. An integrated scope-schedule-cost plan for the project work against which project execution is compared to measure and manage performance.
• Project life cycle. Describes the series of phases that a project passes through from its initiation to its closure.
• Development approach. Describes the product, service, or result development approach, such as predictive, iterative, agile, or a hybrid model.
• Management reviews. Identifies the points in the project when the project manager and relevant stakeholders will review the project progress to determine if performance is as expected, or if preventive or corrective actions are necessary.

While the project management plan is one of the primary documents used to manage the project, other project documents are also used. These other documents are not part of the project management plan; however, they are necessary to manage the project effectively. Table 4-1 is a representative list of the project management plan components and project documents.

Table 4-1. Project Management Plan and Project Documents

Project Management Plan	Project Documents
1. Scope management plan	1. Activity attributes	19. Quality control measurements
2. Requirements management plan	2. Activity list	20. Quality metrics
3. Schedule management plan	3. Assumption log	21. Quality report
4. Cost management plan	4. Basis of estimates	22. Requirements documentation
5. Quality management plan	5. Change log	23. Requirements traceability matrix
6. Resource management plan	6. Cost estimates	24. Resource breakdown structure
7. Communications management plan	7. Cost forecasts	25. Resource calendars
8. Risk management plan	8. Duration estimates	26. Resource requirements
9. Procurement management plan	9. Issue log	27. Risk register
10. Stakeholder engagement plan	10. Lessons learned register	28. Risk report
11. Change management plan	11. Milestone list	29. Schedule data
12. Configuration management plan	12. Physical resource assignments	30. Schedule forecasts
13. Scope baseline	13. Project calendars	31. Stakeholder register
14. Schedule baseline	14. Project communications	32. Team charter
15. Cost baseline	15. Project schedule	33. Test and evaluation documents
16. Performance measurement baseline	16. Project schedule network diagram
17. Project life cycle description	17. Project scope statement
18. Development approach	18. Project team assignments

4.3 DIRECT AND MANAGE PROJECT WORK

Direct and Manage Project Work is the process of leading and performing the work defined in the project management plan and implementing approved changes to achieve the project's objectives. The key benefit of this process is that it provides overall management of the project work and deliverables, thus improving the probability of project success. This process is performed throughout the project. The inputs, tools and techniques, and outputs of the process are depicted in Figure 4-6. Figure 4-7 depicts the data flow diagram for the process.

Direct and Manage Project Work involves executing the planned project activities to complete project deliverables and accomplish established objectives. Available resources are allocated, their efficient use is managed, and changes in project plans stemming from analyzing work performance data and information are carried out. The Direct and Manage Project Work process is directly affected by the project application area. Deliverables are produced as outputs from processes performed to accomplish the project work as planned and scheduled in the project management plan.

The project manager, along with the project management team, directs the performance of the planned project activities and manages the various technical and organizational interfaces that exist in the project. Direct and Manage Project Work also requires review of the impact of all project changes and the implementation of approved changes: corrective action, preventive action, and/or defect repair.

During project execution, the work performance data is collected and communicated to the applicable controlling processes for analysis. Work performance data analysis provides information about the completion status of deliverables and other relevant details about project performance. The work performance data will also be used as an input to the Monitoring and Controlling Process Group, and can be used as feedback into lessons learned to improve the performance of future work packages.

4.3.1 DIRECT AND MANAGE PROJECT WORK: INPUTS

4.3.1.1 PROJECT MANAGEMENT PLAN

Described in Section 4.2.3.1. Any component of the project management plan may be an input to this process.

4.3.1.2 PROJECT DOCUMENTS

Project documents that can be considered as inputs for this process include but are not limited to:

• Change log. Described in Section 4.6.3.3. The change log contains the status of all change requests.
• Lessons learned register. Described in Section 4.4.3.1. Lessons learned are used to improve the performance of the project and to avoid repeating mistakes. The register helps identify where to set rules or guidelines so the team's actions are aligned.
• Milestone list. Described in Section 6.2.3.3. The milestone list shows the scheduled dates for specific milestones.
• Project communications. Described in Section 10.2.3.1. Project communications include performance reports, deliverable status, and other information generated by the project.
• Project schedule. Described in Section 6.5.3.2. The schedule includes at least the list of work activities, their durations, resources, and planned start and finish dates.
• Requirements traceability matrix. Described in Section 5.2.3.2. The requirements traceability matrix links product requirements to the deliverables that satisfy them and helps to focus on the final outcomes.
• Risk register. Described in Section 11.2.3.1. The risk register provides information on threats and opportunities that may impact project execution.
• Risk report. Described in Section 11.2.3.2. The risk report provides information on sources of overall project risk along with summary information on identified individual project risks.

4.3.1.3 APPROVED CHANGE REQUESTS

Described in Section 4.6.3.1. Approved change requests are an output of the Perform Integrated Change Control process, and include those requests reviewed and approved for implementation by the project manager or by the change control board (CCB) when applicable. The approved change request may be a corrective action, a preventive action, or a defect repair. Approved change requests are scheduled and implemented by the project team and can impact any area of the project or project management plan. The approved change requests can also modify the formally controlled project management plan components or project documents.

4.3.1.4 ENTERPRISE ENVIRONMENTAL FACTORS

The enterprise environmental factors that can influence the Direct and Manage Project Work process include but are not limited to:

• Organizational structure, culture, management practices, and sustainability;
• Infrastructure (e.g., existing facilities and capital equipment); and
• Stakeholder risk thresholds (e.g., allowable cost overrun percentage).

4.3.1.5 ORGANIZATIONAL PROCESS ASSETS

The organizational process assets that can influence the Direct and Manage Project Work process include but are not limited to:

• Organizational standard policies, processes, and procedures;
• Issue and defect management procedures defining issue and defect controls, issue and defect identification and resolution, and action item tracking;
• Issue and defect management database(s) containing historical issue and defect status, issue and defect resolution, and action item results;
• Performance measurement database used to collect and make available measurement data on processes and products;
• Change control and risk control procedures; and
• Project information from previous projects (e.g., scope, cost, schedule, performance measurement baselines, project calendars, project schedule network diagrams, risk registers, risk reports, and lessons learned repository).

4.3.2 DIRECT AND MANAGE PROJECT WORK: TOOLS AND TECHNIQUES

4.3.2.1 EXPERT JUDGMENT

Described in Section 4.1.2.1. Expertise should be considered from individuals or groups with specialized knowledge or training in the following topics:

• Technical knowledge on the industry and focus area of the project,
• Cost and budget management,
• Legal and procurement,
• Legislation and regulations, and
• Organizational governance.

4.3.2.2 PROJECT MANAGEMENT INFORMATION SYSTEM (PMIS)

The PMIS provides access to information technology (IT) software tools, such as scheduling software tools, work authorization systems, configuration management systems, information collection and distribution systems, as well as interfaces to other online automated systems such as corporate knowledge base repositories. Automated gathering and reporting on key performance indicators (KPI) can be part of this system.

4.3.2.3 MEETINGS

Meetings are used to discuss and address pertinent topics of the project when directing and managing project work. Attendees may include the project manager, the project team, and appropriate stakeholders involved or affected by the topics addressed. Each attendee should have a defined role to ensure appropriate participation. Types of meetings include but are not limited to: kick-off, technical, sprint or iteration planning, Scrum daily standups, steering group, problem solving, progress update, and retrospective meetings.

4.3.3 DIRECT AND MANAGE PROJECT WORK: OUTPUTS

4.3.3.1 DELIVERABLES

A deliverable is any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project. Deliverables are typically the outcomes of the project and can include components of the project management plan.

Change control should be applied once the first version of a deliverable has been completed. The control of the multiple versions or editions of a deliverable (e.g., documents, software, and building blocks) is supported by configuration management tools and procedures.

4.3.3.2 WORK PERFORMANCE DATA

Work performance data are the raw observations and measurements identified during activities being performed to carry out the project work. Data are often viewed as the lowest level of detail from which information is derived by other processes. Data is gathered through work execution and passed to the controlling processes for further analysis.

Examples of work performance data include work completed, key performance indicators (KPIs), technical performance measures, actual start and finish dates of schedule activities, story points completed, deliverables status, schedule progress, number of change requests, number of defects, actual costs incurred, actual durations, etc.

4.3.3.3 ISSUE LOG

Throughout the life cycle of a project, the project manager will normally face problems, gaps, inconsistencies, or conflicts that occur unexpectedly and that require some action so they do not impact the project performance. The issue log is a project document where all the issues are recorded and tracked. Data on issues may include:

• Issue type,
• Who raised the issue and when,
• Description,
• Priority,
• Who is assigned to the issue,
• Target resolution date,
• Status, and
• Final solution.

The issue log will help the project manager effectively track and manage issues, ensuring that they are investigated and resolved. The issue log is created for the first time as an output of this process, although issues may happen at any time during the project. The issue log is updated as a result of the monitoring and control activities throughout the project's life cycle.

4.3.3.4 CHANGE REQUESTS

A change request is a formal proposal to modify any document, deliverable, or baseline. When issues are found while project work is being performed, change requests can be submitted, which may modify project policies or procedures, project or product scope, project cost or budget, project schedule, or quality of the project or product results. Other change requests cover the needed preventive or corrective actions to forestall negative impact later in the project. Any project stakeholder may request a change. Change requests are processed for review and disposition through the Perform Integrated Change Control process (Section 4.6). Change requests can be initiated from inside or outside the project and they can be optional or legally/contractually mandated. Change requests may include:

• Corrective action. An intentional activity that realigns the performance of the project work with the project management plan.
• Preventive action. An intentional activity that ensures the future performance of the project work is aligned with the project management plan.
• Defect repair. An intentional activity to modify a nonconforming product or product component.
• Updates. Changes to formally controlled project documents, plans, etc., to reflect modified or additional ideas or content.

4.3.3.5 PROJECT MANAGEMENT PLAN UPDATES

Any change to the project management plan goes through the organization's change control process via a change request. Any component of the project management plan may require a change request as a result of this process.

4.3.3.6 PROJECT DOCUMENTS UPDATES

Project documents that may be updated as a result of carrying out this process include but are not limited to:

• Activity list. Described in Section 6.2.3.1. The activity list may be updated with additional or modified activities to be performed to complete project work.
• Assumption log. Described in Section 4.1.3.2. New assumptions and constraints may be added, and the status of existing assumptions and constraints may be updated or closed out.
• Lessons learned register. Described in Section 4.4.3.1. Any lessons learned that will improve performance for current or future projects is recorded as it is learned.
• Requirements documentation. Described in Section 5.2.3.1. New requirements may be identified during this process. Progress on meeting requirements can also be updated.
• Risk register. Described in Section 11.2.3.1. New risks may be identified and existing risks may be updated during this process. Risks are recorded in the risk register via risk management processes.
• Stakeholder register. Described in Section 13.1.3.1. Where additional information on existing or new stakeholders is gathered as a result of this process, it is recorded in the stakeholder register.

4.3.3.7 ORGANIZATIONAL PROCESS ASSETS UPDATES

Any organizational process asset can be updated as a result of this process.

4.4 MANAGE PROJECT KNOWLEDGE

Manage Project Knowledge is the process of using existing knowledge and creating new knowledge to achieve the project's objectives and contribute to organizational learning. The key benefits of this process are that prior organizational knowledge is leveraged to produce or improve the project outcomes, and knowledge created by the project is available to support organizational operations and future projects or phases. This process is performed throughout the project. The inputs, tools and techniques, and outputs of the process are depicted in Figure 4-8. Figure 4-9 depicts the data flow diagram for the process.

Knowledge is commonly split into “explicit” (knowledge that can be readily codified using words, pictures, and numbers) and “tacit” (knowledge that is personal and difficult to express, such as beliefs, insights, experience, and “know-how”). Knowledge management is concerned with managing both tacit and explicit knowledge for two purposes: reusing existing knowledge and creating new knowledge. The key activities that underpin both purposes are knowledge sharing and knowledge integration (of knowledge from different domains, contextual knowledge, and project management knowledge).

It is a common misconception that managing knowledge involves just documenting it so it can be shared. Another common misconception is that managing knowledge involves just obtaining lessons learned at the end of the project, in order to use it in the future projects. Only codified explicit knowledge can be shared in this way. But codified explicit knowledge lacks context and is open to different interpretations, so even though it can easily be shared, it isn't always understood or applied in the right way. Tacit knowledge has context built in but is very difficult to codify. It resides in the minds of individual experts or in social groups and situations, and is normally shared through conversations and interactions between people.

From an organizational perspective, knowledge management is about making sure the skills, experience, and expertise of the project team and other stakeholders are used before, during, and after the project. Because knowledge resides in the minds of people and people cannot be forced to share what they know (or to pay attention to others’ knowledge), the most important part of knowledge management is creating an atmosphere of trust so that people are motivated to share their knowledge. Even the best knowledge management tools and techniques will not work if people are not motivated to share what they know or to pay attention to what others know. In practice, knowledge is shared using a mixture of knowledge management tools and techniques (interactions between people) and information management tools and techniques (in which people codify part of their explicit knowledge by documenting it so it can be shared).

4.4.1 MANAGE PROJECT KNOWLEDGE: INPUTS

4.4.1.1 PROJECT MANAGEMENT PLAN

Described in Section 4.2.3.1. All components of the project management plan are inputs.

4.4.1.2 PROJECT DOCUMENTS

Project documents that can be considered as inputs for this process include but are not limited to:

• Lessons learned register. Described in Section 4.4.3.1. The lessons learned register provides information on effective practices in knowledge management.
• Project team assignments. Described in Section 9.3.3.1. Project team assignments provide information on the type of competencies and experience available in the project and the knowledge that may be missing.
• Resource breakdown structure. Described in Section 9.2.3.3. The resource breakdown structure includes information on the composition of the team and may help to understand what knowledge is available as a group and what knowledge is missing.
• Stakeholder register. Described in Section 13.1.3.1. The stakeholder register contains details about the identified stakeholders to help understand the knowledge they may have.

4.4.1.3 DELIVERABLES

A deliverable is any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project. Deliverables are typically tangible components completed to meet the project objectives and can include components of the project management plan.

4.4.1.4 ENTERPRISE ENVIRONMENTAL FACTORS

The enterprise environmental factors that can influence the Manage Project Knowledge process include but are not limited to:

• Organizational, stakeholder, and customer culture. The existence of trusting working relationships and a no-blame culture is particularly important in managing knowledge. Other factors include the value placed on learning and social behavioral norms.
• Geographic distribution of facilities and resources. The location of team members helps determine methods for gaining and sharing knowledge.
• Organizational knowledge experts. Some organizations have a team or individual that specializes in knowledge management.
• Legal and regulatory requirements and/or constraints. These include confidentiality of project information.

4.4.1.5 ORGANIZATIONAL PROCESS ASSETS

Knowledge about project management is often embedded in processes and routines. The organizational process assets that can influence the Manage Project Knowledge process include but are not limited to:

• Organizational standard policies, processes, and procedures. These may include: confidentiality and access to information; security and data protection; record retention policies; use of copyrighted information; destruction of classified information; format and maximum size of files; registry data and metadata; authorized technology and social media; etc.
• Personnel administration. These include, for example, employee development and training records, and competency frameworks that refer to knowledge-sharing behaviors.
• Organizational communication requirements. Formal, rigid communication requirements are good for sharing information. Informal communication is more effective for creating new knowledge and integrating knowledge across diverse stakeholder groups.
• Formal knowledge-sharing and information-sharing procedures. These include learning reviews before, during, and after projects and project phases; for example, identifying, capturing, and sharing lessons learned from the current project and other projects.

4.4.2 MANAGE PROJECT KNOWLEDGE: TOOLS AND TECHNIQUES

4.4.2.1 EXPERT JUDGMENT

Described in Section 4.1.2.1. Expertise should be considered from individuals or groups with specialized knowledge or training in the following topics:

• Knowledge management,
• Information management,
• Organizational learning,
• Knowledge and information management tools, and
• Relevant information from other projects.

4.4.2.2 KNOWLEDGE MANAGEMENT

Knowledge management tools and techniques connect people so they can work together to create new knowledge, share tacit knowledge, and integrate the knowledge of diverse team members. The tools and techniques appropriate in a project depend on the nature of the project, especially the degree of innovation involved, the project complexity, and the level of diversity (including diversity of disciplines) among team members.

Tools and techniques include but are not limited to:

• Networking, including informal social interaction and online social networking. Online forums where people can ask open questions (“What does anyone know about…?”) are useful for starting knowledge-sharing conversations with specialists;
• Communities of practice (sometimes called communities of interest or just communities) and special interest groups;
• Meetings, including virtual meetings where participants can interact using communications technology;
• Work shadowing and reverse shadowing;
• Discussion forums such as focus groups;
• Knowledge-sharing events such as seminars and conferences;
• Workshops, including problem-solving sessions and learning reviews designed to identify lessons learned;
• Storytelling;
• Creativity and ideas management techniques;
• Knowledge fairs and cafés; and
• Training that involves interaction between learners.

All of these tools and techniques can be applied face-to-face or virtually, or both. Face-to-face interaction is usually the most effective way to build the trusting relationships that are needed to manage knowledge. Once relationships are established, virtual interaction can be used to maintain the relationship.

4.4.2.3 INFORMATION MANAGEMENT

Information management tools and techniques are used to create and connect people to information. They are effective for sharing simple, unambiguous, codified explicit knowledge. They include but are not limited to:

• Methods for codifying explicit knowledge; for example, for producing lessons to be learned entries for the lessons learned register;
• Lessons learned register;
• Library services;
• Information gathering, for example, web searches and reading published articles; and
• Project management information system (PMIS). Described in Section 4.3.2.2. Project management information systems often include document management systems.

Tools and techniques that connect people to information can be enhanced by adding an element of interaction, for example, include a “contact me” function so users can get in touch with the originators of the lessons and ask for advice specific to their project and context.

Interaction and support also helps people find relevant information. Asking for help is generally quicker and easier than trying to identify search terms. Search terms are often difficult to select because people may not know which keywords or key phrases to use to access the information they need.

Knowledge and information management tools and techniques should be connected to project processes and process owners. Communities of practice and subject matter experts (SMEs), for example, may generate insights that lead to improved control processes; having an internal sponsor can ensure improvements are implemented. Lessons learned register entries may be analyzed to identify common issues that can be addressed by changes to project procedures.

4.4.2.4 INTERPERSONAL AND TEAM SKILLS

The interpersonal and team skills used include but are not limited to:

• Active listening. Described in Section 10.2.2.6. Active listening helps reduce misunderstandings and improves communication and knowledge sharing.
• Facilitation. Described in Section 4.1.2.3. Facilitation helps effectively guide a group to a successful decision, solution, or conclusion.
• Leadership. Described in Section 3.4.4. Leadership is used to communicate the vision and inspire the project team to focus on the appropriate knowledge and knowledge objectives.
• Networking. Described in Section 10.2.2.6. Networking allows informal connections and relations among project stakeholders to be established and creates the conditions to share tacit and explicit knowledge.
• Political awareness. Described in Section 10.1.2.6. Political awareness helps the project manager to plan communications based on the project environment as well as the organization's political environment.

4.4.3 MANAGE PROJECT KNOWLEDGE: OUTPUTS

4.4.3.1 LESSONS LEARNED REGISTER

The lessons learned register can include the category and description of the situation. The lessons learned register may also include the impact, recommendations, and proposed actions associated with the situation. The lessons learned register may record challenges, problems, realized risks and opportunities, or other content as appropriate.

The lessons learned register is created as an output of this process early in the project. Thereafter it is used as an input and updated as an output in many processes throughout the project. The persons or teams involved in the work are also involved in capturing the lessons learned. Knowledge can be documented using videos, pictures, audios, or other suitable means that ensure the efficiency of the lessons captured.

At the end of a project or phase, the information is transferred to an organizational process asset called a lessons learned repository.

4.4.3.2 PROJECT MANAGEMENT PLAN UPDATES

Any change to the project management plan goes through the organization's change control process via a change request. Any component of the project management plan may be updated as a result of this process.

4.4.3.3 ORGANIZATIONAL PROCESS ASSETS UPDATES

All projects create new knowledge. Some of this knowledge is codified, embedded in deliverables, or embedded in improvements to processes and procedures as a result of the Manage Project Knowledge process. Existing knowledge can also be codified or embedded for the first time as a result of this process; for example, if an existing idea for a new procedure is piloted in the project and found to be successful.

Any organizational process asset can be updated as a result of this process.

4.5 MONITOR AND CONTROL PROJECT WORK

Monitor and Control Project Work is the process of tracking, reviewing, and reporting the overall progress to meet the performance objectives defined in the project management plan. The key benefits of this process are that it allows stakeholders to understand the current state of the project, to recognize the actions taken to address any performance issues, and to have visibility into the future project status with cost and schedule forecasts. This process is performed throughout the project. The inputs, tools and techniques, and outputs of the process are depicted in Figure 4-10. Figure 4-11 depicts the data flow diagram for the process.

Monitoring is an aspect of project management performed throughout the project. Monitoring includes collecting, measuring, and assessing measurements and trends to effect process improvements. Continuous monitoring gives the project management team insight into the health of the project and identifies any areas that may require special attention. Control includes determining corrective or preventive actions or replanning and following up on action plans to determine whether the actions taken resolved the performance issue. The Monitor and Control Project Work process is concerned with:

• Comparing actual project performance against the project management plan;
• Assessing performance periodically to determine whether any corrective or preventive actions are indicated, and then recommending those actions as necessary;
• Checking the status of individual project risks;
• Maintaining an accurate, timely information base concerning the project's product(s) and their associated documentation through project completion;
• Providing information to support status reporting, progress measurement, and forecasting;
• Providing forecasts to update current cost and current schedule information;
• Monitoring implementation of approved changes as they occur;
• Providing appropriate reporting on project progress and status to program management when the project is part of an overall program; and
• Ensuring that the project stays aligned with the business needs.

4.5.1 MONITOR AND CONTROL PROJECT WORK: INPUTS

4.5.1.1 PROJECT MANAGEMENT PLAN

Described in Section 4.2.3.1. Monitoring and controlling project work involves looking at all aspects of the project. Any component of the project management plan may be an input for this process.

4.5.1.2 PROJECT DOCUMENTS

Project documents that can be considered as inputs for this process include but are not limited to:

• Assumption log. Described in Section 4.1.3.2. The assumption log contains information about assumptions and constraints identified as affecting the project.
• Basis of estimates. Described in Sections 6.4.3.2 and 7.2.3.2. Basis of estimates indicates how the various estimates were derived and can be used to make a decision on how to respond to variances.
• Cost forecasts. Described in Section 7.4.3.2. Based on the project's past performance, the cost forecasts are used to determine if the project is within defined tolerance ranges for budget and to identify any necessary change requests.
• Issue log. Described in Section 4.3.3.3. The issue log is used to document and monitor who is responsible for resolving specific issues by a target date.
• Lessons learned register. Described in Section 4.4.3.1. The lessons learned register may have information on effective responses for variances, and corrective and preventive actions.
• Milestone list. Described in Section 6.2.3.3. The milestone list shows the scheduled dates for specific milestones and is used to check if the planned milestones have been met.
• Quality reports. Described in Section 8.2.3.1. The quality report includes quality management issues; recommendations for process, project, and product improvements; corrective actions recommendations (includes rework, defect/bugs repair, 100% inspection, and more); and the summary of findings from the Control Quality process.
• Risk register. Described in Section 11.2.3.1. The risk register provides information on threats and opportunities that have occurred during project execution.
• Risk report. Described in Section 11.2.3.2. The risk report provides information on the overall project risks as well as information on specified individual risks.
• Schedule forecasts. Described in Section 6.6.3.2. Based on the project's past performance, the schedule forecasts are used to determine if the project is within defined tolerance ranges for schedule and to identify any necessary change requests.

4.5.1.3 WORK PERFORMANCE INFORMATION

Work performance data is gathered through work execution and passed to the controlling processes. To become work performance information, the work performance data are compared with the project management plan components, project documents, and other project variables. This comparison indicates how the project is performing.

Specific work performance metrics for scope, schedule, budget, and quality are defined at the start of the project as part of the project management plan. Performance data are collected during the project through the controlling processes and compared to the plan and other variables to provide a context for work performance.

For example, work performance data on cost may include funds that have been expended. However, to be useful, that data has to be compared to the budget, the work that was performed, the resources used to accomplish the work, and the funding schedule. This additional information provides the context to determine if the project is on budget or if there is a variance. It also indicates the degree of variance from the plan, and by comparing it to the variance thresholds in the project management plan it can indicate if preventive or corrective action is required. Interpreting work performance data and the additional information as a whole provides a context that provides a sound foundation for project decisions.

4.5.1.4 AGREEMENTS

Described in Section 12.2.3.2. A procurement agreement includes terms and conditions, and may incorporate other items that the buyer specifies regarding what the seller is to perform or provide. If the project is outsourcing part of the work, the project manager needs to oversee the contractor's work to make certain that all the agreements meet the specific needs of the project while adhering to organizational procurement policies.

4.5.1.5 ENTERPRISE ENVIRONMENTAL FACTORS

The enterprise environmental factors that can influence the Monitor and Control Project Work process include but are not limited to:

• Project management information systems such as scheduling, cost, resourcing tools, performance indicators, databases, project records, and financials;
• Infrastructure (e.g., existing facilities and equipment, organization´s telecommunications channels);
• Stakeholders’ expectations and risk thresholds; and
• Government or industry standards (e.g., regulatory agency regulations, product standards, quality standards, and workmanship standards).

4.5.1.6 ORGANIZATIONAL PROCESS ASSETS

The organizational process assets that can influence the Monitor and Control Project Work process include but are not limited to:

• Organizational standard policies, processes, and procedures;
• Financial controls procedures (e.g., required expenditure and disbursement reviews, accounting codes, and standard contract provisions);
• Monitoring and reporting methods;
• Issue management procedures defining issue controls, issue identification, and resolution and action item tracking;
• Defect management procedures defining defect controls, defect identification, and resolution and action item tracking; and
• Organizational knowledge base, in particular process measurement and the lessons learned repository.

4.5.2 MONITOR AND CONTROL PROJECT WORK: TOOLS AND TECHNIQUES

4.5.2.1 EXPERT JUDGMENT

Described in Section 4.1.2.1. Expertise should be considered from individuals or groups with specialized knowledge or training in the following topics:

• Earned value analysis,
• Interpretation and contextualization of data,
• Techniques to estimate duration and costs,
• Trend analysis,
• Technical knowledge on the industry and focus area of the project,
• Risk management, and
• Contract management.

4.5.2.2 DATA ANALYSIS

Data analysis techniques that can be used include but are not limited to:

• Alternatives analysis. Alternatives analysis is used to select the corrective actions or a combination of corrective and preventive actions to implement when a deviation occurs.
• Cost-benefit analysis. Described in Section 8.1.2.3. Cost-benefit analysis helps to determine the best corrective action in terms of cost in case of project deviations.
• Earned value analysis. Described in Section 7.4.2.2. Earned value provides an integrated perspective on scope, schedule, and cost performance.
• Root cause analysis. Described in Section 8.2.2.2. Root cause analysis focuses on identifying the main reasons of a problem. It can be used to identify the reasons for a deviation and the areas the project manager should focus on in order to achieve the objectives of the project.
• Trend analysis. Trend analysis is used to forecast future performance based on past results. It looks ahead in the project for expected slippages and warns the project manager ahead of time that there may be problems later in the schedule if established trends persist. This information is made available early enough in the project timeline to give the project team time to analyze and correct any anomalies. The results of trend analysis can be used to recommend preventive actions if necessary.
• Variance analysis. Variance analysis reviews the differences (or variance) between planned and actual performance. This can include duration estimates, cost estimates, resources utilization, resources rates, technical performance, and other metrics. Variance analysis may be conducted in each Knowledge Area based on its particular variables. In Monitor and Control Project Work, the variance analysis reviews the variances from an integrated perspective considering cost, time, technical, and resource variances in relation to each other to get an overall view of variance on the project. This allows for the appropriate preventive or corrective actions to be initiated.

4.5.2.3 DECISION MAKING

A decision-making technique that can be used includes but is not limited to voting. Described in Section 5.2.2.4. Voting can include making decisions based on unanimity, majority, or plurality.

4.5.2.4 MEETINGS

Meetings may be face-to-face, virtual, formal, or informal. They may include project team members and other project stakeholders when appropriate. Types of meetings include but are not limited to user groups and review meetings.

4.5.3 MONITOR AND CONTROL PROJECT WORK: OUTPUTS

4.5.3.1 WORK PERFORMANCE REPORTS

Work performance information is combined, recorded, and distributed in a physical or electronic form in order to create awareness and generate decisions or actions. Work performance reports are the physical or electronic representation of work performance information intended to generate decisions, actions, or awareness. They are circulated to the project stakeholders through the communication processes as defined in the project communications management plan.

Examples of work performance reports include status reports and progress reports. Work performance reports can contain earned value graphs and information, trend lines and forecasts, reserve burndown charts, defect histograms, contract performance information, and risk summaries. They can be presented as dashboards, heat reports, stop light charts, or other representations useful for creating awareness and generating decisions and actions.

4.5.3.2 CHANGE REQUESTS

Described in Section 4.3.3.4. As a result of comparing planned results to actual results, change requests may be issued to expand, adjust, or reduce project scope, product scope, or quality requirements and schedule or cost baselines. Change requests may necessitate the collection and documentation of new requirements. Changes can impact the project management plan, project documents, or product deliverables. Change requests are processed for review and disposition through the Perform Integrated Change Control process (Section 4.6). Changes may include but are not limited to:

• Corrective action. An intentional activity that realigns the performance of the project work with the project management plan.
• Preventive action. An intentional activity that ensures the future performance of the project work is aligned with the project management plan.
• Defect repair. An intentional activity that modifies a nonconforming product or product component.

4.5.3.3 PROJECT MANAGEMENT PLAN UPDATES

Any change to the project management plan goes through the organization's change control process via a change request. Changes identified during the Monitor and Control Project Work process may affect the overall project management plan.

4.5.3.4 PROJECT DOCUMENTS UPDATES

Project documents that may be updated as a result of carrying out this process include but are not limited to:

• Cost forecasts. Described in Section 7.4.3.2. Changes in cost forecasts resulting from this process are recorded using cost management processes.
• Issue log. Described in Section 4.3.3.3. New issues raised as a result of this process are recorded in the issue log.
• Lessons learned register. Described in Section 4.4.3.1. The lessons learned register is updated with effective responses for variances and corrective and preventive actions.
• Risk register. Described in Section 11.2.3.1. New risks identified during this process are recorded in the risk register and managed using the risk management processes.
• Schedule forecasts. Described in Section 6.6.3.2. Changes in schedule forecasts resulting from this process are recorded using schedule management processes.

4.6 PERFORM INTEGRATED CHANGE CONTROL

Perform Integrated Change Control is the process of reviewing all change requests; approving changes and managing changes to deliverables, project documents, and the project management plan; and communicating the decisions. This process reviews all requests for changes to project documents, deliverables, or the project management plan and determines the resolution of the change requests. The key benefit of this process is that it allows for documented changes within the project to be considered in an integrated manner while addressing overall project risk, which often arises from changes made without consideration of the overall project objectives or plans. This process is performed throughout the project. The inputs, tools and techniques, and outputs of the process are depicted in Figure 4-12. Figure 4-13 depicts the data flow diagram for the process.

The Perform Integrated Change Control process is conducted from project start through completion and is the ultimate responsibility of the project manager. Change requests can impact the project scope and the product scope, as well as any project management plan component or any project document. Changes may be requested by any stakeholder involved with the project and may occur at any time throughout the project life cycle. The applied level of change control is dependent upon the application area, complexity of the specific project, contract requirements, and the context and environment in which the project is performed.

Before the baselines are established, changes are not required to be formally controlled by the Perform Integrated Change Control process. Once the project is baselined, change requests go through this process. As a general rule, each project's configuration management plan should define which project artifacts need to be placed under configuration control. Any change in a configuration element should be formally controlled and will require a change request.

Although changes may be initiated verbally, they should be recorded in written form and entered into the change management and/or configuration management system. Change requests may require information on estimated schedule impacts and estimated cost impacts prior to approval. Whenever a change request may impact any of the project baselines, a formal integrated change control process is always required. Every documented change request needs to be either approved, deferred, or rejected by a responsible individual, usually the project sponsor or project manager. The responsible individual will be identified in the project management plan or by organizational procedures. When required, the Perform Integrated Change Control process includes a change control board (CCB), which is a formally chartered group responsible for reviewing, evaluating, approving, deferring, or rejecting changes to the project and for recording and communicating such decisions.

Approved change requests can require new or revised cost estimates, activity sequences, schedule dates, resource requirements, and/or analysis of risk response alternatives. These changes can require adjustments to the project management plan and other project documents. Customer or sponsor approval may be required for certain change requests after CCB approval, unless they are part of the CCB.

4.6.1 PERFORM INTEGRATED CHANGE CONTROL: INPUTS

4.6.1.1 PROJECT MANAGEMENT PLAN

Described in Section 4.2.3.1. Project management plan components include but are not limited to:

• Change management plan. Described in Section 4.2.3.1. The change management plan provides the direction for managing the change control process and documents the roles and responsibilities of the change control board (CCB).
• Configuration management plan. Described in Section 4.2.3.1. The configuration management plan describes the configurable items of the project and identifies the items that will be recorded and updated so that the product of the project remains consistent and operable.
• Scope baseline. Described in Section 5.4.3.1. The scope baseline provides the project and product definition.
• Schedule baseline. Described in Section 6.5.3.1. The schedule baseline is used to assess the impact of the changes in the project schedule.
• Cost baseline. Described in Section 7.3.3.1. The cost baseline is used to assess the impact of the changes to the project cost.

4.6.1.2 PROJECT DOCUMENTS

Project documents that can be considered as inputs for this process include but are not limited to:

• Basis of estimates. Described in Section 6.4.3.2. Basis of estimates indicate how the duration, cost, and resources estimates were derived and can be used to calculate the impact of the change in time, budget, and resources.
• Requirements traceability matrix. Described in Section 5.2.3.2. The requirements traceability matrix helps assess the impact of the change on the project scope.
• Risk report. Described in Section 11.2.3.2. The risk report presents information on sources of overall and individual project risks involved by the change requested.

4.6.1.3 WORK PERFORMANCE REPORTS

Described in Section 4.5.3.1. Work performance reports of particular interest to the Perform Integrated Change Control process include resource availability, schedule and cost data, earned value reports, and burnup or burndown charts.

4.6.1.4 CHANGE REQUESTS

Many processes produce change requests as an output. Change requests (described in Section 4.3.3.4) may include corrective action, preventive action, defect repairs, as well as updates to formally controlled documents or deliverables to reflect modified or additional ideas or content. Changes may or may not impact the project baselines—sometimes only the performance against the baseline is affected. Decisions on those changes are usually made by the project manager.

Change requests that have an impact on the project baselines should normally include information about the cost of implementing the change, modifications in the scheduled dates, resource requirements, and risks. These changes should be approved by the CCB (if it exists) and by the customer or sponsor, unless they are part of the CCB. Only approved changes should be incorporated into a revised baseline.

4.6.1.5 ENTERPRISE ENVIRONMENTAL FACTORS

The enterprise environmental factors that can influence the Perform Integrated Change Control process include but are not limited to:

• Legal restrictions, such as country or local regulations;
• Government or industry standards (e.g., product standards, quality standards, safety standards, and workmanship standards);
• Legal and regulatory requirements and/or constraints;
• Organizational governance framework (a structured way to provide control, direction, and coordination through people, policies, and processes to meet organizational strategic and operational goals); and
• Contracting and purchasing constraints.

4.6.1.6 ORGANIZATIONAL PROCESS ASSETS

The organizational process assets that can influence the Perform Integrated Change Control process include but are not limited to:

• Change control procedures, including the steps by which organizational standards, policies, plans, procedures, or any project documents will be modified, and how any changes will be approved and validated;
• Procedures for approving and issuing change authorizations; and
• Configuration management knowledge base containing the versions and baselines of all official organizational standards, policies, procedures, and any project documents.

4.6.2 PERFORM INTEGRATED CHANGE CONTROL: TOOLS AND TECHNIQUES

4.6.2.1 EXPERT JUDGMENT

Described in Section 4.1.2.1. Expertise should be considered from individuals or groups with specialized knowledge of or training in the following topics:

• Technical knowledge of the industry and focus area of the project,
• Legislation and regulations,
• Legal and procurement,
• Configuration management, and
• Risk management.

4.6.2.2 CHANGE CONTROL TOOLS

In order to facilitate configuration and change management, manual or automated tools may be used. Configuration control is focused on the specification of both the deliverables and the processes, while change control is focused on identifying, documenting, and approving or rejecting changes to the project documents, deliverables, or baselines.

Tool selection should be based on the needs of the project stakeholders including organizational and environmental considerations and/or constraints. Tools should support the following configuration management activities:

• Identify configuration item. Identification and selection of a configuration item to provide the basis for which the product configuration is defined and verified, products and documents are labeled, changes are managed, and accountability is maintained.
• Record and report configuration item status. Information recording and reporting about each configuration item.
• Perform configuration item verification and audit. Configuration verification and configuration audits ensure that the composition of a project's configuration items is correct and that corresponding changes are registered, assessed, approved, tracked, and correctly implemented. This ensures that the functional requirements defined in the configuration documentation are met.

Tools should support the following change management activities as well:

• Identify changes. Identifying and selecting a change item for processes or project documents.
• Document changes. Documenting the change into a proper change request.
• Decide on changes. Reviewing the changes; approving, rejecting, deferring, or making any other decision about changes to the project documents, deliverables, or baselines.
• Track changes. Verifying that the changes are registered, assessed, approved, and tracked and communicating final results to stakeholders.

Tools are also used to manage the change requests and the resulting decisions. Additional considerations should be made for communications to assist the change control board (CCB) members in their duties, as well as to distribute the decisions to the appropriate stakeholders.

4.6.2.3 DATA ANALYSIS

Data analysis techniques that can be used for this process include but are not limited to:

• Alternatives analysis. Described in Section 9.2.2.5. This technique is used to assess the requested changes and decide which are accepted, rejected, or need to be modified to be finally accepted.
• Cost-benefit analysis. Described in Section 8.1.2.3. This analysis helps to determine if the requested change is worth its associated cost.

4.6.2.4 DECISION MAKING

Decision-making techniques that can be used for this process include but are not limited to:

• Voting. Described in Section 5.2.2.4. Voting can take the form of unanimity, majority, or plurality to decide on whether to accept, defer, or reject change requests.
• Autocratic decision making. In this decision-making technique, one individual takes the responsibility for making the decision for the entire group.
• Multicriteria decision analysis. Described in Section 8.1.2.4. This technique uses a decision matrix to provide a systematic analytical approach to evaluate the requested changes according to a set of predefined criteria.

4.6.2.5 MEETINGS

Change control meetings are held with a change control board (CCB) that is responsible for meeting and reviewing the change requests and approving, rejecting, or deferring change requests. Most changes will have some sort of impact on time, cost, resources, or risks. Assessing the impact of the changes is an essential part of the meeting. Alternatives to the requested changes may also be discussed and proposed. Finally, the decision is communicated to the request owner or group.

The CCB may also review configuration management activities. The roles and responsibilities of these boards are clearly defined and agreed upon by the appropriate stakeholders and are documented in the change management plan. CCB decisions are documented and communicated to the stakeholders for information and follow-up actions.

4.6.3 PERFORM INTEGRATED CHANGE CONTROL: OUTPUTS

4.6.3.1 APPROVED CHANGE REQUESTS

Change requests (described in Section 4.3.3.4) are processed according to the change management plan by the project manager, CCB, or an assigned team member. As a result, changes may be approved, deferred, or rejected. Approved change requests will be implemented through the Direct and Manage Project Work process. Deferred or rejected change requests are communicated to the person or group requesting the change.

The disposition of all change requests are recorded in the change log as a project document update.

4.6.3.2 PROJECT MANAGEMENT PLAN UPDATES

Any formally controlled component of the project management plan may be changed as a result of this process. Changes to baselines are only made from the last baseline forward. Past performance is not changed. This protects the integrity of the baselines and the historical data of past performance.

4.6.3.3 PROJECT DOCUMENTS UPDATES

Any formally controlled project document may be changed as a result of this process. A project document that is normally updated as a result of this process is the change log. The change log is used to document changes that occur during a project.

4.7 CLOSE PROJECT OR PHASE

Close Project or Phase is the process of finalizing all activities for the project, phase, or contract. The key benefits of this process are the project or phase information is archived, the planned work is completed, and organizational team resources are released to pursue new endeavors. This process is performed once or at predefined points in the project. The inputs, tools and techniques, and outputs of the process are depicted in Figure 4-14. Figure 4-15 depicts the data flow diagram for the process.

When closing the project, the project manager reviews the project management plan to ensure that all project work is completed and that the project has met its objectives. The activities necessary for the administrative closure of the project or phase include but are not limited to:

• Actions and activities necessary to satisfy completion or exit criteria for the phase or project such as:

• Making certain that all documents and deliverables are up-to-date and that all issues are resolved;
• Confirming the delivery and formal acceptance of deliverables by the customer;
• Ensuring that all costs are charged to the project;
• Closing project accounts;
• Reassigning personnel;
• Dealing with excess project material;
• Reallocating project facilities, equipment, and other resources; and
• Elaborating the final project reports as required by organizational policies.

• Activities related to the completion of the contractual agreements applicable to the project or project phase such as:

• Confirming the formal acceptance of the seller's work,
• Finalizing open claims,
• Updating records to reflect final results, and
• Archiving such information for future use.

• Activities needed to:

• Collect project or phase records,
• Audit project success or failure,
• Manage knowledge sharing and transfer,
• Identify lessons learned, and
• Archive project information for future use by the organization.

• Actions and activities necessary to transfer the project's products, services, or results to the next phase or to production and/or operations.
• Collecting any suggestions for improving or updating the policies and procedures of the organization, and sending them to the appropriate organizational unit.
• Measuring stakeholder satisfaction.

The Close Project or Phase process also establishes the procedures to investigate and document the reasons for actions taken if a project is terminated before completion. In order to successfully achieve this, the project manager needs to engage all the proper stakeholders in the process.

4.7.1 CLOSE PROJECT OR PHASE: INPUTS

4.7.1.1 PROJECT CHARTER

Described in Section 4.1.3.1. The project charter documents the project success criteria, the approval requirements, and who will sign off on the project.

4.7.1.2 PROJECT MANAGEMENT PLAN

Described in Section 4.2.3.1. All components of the project management plan are an input to this process.

4.7.1.3 PROJECT DOCUMENTS

Project documents that may be inputs for this process include but are not limited to:

• Assumption log. Described in Section 4.1.3.2. The assumption log has a record of all the assumptions and constraints that guided the technical specifications, estimates, schedule, risks, etc.
• Basis of estimates. Described in Sections 6.4.3.2 and 7.2.3.2. The basis of estimates is used to evaluate how the estimation of durations, cost, resources, and cost control compared to the actual results.
• Change log. Described in Section 4.6.3.3. The change log contains the status of all change requests throughout the project or phase.
• Issue log. Described in Section 4.3.3.3. The issue log is used to check that there is no open issue.
• Lessons learned register. Described in Section 4.3.3.1. The lessons learned in the phase or project will be finalized before being entered into the lessons learned repository.
• Milestone list. Described in Section 6.2.3.3. The milestone list shows the final dates on which the project milestones have been accomplished.
• Project communications. Described in Section 10.2.3.1. Project communications include any and all communications that have been created throughout the project.
• Quality control measurements. Described in Section 8.3.3.1. The quality control measurements document the results of Control Quality activities and demonstrate compliance with the quality requirements.
• Quality reports. Described in Section 8.2.3.1. The information presented in the quality report may include all quality assurance issues managed or escalated by the team, recommendations for improvement, and the summary of findings from the Control Quality process.
• Requirements documentation. Described in Section 5.2.3.1. Requirements documentation is used to demonstrate compliance with the project scope.
• Risk register. Described in Section 11.2.3.1. The risk register provides information on risks that have occurred throughout the project.
• Risk report. Described in Section 11.2.3.2. The risk report provides information on the risk status and is used to check that there are no open risks at the end of the project.

4.7.1.4 ACCEPTED DELIVERABLES

Described in Section 5.5.3.1. Accepted deliverables may include approved product specifications, delivery receipts, and work performance documents. Partial or interim deliverables may also be included for phased or cancelled projects.

4.7.1.5 BUSINESS DOCUMENTS

Described in Section 1.2.6. Business documents include but are not limited to:

• Business case. The business case documents the business need and the cost benefit analysis that justify the project.
• Benefits management plan. The benefits management plan outlines the target benefits of the project.

The business case is used to determine if the expected outcomes from the economic feasibility study used to justify the project occurred. The benefits management plan is used to measure whether the benefits of the project were achieved as planned.

4.7.1.6 AGREEMENTS

Described in Section 12.2.3.2. The requirements for formal procurement closure are usually defined in the terms and conditions of the contract and are included in the procurement management plan. A complex project may involve managing multiple contracts simultaneously or in sequence.

4.7.1.7 PROCUREMENT DOCUMENTATION

Described in Section 12.3.1.4. To close the contract, all procurement documentation is collected, indexed, and filed. Information on contract schedule, scope, quality, and cost performance along with all contract change documentation, payment records, and inspection results are cataloged. “As-built” plans/drawing or “as-developed” documents, manuals, troubleshooting, and other technical documentation should also be considered as part of the procurement documents when closing a project. This information can be used for lessons learned information and as a basis for evaluating contractors for future contracts.

4.7.1.8 ORGANIZATIONAL PROCESS ASSETS

The organizational process assets that can influence the Close Project or Phase process include but are not limited to:

• Project or phase closure guidelines or requirements (e.g., lessons learned, final project audits, project evaluations, product validations, acceptance criteria, contract closure, resource reassignment, team performance appraisals, and knowledge transfer).
• Configuration management knowledge base containing the versions and baselines of all official organizational standards, policies, procedures, and any project documents.

4.7.2 CLOSE PROJECT OR PHASE: TOOLS AND TECHNIQUES

4.7.2.1 EXPERT JUDGMENT

Described in Section 4.1.2.1. Expertise should be considered from individuals or groups with specialized knowledge or training in the following topics:

• Management control,
• Audit,
• Legal and procurement, and
• Legislation and regulations.

4.7.2.2 DATA ANALYSIS

Data analysis techniques that can be used in project closeout include but are not limited to:

• Document analysis. Described in Section 5.2.2.3. Assessing available documentation will allow identifying lessons learned and knowledge sharing for future projects and organizational assets improvement.
• Regression analysis. This technique analyzes the interrelationships between different project variables that contributed to the project outcomes to improve performance on future projects.
• Trend analysis. Described in Section 4.5.2.2. Trend analysis can be used to validate the models used in the organization and to implement adjustments for future projects.
• Variance analysis. Described in Section 4.5.2.2. Variance analysis can be used to improve the metrics of the organization by comparing what was initially planned and the end result.

4.7.2.3 MEETINGS

Meetings are used to confirm that the deliverables have been accepted, to validate that the exit criteria have been met, to formalize the completion of the contracts, to evaluate the satisfaction of the stakeholders, to gather lessons learned, to transfer knowledge and information from the project, and to celebrate success. Attendees may include project team members and other stakeholders involved in or affected by the project. Meetings may be face-to-face, virtual, formal, or informal. Types of meetings include but are not limited to close-out reporting meetings, customer wrap-up meetings, lessons learned meetings, and celebration meetings.

4.7.3 CLOSE PROJECT OR PHASE: OUTPUTS

4.7.3.1 PROJECT DOCUMENTS UPDATES

All project documents may be updated and marked as final versions as a result of project closure. Of particular interest is the lessons learned register, which is finalized to include final information on phase or project closure. The final lessons learned register may include information on benefits management, accuracy of the business case, project and development life cycles, risk and issue management, stakeholder engagement, and other project management processes.

4.7.3.2 FINAL PRODUCT, SERVICE, OR RESULT TRANSITION

A product, service, or result, once delivered by the project, may be handed over to a different group or organization that will operate, maintain, and support it throughout its life cycle.

This output refers to this transition of the final product, service, or result that the project was authorized to produce (or in the case of phase closure, the intermediate product, service, or result of that phase) from one team to another.

4.7.3.3 FINAL REPORT

The final report provides a summary of the project performance. It can include information such as:

• Summary level description of the project or phase.
• Scope objectives, the criteria used to evaluate the scope, and evidence that the completion criteria were met.
• Quality objectives, the criteria used to evaluate the project and product quality, the verification and actual milestone delivery dates, and reasons for variances.
• Cost objectives, including the acceptable cost range, actual costs, and reasons for any variances.
• Summary of the validation information for the final product, service, or result.
• Schedule objectives including whether results achieved the benefits that the project was undertaken to address. If the benefits are not met at the close of the project, indicate the degree to which they were achieved and estimate for future benefits realization.
• Summary of how the final product, service, or result achieved the business needs identified in the business plan. If the business needs are not met at the close of the project, indicate the degree to which they were achieved and estimate for when the business needs will be met in the future.
• Summary of any risks or issues encountered on the project and how they were addressed.

4.7.3.4 ORGANIZATIONAL PROCESS ASSET UPDATES

Organizational process assets that are updated include but are not limited to:

• Project documents. Documentation resulting from the project's activities; for example, project management plan; scope, cost, schedule, and project calendars; and change management documentation.
• Operational and support documents. Documents required for an organization to maintain, operate, and support the product or service delivered by the project. These may be new documents or updates to existing documents.
• Project or phase closure documents. Project or phase closure documents, consisting of formal documentation that indicates completion of the project or phase and the transfer of the completed project or phase deliverables to others, such as an operations group or to the next phase. During project closure, the project manager reviews prior phase documentation, customer acceptance documentation from the Validate Scope process (Section 5.5), and the agreement (if applicable) to ensure that all project requirements are completed prior to finalizing the closure of the project. If the project was terminated prior to completion, the formal documentation indicates why the project was terminated and formalizes the procedures for the transfer of the finished and unfinished deliverables of the cancelled project to others.
• Lessons learned repository. Lessons learned and knowledge gained throughout the project are transferred to the lessons learned repository for use by future projects.