The Project Integration Management Knowledge Area comprises six processes, as shown in Table 2.1.

The Project Integration Management Knowledge Area is concerned with coordinating all aspects of the project plan and is highly interactive. This Knowledge Area involves identifying and defining the work of the project and combining, unifying, and integrating the appropriate processes. This Knowledge Area also takes into account satisfactorily meeting the requirements of the customer and stakeholder and managing their expectations.

Project planning, project execution, project work monitoring, and change control occur throughout the project and are repeated continuously while you're working on the project. Project planning and execution involve weighing the objectives of the project against the alternatives to bring the project to a successful completion. This includes making choices about how to effectively use resources and coordinating the work of the project on a continuous basis. Monitoring the work of the project involves anticipating potential problems and issues and dealing with them before they reach the critical point. Change control impacts the project plan, which in turn impacts the work of the project, which in turn can impact the project management plan, so you can see that these processes are tightly linked. The processes in this area, as with all the Knowledge Areas, also interact with other processes in the remaining Knowledge Areas. For example, the Identify Stakeholders process uses an output from the Develop Project charter process as an input.

The Project Integration Management Knowledge Area has two tools for assisting with process integration: earned value management (EVM) and project management software. EVM is a project-integrating methodology used in this Knowledge Area to integrate the processes and measure project performance through a project's life cycle. I'll further define EVM and talk more about project management software tools in Chapter 4, "Creating the Project Schedule."

The Project Scope Management Knowledge Area has five processes, as shown in Table 2.2.

Project Scope Management is concerned with defining all the work of the project and only the work needed to successfully produce the project goals. These processes are highly interactive. They define and control what is and what is not part of the project. Each process occurs at least once—and often many times—throughout the project's life.

Project Scope Management encompasses both product scope and project scope. Product scope concerns the characteristics of the product, service, or result of the project. It's measured against the product requirements to determine successful completion or fulfillment. The application area usually dictates the process tools and techniques you'll use to define and manage product scope. Project scope involves managing the work of the project and only the work of the project. Project scope is measured against the project management plan, the project scope statement, the work breakdown structure (WBS), and the WBS dictionary.

Define Scope, Create WBS, Verify Scope, and Control Scope involve the following:

The Project Time Management Knowledge Area has six processes, as shown in Table 2.3.

This Knowledge Area is concerned with estimating the duration of the project plan activities, devising a project schedule, and monitoring and controlling deviations from the schedule. Collectively, this Knowledge Area deals with completing the project in a timely manner. Time management is an important aspect of project management because it concerns keeping the project activities on track and monitoring those activities against the project plan to ensure that the project is completed on time.

Although each process in this Knowledge Area occurs at least once in every project (and sometimes more), in many cases, particularly on small projects, Sequence Activities, Estimate Activity Durations, and Develop Schedule are completed as one activity. Only one person is needed to complete these processes for small projects, and they're all worked on at the same time.

As its name implies, the Project Cost Management Knowledge Area centers around costs and budgets. Table 2.4 shows the processes that make up this Knowledge Area.

The activities in The Project Cost Management Knowledge Area establish cost estimates for resources, establish budgets, and keep watch over those costs to ensure that the project stays within the approved budget. This Knowledge Area is primarily concerned with the costs of resources, but you should think about other costs as well. For example, make certain to examine ongoing maintenance and support costs for software you're considering for the project.

Depending on the complexity of the project, these processes might need the involvement of more than one person. For example, the finance person might not have expertise about the resources documented in the staffing management plan, so the project manager will need to bring in a staff member with those skills to assist with the activities in this process.

Two techniques are used in this Knowledge Area to decide among alternatives and improve the project process: life cycle costing and value engineering. The life cycle costing technique considers a group of costs collectively (such as acquisition, operations, disposal, and so on) when deciding among or comparing alternatives. The value engineering technique helps improve project schedules, profits, quality, and resource usage and optimizes life cycle costs, among others. Value engineering, in a nutshell, involves optimizing project performance and cost and is primarily concerned with eliminating unnecessary costs. By examining the project processes, performance, or even specific activities, the project manager can identify those elements that are not adding value and could be eliminated, modified, or reduced to realize cost savings. These techniques can improve decision making, reduce costs, reduce activity durations, and improve the quality of the deliverables. Some application areas require additional financial analysis to help predict project performance. Techniques such as payback analysis, return on investment, and discounted cash flows are a few of the tools used to accomplish this.

The Project Quality Management Knowledge Area is composed of three processes, as shown in Table 2.5.

The Project Quality Management Knowledge Area assures that the project meets the requirements that it was undertaken to produce. This Knowledge Area focuses on product quality as well as on the quality of the project management process used during the project. These processes measure overall performance and monitor project results and compare them to the quality standards set out in the project-planning process to ensure that the customers will receive the product, service, or result they commissioned.

The Project Human Resource Management Knowledge Area consists of four processes, as shown in Table 2.6.

Project Human Resource Management involves all aspects of people management and personal interaction, including leading, coaching, dealing with conflict, conducting performance appraisals, and more. These processes ensure that the human resources assigned to the project are used in the most effective way possible. Some of the project participants whom you'll get to practice these skills on are stakeholders, team members, and customers. Each requires the use of different communication styles, leadership skills, and team-building skills. A good project manager knows when to enact certain skills and communication styles based on the situation.

Projects are unique and temporary and so usually are project teams. Teams are put together based on the skills and resources needed to complete the activities of the project, and many times project team members might not know one another. Because the makeup of each team is different and the stakeholders involved in the various stages of the project might change, you'll use different techniques at different times throughout the project to manage the processes in this Knowledge Area.

The processes in The Project Communications Management Knowledge Area are related to general communication skills, but they encompass much more than an exchange of information. Communication skills are considered general management skills that the project manager utilizes on a daily basis. The processes in the Process Communications Management Knowledge Area seek to ensure that all project information—including project plans, risk assessments, meeting notes, and more—is collected, documented, archived, and disposed of at the proper time. These processes also ensure that information is distributed and shared with stakeholders, management, and project members at appropriate times. When the project is closed, the information is archived and used as a reference for future projects. This is referred to as historical information in several project processes.

Everyone on the project has some involvement with this Knowledge Area because all project members will send and/or receive project communication throughout the life of the project. It is important that all team members and stakeholders understand how communication affects the project.

Five processes make up The Project Communications Management Knowledge Area, as shown in Table 2.7.

Project Risk Management, as shown in Table 2.8, contains six processes.

Risks include both threats to and opportunities within the project. The processes in this Knowledge Area are concerned with identifying, analyzing, and planning for potential risks, both positive and negative, that might impact the project. This means minimizing the probability and impact of negative risks while maximizing the probability and impact of positive risks. These processes are also used to identify the positive consequences of risks and exploit them to improve project objectives or discover efficiencies that might improve project performance.

Organizations will often combine several of these processes into one step. For example, Identify Risks and Perform Qualitative Risk Analysis might be performed at the same time. The important factor of The Project Risk Management Knowledge Area is that you should strive to identify all the risks and develop responses for those with the greatest consequences to the project objectives.

Four processes are in The Project Procurement Management Knowledge Area, as shown in Table 2.9.

The Project Procurement Management Knowledge Area includes the processes involved with purchasing goods or services from vendors, contractors, suppliers, and others outside the project team. When discussing the Project Procurement Management processes, it's assumed that the discussion is taking place from your perspective as a buyer, while sellers are external to the project team. Interestingly, the seller might manage their work as a project, particularly when the work is performed on contract, and you as the buyer become a key stakeholder in their project.

The remainder of this book will deal with processes and process groups as they occur in order (that is, Initiating, Planning, Executing, Monitoring and Controlling, and Closing), because this is the way you will encounter and manage them during a project.

Organizations exist to generate profits or serve the public. To stay competitive, organizations are always examining new ways of creating business, new ways of gaining efficiencies, or new ways of serving their customers. Sometimes laws are passed to force organizations to make their products safer or to make them less harmful to the environment. Projects might result from any of these needs as well as from business requirements, opportunities, or problems. Most projects will fit one of the seven needs and demands described next. Let's take a closer look at each of these areas:

All of these needs and demands represent opportunities, business requirements, or problems that need to be solved. Management must decide how to respond to these needs and demands, which will more often than not initiate new projects.

After the opportunity for a project becomes evident, the next step might be to initiate it, which means you're ready to jump right into creating a project charter for the project. But before you take that plunge, you should know that some organizations will require a feasibility study prior to making a final decision about starting the project.

Feasibility studies are undertaken for several reasons. One is to determine whether the project is a viable project. A second reason is to determine the probability of the project succeeding. Feasibility studies can also examine the viability of the product, service, or result of the project. For example, the study might ask, "Will the new lemon-flavored soda be a hit? Is it marketable?" The study might also look at the technical issues related to the project and determine whether the technology proposed is feasible, reliable, and easily assimilated into the organization's existing technology structure.

Feasibility studies might be conducted as separate projects, as subprojects, or as the first phase of a project. When you don't know the outcome of the study, it's best to treat it as a separate project. The group of people conducting the feasibility study should not be the same people who will work on the project. Project team members might have built-in biases toward the project and will tend to influence the feasibility outcome toward those biases.

Most organizations don't have the luxury of performing every project that's proposed. Even consulting organizations that sell their project management services must pick and choose the projects on which they want to work. Selection methods help organizations decide among alternative projects and determine the tangible benefits to the company of choosing or not choosing the project.

Project selection methods will vary depending on the company, the people serving on the selection committee, the criteria used, and the project. Sometimes the criteria for selection methods will be purely financial, sometimes purely marketing, and sometimes they'll be based on public perception or political perception. In most cases, the decision is based on a combination of all these and more.

Most organizations have a formal, or at least semiformal, process for selecting and prioritizing projects. In my organization, a steering committee is responsible for project review, selection, and prioritization. A steering committee is a group of folks comprising senior managers and sometimes midlevel managers who represent each of the functional areas in the organization.

Here's how our process works: The steering committee requests project ideas from the business staff prior to the beginning of the fiscal year. These project ideas are submitted in writing and contain a high-level overview of the project goals, a description of the deliverables, the business justification for the project, a desired implementation date, what the organization stands to gain from implementing the project, a list of the functional business areas affected by the project, and (if applicable) a cost-benefit analysis (I'll talk about that in a bit).

A meeting is called to review the projects, and a determination is made on each project about whether it will be included on the upcoming list of projects for the new year. Once the no-go projects have been weeded out, the remaining projects are prioritized according to their importance and benefit to the organization. The projects are documented on an official project list, and progress is reported on the active projects at the regular monthly steering committee meetings.

In theory, it's a great idea. In practice, it works only moderately well. Priorities can and do change throughout the year. New projects come up that weren't originally submitted during the call for projects, and they must be added to the list. Reprioritization begins anew, and resource alignment and assignments are shuffled. But again, I'm getting ahead of myself. Just be aware that organizations usually have a process to recognize and screen project requests, accept or reject those requests based on some selection criteria, and prioritize the projects based on some criteria.

The project selection methods I'll talk about next are ones you should know and understand for the exam. However, keep in mind they are only one aspect of project selection in the real world. The individual opinion, and power, of selection committee members also plays a part in the projects the organization chooses to perform. Don't underestimate the importance of the authority, political standing, and individual aspirations of selection committee members. Those committee members who happen to carry a lot of weight in company circles, so to speak, are likely to get their projects approved just because they are who they are. This is sometimes how project selection works in my organization. How about yours?

Project selection methods are concerned with the advantages or merits of the product of the project. In other words, selection methods measure the value of what the product, service, or result of the project will produce and how it will benefit the organization. Selection methods involve the types of concerns executive managers are typically thinking about. This includes factors such as market share, financial benefits, return on investment, customer retention and loyalty, and public perceptions. Most of these are reflected in the organization's strategic goals. Projects, whether large or small, should always be weighed against the strategic plan. If the project doesn't help the organization reach its goals (increased market share, for example), then the project probably shouldn't be undertaken.

There are generally two categories of selection methods: mathematical models (also known as calculation methods) and benefit measurement methods (also known as decision models). Decision models examine different criteria used in making decisions regarding project selection, while calculation methods provide a way to calculate the value of the project, which is then used in project selection decision making.

The project statement of work (SOW) describes the product, service, or result the project was undertaken to complete. When the project is internal, this document is usually written by either the project sponsor or the initiator of the project. When the project is external to the organization, the buyer typically writes the SOW. For example, suppose you work for a consulting firm and have been assigned as the project manager for a project your company is performing on contract. The customer, the organization you'll be performing the project for, is the one who writes the SOW.

According to the PMBOK® Guide, a project SOW should contain or consider the following elements:

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. The business case often describes the cost-benefit analysis as well. The project comes about and the business case is written as a result of one of the needs or demands listed in the section "Needs and Demands."

The enterprise environmental factors input shows up as an input to many of the other processes we'll discuss throughout the book. This input refers to the factors outside the project that have (or might have) significant influence on the success of the project. According to the PMBOK® Guide, the environmental factors include the following:

These factors can influence the way you manage the project and, in some cases, the outcomes of the project. For example, perhaps the folks assigned to your project are junior level and don't have the skills, experience, or knowledge needed to complete the work of the project. It's up to the project manager to understand the organization's environmental factors and account for and consider how they can influence the management and outcomes of the project.

Organizational process assets are the organization's policies, guidelines, procedures, plans, approaches, and standards for conducting work, including project work. This includes a wide range of elements that might affect several aspects of the project, such as project management policies, safety policies, performance measurement criteria, templates, financial controls, communication requirements, issue and defect management procedures, change control procedures, risk control procedures, and the procedures used for authorizing work. Organizational process assets are divided into two categories: processes and procedures and corporate knowledge base.

Organizational process assets also include the information the organization has learned on previous projects (including how to store and retrieve that information). For example, previous project risks, performance measurements, earned value data, and schedules for past projects are valuable resources of knowledge for the current project. This information is also known as historical information and it falls into the corporate knowledge base category. If you don't capture and store this information, however, it won't be available when you're starting a new project. You'll want to capture and store information such as project financial data (budgets, costs, overruns), historical information, lessons learned, project files, issues and defects, process measurements, and configuration management knowledge.

Organizational process assets and historical information should be reviewed and examined when a new project is starting. Historical information can be very useful to project managers and to stakeholders. When you're evaluating new projects, historical information about previous projects of a similar nature can be handy in determining whether the new project should be accepted and initiated. Historical information gathered and documented during an active project is used to assist in determining whether the project should proceed to the next phase. Historical information will help you with the project charter, project scope statement, development of the project management plan, the process of defining and estimating activities, and more during the project-planning processes.

Understanding previous projects of a similar nature—their problems, successes, issues, and outcomes—will help you avoid repeating mistakes while reusing successful techniques to accomplish the goals of this project to the satisfaction of the stakeholders. Many of the processes in the project management process groups have organizational process assets as an input, implying that you should review the pertinent organizational assets that apply for the process you're about to start. For example, when performing the Estimating Costs process, you might find it helpful to review the activity estimates and budgets on past projects of similar size and scope before estimating the costs for the activities on the new project.

Expert judgment is the only tool and technique in this process. The concept behind expert judgment is to rely on individuals, or groups of people, who have training, specialized knowledge, or skills in the areas you're assessing. These folks might be stakeholders, consultants, other experts in the organization, subject matter experts, the PMO, industry experts, or technical or professional organizations. Expert judgment is a tool and technique used in other planning processes as well.

In the case of developing a project charter, expert judgment would be helpful in assessing the inputs of this process, the environmental factors, organizational assets, and historical information. For example, as the project manager, you might rely on the expertise of your executive committee to help you understand how the proposed project gels with the strategic plan. Or you might rely on team members who have participated on similar projects in the past to make recommendations regarding the proposed project.

The PMBOK® Guide states that the project charter forms a partnership between the organization requesting the project and the one performing the project. The project charter should always be written before beginning the Planning process group. The signature of the project initiator signifies the formal authorization of the project. In practice, my experience has been that the project charter requires input from the key stakeholders and is published under the name of the project sponsor. Let's take a look at the roles of some of the key stakeholders in the project process next.

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

The important factors to remember for the exam about the project charter are that it authorizes the project to begin, it authorizes the project manager to assign resources to the project, it documents the business need and justification, it describes the customer's requirements, and it ties the project to the ongoing work of the organization.

The project charter isn't complete until you've received sign-off from the project sponsor, senior management, and key stakeholders. Sign-off indicates that the document has been read by those signing it (let's hope so, anyway), and that they agree with its contents and are on board with the project. It also involves the major stakeholders right from the beginning and should win their continued participation in the project going forward. If someone has a problem with any of the elements in the charter, now is the time to raise the red flag.

Prior to publishing the charter, I like to hold a kickoff meeting with the key stakeholders to discuss the charter and then obtain their sign-off. I think it's imperative you identify your key stakeholders as soon as possible and involve them in the creation of the project charter. Remember that stakeholder identification is an ongoing activity.

Signing the project charter document is the equivalent of agreeing to and endorsing the project. This doesn't mean the project charter is set in stone, however. Project charters will change throughout the course of the project. As more details are uncovered and outlined and as the Planning processes begin, more project issues will come to light. This is part of the iterative process of project management and is to be expected. The charter will occasionally be revised to reflect these new details, project plans will be revised, and project execution will change to incorporate the new information or direction.

The last step in this process is publishing the charter. Publishing, in this case, simply means distributing a copy of the project charter to the key stakeholders, the customer, the management team, and others who might be involved with the project. Publication can take several forms, including printed format or electronic format distributed via the company email system or on the company's intranet.

Next, we'll look at the Identify Stakeholders process.

The Identify Stakeholders process involves identifying and documenting all the stakeholders on the project, including their interests and potential positive or negative impacts on the project.

Identifying key stakeholders seems like it should be fairly easy, but once you get beyond the obvious stakeholders, the process can get difficult. Sometimes stakeholders, even key stakeholders, will change throughout the project's life. The key stakeholders on a project might include the project sponsor, the customer (who might also be the project sponsor), the project manager, project team members, management personnel, contractors, suppliers, and so on. The stakeholders involved in the project charter and the contract are obvious picks to be included in the stakeholder register, one output of this process.

The inputs of this process are as follows:

According to the PMBOK® Guide, the environmental factors you'll want to pay particular attention to during this process are company culture, organizational structure, and governmental or industry standards. The organization structure will help you understand who has influence and power based on position and where they reside in the organization. The organizational process assets you should be concerned about include stakeholder register templates, lessons learned, and the stakeholder registers from previous projects. We'll talk more about stakeholder register templates later in this chapter.

Don't forget important stakeholders. That could be a project killer. Leaving out an important stakeholder, or one whose business processes weren't considered particularly during the Initiating and Planning processes, could spell disaster for your project.

The tools and techniques of Identify Stakeholders are stakeholder analysis and expert judgment.

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. Be warned that stakeholders are mostly concerned about their own interests and what they (or their organizations) have to gain or lose from the project. In all fairness, we all fall into the stakeholder category, so we're all guilty of focusing on those issues that impact us most.

According to the PMBOK® Guide, there are three steps involved in stakeholder analysis: identifying stakeholders, identifying potential impact, and assessing how stakeholders are likely to react to given situations. Let's look at each step independently.

The first step is identifying all potential stakeholders and capturing general information about them such as the department they work in, contact information, knowledge levels, and influence levels. Since the output of this process is the stakeholder register, I would devise a stakeholder register template now and capture all information about the stakeholders in one place. Table 2.13 is an example of a stakeholder register template.

When we discuss the stakeholder register output later in this section, I'll tell you what additional elements you need to add to your chart.

Stakeholders can be internal or external to the organization. One way to uncover stakeholders whom you might not have thought about at the start is to ask known stakeholders if they're aware of anyone else who might be impacted by this project. Ask team members whether they're aware of stakeholders who haven't been identified. Stakeholders might also come to the forefront once you start uncovering some of the goals and deliverables of the project.

Stakeholder register and stakeholder management strategy are the two outputs of this process. The stakeholder register contains the information we discussed earlier in this section in the stakeholder register template. In addition to the elements we already discussed, the stakeholder register should also contain at least the following details according to the PMBOK® Guide:

The stakeholder management strategy is the documented approach you'll use to minimize negative impacts or influences that stakeholders may have throughout the life of the project. You could use a spreadsheet approach similar to the stakeholder register template to document this information. I would most likely combine the stakeholder register information with the stakeholder management strategy so all the information is contained in one place.

According to the PMBOK® Guide, you'll want to include the following elements in the stakeholder management strategy: