,

Chapter 2

Creating the Project Charter

The PMP® exam content from the Initiating the Project performance and planning the project domains covered in this chapter includes the following:

• Task 1: Perform project assessment based on available information and meetings with the sponsor, customer, and other subject matter experts, in order to evaluate the feasibility of new products or services within the given assumptions and/or constraints.
• Task 2: Define the high-level scope of the project based on business and compliance requirements in order to meet the customer’s project expectations.
• Task 3: Perform key stakeholder analysis using brainstorming, interviewing, and other data-gathering techniques in order to ensure expectation alignment and gain support for the project.
• Task 4: Identify and document high-level risks, assumptions, and constraints based on current environment, historical data, and/or expert judgment in order to identify project limitations and propose an implementation approach.
• Task 5: Develop the project charter by further gathering and analyzing stakeholder requirements in order to document project scope, milestones, and deliverables.
• Task 6: Obtain approval of the project charter from the sponsor and customer (if required) in order to formalize the authority assigned to the project manager and gain commitment and acceptance for the project.
• Task 12: Conduct a kick-off meeting with all key stakeholders, in order to announce the start of the project, communicate the project milestones, and share other relevant information..
• Knowledge and Skills:
  • Cost-benefit analysis
  • Business case development
  • Project section criteria (for example, cost, feasibility, impact)
  • Stakeholder identification techniques
  • Risk identification techniques
  • Elements of a project charter

Now that you’re armed with a detailed overview of project management, you can easily determine whether your next assignment really is a project or an ongoing operation. You’ve learned some of the basics of good project management techniques. Now you can start putting those techniques into practice during the Initiating process group, which is where all projects start. As you’ve probably already guessed, you’ll be using some of the general management skills outlined in Chapter 1, “What Is a Project?”

One of the first skills you will put to use will be your communication skills. Are you surprised? Of course you’re not. It all starts with communication. You can’t start defining the project until you’ve first talked to the project sponsor, key stakeholders, and management personnel. All good project managers have honed their communication skills to a nice sharp edge.

You’ll remember from Chapter 1 that Initiating is the first process group in the five project management process groups. You can think of it as the official project kickoff. Initiating acknowledges that the project, or the next phase in an active project, should begin. This process group culminates in the publication of a project charter and a stakeholder register. I’ll cover each in this chapter. But before we dive into the Initiating processes, we have one more preliminary topic to cover regarding the nine Knowledge Areas.

At the end of this chapter, I’ll introduce a case study that will illustrate the main points of the chapter. I’ll expand on this case study from chapter to chapter, and you’ll begin building a project using each of the skills you learn.

Exploring the Project Management Knowledge Areas

We talked about the five process groups in Chapter 1. They are Initiating, Planning, Executing, Monitoring and Controlling, and Closing. Each process group is made up of a collection of processes used throughout the project life cycle. The PMBOK® Guide groups these processes into nine categories that it calls the Project Management Knowledge Areas. These groupings, or Knowledge Areas, bring together processes that have characteristics in common. For example, the Project Cost Management Knowledge Area involves all aspects of the budgeting process, as you would suspect. Therefore, processes such as Estimate Costs, Determine Budget, and Control Costs belong to this Knowledge Area. Here’s the tricky part: these processes don’t belong to the same project management process groups (Estimate Costs and Determine Budget are part of the Planning process group, and Control Costs is part of the Monitoring and Controlling process group). Think of it this way: Knowledge Areas bring together processes by commonalities, whereas project management process groups are more or less the order in which you perform the project management processes (although remember that you can come back through these processes more than once). The PMBOK® Guide names the nine Knowledge Areas as follows:

• Project Integration Management
• Project Scope Management
• Project Time Management
• Project Cost Management
• Project Quality Management
• Project Human Resource Management
• Project Communications Management
• Project Risk Management
• Project Procurement Management

Let’s take a closer look at each Knowledge Area so you understand how they relate to the process groups. Included in each of the following sections are tables that illustrate the processes that make up the Knowledge Area and the project management process group to which each process belongs. This will help you see the big picture in terms of process groups compared to Knowledge Areas. I’ll discuss each of the processes in the various Knowledge Areas throughout the book, but for now, you’ll take a high-level look at each of them.

Project Integration Management

The Project Integration Management Knowledge Area comprises six processes, as shown in Table 2-1.

Table 2-1: Project Integration Management

Process Name	Project Management Process Group
Develop Project Charter	Initiating
Develop Project Management Plan	Planning
Direct and Manage Project Execution	Executing
Monitor and Control Project Work	Monitoring and Controlling
Perform Integrated Change Control	Monitoring and Controlling
Close Project or Phase	Closing

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

Project Scope Management

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

Table 2-2: Project Scope Management

Process Name	Project Management Process Group
Collect Requirements	Planning
Define Scope	Planning
Create WBS	Planning
Verify Scope	Monitoring and Controlling
Control Scope	Monitoring and Controlling

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:

• Defining and detailing the deliverables and requirements of the product of the project
• Creating a project scope management plan
• Creating a WBS
• Verifying deliverables using measurement techniques
• Controlling changes to these processes

Project Time Management

The Project Time Management Knowledge Area has six processes, as shown in Table 2-3.

Table 2-3: Project Time Management

Process Name	Project Management Process Group
Define Activities	Planning
Sequence Activities	Planning
Estimate Activity Resources	Planning
Estimate Activity Durations	Planning
Develop Schedule	Planning
Control Schedule	Monitoring and Controlling

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.

Project Cost Management

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.

Table 2-4: Project Cost Management

Process Name	Project Management Process Group
Estimate Costs	Planning
Determine Budget	Planning
Control Costs	Monitoring and Controlling

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.

Project Quality Management

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

Table 2-5: Project Quality Management

Process Name	Project Management Process Group
Plan Quality	Planning
Perform Quality Assurance	Executing
Perform Quality Control	Monitoring and Controlling

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.

Project Human Resource Management

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

Table 2-6: Project Human Resource Management

Process Name	Project Management Process Group
Develop Human Resource Plan	Planning
Acquire Project Team	Executing
Develop Project Team	Executing
Manage Project Team	Executing

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

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

Table 2-7: Project Communication Management

Process Name	Project Management Process Group
Identify Stakeholders	Initiating
Plan Communications	Planning
Distribute Information	Executing
Manage Stakeholder Expectations	Executing
Report Performance	Monitoring and Controlling

Project Risk Management

Project Risk Management, as shown in Table 2-8, contains six processes.

Table 2-8: Project Risk Management

Process Name	Project Management Process Group
Plan Risk Management	Planning
Identify Risks	Planning
Perform Qualitative Risk Analysis	Planning
Perform Quantitative Risk Analysis	Planning
Plan Risk Responses	Planning
Monitor and Control Risk	Monitoring and Controlling

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.

Project Procurement Management

Four processes are in the Project Procurement Management Knowledge Area, as shown in Table 2-9.

Table 2-9: Project Procurement Management

Process Name	Project Management Process Group
Plan Procurements	Planning
Conduct Procurements	Executing
Administer Procurements	Monitoring and Controlling
Close Procurements	Closing

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.

Understanding How Projects Come About

Your company’s quarterly meeting is scheduled for today. You take your seat, and each of the department heads gets up and gives their usual “We can do it” rah-rah speech, one after the other. You sit up a little straighter when the CEO takes the stage. He starts his part of the program pretty much the same way the other department heads did, and before long, you find yourself drifting off. You are mentally reviewing the status of your current project when suddenly your daydreaming trance is shattered. You perk up as you hear the CEO say, “And the new phone system will be installed by Thanksgiving.”

Wait a minute. You work in the telecom department and haven’t heard a word about this project until today. You also have a funny feeling that you’ve been elected to manage this project. It’s amazing how good communication skills are so important for project managers but not for… well, we won’t go there.

Project initiation is the formal recognition that a project, or the next phase in an existing project, should begin and resources should be committed to the project. Unfortunately, many projects are initiated the way the CEO did in this example. Each of us, at one time or another, has experienced being handed a project with little to no information and told to “make it happen.” The new phone system scenario is an excellent example of how not to initiate a project.

Taking one step back leads you to ask, “How do projects come about in the first place? Do CEOs just make them up like in this example?” Even though your CEO announced this new project at the company meeting with no forewarning, no doubt it came about as a result of a legitimate need. Believe it or not, CEOs don’t just dream up projects just to give you something to do. They’re concerned about the future of the company and the needs of the business and its customers.

The business might drive the need for a project, customers might demand changes to products, or legal requirements might create the need for a new project. According to the PMBOK® Guide, projects come about as a result of one of seven needs or demands. Once those needs and demands are identified, the next logical step might include performing a feasibility study to determine the viability of the project. I’ll cover these topics next.

Needs and Demands

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. According to the PMBOK® Guide, most projects will fit one of the seven needs and demands described next. 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 multifunctioning cell phone that keeps names and addresses handy along with a calendar and a to-do list of some kind. I couldn’t live without mine. However, a newer, better version is always coming to market. Satellite communications now allow these devices to also act as GPS units. The introduction of satellite communications is an example of a technological advance. Because of this introduction, electronics manufacturers revamped their products to take advantage of this new technology.

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 laws might require new programming to the existing sales tax system. The requirement that food labels appear on every package describing the ingredients and the recommended daily allowances is another example of legal requirements that drive a project.

Ecological impacts Many organizations today are undergoing a “greening” effort to reduce energy consumption, save fuel, reduce their carbon footprint, and so on. These are examples of ecological impacts 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. 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.

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.

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

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

How projects are assessed 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 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 selecting projects is outside the scope of the project manager’s duties. Selection methods are one way the sponsor or customer may choose between projects. 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?

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

Mathematical Models

For the exam, all you need to understand about mathematical models is that they use linear, dynamic, integer, nonlinear, and/or multi-objective programming in the form of algorithms—or in other words, a specific set of steps to solve a particular problem. These are complicated mathematical formulas and algorithms that are beyond the scope of this book and require an engineering, statistical, or mathematical background to fully understand. Organizations considering undertaking projects of enormous complexity might use mathematical modeling techniques to make decisions regarding these projects. Mathematical models are also known as constrained optimization methods. The vast majority of project selection techniques will use the benefit measurement methods to make project selection decisions.

Benefit Measurement Methods

Benefit measurement methods employ various forms of analysis and comparative approaches to make project decisions. These methods include comparative approaches such as cost-benefit analysis, scoring models, and benefit contribution methods that include various cash flow techniques and economic models. You’ll examine several of these methods, starting with cost-benefit analysis.

Cost-Benefit Analysis

One common benefit measurement method is the cost-benefit analysis. The name of this method implies what it does—it compares the cost to produce the product, service, or result of the project to the benefit (usually financial in the form of savings or revenue generation) that the organization will receive as a result of executing the project. Obviously, a sound project choice is one where the costs to implement or produce the product of the project are less than the financial benefits. How much less is the organization’s decision. Some companies are comfortable with a small margin, while others are comfortable with a much larger margin between the two figures.

When examining costs for a cost-benefit analysis, include the costs to produce the product or service, the costs to take the product to market, and the ongoing operational support costs. For example, let’s say your company is considering writing and marketing a database software product that will allow banks to dissect their customer base, determine which types of customers buy which types of products, and then market more effectively to those customers. You will take into account some of the following costs:

• The costs to develop the software, such as programmer costs, hardware costs, and testing costs
• Marketing costs such as advertising, traveling costs to perform demos at potential customer sites, and so on
• Ongoing costs such as having a customer support staff available during business hours to assist customers with product questions and problems

Let’s say the cost to produce this software plus the ongoing support costs total $5 million. Initial projections look like the demand for this product is high. Over a three-year period, which is the potential life of the software in its proposed form, projected revenues are $12 million. Taking only the financial information into account, the benefits outweigh the costs of this project. This project should receive a go recommendation.

Scoring Models

Another project selection technique in the benefit measurement category is a scoring model, or weighted scoring model. My organization uses weighted scoring models not only to choose between projects but also as a method to choose between competing bids on outsourced projects.

Weighted scoring models are quite simple. The project selection committee decides on the criteria that will be used on the scoring model—for example, profit potential, marketability of the product or service, ability of the company to quickly and easily produce the product or service, and so on. Each of these criteria is assigned a weight depending on its importance to the project committee. More important criteria should carry a higher weight than less important criteria.

Then each project is rated on a scale from 1 to 5 (or some such assignment), 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. Table 2-10 shows an example that brings this together.

Table 2-10: Weighted Scoring Model

In this example, Project A is the obvious choice.

Cash Flow Analysis Techniques

The remaining benefit measurement methods involve a variety of cash flow analysis techniques, including payback period, discounted cash flows, net present value, and internal rate of return. We’ll look at each of these techniques individually, and I’ll provide you with a crash course on their meanings and calculations.

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. For example, say the initial investment on a project is $200,000, with expected cash inflows of $25,000 per quarter every quarter for the first two years and $50,000 per quarter from then on. The payback period is two years and can be calculated as follows:

Initial investment = $200,000

Cash inflows = $25,000 * 4 (quarters in a year) = $100,000 per year total inflow

Initial investment ($200,000) – year 1 inflows ($100,000) = $100,000 remaining balance

Year 1 inflows remaining balance – year 2 inflows = $0

Total cash flow year 1 and year 2 = $200,000

The payback is reached in two years.

The fact that inflows are $50,000 per quarter starting in year 3 makes no difference because payback is reached in two years.

The payback period is the least precise of all the cash flow calculations. That’s because the payback period does not consider the value of the cash inflows made in later years, commonly called the time value of money. For example, if you have a project with a five-year payback period, the cash inflows in year 5 are worth less than they are if you received them today. The next section will explain this idea more fully.

Discounted Cash Flows

As I just stated, money received in the future is worth less than money received today. The reason for that is the time value of money. If I borrowed $2,000 from you today and promised to pay it back in three years, you would expect me to pay interest in addition to the original amount borrowed. If you were a family member or a really close friend, maybe you wouldn’t, but ordinarily this is the way it works. You would have had the use of the $2,000 had you not lent it to me. If you had invested the money (does this bring back memories of your mom telling you to save your money?), you’d receive a return on it. Therefore, the future value of the $2,000 you lent me today is $2,315.25 in three years from now at 5 percent interest per year. Here’s the formula for future value calculations:

FV = PV(1 + i)n

In English, this formula says 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. Let’s plug in the numbers:

FV = 2,000(1.05)3

FV = 2,000(1.157625)

FV = $2,315.25

The discounted cash flow technique compares the value of the future cash flows of the project to today’s dollars. In order to calculate discounted cash flows, you need to know the value of the investment in today’s terms, or the PV. PV is calculated as follows:

PV = FV / (1 + i)n

This is the reverse of the FV formula talked about earlier. So, if you ask the question, “What is $2,315.25 in three years from now worth today given a 5 percent interest rate?” you’d use the preceding formula. Let’s try it:

PV = $2,315.25 / (1 + .05)3

PV = $2,315.25 / 1.157625

PV = $2,000

$2,315.25 in three years from now is worth $2,000 today.

Discounted cash flow is calculated just like this for the projects you’re comparing for selection purposes or when considering alternative ways of doing the project. Apply the PV formula to the projects you’re considering, and then compare the discounted cash flows of all the projects against each other to make a selection. Here is an example comparison of two projects using this technique:

Project A is expected to make $100,000 in two years.

Project B is expected to make $120,000 in three years.

If the cost of capital is 12 percent, which project should you choose?

Using the PV formula used previously, calculate each project’s worth:

The PV of Project A = $79,719.

The PV of Project B = $85,414.

Project B is the project that will return the highest investment to the company and should be chosen over Project A.

Net Present Value

Projects might begin with a company investing some amount of money into the project to complete and accomplish its goals. In return, the company expects to receive revenues, or cash inflows, from the resulting project. Net present value (NPV) allows you to calculate an accurate value for the project in today’s dollars. The mathematical formula for NPV is complicated, and you do not need to memorize it in that form for the test. However, you do need to know how to calculate NPV for the exam, so I’ve given you some examples of a less complicated way to perform this calculation in Table 2-11 and Table 2-12 using the formulas you’ve already seen.

Table 2-11: Project A

Year	Inflows	PV
1	10,000	8,929
2	15,000	11,958
3	5,000	3,559
Total	30,000	24,446
Less investment	—	24,000
NPV	—	446

Table 2-12: Project B

Year	Inflows	PV
1	7,000	6,250
2	13,000	10,364
3	10,000	7,118
Total	30,000	23,732
Less investment	—	24,000
NPV	—	(268)

Net present value 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 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’s the rule: If the NPV calculation is greater than zero, accept the project. If the NPV calculation is less than zero, reject the project.

Look at the two project examples in Tables 2-11 and 2-12. Project A and Project B have total cash inflows that are the same at the end of the project, but the amount of inflows at each period differs for each project. We’ll stick with a 12 percent cost of capital. Note that the PV calculations were rounded to two decimal places.

Project A has an NPV greater than zero and should be accepted. Project B has an NPV less than zero and should be rejected. When you get a positive value for NPV, it means that the project will earn a return at least equal to or greater than the cost of capital.

Another note on NPV calculations: projects with high returns early in the project are better projects than projects with lower returns early in the project. In the preceding examples, Project A fits this criterion also.

Internal Rate of Return

The internal rate of return (IRR) is the most difficult equation to calculate of all the cash flow techniques we’ve discussed. It is a complicated formula and should be performed on a financial calculator or computer. IRR can be figured manually, but it’s a trial-and-error approach to get to the answer.

Technically speaking, 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 the project, projects with higher IRR values are generally considered better than projects with low IRR values.

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, two, or several of the benefit measurement methods alone or in combination 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.

Kicking Off the Project Charter

Your first stop in the Initiating group is a process called Develop the Project Charter. As the name of the process suggests, your purpose is to create a project charter. As I talked about in Chapter 1, the purpose for the Initiating group is to authorize a project, or the next phase of a project, to begin. It also gives the project manager the authority to apply resources to the project. These are also the purposes of a project charter: formally authorizing the project to begin and committing resources.

As you’ll discover, every process has inputs, tools and techniques, and outputs, and this one is no exception. You’ll start with the inputs. Let’s get to it.

Inputs to the project processes are typically informational in nature, or they are outputs from previously completed processes. Inputs are used in combination with the tools and techniques to produce the outputs of each process. Process outputs are usually tangible, such as a report or an update or a list, for example. To get to the output, you have to start with the inputs. Let’s take a look at the Develop Project Charter process inputs:

• Project statement of work
• Business case
• Contract
• Enterprise environmental factors
• Organizational process assets

The contract input is applicable only when the organization you are working for is performing a project for a customer external to the organization. The contract 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.

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 here 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 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 so 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 installing a new human resources 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 as well.

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 analysis are generally included in this section of the business case.)
• Description of the expected results of each alternative solution.
• Recommended solution.

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 include the following:

Organizational culture, structure, and processes 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.

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

Expert Judgment Tool and Technique

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.

Formalizing and Publishing the Project Charter

The project charter is the official, written acknowledgment and recognition that a project exists. It ties the work of the project with the ongoing operations of the organization. It’s usually signed by a senior manager or project sponsor, and it gives the project manager the authority to assign organizational resources to the project.

The charter documents the business need or demand that the project was initiated to address, and it includes a description of the product, service, or result of the project. It is usually the first official document of the project once acceptance of the project has been granted. Project charters are often used as a means to introduce a project to the organization. Because this document outlines the high-level project description, the business opportunity or need, and the project’s purpose, executive managers can get a “first-glance” look at the benefits of the project. Good project charters that are well documented will address many of the questions your stakeholders are likely to have up front.

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:

• 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

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 sets stakeholder expectations, 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 on 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 beginning the Planning process group.

According to the PMBOK® Guide, the project charter is signed by the project initiator. In practice, 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 next. I’ll explain how to identify the right stakeholders for your project in the next section, “Identifying Stakeholders.”

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 project charter identifies the project manager and describes the authority the project manager has in carrying out the project. The project manager’s primary responsibilities are project planning and then executing and managing the work of the project. By overseeing the project charter and the project planning documents created later in the project, the project manager is assured that everyone knows and understands what’s expected of them and what constitutes a successful project.

Project managers are responsible for setting the standards and policies for the projects on which they work. As a project manager, it is your job to establish and communicate the project procedures to the project team and stakeholders.

Project managers will identify activities and tasks, resource requirements, project costs, project requirements, performance measures, and more. Communication and documentation must become the project manager’s best friends. Keeping stakeholders, the project sponsor, the project team, and all other interested parties informed is “job one,” as the famous car manufacturer’s ads say.

Project Sponsor

Have you ever attended a conference or event that was put on by a sponsor? In the information technology field, software development companies often sponsor conferences and seminars. The sponsor pays for the event, the facilities, and the goodies and provides an opportunity for vendors to display their wares. In return, the sponsor comes out looking like a winner. Because it is footing the bill for all this fun, the sponsor gets to call the shots on conference content, and it gets the prime spots for discussing its particular solutions. Last but not least, it usually provides the keynote speaker and gets to present its information to a captive audience.

Project sponsors are similar to this in that they rally support from stakeholders and the executive management team for the project. 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, so to speak, and gets to call the shots regarding project outcomes. The project sponsor is also the one with the big bucks who provides funds for your project. The project sponsor should be named in the project charter and identified as the final authority and decision maker for project issues.

Sponsors are actively involved in the Initiating and Planning phases of the project and tend to have less involvement during the Execution and Monitoring and Controlling phases. It’s up to the project manager to keep the project sponsor informed of all project activities, project progress, and any conflicts or issues that arise. The sponsor is the one with the authority to resolve conflicts and set priorities when these things can’t be dealt with any other way.

Project Champion

The project champion is another strong project supporter. Unlike the sponsor, the project champion doesn’t necessarily have a lot of authority or executive powers. The champion helps focus attention on the project from a technical perspective. The project champion is usually someone with a great deal of technical expertise or industry knowledge regarding the project. They can lend credibility to the viability of the project and to the skills and abilities of the key project team members to carry out project activities. Sometimes, the project manager might act as project champion.

The project champion isn’t necessarily identified in the project charter. But as a project manager, you’ll want to know who this person is because the person is a strong project advocate, and because you might need them later to help rally support for project decisions.

Functional Managers

I covered functional managers briefly in Chapter 1. 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. It’s a good idea to identify the functional managers who will be working on project tasks or assigned project responsibilities in the charter.

It’s also a good idea to identify the key project stakeholders in the project charter. Although this isn’t explicitly stated as part of this process, you’ll see in the next section that stakeholder influences make up one of the components of the project charter. To identify stakeholder influences, it’s also necessary to identify the stakeholders and describe their roles in high-level terms as I’ve done here.

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

Identifying Stakeholders

Think of stakeholders and project participants as a highly polished orchestra. Each participant has a part to play. Some play more parts than others, and, alas, some don’t play their parts as well as others. An integral part of project management is getting to know your stakeholders and the parts they play. You’ll remember from Chapter 1 that stakeholders are those people or organizations who have a vested interest in the outcome of the project. They have something to either gain or lose as a result of the project, and they have the ability to influence project results.

Identifying Stakeholders Inputs

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 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, lessons learned, and 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 very 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 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, three steps are 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.

Table 2-13: 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.

Understanding Stakeholder Roles

The second step in identifying stakeholders is identifying the potential impact on or support for the project each may have and then classifying them according to impact so that you can devise a strategy to deal with those impacts should they arise.

In order to determine potential impact, it’s important for the project manager to understand each stakeholder’s role in the project and in the organization. Get to know them and their interests. Determine the relationship structure among the various stakeholders. Start cultivating partnerships with these stakeholders now, because it’s going to get pretty cozy during the course of your project. If you establish good working relationships up front and learn a little about their business concerns and needs, it might be easier to negotiate or motivate them later when you have a pressing issue that needs action. Knowing which stakeholders work well together and which don’t can also help you in the future. One stakeholder might have the authority or influence to twist the arm of another, figuratively speaking, of course. Conversely, you might know of two stakeholders who are like oil and water when put into the same room together. This can be valuable information to keep under your hat for future reference.

Some stakeholders may have a significant amount of influence over the project and its outcomes. Understanding the organizational structure, and where the stakeholders fit in that structure, should be your first step in determining the level of influence they have. For example, if Melanie in accounting wields a significant amount of power and influence over the organization, when you need input or decisions from her regarding costs or budgets for the project, you better believe that those decisions are not likely to be overridden. Conversely, if stakeholders with little influence provide direction that you don’t verify, that input could be overridden at a later date by a more powerful stakeholder, causing changes to the project.

You can essentially classify the power and influence of each stakeholder on a simple four-square grid. The PMBOK® Guide lists four classification models for this task:

• Power/Interest grid
• Power/Influence grid
• Influence/Impact grid
• Salience model

The first three grids are self-explanatory. The Salience model is more complicated than a four-square grid because it charts three factors: stakeholder power, urgency, and legitimacy. Urgency refers to a stakeholder’s level of need for attention as immediate, occasional, or rarely. Legitimacy concerns the appropriateness of the stakeholder’s participation at given times during the project.

Assessing Stakeholders

The third step in stakeholder analysis is assessing the influence and potential negative impacts key stakeholders may have on the project. As I said earlier, some stakeholders may have a significant amount of influence over the project and its outcomes. As with assessing a stakeholder’s role, your first step in determining the level of influence they have should be to understand the organizational structure and where they fit in. Once the stakeholder assessment is complete, you should devise a plan to deal with any potential impacts such as the case mentioned earlier where a stakeholder with little influence makes a decision that could later be overturned.

Stakeholder Register and Strategy

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:

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 importantly, whether they support the project, are resistant to the project, or have no opinion.

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:

• Name of key stakeholders who could have a significant impact on the project
• Stakeholders’ anticipated level of participation
• Stakeholder groups
• Assessment of impact
• Potential strategies for gaining support

Introducing the Kitchen Heaven Project Case Study

This chapter introduces a case study that we’ll follow throughout the remainder of the book. The case study is updated at the end of every chapter. It’s designed to show you how a project manager might apply the material covered in the chapter to a real-life project. As happens in real life, not every detail of every process is followed during all projects. Remember that the processes from the PMBOK® Guide that I’ll cover in the remaining chapters are project management guidelines. You will often combine processes during your projects, which will allow you to perform several steps at once. The case studies will present situations or processes that you might find during your projects and describe how one project manager resolves them.

You have a question or two for Dirk.

“Is there a special reason we have to open, let’s see, six months from now, which is February 1?”

He responds, “Yes, we want the store open the first week in February. Early February is when the Garden and Home Show conference hits the Springs area. We’ll have a trade show booth there. We know from experience in other areas that our stores generally see a surge in sales during this month as a result of the trade show. It’s a great way to get a lot of advertising out there and let folks know where we’re located.”

“Another question, Dirk. Is there a budget set for this project yet?”

“We haven’t set a hard figure,” Dirk replies. “But again, from past experience we know it takes anywhere from $1.5 to $2 million to open a new store—and we don’t want to forget the big bash for the grand opening.”

“Thanks, Dirk. I’ll get started writing the project charter right away. I’ll put your name on the document because you’re the project sponsor.”

Dirk concludes with, “Feel free to come to me with questions or concerns at any time.”

One week later.

You review your notes and reread the project charter you’ve prepared for the Kitchen Heaven retail store one last time before looking for Dirk. You finally run across Dirk in a hallway near the executive washroom.

“Dirk, I’m glad I caught you. I’d like to go over the project charter with you before the kickoff meeting tomorrow. Do you have a few minutes?”

“Sure,” Dirk says to you. “Let’s have it.”

“The project charter states the purpose of the project, which of course is to open the 50th Kitchen Heaven store in Colorado Springs. I also documented some of the high-level requirements, many of which we talked about last time we met. I documented the assumptions and constraints you gave me with the understanding that we’ll define these much more closely when I create the scope statement. I’ve included a section that outlines a preliminary milestone schedule, and I’ve included some preliminary return on investment calculations. Using your estimate of $2 million as our initial budget request and based on the projected inflows you gave me last week, I’ve calculated a payback period of 19 months, with an internal rate of return (IRR) of 6 percent.”

“That’s impressive,” replies Dirk. “That’s even better than our Phoenix store. If I recall, the payback period there was just over two years. Let’s hope those numbers hold true.”

“I think they’re reliable figures,” you say. “I researched our data based on recent store openings in similar-sized cities and factored in the economic conditions of the Colorado Springs area. Since they’re on a growth pattern, we think the timing is perfect.

“As you know, the project kickoff is scheduled for tomorrow. What I’ll need, then, is for you to talk about the project and the goals, talk about the commitment you’ll need from the management team to support this project, and introduce me as the project manager. I’ve already forwarded a copy of the project charter to the meeting attendees so that they can review it before the meeting. I included a list of the assumptions we’ve made so far as an appendix to the charter. Lastly, I’ll need you to ask everyone present to sign a copy of the project charter.”

“Sounds like you’ve covered everything,” Dirk says. “I don’t anticipate any problems tomorrow, because everyone is looking forward to this store opening.”

Project Case Study Checklist

• Project objective: To open a new store in Colorado Springs six months from today.
• Business need or demand for project: Company data concludes that the Kitchen Heaven consumers have incomes of more than $150,000 a year. The Colorado Springs area is home to a large number of people with that income. Currently, there is not a Kitchen Heaven there, but there appears to be a demand for one.
• Project sponsor: Dirk Perrier, VP of marketing.
• Organizational structure: Functional organization with a separate projectized department.
• Project selection methods: Payback period calculated at 19 months and IRR calculated at 6 percent.

• Created project charter: Project charter contains the following:
• High-level overview of project
• List of measurable project objectives
• High-level risks
• Summary milestone schedule with initial completion date of February 1
• Summary budget of $2 million
• Project manager authority levels
• Definition of roles of project sponsor and project manager

Next steps: Kickoff meeting set up to discuss charter and obtain sign-off.

Understanding How This Applies to Your Next Project

There are as many ways to select and prioritize projects as there are organizations. You might be profit driven, so money will be king. You might have a stakeholder committee that weighs the pros and cons, or you might have an executive director who determines which project is up next. Scoring models and cash flow analysis techniques are useful on the job. Whether your organization uses these methods or others, an organized, consistent way to select and prioritize projects is necessary. I know I could work the next 100 years straight and probably still not get all the projects completed my organization would like to see implemented. What I’ve found is that the selection method must be fair and reasonable. If your organization uses an arbitrary method—say you like Tara better than Joe, so Tara’s projects always end up on the “yes” list—it won’t be long before stakeholders demand that another method be devised to select projects that everyone can understand. Whatever method you’re using, stick to it consistently.

If you’re like me, when I’m faced with a new project, I want to get right to the heart of the matter and understand the purpose of the project. Projects come about for many reasons. Most of the time, understanding the reason it came about will give you some insight into its purpose. For example, if a new law is passed that requires anyone applying for a driver’s license to show two forms of identification but the existing system has the space to record verification of only one document, you immediately have a firm grasp on the purpose of the project—you’ll have to update the system to include additional space for recording the second document.

It has been my experience in working with project teams that when the team understands the reason or the need that brought about the project and it understands the goal of the project, the project is more successful. Now I don’t have any scientific evidence for this, but when the teams have a clear understanding of what they’re working on and why, they tend to stay more focused and fewer unplanned changes make their way into the project. Don’t assume everyone on the project team understands the goal of the project. It’s good practice to review the project goal early in the project and again once the work of the project is underway. Reminding the team of the goal helps keep the work on track.

I usually write a project charter for all but the smallest of projects. I believe the most important sections of the charter are the objectives of the project, the summary milestone schedule, and the summary budget. If the project is so small that a charter seems like too much, I’ll write a statement of work. It’s important that the goal or objective of the project is written down, no matter how small the project is, so that the team and the stakeholders know what they’re working toward.

Identifying the stakeholders early in the project is imperative to project success. You won’t really want to write the charter without their involvement. The two processes described in this chapter are almost performed simultaneously when you’re conducting a project. I won’t begin writing the charter without stakeholder input first, and it’s just as important to understand the role stakeholders will play in the project as well as their influence. If the CFO has ultimate influence over which projects proceed and what they’ll include, you’ll want the CFO’s buy-in as soon as possible. Involvement in writing the charter and developing the future Planning process outputs helps to assure their buy-in. At a minimum, it helps reduce surprises midway through the project.

Always, and I mean always, get approval and signatures on the project charter. You will use this document as your basis for project planning, so you want to make certain the sponsor, key stakeholders, and the project manager understand the goals of the project the same way.

Summary

This chapter started with a discussion of the nine Knowledge Areas. The Knowledge Areas bring together processes that have characteristics in common. They also help you understand what types of skills and resources are needed to complete the processes within them.

Next, I detailed how projects are initiated. Projects come about as a result of one of seven needs or demands: market demands, organizational needs, customer requests, technological advances, legal requirements, ecological impacts, or social needs.

Project selection methods include decision models in the form of benefit measurement methods and mathematical models (also called constrained optimization methods). The mathematical methods utilize mathematical models. Benefit measurement methods come in the form of cost-benefit analyses, scoring models, and economic analyses. These are primarily comparative approaches. Besides cost-benefit analysis, the most commonly used form of benefit measurement methods is cash flow analysis.

Analysis of cash flows includes payback period, discounted cash flows, net present value (NPV), and internal rate of return (IRR). These last three methods are concerned with the time value of money—or, in other words, converting future dollars into today’s value. Generally, projects with a shorter payback period are desired over those with longer payback periods. Projects that have an NPV greater than zero should be accepted. Projects with the highest IRR value are considered a better benefit to the organization than projects with lower IRR values.

The Develop the Project Charter process is the first process within the Initiating process group. The project statement of work is an input to this process that describes the product, service, or result the project was undertaken to complete. The SOW should include the business needs of the organization and a product scope description and should map to the organization’s strategic plan.

Enterprise environmental factors are factors outside the project that might have significant influence on the success of the project. Organizational process assets refer to policies, guidelines, and procedures for conducting the project work.

Expert judgment is the only tool and technique of this process. Experts usually have specialized knowledge or skills and can include staff from other departments in the company, external or internal consultants, and members of professional and technical associations or industry groups.

The output of this process is the project charter, which is the formal recognition that a project, or the next project phase, should begin. The charter 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 Identify Stakeholders process concerns identifying, assessing, and classifying stakeholders in a stakeholder register and developing a stakeholder management strategy. Stakeholder involvement is critical to the success of the project. The more the project manager understands stakeholder influences, expectations, and impacts, the easier it is to prepare a strategy plan to deal with the impacts or issues, sometimes before they occur.

Exam Essentials

Be able to name the nine Project Management Knowledge Areas. The nine Project Management Knowledge Areas are Project Integration Management, Project Scope Management, Project Time Management, Project Cost Management, Project Quality Management, Project Human Resource Management, Project Communications Management, Project Risk Management, and Project Procurement Management.

Be able to distinguish between the seven needs or demands that bring about project creation. The seven needs or demands that bring about project creation are market demand, organizational need, customer requests, technological advances, legal requirements, ecological impacts, and social needs.

Be able to define decision models. Decision models are project selection methods that are used prior to the Develop Project Charter process to determine the viability of the project. Decision models include benefit measurement methods and mathematical models.

Be able to describe and calculate the payback period. The payback period is the amount of time it will take the company to recoup its initial investment in the product of the project. It’s calculated by adding up the expected cash inflows and comparing them to the initial investment to determine how many periods it takes for the cash inflows to equal the initial investment.

Be able to denote the decision criteria for NPV and IRR. Projects with an NPV greater than zero should be accepted, and those with an NPV less than zero should be rejected. Projects with high IRR values should be accepted over projects with lower IRR values. IRR is the discount rate when NPV is equal to zero, and IRR assumes reinvestment at the IRR rate.

Be able to denote the Develop Project Charter inputs. The inputs for Develop Project Charter are project statement of work, business case, contract, enterprise environmental factors, and organizational process assets.

Be able to describe the purpose for the 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.

Be able to describe the importance of the project charter. The project charter is the document that officially recognizes and acknowledges that a project exists. The charter 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.

Understand the Identify Stakeholders process. The purpose of this process is to identify the project stakeholders, assess their influence and level of involvement, devise a plan to deal with potential negative impacts, and record stakeholder information in the stakeholder register.

Key Terms

You’ve learned just how important a charter is to every project. Be sure you understand the elements essential to the document and the processes used to ensure that your charter is complete. Skimping on the planning steps is almost certain to spell disaster down the road. Know these processes, and know them by the names used in the PMBOK® Guide:

Develop Project Charter

Identify Stakeholders

You’ve also learned a lot of new key words in this chapter. PMI has worked hard to develop and define standard project management terms that apply across industries. Here is a list of some of the terms you came across in this chapter:

benefit measurement methods	internal rate of return (irr)
calculation methods	mathematical models
constrained optimization methods	net present value (NPV)
cost-benefit	payback period
decision models	project charter
discounted cash flow	project statement of work (SOW)
expert judgment	scoring model
historical information	steering committee
Initiating	weighted scoring model

Review Questions

1. When a project is being performed under contract, the SOW is provided by which of the following?

A. The buyer

B. The project sponsor

C. The project manager

D. The contractor

2. You’ve been hired as a manager for the adjustments department of a nationwide bank based in your city. The adjustments department is responsible for making corrections to customer accounts. This is a large department, with several smaller sections that deal with specific accounts, such as personal checking or commercial checking. You’ve received your first set of management reports and can’t make heads or tails of the information. Each section appears to use a different methodology to audit their work and record the data for the management report. You request that a project manager from the PMO comes down and gets started right away on a project to streamline this process and make the data and reports consistent. This project came about as a result of which of the following?

A. Technological advance

B. Organizational need

C. Customer request

D. Legal requirement

3. What are the inputs to the Develop Project Charter process?

A. Contract, project SOW, business case, enterprise environmental factors, and organizational process assets

B. Project SOW, business case, and organizational process assets

C. Contract, enterprise environmental factors, and organizational process assets

D. Project SOW, enterprise environmental factors, and organizational process assets

4. You work for a large manufacturing plant. Your firm is thinking of initiating a new project to release an overseas product line. This is the company’s first experience in the overseas market, and it wants to make a big splash with the introduction of this product. The project entails producing your product in a concentrated formula and packaging it in smaller containers than the U.S. product uses. A new machine is needed in order to mix the first set of ingredients in the concentrated formula. Which of the following actions is the next best step the project manager should take?

A. The project manager should document the project’s high-level requirements in a project charter document and recommend that the project proceed.

B. The project manager knows the project is a go and should document the description of the product in the statement of work.

C. The project manager should document the business need for the project and recommend that a feasibility study be performed to determine the viability of the project.

D. The project manager should document the needs and demands that are driving the project in a business case document.

5. You are the project manager for Fun Days Vacation Resorts. Your new project assignment is to head up the Fun Days resort opening in Austin, Texas. You are estimating the duration of the project plan activities, devising the project schedule, and monitoring and controlling deviations from the schedule. Which of the Project Management Knowledge Areas are you working in?

A. Project Scope Management

B. Project Quality Management

C. Project Integration Management

D. Project Time Management

6. According to the PMBOK® Guide, the project statement of work should contain or reference which of the following elements?

A. Strategic plan, product scope description, measurable project objectives, and business need

B. Business need, strategic plan, product scope description

C. Project purpose, measurable project objectives, business case, and product scope description

D. Product scope description, project purpose, and business need

7. Your nonprofit organization is preparing to host its first annual 5K run/walk in City Park. You worked on a similar project for the organization two years ago when it cohosted the 10K run through Overland Pass. Which of the organizational process assets might be most helpful to you on your new project?

A. The organization’s marketing plans

B. Historical information from a previous 10K run or similar project

C. The marketplace and political conditions

D. The organization’s project management information systems

8. Which of the following lists of processes belong to The Project Integration Management Knowledge Area?

A. Define Scope, Close Procurements, and Perform Integrated Change Control

B. Develop Project Management Plan, Direct and Manage Project Execution, and Perform Integrated Change Control

C. Define Scope, Direct and Manage Project Execution, and Manage Stakeholders Expectations

D. Define Scope, Collect Requirements, and Close Project or Phase

9. Comparative methods, scoring methods, and economic and cash flow analysis are all part of which of the following?

A. Benefit measurement methods

B. Constrained optimization methods

C. Benefit measurement methods, which are a component of a tool and technique of the Develop Project Charter process

D. Constrained optimization methods, which are a component of a tool and technique of the Develop Project Charter process

10. You are the project manager for the Late Night Smooth Jazz Club chain, with stores in 12 states. Smooth Jazz is considering opening a new club in Arizona or Nevada. You have derived the following information:

Project Arizona: The payback period is 18 months, and the NPV is (250).

Project Nevada: The payback period is 24 months, and the NPV is 300.

Which project would you recommend to the selection committee?

A. Project Arizona, because the payback period is shorter than the payback period for Project Nevada

B. Project Nevada, because its NPV is a positive number

C. Project Arizona, because its NPV is a negative number

D. Project Nevada, because its NPV is a higher number than Project Arizona’s NPV

11. You are the project manager for the Late Night Smooth Jazz Club chain, with stores in 12 states. Smooth Jazz is considering opening a new club in Kansas City or Spokane. You have derived the following information:

Project Kansas City: The payback period is 27 months, and the IRR is 6 percent.

Project Spokane: The payback period is 25 months, and the IRR is 5 percent.

Which project should you recommend to the selection committee?

A. Project Spokane, because the payback period is the shortest

B. Project Kansas City, because the IRR is the highest

C. Project Spokane, because the IRR is the lowest

D. Project Kansas City, because the payback period is the longest

12. Which of the following is true regarding NPV?

A. NPV assumes reinvestment at the cost of capital.

B. NPV decisions should be made based on the lowest value for all the selections.

C. NPV assumes reinvestment at the prevailing rate.

D. NPV assumes reinvestment at the NPV rate.

13. You are the project manager for Insomniacs International. Since you don’t sleep much, you get a lot of project work done. You’re considering recommending a project that costs $575,000; expected inflows are $25,000 per quarter for the first two years and then $75,000 per quarter thereafter. What is the payback period?

A. 40 months

B. 38 months

C. 39 months

D. 41 months

14. Which of the following is true regarding IRR?

A. IRR assumes reinvestment at the cost of capital.

B. IRR is not difficult to calculate.

C. IRR is a constrained optimization method.

D. IRR is the discount rate when NPV is equal to zero.

15. Which of the following best describes the purpose of a business case?

A. To determine project viability and probability of success

B. To understand the need or demand that brought about the project

C. To understand the business need for the project and determine whether the investment in the project is worthwhile

D. To perform analysis using mathematical models and benefit measurement methods that will assist in project selection

16. All of the following people are responsible for selecting the projects the organization should undertake except for which one?

A. Project manager

B. Project sponsor

C. Customers

D. Subject matter experts

17. Your selection committee is debating between two projects. Project A has a payback period of 18 months. Project B has a cost of $125,000, with expected cash inflows of $50,000 the first year and $25,000 per quarter after that. Which project should you recommend?

A. Either Project A or Project B, because the payback periods are equal

B. Project A, because Project B’s payback period is 21 months

C. Project A, because Project B’s payback period is 24 months

D. Project A, because Project B’s payback period is 20 months

18. Which of the following is true?

A. Discounted cash flow analysis is the least precise of the cash flow techniques because it does not consider the time value of money.

B. NPV is the least precise of the cash flow analysis techniques because it assumes reinvestment at the discount rate.

C. Payback period is the least precise of the cash flow analysis techniques because it does not consider the time value of money.

D. IRR is the least precise of the cash flow analysis techniques because it assumes reinvestment at the cost of capital.

19. You are a project manager for Zippy Tees. Your selection committee has just chosen a project you recommended for implementation. Your project is to manufacture a line of miniature stuffed bears that will be attached to your company’s trendy T-shirts. The bears will be wearing the same T-shirt design as the shirt to which they’re attached. Your project sponsor thinks you’ve really impressed the big boss and wants you to skip to the manufacturing process right away. What is your response?

A. Agree with the project sponsor because that person is your boss and has a lot of authority and power in the company.

B. Require that a preliminary budget be established and a resource list be put together to alert other managers of the requirements of this project. This should be published and signed by the other managers who are impacted by this project.

C. Require that a project charter be written and signed off on by all stakeholders before proceeding.

D. Suggest that a preliminary statement of work be written to outline the objectives of the project.

20. Which of the following is true regarding the project charter?

A. The project charter should be published under the name of a manager external to the project.

B. The project charter should be published under a key stakeholder’s name.

C. The project charter should be published under the name of the project manager.

D. The project charter should be published under the name of the project champion.

Answers to Review Questions

1. A. The buyer provides the SOW when projects are performed under contract.

2. B. This came about because of an organizational need. Staff members were spending unproductive hours producing information for the management report that wasn’t consistent or meaningful.

3. A. Develop Project Charter has five inputs, and they are project SOW, business case, contract, enterprise environmental factors, and organizational process assets.

4. C. The most correct answer is to perform a feasibility study. Because this project is taking the company into a new, unknown market, there’s lots of potential for error and failure. A feasibility study would help the stakeholders determine whether the project is viable and cost effective and whether it has a high potential for success.

5. D. Project Time Management involves the following processes: Define Activities, Sequence Activities, Estimate Activity Resources, Estimate Activity Durations, Develop Schedule, and Control Schedule.

6. B. The project SOW should contain the business need for the project and the product scope description and should support the organization’s strategic plan.

7. B. Historical information on projects of a similar nature can be helpful when initiating new projects. They can help in formulating project deliverables and identifying constraints and assumptions and will be helpful later in the project Planning processes as well.

8. B. The Project Integration Management Knowledge Area consists of the following processes: Develop Project Charter, Develop Project Management Plan, Direct and Manage Project Execution, Monitor and Control Project Work, Perform Integrated Change Control, and Close Project or Phase.

9. A. Benefit measurement methods include comparative methods, scoring models, and cash flow analysis. They are used as project selection tools to determine which project to proceed with or to determine which project among a list of projects should be undertaken.

10. B. Projects with NPV greater than zero should be given an accept recommendation.

11. B. Projects with the highest IRR value are favored over projects with lower IRR values.

12. A. Net present value (NPV) assumes reinvestment is made at the cost of capital.

13. C. Year 1 and 2 inflows are each $100,000 for a total of $200,000. Year 3 inflows are an additional $300,000. Add one more quarter to this total, and the $575,000 is reached in three years and three months, or 39 months.

14. D. IRR assumes reinvestment at the IRR rate and is the discount rate when NPV is equal to zero.

15. C. The purpose of the business case is to understand the business need for the project and determine whether the investment in the project is worthwhile. This may include analysis using mathematical models and/or benefit measurement methods but that is not the primary purpose of the business case.

16. A. It is outside the project manager’s scope of responsibilities to select projects. Project selection is performed by the sponsor, customers, and/or subject matter experts.

17. B. Project B has a payback period of 21 months; $50,000 is received in the first 12 months, with another $75,000 coming in over each of the next three quarters, or nine months.

18. C. Payback period does not consider the time value of money and is, therefore, the least precise of all the cash flow analysis techniques.

19. C. The project should be kicked off with a project charter that authorizes the project to begin, assigns the project manager, and describes the project objectives and purpose for the project. This ensures that everyone is working with the same purposes in mind.

20. A. According to the PMBOK® Guide, the project charter should be published by a manager external to the project (usually the project sponsor) but with sufficient power and authority to carry it off.