Project Integration Management

The Project Integration Management Knowledge Area consists of seven processes. Table 2.1 lists the processes and the process group for each. The Project Integration Management Knowledge Area involves identifying and defining the work of the project and combining, unifying, and integrating the appropriate processes. This is the only Knowledge Area that contains processes across all five of the project management process groups. The processes within Project Integration are tightly linked because they occur continually throughout the project, meaning that they are iterative in nature.

The Project Integration Management Knowledge Area involves the following:

• Identifying and defining the work of the project
• Combining, unifying, and integrating the appropriate processes
• Managing customer and stakeholder expectations and meeting stakeholder requirements

The following tasks are typical of those performed during work covered by the Project Integration Management Knowledge Area:

• Making choices about where to concentrate resources
• Making choices about where to expend daily efforts
• Anticipating potential issues
• Dealing with issues before they become critical
• Coordinating the work for the overall good of the project
• Making trade-offs among competing objectives and alternatives

Figure 2.1 shows the highlights of the Knowledge Area’s purpose.

Project Scope Management

The Project Scope Management Knowledge Area consists of six processes. Table 2.2 lists the processes and the process group for each. These processes are interactive and define and control what is strategically included versus intentionally excluded from the project scope.

The Project Scope Management Knowledge Area encompasses the following:

Project Scope According to the PMBOK^® Guide, project scope identifies the work that needs to be accomplished to deliver a product, service, or result with the specified features and functionality. This is typically measured against the project management plan.

Product Scope Product scope addresses the features and functionality that characterize the product, service, or result of the project. This is measured against the product specifications to determine successful completion or fulfillment. Product scope entails the following:

• Detailing the requirements of the product of the project
• Validating those details using measurement techniques
• Creating a scope management plan
• Creating a work breakdown structure (WBS)
• Controlling changes to these processes

The following tasks are typical of those performed during work covered by the Project Scope Management Knowledge Area:

• Collecting the project requirements
• Defining the overall project scope
• Measuring the project against the project management plan, project scope statement, and WBS
• Measuring the completion of a product against the product requirements

Keep in mind that the Project Scope Management Knowledge Area is concerned with making sure the project includes all the work required to complete the project—and only the work required to complete the project successfully.

Figure 2.2 shows the highlights of the Knowledge Area’s purpose.

Project Schedule Management

The Project Schedule Management Knowledge Area consists of six processes. Table 2.3 lists the processes and the process group for each. On small projects, the Sequence Activities, Estimate Activity Durations, and Develop Schedule processes are completed as one activity.

The Project Schedule Management Knowledge Area involves the following:

• Creating a detailed plan for how and when the project will produce the results defined by the project scope
• Keeping project activities on track and monitoring those activities against the project plan
• Ensuring that the project is completed on time

The flow of the Project Schedule Management Knowledge Area is very intuitive. First, the project activities are identified and put into the order in which they will occur. Next, duration of activities is estimated. Finally, the project schedule is developed and controlled as the project work moves forward.

Figure 2.3 shows the highlights of the Knowledge Area’s purpose.

Project Cost Management

The Project Cost Management Knowledge Area consists of four processes. Table 2.4 lists the processes and the process group for each. For small projects, the Estimate Costs process and Determine Budget process may be combined into a single process. Remember that your ability to influence cost is greatest at the beginning of the project. Minimal resources have been used, in comparison with other stages. Therefore, changes made during these processes have a greater impact on cost reduction, and your opportunities to effect change decline as you move deeper into the project.

The Project Cost Management Knowledge Area involves the following:

• Establishing cost estimates for resources
• Establishing budgets
• Ensuring that the project is executed within the approved budget
• Improving the quality of deliverables through two techniques: life-cycle costing and value engineering

Life-cycle costing and value engineering are used to improve deliverables. The following is a brief overview of these two techniques:

Life-Cycle Costing Life-cycle costing is an economic evaluation technique that determines the total cost of not only the project (temporary costs) but also owning, maintaining, and operating something from an operational standpoint after the project is completed and turned over.

Value Engineering Value engineering is a technique that looks for alternative product ideas to make certain the team is applying the lowest cost for the same or better-quality results. So, for example, if the original engineer suggests a custom part for a step of the production process, a value engineering review might suggest an alternative that can use a readily available, lower-cost standard part that will produce the same output for a better value.

These are typical tasks performed during work covered by the Project Cost Management Knowledge Area:

• Developing the cost management plan
• Considering the effects of project decisions on cost
• Considering the information requirements of stakeholders

Figure 2.4 shows the highlights of the Knowledge Area’s purpose.

Project Quality Management

The Project Quality Management Knowledge Area consists of three processes. Table 2.5 lists the processes and the process group for each.

The Project Quality Management Knowledge Area involves the following:

• Ensuring that the project meets the requirements that it was undertaken to produce
• Converting stakeholder needs, wants, and expectations into requirements
• Focusing on product quality and the quality of the project management processes used
• Measuring overall performance
• Monitoring project results and comparing them with the quality standards established in the project planning process

The following tasks are typical of those performed during work covered by the Project Quality Management Knowledge Area:

• Implementing the quality management system through the policy, procedures, and quality processes
• Improving the processes
• Verifying that the project is compatible with applicable standards, such as ISO standards

Figure 2.5 shows the highlights of the Knowledge Area’s purpose.

Project Resource Management

The Project Resource Management Knowledge Area consists of six processes. These processes identify, help acquire, and manage the resources needed for project success. Table 2.6 lists the processes and the process group for each. In addition to other resources, developing the project team is a key aspect of this Knowledge Area. Because the makeup of each team is different and the stakeholders involved in the various stages of the project might change, project managers use different techniques at different times throughout the project to manage these processes.

The Project Resource Management Knowledge Area involves the following:

• Addressing all aspects of people management and personnel interaction
• Ensuring that physical and human resources assigned to the project are used in the most effective way possible
• Practicing good project management by knowing when to enact certain skills and communication styles based on the situation

The Project Resource Management Knowledge Area also includes enhancing the skill and efficiency of the project team, which, in turn, improves project performance.

Keep in mind that the project management team and project team are different. The project management team is the group of individuals responsible for planning, controlling, and closing activities. They are considered to be the leadership team of the project. The project team is made up of all the individuals that have assigned roles and responsibilities for completing the project. They are also referred to as the project staff.

Physical resource management focuses on assigning and utilizing materials, equipment, and supplies that are needed for successful completion of the project. It is important for organizations to have data on demands, configuration, and supply of resources.

Figure 2.6 shows the highlights of the Knowledge Area’s purpose.

Project Communications Management

The Project Communications Management Knowledge Area consists of three processes. Together, these processes connect people and information for successful communication throughout the project. Table 2.7 lists the processes and the process group for each.

The Project Communications Management Knowledge Area involves the following:

• Ensuring that all project information is collected, documented, archived, and disposed of at the proper time.
• Distributing and sharing information with stakeholders, management, and project team members.
• Archiving information after project closure to be used as reference for future projects; this information is known as historical information.

As mentioned in Chapter 1 of this book, a good project manager spends up to 90 percent of their time communicating. Overall, much of the project manager’s work involves managing project communication.

Figure 2.7 shows the highlights of the Knowledge Area’s purpose.

Project Risk Management

The Project Risk Management Knowledge Area consists of seven processes, some of which may be combined into one step. Table 2.8 lists the processes and the process group for each. Risks include both threats to and opportunities within the project.

The Project Risk Management Knowledge Area involves the following:

• Identifying, analyzing, and planning for potential risks, both positive and negative, that might impact the project
• Minimizing the probability and impact of negative risks, and increasing the probability and impact of positive risks
• Identifying the positive consequences of risk and exploiting them to improve project objectives or discover efficiencies that may improve project performance

According to the PMBOK^® Guide, a risk is an uncertain event or condition that has a positive or negative effect on one or more project objectives. Every project has some level of uncertainty and, therefore, some level of risk. Keep in mind that a risk is different from an issue. A risk may or may not occur. But when a negative risk materializes and impacts the project, it becomes an issue that must be handled.

Figure 2.8 shows the highlights of the Knowledge Area’s purpose.

Project Procurement Management

The Project Procurement Management Knowledge Area consists of three processes. Table 2.9 lists the processes and the process group for each. While reviewing the procurement processes, remember that you are viewing the process from the perspective of the buyer and that sellers are external to the project team. Together, these three processes allow you to manage the purchasing activities of the project and the life cycle of the procurement contracts.

The Project Procurement Management Knowledge Area involves purchasing goods or services from vendors, contractors, suppliers, and others outside the project team.

Keep in mind that a contract can be simple or complex; contracts can be tailored to the needs of the project. The PMBOK^® Guide defines a contract as an agreement that binds the seller to provide the specified products or services; it also obligates the buyer to compensate the seller as specified.

Figure 2.9 shows the highlights of the Knowledge Area’s purpose.

Project Stakeholder Management

The Project Stakeholder Management Knowledge Area consists of four processes. Table 2.10 lists the processes and the process group for each. This Knowledge Area is concerned with both internal and external stakeholders.

The Project Stakeholder Management Knowledge Area is concerned with identifying all of the stakeholders of the project. These processes also assess stakeholder needs, expectations and involvement on the project.

According to the PMBOK^® Guide, stakeholder engagement and satisfaction should be managed as a key project objective.

Figure 2.10 shows the highlights of the Knowledge Area’s purpose.

Initiating a Project

Project initiation is the formal recognition that a new project, or the next phase in an existing project, should begin and resources may be committed to the project. A project may come about as a result of a need, demand, opportunity, or problem. Once those needs and demands are identified, the next logical step may include performing a feasibility study to determine the viability of the project.

Selecting a Project

As shown in Figure 2.11 , there are a variety of selection methods an organization may choose to utilize. Selection methods help organizations decide among alternative projects and determine the tangible benefits to the company of choosing or not choosing a project. Project selection methods are also used to evaluate and choose between alternative ways to implement the project.

Depending on the organization, a steering committee may be responsible for project review, selection, and prioritization. A steering committee is a group comprising senior managers and, sometimes, midlevel managers who represent each of the functional areas in the organization.

There are generally two categories of selection methods:

• Mathematical models (also known as constrained optimization methods)
• Benefit measurement methods (also known as decision models)

Benefit Measurement Methods

Benefit measurement methods, also known as decision models, employ various forms of analysis and comparative approaches to make project decisions. These methods include comparative approaches, such as these:

• Cost-benefit analysis
• Scoring models
• Cash flow analysis techniques

Let’s take a closer look at the benefit measurement methods.

Cost-Benefit Analysis

Cost-benefit analysis, also known as cost analysis or benefit analysis, compares the cost to produce the product, service, or result of the project with the benefit that the organization will receive as a result of executing the project.

Scoring Models

For weighted scoring models, the project selection committee decides on the criteria that will be used on the scoring model. Each of these criteria is then assigned a weight depending on its importance to the project committee. More-important criteria should carry a higher weight than less-important criteria. Each project is then rated on a numerical scale, with the higher number being the more desirable outcome to the company and the lower number having the opposite effect. This rating is then multiplied by the weight of the criteria factor and added to other weighted criteria scores for a total weighted score. The project with the highest overall weighted score is the best choice.

For example, if Project A contains a weighted score of 31, Project B contains a weighted score of 42, and Project C contains a weighted score of 40, which project would you choose? The correct answer is Project B, since it has the highest weighted score.

Cash Flow Analysis Techniques

The final benefit measurement methods involve a variety of cash flow analysis techniques:

• Payback period
• Discounted cash flows
• Net present value
• Internal rate of return

Figure 2.12 provides an overview of the cash flow analysis techniques.

Let’s take a closer look at these techniques.

PAYBACK PERIOD

The payback period is the length of time it takes the company to recoup the initial costs of producing the product, service, or result of the project. This method compares the initial investment to the cash inflows expected over the life of the product, service, or result.

DISCOUNTED CASH FLOWS

Money received in the future is worth less than money received today. Therefore, you can calculate what the value of funds will be in the future by using the following formula:

FV = PV (1 + i)ⁿ

This formula says that the future value (FV) of the investment equals the present value (PV) times (1 plus the interest rate) raised to the value of the number of time periods (n) the interest is paid.

The discounted cash flow technique compares the value of the future cash flows of the project to today’s dollars. It is literally the reverse of the FV formula. To calculate discounted cash flows, you need to know the value of the investment in today’s terms, or the present value (PV). PV is calculated using the following formula:

PV = FV ÷ (1 + i)ⁿ

To calculate discounted cash flow for the projects you are comparing for selection purposes, apply the PV formula, and then compare the discounted cash flows of all the projects against each other to make a selection.

NET PRESENT VALUE

Net present value (NPV) allows you to calculate an accurate value for the project in today’s dollars. NPV works like discounted cash flows in that you bring the value of future monies received into today’s dollars. With NPV, you evaluate the cash inflows using the discounted cash flow technique applied to each period in which the inflows are expected instead of in one sum. The total present value of the cash flows is then deducted from your initial investment to determine NPV. NPV assumes that cash inflows are reinvested at the cost of capital.

Here are some important notes on NPV calculations:

• If the NPV calculation is greater than zero, accept the project.
• If the NPV calculation is less than zero, reject the project.
• Projects with high returns early in the project are better projects than projects with lower returns early in the project.

INTERNAL RATE OF RETURN

Internal rate of return (IRR) is the discount rate when the present value of the cash inflows equals the original investment. When choosing between projects or when choosing alternative methods of doing a project, projects with higher IRR values are generally considered better than projects with low IRR values.

Keep the following in mind:

• IRR is the discount rate when NPV equals zero.
• IRR assumes that cash inflows are reinvested at the IRR value.
• You should choose projects with the highest IRR value.

Inputs of the Develop Project Charter Process

For the exam, you should know the following inputs of the Develop Project Charter process:

• Business documents
  • Business case
  • Benefits management plan
• Agreements
• Enterprise environmental factors
• Organizational process assets

Let’s look at each of these inputs more closely.

Business Documents Business documents describe the project’s objectives and how the project will contribute to the business’s goals and include documents such as the business case and the benefits management plan. The business case describes the product, service, or result the project was undertaken to complete from a business perspective. The project benefits management plan describes the positive aspects that the project will create and for whom.

Business Case The purpose of a business case is to understand the business need for the project and determine whether the investment in the project is worthwhile. Performing an economic feasibility study is a great first step in establishing the validity of the benefits and is used as the foundation for authorization of project activities. This document is typically created prior to project initiation and is used throughout the project lifecycle. Most business case documents contain the following items:

• Description of the business need for the project
• Description of any special requirements that must be met
• Description of alternative solutions
• Description of the expected results of each alternative solution
• Cost-benefit analysis
• Recommended solution
• Evaluation of ongoing operational needs

Project Benefits Management Plan Where the business case describes the need for a project, the purpose of the project benefits management plan is to describe how and when the benefits of the project can be obtained. According to the PMBOK^® Guide, a project benefit is defined as an outcome of actions, behaviors, products, services, or results that provide value to the sponsoring organization as well as to the project’s intended beneficiaries. This document is typically created early in the project life cycle. Most project benefits management plans contain the following items:

• Description of the target benefits
• Description of the project’s strategic alignment with the organization
• A listing of the benefits’ owners
• Time frames that define when benefits should be realized
• Metrics that will be used to measure the benefits
• Description of known assumptions and risks

Agreements The agreements input is applicable only when the organization you are working for is performing a project for a customer external to the organization. The agreement is used as an input to this process because it typically documents the conditions under which the project will be executed, the time frame, and a description of the work.

Enterprise Environmental Factors Enterprise environmental factors refer to the factors outside the project that may have significant influence on the success of the project. According to the PMBOK^® Guide, the environmental factors, in relation to this process, include but are not limited to the following items:

• Governmental or industry standards, which include elements such as regulatory standards and regulations, quality standards, product standards, and workmanship standards
• Organizational culture and structure
• Marketplace conditions, referring to the supply-and-demand theory along with economic and financial factors

Organizational Process Assets Organizational process assets are the organization’s policies, guidelines, procedures, plans, approaches, or standards for conducting work, including project work.

These assets include a wide range of elements that might affect several aspects of the project. In relation to this process, organizational process assets refer to the following items:

• Processes, policies, templates, and procedures of the organization
• Corporate knowledge base, such as historical information and lessons learned

Tools and Techniques of the Develop Project Charter Process

The Develop Project Charter process has four tools and techniques that you should be familiar with:

• Expert judgment
• Data gathering
• Interpersonal and team skills
• Meetings

Let’s look at each element more closely:

Expert Judgment The concept behind expert judgment is to rely on individuals, or groups of individuals, who have training, specialized knowledge, or skills in the areas you’re assessing. These individuals may be stakeholders, consultants, other experts in the organization, subject matter experts, the project management office (PMO), industry experts, or technical or professional organizations.

Data Gathering There are several data-gathering techniques that can be used, and the PMBOK^® Guide lists three: brainstorming, focus groups, and interviews.

• Brainstorming. Brainstorming is a technique that helps form a list of ideas in a short period of time. It is typically done in a group setting led by a facilitator.
• Focus groups. Focus groups bring together groups of subject matter experts and stakeholders to discuss success criteria, project risk, and other topics in an open forum.
• Interviews. Interviews can be used to gather information for assumptions, constraints, or high-level requirements by talking directly to stakeholders.

Interpersonal and Team Skills Project managers rely on people skills to help bring results to the project. This technique focuses on the interpersonal and team skills needed for project success. This may include, but isn’t limited to, the following skills:

• Conflict management. During a project there are certain periods of strife and interpersonal clash. Conflict management is a technique used to help bring stakeholders into a pool of shared meaning on objectives, success criteria, project description, and other elements.
• Facilitation. Facilitation refers to the application of the project management processes through the use of brainstorming, meeting management, conflict resolution, and other techniques employed by the facilitators.
• Meeting management. Meeting management includes the activities of agenda creation, ensuring stakeholder representation, and preparing and sending minutes and action items.

Meetings During the creation of the charter, meetings are a key activity for identifying objectives, success criteria, deliverables, requirements, milestones, and other information as needed.

In addition, you should be familiar with who is considered to be a key stakeholder. Key project stakeholders include the following individuals:

Project Manager The project manager is the person who assumes responsibility for the success of the project. The project manager should be identified as early as possible in the project and ideally should participate in writing the project charter. The following are examples of what the role of project manager entails:

• Project planning and managing the overall work of the project
• Setting the standards and policies for the projects on which they work
• Establishing and communicating the project procedures to the project team and stakeholders
• Identifying activities and tasks, resource requirements, project costs, project requirements, performance measures, and more
• Keeping all stakeholders and other interested parties informed

Project Sponsor The project sponsor is usually an executive in the organization who has the power and authority to make decisions and settle disputes or conflicts regarding the project. The sponsor takes the project into the limelight, gets to call the shots regarding project outcomes, and funds the project. The project sponsor should be named in the project charter and identified as the final authority and decision maker for project issues.

Project Champion The project champion is usually someone with a great deal of technical expertise or industry knowledge regarding the project who helps focus attention on the project from a technical perspective. Unlike the sponsor, the project champion doesn’t necessarily have a lot of authority or executive powers.

Functional Managers Project managers must work with and gain the support of functional managers in order to complete the project. Functional managers fulfill the administrative duties of the organization, provide and assign staff members to projects, and conduct performance reviews for their staff.

Outputs of the Develop Project Charter Process

The Develop Project Charter process results in two outputs: the project charter and assumption log.

Project Charter According to the PMBOK^® Guide, a useful and well-documented project charter should include at least these elements:

• Purpose or justification for the project
• Project objectives that are measurable
• High-level list of requirements
• High-level description of the project
• High-level list of risks
• Summary milestone schedule
• Summary budget
• List of key stakeholders known
• Criteria for project approval
• Name of the project manager and their authority levels
• Name of the sponsor (or authorizer of the project) and their authority levels

Assumption Log The business case typically identifies high-level assumptions, both at a strategic and at an operational level. The assumption log is a tool used to record all assumptions and constraints throughout the project life cycle, especially as they evolve to more lower-level activity and task assumptions.

Inputs of the Identify Stakeholders Process

There are seven inputs within the Identify Stakeholders process:

Project Charter Within this process, the project charter provides the list of stakeholders along with other individuals or organizations that are affected by the project.

Business Documents The benefits management plan and business case help inform about who are project stakeholders.

Project Management Plan While the project management plan is not available during initial stakeholder identification, once the project management plan is developed, it can be helpful for this process, specifically the communications management plan and the stakeholder engagement plan.

Project Documents Since stakeholder identification occurs throughout the project, project documents like the change and issue log can be an input to this process.

Agreements The parties to any agreement can be stakeholders, and therefore, agreements serve as an input to this process.

Enterprise Environmental Factors The following enterprise environmental factors are utilized within this process:

• Company culture
• Organizational structure
• Governmental or industry standards
• Local, regional, or global trends and practices

Organizational Process Assets The following organizational process assets pertain to this process:

• Stakeholder register templates
• Lessons learned
• Stakeholder register from previous projects

Tools and Techniques of the Identify Stakeholders Process

The tools and techniques of Identify Stakeholders are expert judgment, data gathering, data analysis, data representation, and meetings.

Expert Judgment Expert judgment is used in combination with stakeholder analysis to ensure that stakeholder identification is comprehensive. This may involve interviewing key stakeholders that are already identified and senior management, subject matter experts, or other project managers.

Data Gathering Data gathering for this process would focus on, but is not limited to, the use of questionnaires, surveys, and brainstorming.

Data Analysis Data analysis techniques used for this process include but are not limited to the following:

Stakeholder Analysis During stakeholder analysis, you’ll want to identify the influences stakeholders have in regard to the project and understand their expectations, needs, and desires. From there, you’ll derive more specifics regarding the project goals and deliverables. Stakeholders are often concerned with their own interests and what they have to gain or lose from the project.

According to the PMBOK^® Guide, two steps are involved in stakeholder analysis:

1. Identify all potential stakeholders and capture general information about them, such as the department they work in, contact information, knowledge levels, and influence levels.
2. Assess the reaction or responses of the stakeholder to various situations. This will assist the project manager in managing the stakeholders.

Document Analysis Document analysis assesses available project documentation, as well as lessons learned from previous projects, to help inform potential project stakeholders.

Data Representation This technique may be used in the Identify Stakeholder process and includes, but is not limited to, stakeholder mapping and representation, identifying the potential impact or support each stakeholder may have on the project, and then classifying them according to impact so that you can devise a strategy to deal with them. The PMBOK^® Guide lists four classification models for classifying the power and influence of each stakeholder on a simple four-square grid:

• Power/interest grid, power/influence grid, or impact/influence grid
• Stakeholder cube
• Directions of influence/impact grid
• Salience model (which charts stakeholder power, urgency, and legitimacy)

Meetings Meetings are often used as a mechanism for performing stakeholder analysis. Project managers often gather and analyze information on roles, positions, and interests of stakeholders through meetings.

Outputs of the Identify Stakeholders Process

The Identify Stakeholders process has four outputs: stakeholder register, change requests, project management plan updates, and project documents updates.

Stakeholder Register A stakeholder register captures all of the information about the stakeholders in one place. This general information includes things like the department they work in, contact information, knowledge levels, and influence levels. In addition, the stakeholder register contains at least the following:

• Identifying Information This includes items like contact information, department, role in the project, and so on.
• Assessment Information This includes elements regarding influence, expectations, key requirements, and when the stakeholder involvement is most critical.
• Stakeholder Classification Stakeholders can be classified according to their relationship to the organization and, more important, whether they support the project, are resistant to the project, or have no opinion.

Change Requests Early in the project there aren’t likely to be any change requests. However, as the project progresses and stakeholder identification continues, new information about stakeholders may result in a change request to the product, project management plan, or project documents.

Project Management Plan Updates Similar to change requests, there are not likely to be any updates at the beginning of the project. As stakeholder identification continues throughout the project, updates to the project management plan documents are likely, including to the following documents:

• Requirements management plan
• Communications management plan
• Risk management plan
• Stakeholder engagement plan

Project Documents Updates This process may result in updating project documents such as the following:

• Assumption log
• Issue log
• Risk register