Project Integration Management

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 management 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. It is concerned with choosing from among alternative projects and performing trade-offs among the competing objectives of several projects. This Knowledge Area also takes into account satisfactorily meeting the requirements of the customer and stakeholder and managing their expectations.

Project planning, executing, monitoring, and change control occur throughout the project and are repeated continuously while you're working on the project. Project planning and executing 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 can impact the project schedule, 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 in Chapter 5, “Developing the Project Budget and Communicating the Plan,” and talk more about project management software tools in Chapter 4, “Creating the Project Schedule.”

Project Scope Management

The Project Scope Management Knowledge Area has six 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 scope baseline is made up of the project scope statement, the work breakdown structure (WBS), and the WBS dictionary.

Collect Requirements, Define Scope, Create WBS, Validate Scope, and Control Scope involve the following:

• Defining and detailing the deliverables and requirements of the product of the project
• Creating a WBS
• Validating deliverables using measurement techniques
• Controlling changes to the scope of the project

Project Time Management

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

This Knowledge Area is concerned with estimating the duration of the project 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 management plan to ensure that the project is completed on time.

Although most processes in this Knowledge Area occur 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.

Project Cost Management

As its name implies, the Project Cost Management Knowledge Area centers 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. The earlier you can develop and agree on the scope of the project, the earlier you can estimate costs. The benefit of this practice is that costs are more easily influenced early in the project.

This Knowledge Area is primarily concerned with the costs of resources, but you should think about other costs as well. For example, be certain to examine ongoing maintenance and support costs for software or equipment that may be handed off to the operations group at the end of 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.

Project Quality Management

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 processes 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.

Project Human Resource Management

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 on whom you'll practice these skills 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 project teams usually are too. Teams are built 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. The earlier you can involve team members on the project, the better because you'll want the benefit of their knowledge and expertise during the planning processes. Their participation early on will also help assure their buy-in to the project. 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.

Project Communications Management

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 interpersonal skills that the project manager utilizes on a daily basis. The processes in the Project Communications Management Knowledge Area seek to ensure that all project information—including plans, risk assessments, meeting notes, and more—is collected, organized, stored, and distributed to stakeholders, management, and project members at the proper time. 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.

Three processes make up the Project Communications Management Knowledge Area, as shown in Table 2.7.

Project Risk Management

TheProject Risk Management Knowledge Area, as shown in Table 2.8, contains six processes.

Risks include both threats to and opportunities to 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.

Project managers 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.

Project Procurement Management

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. As such, these processes involve negotiating and managing contracts and other procurement vehicles and managing changes to the contract or work order. 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.

Project Stakeholder Management

There are four processes in the Project Stakeholder Management Knowledge Area, as shown in Table 2.10.

The Project Stakeholder Management Knowledge Area is concerned with identifying all of the stakeholders associated with the project, both internal and external to the organization. These processes also assess stakeholder needs, expectations, and involvement on the project and seek to keep the lines of communication with stakeholders open and clear. Remember from Chapter 1 that the definition of a successful project is one where the stakeholders are satisfied. These processes assure that stakeholder expectations are met and that their satisfaction is a successful deliverable of the 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.

Needs and Demands

Organizations exist to generate profits or serve the public. To stay competitive, organizations are always examining new ways of creating business, gaining efficiencies, or 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. According to the PMBOK^® Guide, most projects will fit one of the seven needs and demands described next. The needs and demands are documented in the business case, which is an input to the Develop Project Charter process. Let's take a closer look at each of these areas:

Market Demand  The demands of the marketplace can drive the need for a project. For example, a bank initiates a project to offer customers the ability to apply for mortgage loans over the Internet because of a drop in interest rates and an increase in demand for refinancing and new home loans.

Strategic Opportunity/Business Need  The new phone system talked about earlier that was announced at the quarterly meeting came about as a result of a business need. The CEO, on advice from his staff, was advised that call volumes were maxed on the existing system. Without a new system, customer service response times would suffer, and that would eventually affect the bottom line.

Customer Request  Customer requests run the gamut. Generally speaking, most companies have customers, and their requests can drive new projects. Customers can be internal or external to the organization. Government agencies don't have external customers per se (we're captive customers at any rate), but there are internal customers within departments and across agencies.

Perhaps you work for a company that sells remittance-processing equipment and you've just landed a contract with a local utility company. This project is driven by the need of the utility company to automate its process or upgrade its existing process. The utility company's request to purchase your equipment and consulting services is the project driver.

Technological Advance  Many of us own a smartphone that keeps names and addresses handy along with a calendar, a to-do list, and a plethora of other apps to help organize our day or add a little fun in between meetings. I couldn't live without mine. However, a newer, better version is always coming to market. Satellite communications, bigger screens, thinner bodies, touch screens, video streaming, and more are all examples of technological advances. Electronics manufacturers are continually revamping and reinventing their products to take advantage of new technology (thank you!).

Legal Requirement  Private industry and government agencies both generate new projects as a result of laws passed during every legislative season. For example, new sales tax or healthcare laws might require changes to the computer programs that support these systems. The requirement that food labels on packaging describe the ingredients in the product, the calories, and the recommended daily allowances is another example of legal requirements that drive a project.

Environmental Considerations  Many organizations today are undergoing a “greening” effort to reduce energy consumption, save fuel, reduce their carbon footprint, and so on. Another example might include manufacturing or processing plants that voluntarily remove their waste products from water prior to putting the water back into a local river or stream to prevent contamination. These are examples of environmental considerations that result in projects.

Social Need  The last need is a result of social demands. For example, perhaps a developing country is experiencing a fast-spreading disease that's infecting large portions of the population. Medical supplies and facilities are needed to vaccinate and treat those infected with the disease.

Feasibility Studies

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. 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. Sometimes, you'll have a basic feel for the way the study may turn out and you could consider making the feasibility study the first phase of the project. When you don't have any preconceived ideas about 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.

Performing Project Selection and Assessment

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 and evaluation methods help organizations decide among alternative projects and determine the tangible benefits to the company of choosing or not choosing a project.

How projects are assessed will vary depending on the company, the people serving on the selection committee, the criteria used, and the project. Assessments are usually performed first by examining the information presented about the project and developing an understanding of the key deliverables required for success. Reviewing past projects of similar size and scope, including reviewing the lessons learned while performing those projects, will help in determining whether the project is achievable given the known assumptions and constraints. 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 consisting of senior managers and sometimes mid-level 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 and other subject matter experts 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.

I'll discuss several project selection methods next. You may encounter a question or two on the exam regarding these methods, but keep in mind that while you will conduct selection analysis with your stakeholders using the techniques outlined next, the actual selection of the projects is outside the scope of the project manager's duties. The stakeholders and or the project sponsor will select the projects the organization will undertake.

Selection methods are one way the stakeholders may choose between projects. The individual opinions, and power, of selection committee members also play 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?

Using Project Selection Methods

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 about which executive managers are typically thinking. 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), or if it doesn't align with the organization's expected business values, 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 benefit analysis techniques and decision models). Decision models examine different criteria used in making decisions regarding project selection, whereas calculation methods provide a way to calculate the value of the project, which is then used in project-selection decision making.

Applying Project Selection Methods

Now that we've discussed some of the project selection techniques, let's look at how to apply them when choosing projects or project alternatives. You can use one of the benefit measurement methods alone or in combination with others to come up with a selection decision. Remember that payback period is the least precise of all the cash flow techniques, NPV is the most conservative cash flow technique, and NPV and IRR will generally bring you to the same accept/reject conclusion.

You can use project selection methods, and particularly the benefit measurement methods, to evaluate multiple projects or a single project. You might be weighing one project against another or simply considering whether the project you're proposing is worth performing.

Project Statement of Work

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:

Business Need  The business need for the project relates to the needs of the organization itself. The need might be based on governmental regulation, technological advances, market demands, or a legal requirement.

Product Scope Description  The product scope description describes the characteristics of the product, service, or result of the project. The product scope description should be documented and should also include a description of the relationship between the business need or demand that's driving the project and the products being created.

Product descriptions contain less detail in the early phases of a project and more detail as the project progresses. Product scope descriptions, like the work of the project, are progressively elaborated. They will contain the greatest amount of detail in the project's Executing processes.

When a project is performed under contract, typically the buyer of the product or service will provide the product description to the vendor or contractor. The product description can serve as a statement of work when the project is contracted to a vendor. A statement of work describes the product, service, or result in enough detail that the vendor can accurately price the contract and satisfactorily fulfill the requirements of the project.

Strategic Plan  Part of the responsibility of a project manager during the Initiating processes is to take into consideration the company's strategic plan. Perhaps the strategic plan states that one of the company goals is to build 15 new stores by the end of the next fiscal year. If your project entails implementing a new inventory software system, it makes sense to write the requirements for your project with the 15 new stores in mind. Your management team will refer to the strategic plan when choosing which new projects to initiate and which ones to drop, depending on their relationship to the strategic vision of the company.

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. The business case often describes the cost-benefit analysis and the business need or demand that brought about the project.

Performing a feasibility study is a great first step in building the business case. The feasibility study will examine the needs and demands of the business, marketing opportunities, costs, risks, and more while taking into account the given assumptions and constraints of the proposed products or services. Once the feasibility study is completed, it's easy to build a business case based on the findings of the study. Most sound business case documents contain the following elements:

• Description of the business need for the project, including how the project aligns with the organization's strategic vision. This description should include the business need or demand that's driving the project and may note the feasibility study findings. This section should also include a description of the impact to the organization if the project is not undertaken.
• Description of any special requirements that must be met, such as compliance requirements, legal requirements, government regulations, and so on.
• Description of alternative solutions. This should include a high-level description of costs, the feasibility of implementing each alternative, and a description of any impacts to the organization as a result of this solution. (Cost-benefit, payback, and other financial analyses are generally included in this section of the business case.)
• Description of the expected results of each alternative solution.
• Cost-benefit analysis.
• Recommended solution.

Agreements

Agreements refer to documents that define the intent of the project and are usually legal in nature. For example, a contract is an example of an agreement. Other agreements might include a memorandum of understanding, emails, an intergovernmental agency agreement, a verbal commitment, and so on. A contract is applicable when you are performing a project for a customer external to the organization. Agreements are an input to this process because they typically document the conditions under which the project will be executed, the time frame, and a description of the work.

Enterprise Environmental Factors

Enterprise environmental factors show up as 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 may include the following:

Organizational Culture, Structure, and Governance  I talked about organizational structures and their influence on the organization in Chapter 1.

Governmental or Industry Standards  These include elements such as regulatory standards and regulations (for instance, doctors must be licensed to practice medicine on people or pets), quality standards (International Standards Organization standards, for example), product standards, and workmanship standards.

Infrastructure  This refers to the organization's facilities and capital equipment. I'll also include information technology in this category.

Human Resources  This refers to the existing staff's skills and knowledge.

Personnel Administration  These are guidelines for hiring and firing, training, and employee performance reviews.

Organization's Work Authorization System  This defines how the work of the project is authorized.

Marketplace Conditions  The old supply-and-demand theory applies here along with economic and financial factors.

Stakeholder Risk Tolerances  This is the level of risk stakeholders are willing to take on. I'll talk more about this in Chapter 6, “Risk Planning.”

Political Climate  This concerns both the internal and external political climate or influences on the project or organization.

Organization's Established Communications Channels  These are the mechanisms the organization uses to communicate both internally and externally.

Commercial Databases  These refer to industry-specific information, risk databases, and so on.

Project Management Information Systems  These refer to software tools that assist with managing projects, collecting and distributing project data, scheduling projects, managing and controlling changes, and more.

Some or all of 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

Organizational process assets are the organization's policies, guidelines, processes, procedures, plans, approaches, and standards for conducting work, including project work. Organizational process assets are divided into two categories: processes and procedures and corporate knowledge base. Processes and procedures refers to 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.

Corporate knowledge base refers to items such as lessons learned, process measurement databases, project files, and 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 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 both help you avoid repeating mistakes and help you reuse 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 Estimate 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.

Tools and Techniques

Tools and techniques are multifaceted and include elements such as brainstorming, meetings, focus groups, alternatives analysis, and much more. Tools and techniques are used with the inputs of every process to produce the outputs of that process. For example, in Develop Project Charter, the SOW, business case, agreements, and other inputs are examined using the tools and techniques of this process (expert judgment and facilitation techniques) to produce the project charter, which is the only output of this process. Let's look at the two tools and techniques of this process in more detail.

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 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.

Facilitation techniques is a tool used to help derive the final content of the project charter. According to the PMBOK^® Guide, the key facilitation techniques you'll use in this process are brainstorming, managing meetings and keeping them on track, resolving conflict, and resolving problems. Project managers and others who serve as meeting facilitators should hone these skills as you will use them often throughout the course of the project.

Pulling the Project Charter Together

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

• 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
• Milestone schedule (summary level)
• Budget (summary level)
• 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

It is also helpful to include a high-level list of assumptions and constraints that are known at the time the charter is developed. You should examine organizational factors such as culture and past project successes, historical data, information from experts within the organization, and other organizational process assets when determining assumptions and constraints. These will be further defined and documented in the project scope statement that's written later in the Planning process.

For the exam, the important factors to remember 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, justification, and impact; it describes the customer's requirements; it identifies key deliverables based on the business requirements; it sets stakeholder expectations; it ensures stakeholder agreement; and it ties the project to the ongoing work of the organization.

Let's take a brief look at the key stakeholders who might be involved with the project charter and the role they'll play in its development and their role in the project in the future.

Key Stakeholders

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 you begin the Planning process group.

According to the PMBOK^® Guide, the project charter is a document issued by the person (or organization) who initiated the project or the project sponsor. My experience has been that the project charter requires input from the key stakeholders and is published and signed by the project sponsor. Once the charter is signed, the project is formally authorized and work can begin.

Let's take a look at the roles of some of the key stakeholders and how they can help contribute to creating a comprehensive project charter. I'll explain how to identify the right stakeholders for your project in the next main section, “Identifying Stakeholders.”

Project Charter Sign-Off

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 acceptance and participation in the project going forward. If someone has a problem with any of the elements in the charter, now is the time to speak up.

Prior to publishing the charter, I like to hold a kickoff meeting with the key stakeholders to discuss the charter, inform them of the key deliverables and milestones, ensure that they understand their roles and responsibilities in relation to the project, and then obtain their sign-off. I think it's imperative for you to 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, means distributing a copy of the approved 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.

Identify Stakeholders Inputs

The Identify Stakeholders process involves identifying and documenting all the stakeholders on the project, including their interests, interdependencies, 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 become 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:

• Project charter
• Procurement documents
• Enterprise environmental factors
• Organizational process assets

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 and lessons learned, including the stakeholder registers from previous projects. We'll talk more about stakeholder register templates later in this chapter.

The project charter and procurement documents can be helpful in identifying stakeholders. The signature pages of these documents, along with the descriptions and deliverables sections, may name stakeholders or business units you wouldn't ordinarily think about.

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.

Stakeholder Analysis

The tools and techniques of Identify Stakeholders are stakeholder analysis, expert judgment, and meetings. We have already discussed expert judgment. Meetings in this case refers to profiling and analyzing stakeholders’ involvement in the project, their roles, knowledge level, interests, and more.

According to the PMBOK^® Guide, stakeholder analysis involves using qualitative and quantitative data to analyze which stakeholders’ interests should be considered throughout the project. Those with the most influence will also have the most impact.

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, three steps are involved in stakeholder analysis: identifying stakeholders, analyzing 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, you should devise a stakeholder register template now and capture all information about the stakeholders in one place. Here is an example of a stakeholder register template:

When we discuss the stakeholder register output later in this chapter, 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 know 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 Strategy

Stakeholder register is the only output of this process. The stakeholder register contains the information we discussed earlier about the stakeholder register template. In addition to the elements we already discussed, the stakeholder register should contain at least the following details, according to the PMBOK^® Guide:

Identifying Information  This includes items such as 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 (internal or external, for example) and, more important, whether they support the project, are resistant to the project, or have no opinion.