discussion

PMP_Project_Management_Professional_Exam_Study_Gui..._----_Pg_103--208.pdf

Home >Psychology homework help >discussion

Chapter

2 Creating the Project Charter

The PMP® exaM ConTenT froM The InITIaTIng PerforManCe doMaIn Covered In ThIs ChaPTer InCludes The followIng:

✓ Task 1: Perform project assessment based on available information, lessons learned from previous projects, and meetings with the relevant stakeholders in order to support the evaluation of the feasibility of new products or services within the given assumptions and/or constraints.

✓ Task 2: Identify key deliverables based on the business requirements in order to manage customer expectations and direct the achievement of project goals.

✓ Task 3: Perform stakeholder analysis using appropriate tools and techniques in order to align expectations and gain support for the project.

✓ Task 4: Identify high-level risks, assumptions, and constraints based on the current environment, organizational factors, historical data, and expert judgment, in order to propose an implementation strategy.

✓ Task 5: Participate in the development of the project charter by compiling and analyzing gathered information in order to ensure project stakeholders are in agreement on its elements.

✓ Task 6: Obtain project charter approval from the sponsor, in order to formalize the authority assigned to the project manager and gain commitment and acceptance for the project.

Heldman, Kim. PMP: Project Management Professional Exam Study Guide : Updated for the 2015 Exam, John Wiley & Sons, Incorporated, 2015. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/gcu/detail.action?docID=4185201. Created from gcu on 2025-04-16 13:08:48.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

✓ Task 7: Conduct benefit analysis with relevant stakeholders to validate project alignment with organizational strategy and expected business value.

✓ Task 8: Inform stakeholders of the approved project charter to ensure common understanding of the key deliverables, milestones, and their roles and responsibilities.

✓ Knowledge and Skills:

■ Analytical skills

■ Benefit analysis techniques

■ Elements of a project charter

■ Estimation tools and techniques

■ Strategic management

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Now that you’re armed with a detailed overview of project management, you can easily determine whether your next assignment 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: the 10 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. A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Fifth Edition, groups these processes into 10 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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

48 Chapter 2 ■ Creating the Project Charter

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

■ Project Stakeholder 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.

exam spotlight

The PMP® exam may have a question or two regarding the processes that make up a Knowledge Area. Remember that Knowledge Areas bring together processes by commonalities, so thinking about the Knowledge Area itself should tip you off to the processes that belong to it. Projects are executed in process group order, but the Knowledge Areas allow a project manager to think about groups of pro- cesses that require specific skills. This makes the job of assigning resources easier because team members with specific skills might be able to work on and complete several processes at once. To broaden your understanding of the Knowledge Areas, cross‐reference the purposes and the processes that make up each Knowledge Area with the PMBOK® Guide.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Exploring the Project Management Knowledge Areas 49

The process names, inputs, tools and techniques, outputs, and descriptions of the project management process groups and related materials and figures in this chapter are based on content from A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Fifth Edition (PMI, 2013).

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

Ta b le 2 .1 Project Integration Management

Process Name Project Management Process Group

Develop Project Charter Initiating

Develop Project Management Plan Planning

Direct and Manage Project Work 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 management plan and is highly interactive. This Knowledge Area involves identifying and defining the work of the project and combining, unifying, and integrating the appropriate processes. It is concerned with choosing from among alternative projects and performing trade‐offs among the competing objectives of several projects. This Knowledge Area also takes into account satisfactorily meeting the requirements of the customer and stakeholder and managing their expectations.

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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

50 Chapter 2 ■ Creating the Project Charter

Identify Stakeholders process uses an output from the Develop Project Charter process as an input.

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

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

Ta b le 2 . 2 Project Scope Management

Process Name Project Management Process Group

Plan Scope Management Planning

Collect Requirements Planning

Define Scope Planning

Create WBS Planning

Validate 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 scope baseline is made up of the project scope statement, the work breakdown structure (WBS), and the WBS dictionary.

To ensure a successful project, both product and project scope must be well integrated. This implies that Project Scope Management is well integrated with the other Knowledge Area processes.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Exploring the Project Management Knowledge Areas 51

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

■ Defining and detailing the deliverables and requirements of the product of the project

■ Creating a WBS

■ Validating deliverables using measurement techniques

■ Controlling changes to the scope of the project

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

Ta b le 2 . 3 Project Time Management

Process Name Project Management Process Group

Plan Schedule Management Planning

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 activities, devising a project schedule, and monitoring and controlling deviations from the schedule. Collectively, this Knowledge Area deals with completing the project in a timely manner. Time management is an important aspect of project management because it concerns keeping the project activities on track and monitoring those activities against the project management plan to ensure that the project is completed on time.

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

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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

52 Chapter 2 ■ Creating the Project Charter

Ta b le 2 . 4 Project Cost Management

Process Name Project Management Process Group

Plan Cost Management Planning

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. The earlier you can develop and agree on the scope of the project, the earlier you can estimate costs. The benefit of this practice is that costs are more easily influenced early in the project.

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

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

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

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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Exploring the Project Management Knowledge Areas 53

Ta b le 2 .5 Project Quality Management

Process Name Project Management Process Group

Plan Quality Management Planning

Perform Quality Assurance Executing

Control Quality 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 processes used during the project. These processes measure overall performance and monitor project results and compare them to the quality standards set out in the project‐planning process to ensure that the customers will receive the product, service, or result they commissioned.

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

Ta b le 2 .6 Project Human Resource Management

Process Name Project Management Process Group

Plan Human Resource Management 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 built based on the skills and resources needed to complete the activities of the project, and many times project team members might not know one another. The earlier you can involve team members on the project, the better because you’ll want the benefit of their knowledge and expertise during the planning processes. Their participation early on will also help assure their buy‐in to the project. Because the makeup of each team is different and the stakeholders involved in the various stages of the project might change, you’ll use different techniques at different times throughout the project to manage the processes in this Knowledge Area.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

54 Chapter 2 ■ Creating the Project Charter

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

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

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

Ta b le 2 .7 Project Communications Management

Process Name Project Management Process Group

Plan Communications Management Planning

Manage Communications Executing

Control Communications Monitoring and Controlling

Time to Communicate

Project Communications Management is probably the most important Knowledge Area on any project, and most project managers understand the importance of good communication skills and making sure stakeholders are informed of project status. I know a project manager who had difficulties getting time with the project sponsor. The project sponsor agreed to meet with the project manager, even set up the meetings himself, and then canceled them or simply didn’t show up. The poor project manager was at her wits’ end about how to communicate with the sponsor and get some answers to the questions she had. Her desk was not far outside the project sponsor’s office. One day as she peeked around the corner of her cube, she decided if the sponsor wouldn’t come to her, she would go to him. From then on, every time the sponsor left his office, she would jump up from her chair and ride with him on the elevator. He was a captive audience. She was able to get some easy questions answered and finally convince him, after the fourth or fifth elevator ride, that they needed regular face‐to‐face meetings. She understood the importance of communication and went to great lengths to make certain the sponsor did too.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Exploring the Project Management Knowledge Areas 55

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

Ta b le 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

Control Risk Monitoring and Controlling

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

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

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

Ta b le 2 . 9 Project Procurement Management

Process Name Project Management Process Group

Plan Procurement Management Planning

Conduct Procurements Executing

Control Procurements Monitoring and Controlling

Close Procurements Closing

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

56 Chapter 2 ■ Creating the Project Charter

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

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

Ta b le 2 .10 Project Stakeholder Management

Process name Project management process group

Identify Stakeholders Initiating

Plan Stakeholder Management Planning

Manage Stakeholder Engagement Executing

Control Stakeholder Engagement Monitoring and Controlling

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

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

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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Understanding How Projects Come About 57

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 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, gaining efficiencies, or serving their customers. Sometimes laws are passed to force organizations to make their products safer or to make them less harmful to the environment. Projects might result from any of these needs as well as from business requirements, opportunities, or problems. According to the PMBOK® Guide, most projects will fit one of the seven needs and demands described next. The needs and demands are documented in the business case, which is an input to the Develop Project Charter process. Let’s take a closer look at each of these areas:

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

Strategic Opportunity/Business Need The new phone system talked about earlier that was announced at the quarterly meeting came about as a result of a business need. The CEO, on advice from his staff, was advised that call volumes were maxed on the existing system.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

58 Chapter 2 ■ Creating the Project Charter

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 util- ity company to automate its process or upgrade its existing process. The utility company’s request to purchase your equipment and consulting services is the project driver.

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

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

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

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

exam spotlight

Understand the needs and demands that bring about a project. All of these needs and demands represent opportunities, business requirements, or problems that need to be solved. Each may also introduce risk to the project. Management must decide how to respond to these needs and demands, which will more often than not initiate new projects.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Understanding How Projects Come About 59

Project Initiation

Corey is an information technology manager who works for the National Park Service. One warm spring Sunday morning he is perusing the local newspaper online and comes across an article about new services being offered at some of the national parks. He perks up when he sees his boss’s name describing the changing nature of technology and how it impacts the types of services the public would like to see at the parks. Corey knows that the public has been asking when wireless Internet services will be available in some of the larger parks and has also been involved in the discussions about the resources needed to make this happen, but the project never has enough steam to get off the ground. It seems that a higher‐priority project always takes precedence. However, all that changes when Corey sees the next sentence in the article: his boss promising wireless access in two of the largest parks in their region by July 4th. It looks like the customer requests have finally won out, and Corey has just learned he has a new project on his hands.

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

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

Feasibility studies might be conducted as separate projects, as subprojects, or as the first phase of a project. Sometimes, you’ll have a basic feel for the way the study may turn out and you could consider making the feasibility study the first phase of the project. When you don’t have any preconceived ideas about the outcome of the study, it’s best to treat it as a separate project. The group of people conducting the feasibility study should not be the same people who will work on the project. Project team members might have built‐in biases toward the project and will tend to influence the feasibility outcome toward those biases.

It’s always a good idea to meet with the sponsor, customer, and other subject matter experts when evaluating the feasibility of new products or services.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

60 Chapter 2 ■ Creating the Project Charter

The Interactive voice response (Ivr) Tax‐filing system

Jason, Sam, and Kate are web programmers working for the Department of Revenue in the State of Bliss. Ron, their manager, approaches them one day with an idea.

“Team, business unit managers think it would be a great idea to offer taxpayers the ability to file their income tax returns over the telephone. We already offer them the ability to file on the Internet, thanks to all your efforts on that project last year. It has been a fabulous success. No other state has had the success that Bliss has had with our Internet system.”

“Kate, I know you’ve had previous experience with IVR technology, but I’m not sure about you guys, so this is new territory for us. I’d like to hear what each of you thinks about this project.”

Jason speaks up first. “I think it’s a great idea. You know me; I’m always up for learning new things, especially when it comes to programming. When can we start?”

Sam echoes Jason’s comments.

“This technology is pretty sophisticated,” Kate says. “Jason and Sam are excellent coders and could work on the programming side of things, but I would have to pick up the telephony piece on my own. After we’re up and running, we could go over the telephony portions step‐by‐step, so Jason and Sam could help me support it going forward. I’d really like to take on this project. It would be good for the team and good for the department.”

Ron thinks for a minute. “Let’s not jump right into this. I know you’re anxious to get started, but I think a feasibility study is in order. The senior director of the tax business unit doesn’t know whether this project is cost justified and has some concerns about its life span. A feasibility study will tell us the answers to those questions. It should also help us determine whether we’re using the right technology to accomplish our goals, and it will outline alternative ways of performing the project that we haven’t considered. I don’t want Kate going it alone without first examining all the issues and potential impacts to the organization.”

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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Understanding How Projects Come About 61

How projects are assessed will vary depending on the company, the people serving on the selection committee, the criteria used, and the project. Assessments are usually performed first by examining the information presented about the project and developing an understanding of the key deliverables required for success. Reviewing past projects of similar size and scope, including reviewing the lessons learned while performing those projects, will help in determining whether the project is achievable given the known assumptions and constraints. Sometimes the criteria for selection methods will be purely financial, sometimes purely marketing, and sometimes they’ll be based on public perception or political perception. In most cases, the decision is based on a combination of all these and more.

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

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

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

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

exam spotlight

According to PMI®, project selection is outside the scope of the project manager’s role. In reality, the project manager often participates in the decision and assists with analysis and selection methods. For the exam, remember that project selection is performed by the project sponsor, customer, or subject matter experts.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

62 Chapter 2 ■ Creating the Project Charter

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

Selection methods are one way the stakeholders may choose between projects. The individual opinions, and power, of selection committee members also play a part in the projects the organization chooses to perform. Don’t underestimate the importance of the authority, political standing, and individual aspirations of selection committee members. Those committee members who happen to carry a lot of weight in company circles, so to speak, are likely to get their projects approved just because they are who they are. This is sometimes how project selection works in my organization. How about yours?

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

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

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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Understanding How Projects Come About 63

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.

exam spotlight

Project selection methods are also used to evaluate and choose between alternative ways of performing the project.

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.

exam spotlight

Benefit analysis is used to ensure that the project undergoing evaluation aligns with the organization’s strategic goals and returns the business value the stakeholders are expecting.

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, whereas others are comfortable with a much larger margin between the two figures.

Cost‐benefit analysis is also known as benefit/cost analysis. The techniques are the same. Benefit/cost has a more positive connotation because it shows the benefit, or the good stuff, before the cost, which is the not‐so‐good stuff.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

64 Chapter 2 ■ Creating the Project Charter

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.

Projects of significant cost or complexity usually involve more than one benefit measurement method when go or no‐go decisions are being made or one project is being chosen over another. Keep in mind that selection methods can take subjective considerations into account as well—the project is a go because it’s the new CEO’s pet project; nothing else needs to be said.

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 out- sourced 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.11 shows an example that brings this together.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Understanding How Projects Come About 65

Ta b le 2 .11 Weighted scoring model

Criteria Weight Project A Score*

Project A Totals

Project B Score*

Project B Totals

Project C Score*

Project C Totals

Profit potential 5 5 25 5 25 3 15

Marketability 3 4 12 3 9 4 12

Ease to produce/sup- port

1 4 4 3 3 2 2

Weighted score — — 41 — 37 — 29

*5 = highest

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.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

66 Chapter 2 ■ Creating the Project Charter

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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Understanding How Projects Come About 67

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.12 and Table 2.13 using the formulas you’ve already seen.

Ta b le 2 .12 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

Ta b le 2 .13 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 initial investment is then deducted from the sum of the present value of the cash flows to determine NPV. NPV assumes that cash inflows are reinvested at the cost of capital.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

68 Chapter 2 ■ Creating the Project Charter

Here’s the rule: If the NPV calculation is greater than 0, accept the project. If the NPV calculation is less than 0, reject the project.

Look at the two project examples in Table 2.12 and Table 2.13. 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 whole numbers.

Project A has an NPV greater than 0 and should be accepted. Project B has an NPV less than 0 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.

exam spotlight

Although the PMBOK® Guide doesn’t specifically address project selection methods or cash flow techniques, you may see exam questions on these topics.

exam spotlight

For the exam, you need to know three facts concerning IRR:

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

Applying Project Selection Methods Now that we’ve discussed some of the project selection techniques, let’s look at how to apply them when choosing projects or project alternatives. You can use one of the benefit measurement methods alone or in combination with others to come up with a selection decision. Remember that payback period is the least precise of all the cash flow techniques,

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Understanding How Projects Come About 69

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.

fun days vacation resorts

Nick is a project manager for Fun Days Vacation Resorts. He is working on three different project proposals to present to the executive steering committee for review. As part of the information‐gathering process, Nick visits the various resorts pretending to be a guest. This gives him a feel for what Fun Days guests experience on their vacations, and it better prepares him to present project particulars and alternatives.

Nick has prepared the project overviews for three projects and called on the experts in marketing to help him out with the projected revenue figures. He works up the numbers and finds the following:

Project A: payback period = 5 years; IRR = 8 percent

Project B: payback period = 3.5 years; IRR = 3 percent

Project C: payback period = 2 years; IRR = 3 percent

Funding exists for only one of the projects. Nick recommends Project A and predicts that this is the project the steering committee will choose since the projects are mutually exclusive.

Nick’s turn to present comes up at the steering committee. Let’s listen in on the action:

“On top of all the benefits I’ve just described, Project A provides an IRR of 8 percent, a full 5 percent higher than the other two projects we discussed. I recommend the committee chooses Project A.”

“Thank you, Nick,” Jane says. “Good presentation.” Jane is the executive chairperson of the steering committee and has the authority to break ties or make final decisions when the committee can’t seem to agree.

“However, here at Fun Days we like to have our fun sooner rather than later.” Chuckles ensue from the steering committee. They’ve all heard this before. “I do agree that an 8 percent IRR is a terrific return, but the payback is just too far out into the future. There are too many risks and unknowns for us to take on a project with a payback period this long. As you know, our industry is directly impacted by the health of the economy. Anything can happen in five years’ time. I think we’re much better off going with Project C. I recommend we accept Project C. Committee members, do you have anything to add?”

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

70 Chapter 2 ■ Creating the Project Charter

Kicking Off the Project Charter Your first stop in the Initiating process group is a process called Develop 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 process 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.

The charter contains several elements that I’ll discuss in the section “Formalizing and Publishing the Project Charter” later in this chapter.

exam spotlight

The project charter (which is an output of the Develop Project Charter process) is the written acknowledgment that the project exists. The project charter documents the name of the project manager and gives that person the authority to assign organizational resources to the project. The project is officially authorized when the project charter is signed by the project sponsor.

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 management processes are typically documents or other forms of information that are key to the process. They come from one of two places: they are outputs from a previously completed process, or they are produced outside the project. 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

■ Agreements

■ Enterprise environmental factors

■ Organizational process assets

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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Kicking Off the Project Charter 71

the organization, the buyer typically writes the SOW. For example, suppose you work for a consulting firm and have been assigned as the project manager for a project your company is performing on contract. The customer, the organization you’ll be performing the project for, is the one who writes the SOW.

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

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

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

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

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

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

Business Case The purpose of a business case is to understand the business need for the project and determine whether the investment in the project is worthwhile. The business case often describes the cost‐benefit analysis and the business need or demand that brought about the project.

Performing a feasibility study is a great first step in building the business case. The feasibility study will examine the needs and demands of the business, marketing opportunities, costs, risks, and more while taking into account the given assumptions and constraints of the proposed products or services. Once the feasibility study is completed, it’s

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

72 Chapter 2 ■ Creating the Project Charter

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 require- ments, legal requirements, government regulations, and so on.

■ Description of alternative solutions. This should include a high‐level description of costs, the feasibility of implementing each alternative, and a description of any impacts to the organization as a result of this solution. (Cost‐benefit, payback, and other financial analyses are generally included in this section of the business case.)

■ Description of the expected results of each alternative solution. ■ Cost‐benefit analysis. ■ Recommended solution.

Remember that when your selection committee is analyzing the business case, discussing initial funding requirements, and approving the business case (and thus triggering the Develop Project Charter process), they are completing these activities outside the boundaries of the project. Typically, the project team is not involved at this stage. In other words, the project isn’t a project until the project charter is approved, and the project charter cannot be started until the business case is approved.

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

Enterprise Environmental Factors Enterprise environmental factors show up as input to many of the other processes we’ll discuss throughout the book. This input refers to the factors outside the project that have (or might have) significant influence on the success of the project. According to the PMBOK® Guide, the environmental factors may include the following:

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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Kicking Off the Project Charter 73

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

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

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

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

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

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

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

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

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

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

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

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

Organizational Process Assets Organizational process assets are the organization’s policies, guidelines, processes, procedures, plans, approaches, and standards for conducting work, including project work. Organizational process assets are divided into two categories: processes and procedures and corporate knowledge base. Processes and procedures refers to a wide range of elements that might affect several aspects of the project, such as project management policies, safety policies, performance measurement criteria, templates, financial controls, communication requirements, issue and defect management

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

74 Chapter 2 ■ Creating the Project Charter

procedures, change control procedures, risk control procedures, and the procedures used for authorizing work.

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

There are too many organizational process assets to cover in this chapter. I’ll discuss many of them throughout the Planning chapters when a certain organizational process asset pertains to a specific process.

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

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

exam spotlight

Remember that organizational process assets encompass many elements, including poli- cies, guidelines, standards, historical information, and so on, and that they’re divided into two categories: processes and procedures and corporate knowledge base. For the exam, make certain you understand what the organizational process assets entail and that you can differentiate them from the enterprise environmental factors input.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Formalizing and Publishing the Project Charter 75

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

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

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

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

Formalizing and Publishing the Project Charter The approved 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 the project sponsor, it gives the project manager the authority to assign organizational resources to the project, and it shows commitment and acceptance of the project by the business unit or organization.

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,

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

76 Chapter 2 ■ Creating the Project Charter

the business opportunity or need, and the project’s purpose, executive managers can get a first glance 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 these:

■ Purpose or justification for the project

■ Project objectives that are measurable

■ High‐level list of requirements

■ High‐level description of the project

■ High‐level list of risks

■ Milestone schedule (summary level)

■ Budget (summary level)

■ Criteria for project approval

■ Name of the project manager and their authority levels

■ Name of the sponsor (or authorizer of the project) and their authority levels

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

For the exam, the important factors to remember about the project charter are that it authorizes the project to begin; it authorizes the project manager to assign resources to the project; it documents the business need, justification, and impact; it describes the customer’s requirements; it identifies key deliverables based on the business requirements; it sets stakeholder expectations; it ensures stakeholder agreement; and it ties the project to the ongoing work of the organization.

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

Key Stakeholders The PMBOK® Guide states that the project charter forms a partnership between the organization requesting the project and the one performing the project. The project charter should always be written before you begin the Planning process group.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Formalizing and Publishing the Project Charter 77

The project charter will help assure that stakeholders’ expectations are in alignment with the project scope and with the final results of the project. According to the PMBOK® Guide, a project charter assures a well‐defined start date for the project and provides a way for senior management to formally accept the project.

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

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

Project 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. In turn, the project team is responsible for supporting you by performing the work of the project.

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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

78 Chapter 2 ■ Creating the Project Charter

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 their role as project champions, they rally support from stakeholders and the executive management team. They keep projects front and center at the higher levels of the organization and are the spokespeople for projects.

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. Ultimately, the project sponsor is responsible for facilitating the project’s success.

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.

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.

exam spotlight

In some organizations, the project manager might write the project charter. However, if you (as the project manager) are asked to write the charter, remember that your name should not appear as the author. Because the project charter authorizes the project and authorizes you as the project manager, it doesn’t make sense for you to write a document authorizing yourself to manage the project. The author of the charter should be an executive manager in your organization with the power and authority to assign resources to this project. This is usually the project sponsor or project initiator.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Identifying Stakeholders 79

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

Prior to publishing the charter, I like to hold a kickoff meeting with the key stakeholders to discuss the charter, inform them of the key deliverables and milestones, ensure that they understand their roles and responsibilities in relation to the project, and then obtain their sign‐off. I think it’s imperative for you to identify your key stakeholders as soon as possible and involve them in the creation of the project charter. Remember that stakeholder identification is an ongoing activity.

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

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

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

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.

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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

80 Chapter 2 ■ Creating the Project Charter

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

The inputs of this process are as follows:

■ Project charter

■ Procurement documents

■ Enterprise environmental factors

■ Organizational process assets

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

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

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

exam spotlight

Stakeholder identification should occur as early as possible in the project and continue throughout its life. Likewise, the stakeholder analysis and strategy should be reviewed periodically throughout the project and updated as needed. Remember to manage stakeholder satisfaction just as you would any key deliverable on the project. Identifying and analyzing their needs throughout the project will help make certain you are managing their expectations, and thus their satisfaction.

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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Identifying Stakeholders 81

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

During stakeholder analysis, you’ll want to identify the influences stakeholders have in regard to the project and understand their expectations, needs, and desires. From there, you’ll derive more specifics regarding the project goals and deliverables. Be warned that stakeholders are mostly concerned about their own interests and what they (or their organizations) have to gain or lose from the project. In all fairness, we all fall into the stakeholder category, so we’re all guilty of focusing on those issues that impact us most.

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

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

Name Department Knowledge Level Expectations

Influence Levels Phone Email

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

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

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. That way, you can devise a strategy to deal with those impacts should they arise.

To determine potential impact, as project manager you must 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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

82 Chapter 2 ■ Creating the Project Charter

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 where power is on one axis and interest on the other. 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 how your stakeholders may respond to different situations that arise throughout the project and how you might influence them to obtain the best possible outcome. As I said earlier, some stakeholders may have a significant amount of influence over the project and its outcomes and their level of influence may shed some light on how they may respond to various situations. Your first step in determining the level of influence they have should be to understand the organizational structure and where they fit in. Conducting informal interviews with project team members, other stakeholders, and the stakeholders themselves about their behaviors on past projects will also give you some insight on how they may react to your project.

You might want to consider the following elements when assessing stakeholders:

■ Identifying the key stakeholders who could have a significant impact on the project based on position, influence, and power

■ Stakeholders’ anticipated level of participation

■ Stakeholders’ groups or committees and their level of influence

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Introducing the Kitchen Heaven Project Case Study 83

Once the stakeholder assessment is complete, you should devise a plan to deal with any potential impacts and/or potential strategies for gaining their support.

Remember that the definition of a successful project is one that accomplishes the goals of the project and meets stakeholders’ expectations. Understand and document those expectations and you’re off to a good start.

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

Identifying Information This includes items such as contact information, department, role in the project, and so on.

Assessment Information This includes elements regarding influence, expectations, key requirements, and when the stakeholder involvement is most critical.

Stakeholder Classification Stakeholders can be classified according to their relationship to the organization (internal or external, for example) and, more important, whether they support the project, are resistant to the project, or have no opinion.

Remember that project documents are usually easily accessible by the project team and stakeholders. Use caution when documenting sensitive information regarding a stakeholder and your strategy for dealing with that stakeholder because it could become public knowledge.

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 study will present

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

84 Chapter 2 ■ Creating the Project Charter

situations or processes that you might find during your projects and describe how one project manager resolves them.

Project Case study: new kitchen heaven retail store

You are a project manager for Kitchen Heaven, a chain of retail stores specializing in kitchen utensils, cookware, dishes, small appliances, and some gourmet foodstuffs, such as bottled sauces and spices. You’re fairly new to the position, having been hired to replace a project manager who recently retired.

Kitchen Heaven currently owns 49 stores in 34 states and Canada. The world headquarters for Kitchen Heaven is in Denver, Colorado. Counting full‐time and part‐time employees, the company employs 1,500 people, 200 of whom work at headquarters.

The company’s mission statement reads, “Great gadgets for people interested in great food.”

Recently, the vice president of marketing paid you a visit. Dirk Perrier is a very nice, well‐dressed man with the formal air you would expect a person in his capacity might have. He shakes your hand and gives you a broad, friendly smile.

“We’ve decided to go forward with our 50th store opening! Sales are up, and our new line of ceramic cookware is a hot seller, no pun intended. I don’t know if you’re familiar with our store philosophy, so let me take a moment to explain it. We like to place our stores in neighborhoods that are somewhat affluent. The plain fact is that most of our shoppers have incomes of more than $150,000 a year. So, we make an effort to place our stores in areas where those folks usually shop.

“We’re targeting the type of customer who watches the Food Network channel and must have all the gadgets and tools they see the famous chefs using. So, the stores are upbeat and convey a fun, energetic feel, if you will.

“Our next store is going to be right here in our home area—Colorado Springs. Because this is going to be our 50th store, we plan on having a 50th grand‐opening celebration, with the kind of surprises and activities you might expect for such a notable opening.

“Our stores generally occupy from 1,500 to 2,500 square feet of retail space, and we typically use local contractors for the build‐out. A store build‐out usually takes 120 days from the date the property has been procured until the doors open to the public. I can give you our last opening’s project plan so you have a feel for what happens. Your job will be to procure the property, negotiate the lease, procure the shelving and associated store furnishings, get a contractor on the job, and prepare the 50th store festivities. My marketing folks will assist you with that last part.

“You have six months to complete the project. Any questions?”

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Introducing the Kitchen Heaven Project Case Study 85

You take in a deep breath and collect your thoughts. Dirk has just given you a lot of information with hardly a pause between thoughts. A few initial ideas drift through your head while you’re reaching for your notebook.

You work in a functional organization with a separate projectized department responsible for carrying out projects of this nature. You’ve been with the company long enough to know that Dirk is high up there in the executive ranks and carries the authority and power to make things happen. Therefore, Dirk is the perfect candidate for project sponsor.

You grab your notebook and start documenting some of the things Dirk talked about, clarifying with him as you write:

The project objective is to open a new store in Colorado Springs six months from today.

The store should be located in an affluent area.

The store will carry the full line of products, from utensils to gourmet food items.

The grand opening will be accompanied by lots of fanfare because this is the 50th store opening.

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.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

86 Chapter 2 ■ Creating the Project Charter

“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 ROI [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 IRR [internal rate of return] 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. Last, 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 no Kitchen Heaven in the area, 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.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Understanding How This Applies to Your Next Project 87

■ 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. I don’t have any scientific evidence for

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

88 Chapter 2 ■ Creating the Project Charter

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 several times after the work of the project is under way. 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 high‐level deliverables, 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, 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 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 10 Knowledge Areas. The Knowledge Areas bring together processes that have characteristics in common. They also help you under- stand 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, strategic opportunity/business needs, customer requests, technological advances, legal requirements, environmental considerations, or social needs.

Project selection methods include decision models in the form of benefit measurement methods and mathematical methods (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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Exam Essentials 89

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 0 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 Project Charter process is the first process in the Initiating process group. The project statement of work (SOW) 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 as well as a product scope description and should map to the organization's strategic plan and the stakeholders’ business value expectations. The other inputs to this process are business case and agreements.

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 and facilitation techniques are the two tools and techniques 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. 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 10 Project Management Knowledge Areas. The 10 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, Project Procurement Management, and Project Stakeholder 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, strategic opportunity/business need, customer requests, technological advances, legal requirements, environmental considerations, and social needs.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

90 Chapter 2 ■ Creating the Project Charter

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 0 should be accepted, and those with an NPV less than 0 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 0, and IRR assumes reinvestment at the IRR rate.

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

Be able to describe the purpose of 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. It usually includes a cost‐benefit analysis and the needs or demands that brought about the project.

Be able to describe the importance of the project charter. The approved 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, and record stakeholder information in the stakeholder register.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Review Questions 91

Review Questions You can find the answers to the review questions in Appendix A.

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 come down and get 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. Strategic opportunity/business need

C. Customer request

D. Legal requirement

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

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

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

C. Agreements, 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 US 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 op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

92 Chapter 2 ■ Creating the Project Charter

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 management 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 belongs 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 Work, and Perform Integrated Change Control

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

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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Review Questions 93

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 clubs 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 shorter

B. Project Kansas City, because the IRR is higher

C. Project Spokane, because the IRR is lower

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

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.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

94 Chapter 2 ■ Creating the Project Charter

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. You are in the process of identifying your stakeholders. You are using one of the tools and techniques of this process that according to the PMBOK® Guide involves all of the following steps except for which one?

A. Determining the level of stakeholder participation on the project

B. Assessing how stakeholders are likely to react to certain situations

C. Identifying stakeholders

D. Analyzing potential impacts stakeholders may present

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

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Review Questions 95

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 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 issued by a manager external to the project. Once approved, the charter formalizes the authority assigned to the project manager and ensures commitment and acceptance of the project by the stakeholders.

B. The project charter should be issued by a key stakeholder. Once approved, it ensures a common understanding of the key deliverables, milestones, and roles and responsibilities of the stakeholders.

C. The project charter should be issued by the project manager. Once approved, the charter formalizes the authority assigned to the project manager and ensures commitment and acceptance of the project by the stakeholders.

D. The project charter should be issued by the project sponsor. Once approved, it ensures a common understanding of the key deliverables, milestones, and roles and responsibilities of the stakeholders.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Chapter

3 Developing the Project Scope Statement

The PMP® exaM conTenT froM The Planning PerforMance doMain covered in This chaPTer includes The following:

✓ Task 1: review and assess detailed project requirements, constraints, and assumptions with stakeholders based on the project charter, lessons learned, and by using requirement gathering techniques in order to establish the project deliverables.

✓ Task 2: develop a scope management plan, based on the approved project scope and using scope management techniques, in order to define, maintain, and manage the scope of the project.

✓ Task 9: develop the change management plan by defining how changes will be addressed and controlled in order to track and manage change.

✓ Task 12: conduct kick‐off meeting, communicating the start of the project, key milestones, and other relevant information in order to inform and engage stakeholders and gain commitment.

✓ Knowledge and skills:

■ Requirements gathering techniques (e.g., planning sessions,

brainstorming, and focus groups)

■ Estimation tools and techniques

■ Scope deconstruction (e.g., WBS, Scope Backlog) tools and

techniques

■ Scope management planning

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Great job! You’ve successfully completed the project Initiating processes and published the project charter and the stakeholder register. The project is officially under way.

Stakeholders have been identified and informed of the project, you have management buy‐ in on the project, the project manager has been assigned, and the project objectives and description have been identified. A solid foundation for the planning process is in place.

In this chapter, we will begin the Planning processes for the project. In fact, I will continue discussing the Planning processes through Chapter 7, “Planning Project Resources.” Planning is a significant activity in any project and, if done correctly, will go a long way toward ensuring project success.

This chapter begins with the Develop Project Management Plan process. This process will describe the overall approach you’ll use to manage the project. The result of this process is the project management plan document that describes how you’ll execute, monitor, and control the project outcomes as the project progresses and how you’ll close out the project once it concludes.

Then you’ll move on to the Plan Scope Management process. Here we will examine documenting a plan that outlines how to define, validate, and control the project scope.

The Collect Requirements process is next. During this process, quantified requirements are gathered and documented to assure that stakeholder needs are met and expectations are managed.

During the Define Scope process, you’ll use the project charter and the requirements documentation—plus some other inputs—and then apply the tools and techniques of this process to come up with the project scope statement. I’ll talk in depth about project objectives, requirements, constraints, assumptions, and other elements of writing the project scope statement, which is an output of this process.

Once you have the deliverables and requirements well defined, you’ll begin the process of breaking down the work of the project via a work breakdown structure (WBS). You’ll accomplish this task in the Create WBS process. The WBS defines the scope of the project and breaks the work down into components that can be scheduled and estimated as well as easily monitored and controlled.

We have a lot to cover in this chapter, so let’s get started.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Developing the Project Management Plan 99

Developing the Project Management Plan The first process in the Planning process group is the Develop Project Management Plan process. It’s first for good reasons. This process is part of the Project Integration Management Knowledge Area and is concerned with defining, preparing, coordinating, and then integrating all the various subsidiary project plans into an overall project management plan.

If you haven’t already done so, make certain to conduct a project kick‐off meeting with the stakeholders and project team members. Before beginning the processes we’ll discuss in this chapter, you need stakeholder buy‐in and commitment to the project in order to successfully document requirements, key milestones, and deliverables.

Exam Spotlight

The PMI® Project Management Professional (PMP®) Examination Content Outline documents the official project kick‐off meeting in the Planning process group. In reality, many of you, myself included, may perform this step during the Initiating process, but remember for the exam that it occurs in the Planning process group.

This process involves defining and documenting the processes you’re going to use to manage this project. For example, let’s say you and the project team have determined you will use project management processes involving costs, human resources, risks, and a project schedule. (Warning: This is a demonstration only—don’t try this at home. In reality, professionals perform many more processes than this on a typical project.) Each particular process might have a management plan that describes it. For instance, a cost management plan (an example of a subsidiary plan) would describe how costs will be managed and controlled and how changes to costs will be approved and managed throughout the project. The Develop Project Management Plan process brings all these subsidiary plans together, along with the outputs of the Planning group processes, into one document called the project management plan.

In Chapter 1, “What Is a Project?,” I talked about tailoring—determining which processes within each process group are appropriate for the project on which you’re working. Tailoring is used in the Develop Project Management Plan process because it’s here you’ll determine what processes to use to best manage the project.

To create and document the plan, you need to gather some inputs and build on the information you’ve already collected.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

100 Chapter 3 ■ Developing the Project Scope Statement

developing inputs The Develop Project Management Plan process has four inputs:

■ Project charter

■ Outputs from other processes

■ Enterprise environmental factors

■ Organizational process assets

Let’s take a look at each next.

Project Charter You’ll recall that the project charter describes the objectives of the project and the high‐level requirements needed to satisfy stakeholder expectations. It’s an input into this process is because the content of the project charter—including project objectives, project description, high‐level requirements, summary milestone schedule, summary budget, and so on—will help you and the team determine exactly which project management processes to use on the project.

Outputs from Other Processes The project management processes include all the individual processes that make up the process groups we’re talking about throughout this book. The Initiating group, for example, has two processes, Planning has a zillion (okay, not that many, but it seems like it), and so on. The outputs from other processes you use on the project become inputs to the Develop Project Management Plan process. For example, the cost management plan we talked about in the introduction is an input. Any processes you use that produce a baseline (such as schedule or cost) or a subsidiary management plan (such as a risk management plan, communication management plan, and so on) are included as inputs to this process.

I’ll talk more about baselines and the makeup of individual subsidiary management plans as we discuss the various Planning processes, starting with this chapter and continuing through Chapter 7.

Enterprise Environmental Factors You’ve seen enterprise environmental factors before. Some of the key elements of the environmental factors you should consider when choosing the processes to perform for this project include standards and regulations (both industry and governmental), company culture and organizational structure, personnel administration, infrastructure, and the project management information system (PMIS).

Organizational Process Assets Some of the critical elements of the organizational process assets input you should consider when choosing the processes to perform for this project include project management plan template, change control procedures, performance measurement criteria, historical information, and the configuration management

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Developing the Project Management Plan 101

knowledge database that contains the official company policies, standards, procedures, and other project documents.

The PMIS is an automated (or manual) system used to document the project management plan and subsidiary plans, to facilitate the feedback process, and to revise the documents. It incorporates the configuration management system and the change control system, both of which I’ll cover in Chapter 10, “Measuring and Controlling Project Performance.” Later in the project, the PMIS can be used to control changes to any of the plans. When you’re thinking about the PMIS as an input (that is, as part of the enterprise environmental factors), think of it as a collection and distribution point for information as well as an easy way to revise and update documents. When you’re thinking about the PMIS as a tool and technique, think of it just that way—as a tool to facilitate the automation, collection, and distribution of data and to help monitor processes such as scheduling, resource leveling, budgeting, and web interfaces.

As I talked about in Chapter 1, the processes you choose to perform for the project will be based on the complexity of the project, the project scope, and the type of industry in which you work. Your organization’s standards, guidelines, and policies or the project management office (PMO) might also dictate the types of processes you’ll use for the project. You should also consider whether your organization has existing change control processes in place, templates that you’re required to use, or financial controls and processes. Historical information and past project files are useful in helping you decide which processes to use for this project.

Exam Spotlight

The PMIS in the Develop Project Management Plan process includes a subsystem called the configuration management system, and the change control system is a subsystem of the configuration management system.

The two tools and techniques of this process are expert judgment and facilitation techniques. We looked at facilitation techniques in Chapter 2, “Creating the Project Charter.” According to the PMBOK® Guide, you’ll need the following types of expert judgment to complete this process:

■ Tailoring techniques

■ Understanding technical and management details that need to be included in the project management plan

■ Determining resources and assessing skill levels needed for project work

■ Determining and defining the amount of configuration management to apply on the project

■ Determining which project documents require formal change control processes

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

102 Chapter 3 ■ Developing the Project Scope Statement

documenting the Project Management Plan The purpose of most processes is, of course, to produce an output. Outputs are usually a report or document of some type or a deliverable. In this case, you end up with a document—the project management plan—that describes, integrates, and coordinates baselines and subsidiary plans for the processes you’ve determined to use for the project. The project management plan can be detailed, or it can be a high‐level summary based on the needs of the project.

According to the PMBOK® Guide, the project management plan defines how the project is executed, how it’s monitored, and how it’s controlled. It is progressively elaborated over the life of the project. It also documents the outputs of the Planning group processes, which I’ll cover over the next several chapters. The project management plan should include or discuss the following elements:

■ Processes you’ll use to perform each phase of the project and their level of implementation, the tools and techniques you’ll use from these processes, and the interactions and dependencies among the processes. All this was determined as part of the tailoring exercise we talked about in Chapter 2.

■ The life cycle you’ll use for the project and for each phase of the project if applicable.

■ Methods for executing the work of the project to fulfill the objectives.

■ Change management plan describing methods for monitoring and controlling change.

■ Configuration management plan.

■ Methods for determining and maintaining the validity of performance baselines.

■ Communication needs of the stakeholders and techniques to fulfill those needs.

■ Management reviews of content, issues, and pending decisions.

In addition to these elements, the subsidiary plans that are associated with the processes you’ll be using for this project should be documented in the project management plan. Each of these subsidiary management plans might contain the same elements that the overall project management plan does, but they’re specifically related to the topic at hand. For example, the cost management plan should define how changes to cost estimates will be reflected in the project budget and how changes or variances with a significant impact should be communicated to the project sponsor and stakeholders. The schedule management plan describes how changes to the schedule will be managed, and so on.

The subsidiary plans might be detailed or simply a synopsis, depending on the needs of the project. I’ve listed the subsidiary plans along with a brief description next. I will cover each of these plans in more detail throughout the remainder of this book. According to the PMBOK® Guide, the subsidiary plans are as follows:

Scope Management Plan Describes the process for defining, maintaining, and managing project scope, facilitates creating the work breakdown structure (WBS), describes how the product or service of the project is validated and accepted, and documents how changes to scope will be handled.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Developing the Project Management Plan 103

Requirements Management Plan Describes how requirements will be analyzed, documented, traced, reported, and managed throughout the project.

Schedule Management Plan Describes how the project schedule will be developed and controlled and how changes will be incorporated into the project schedule.

Cost Management Plan Describes how costs will be managed and controlled and how changes to costs will be approved and managed.

Quality Management Plan Describes how the organization’s quality policy will be implemented. It should address and describe quality control procedures and measures, quality assurance procedures and measures, and continuous process improvement.

Communications Management Plan Describes the communication needs of the stakeholders, including timing, frequency, and methods of communications.

Risk Management Plan Describes how risks will be managed and controlled during the project. This should include risk management methodology; roles and responsibilities; definitions of probability and impact; when risk management will be performed; and the categories of risk, risk tolerances, and reporting and tracking formats.

Procurement Management Plan Describes how the procurement processes will be managed throughout the project. This might include elements such as type of contract, procurement documents, and lead times for purchases.

Process Improvement Plan Focuses on finding inefficiencies in a process or activity and eliminating them.

Human Resource Management Plan Documents the roles and responsibilities for project team members, their reporting relationships, and how the team will be managed.

Stakeholder Management Plan Documents what strategies to use to encourage stakeholder participation, documents the analysis of their needs and interests and impacts, and documents the process regarding project decision making.

The project management plan is not limited to the subsidiary plans listed here. For example, even though the PMBOK® Guide does not mention the change management plan in the list of subsidiary plans, you should develop and include a change management plan with your project management plan. The change management plan describes how you will document, address, track, and control changes. You might include other plans and documentation that help describe how the project will be executed or monitored and controlled. Perhaps you’re working on a project that requires precise calculations and exact adherence to requirements. You could include a plan that describes these calculations, how they’ll be monitored and measured, and the processes you’ll use to make changes or corrections.

The project management plan also includes project baselines, such as these:

■ Schedule baseline

■ Cost baseline

■ Scope baseline

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

104 Chapter 3 ■ Developing the Project Scope Statement

I’ll talk about each of these documents in the remaining chapters as well.

Exam Spotlight

Understand that the purpose of the project management plan is to define how the project is executed, monitored and controlled, and closed as well as to document the processes you’ll use during the project.

As the project progresses and more and more processes are performed, the subsidiary plans and the project management plan itself might change. You will manage these changes using the Perform Integrated Change Control process. All changes should be reviewed following the processes outlined in the change control plan, and the project management plan should be updated to reflect the approved changes.

Exam Spotlight

In practice, you’ll find that you’ll prepare the project management plan after you’ve progressed through several of the other Planning processes. It’s difficult to finalize some of these subsidiary plans without thinking through or sometimes performing the process they’re associated with first. However, for the exam, remember that Develop Project Management Plan is the first process in the Planning group, and it should be performed first. Updates can and should occur to the project management plan as subsidiary plans are created or changed.

Plan Scope Management Plan Scope Management is the first process in the Project Scope Management Knowledge Area. You might recall from Chapter 1 that the purpose of the Project Scope Management Knowledge Area is to describe and control what is and what is not work of the project. Scope is collectively the product, service, or result of the project and the deliverables the project intends to produce.

The primary purpose of this process is twofold: to write the scope management plan and to develop the requirements management plan. The scope management plan is a planning tool that documents how the project team will go about defining project scope, how changes to scope will be maintained and controlled, and how project scope will be verified. The requirements management plan addresses analyzing, documenting, and managing the project requirements. I’ll cover the requirements management plan in detail in the section “Documenting the Scope Management Plan” later in this chapter.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Plan Scope Management 105

Exam Spotlight

According to the PMI® Project Management Professional (PMP®) Examination Content Outline, the activities and processes in the Planning process group involve defining, assessing, and reviewing detailed project requirements based on the project charter in order to establish the project deliverables. You will perform these processes with your stakeholders using requirements gathering techniques. Reviewing lessons learned from previous projects of similar size and scope and reviewing the constraints and assumptions of this project are all keys to documenting a detailed list of project deliverables.

For now you’ll concentrate on the inputs to this process, which will help you get started documenting the decisions about the Plan Scope Management process for your project.

understanding the Plan scope Management inputs You’ve seen the inputs to the Plan Scope Management process before. They are as follows:

■ Project management plan

■ Project charter

■ Enterprise environmental factors

■ Organizational process assets

Even though I’ve talked about these before, you’ll want to look at specific elements of some of these inputs closely. Defining project scope, and managing that scope as you progress through the project, has a direct relationship to the success of the project. It’s difficult to document how you’ll define project scope if you don’t first understand the purpose behind the project; the product, service, or result you’re trying to produce; and the environmental factors and organizational process assets under which you’re working. The process of how you’ll go about defining and managing scope is what the scope management plan (which is what you’re ultimately getting to with this process) is about.

The project charter describes the purpose and high‐level requirements of the project. Analyzing the information in this document will help you determine the appropriate tools and methodologies to use (as well as which processes to perform) for the project. The idea here is that you want to understand the size and complexity of the project so that you don’t spend more time than needed documenting how you’re going to go about defining and managing scope.

One of the environmental factors that might influence the way scope is managed is personnel administration, or more specifically, the human resources involved on the project. Their skills, knowledge, and abilities to communicate and escalate issues appropriately might influence the way project scope is managed. Personnel policies governing those resources might also have an effect. For example, you might have a team member who has a close relationship with one of the stakeholders. Let’s say the stakeholder

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

106 Chapter 3 ■ Developing the Project Scope Statement

wants a change to the project. The stakeholder and team member grab a cup of coffee together at the corner deli, and the next thing you know, the team member is incorporating the change into the project. Scope can’t be managed efficiently when it’s being changed without the knowledge of the project manager or project team.

Other environmental factors that might affect scope management are the organization’s culture, economic conditions, market conditions, and physical and technological infrastructure.

Organizational process assets typically include policies and procedures, whether formal or informal. Your organization’s policies or the policies and guidelines of your industry might have an effect on scope management, so make certain you’re familiar with them. And don’t forget historical information. You can review the scope management plan from previous projects of similar size and scope to help you craft the one for this project.

Scope Management Plan Requirements

Phil Reid is a gifted engineer. He works as an accident reconstructionist and has a 90 percent success rate at assisting his clients (who are attorneys) at winning court cases. Phil can intuitively and scientifically determine whether the scene of an accident is real or is insurance fraud. Most cases Phil works on are managed as projects because each accident is unique, the cause of each accident is unique, and each investigation has a definite beginning and ending. The attorneys that Phil’s organization works with want the final results of the investigation delivered in different formats. Although Phil is exceptionally good at determining the forensic evidence needed to prove or disprove how the accident occurred, he is not at all gifted in oral communication skills. As a result, the scope management plan requires the client to define how the outcome of the investigation should be presented and whether the engineer might be required to testify regarding the results of the investigation. That way, Phil’s organization can plan in advance how to use his talents on the project and assign a resource to work with him who has the communication skills and ability to testify if that’s required.

using Plan scope Management Tools and Techniques Plan Scope Management has two tools and techniques:

Expert Judgment You’ll rely on the expert judgment of people or groups with specific skills, knowledge, or training to help assess the process inputs. One expert you can count on in this process is the executive manager who wrote or contributed to the project charter. This person can clarify questions you might have about the project objectives as well as the product description. Stakeholders, industry experts, team members, people with specialized training, or other project managers with previous experience on projects similar to yours can help you determine how scope management should work for this project.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Plan Scope Management 107

Meetings You will use meetings with the experts just noted to determine and formalize the information contained in the scope management plan.

documenting the scope Management Plan The first output of the Plan Scope Management process is the scope management plan. This plan describes how the project team will go about defining project scope, validating the work of the project, and managing and controlling scope. According to the PMBOK® Guide, the scope management plan should contain the following:

■ The process you’ll use to prepare the project scope statement. The project scope statement (which I’ll define later in this chapter) contains a detailed description of what the deliverables and requirements of the project are and is based on the information contained in the preliminary scope.

■ A process for creating, maintaining, and approving the WBS. The WBS further defines the work of the project (as defined in the project scope statement) by breaking down the deliverables into smaller pieces of work.

■ A definition of how the deliverables will be validated for accuracy and the process used for accepting deliverables.

■ A description of the process for controlling scope change requests, including the procedure for requesting changes and how to obtain a change request form.

Exam Spotlight

The scope management plan is a planning tool that documents how the project team will go about defining project scope, how the work breakdown structure will be developed, how changes to scope will be controlled, and how the work of the project will be validated and accepted. The scope management plan is based on the approved project scope. And don’t forget, the scope management plan is a component of (or a subsidiary of) the project management plan.

documenting the requirements Management Plan The requirements management plan is much like the scope management plan but focuses on the project requirements. This plan details how to analyze, document, and manage the project requirements throughout all phases of the project. Managing the requirements is the key to this process, and the phase‐to‐phase relationship you use to run the project will influence how you will manage the project requirements. For example, a sequential phase‐to‐ phase relationship would dictate that all the requirements for each phase be completed before beginning the work of the phase and most certainly before moving on to the next phase of the project. An overlapping relationship might mean that the requirements are not fully defined before the work begins and are progressively elaborated as the project (or phase) progresses.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

108 Chapter 3 ■ Developing the Project Scope Statement

We talked about phase‐to‐phase relationships in Chapter 1. There are two types: sequential and overlapping.

Exam Spotlight

Make certain you document the phase‐to‐phase relationship you’ll use during the project life cycle in the requirements management plan.

There are several components of a sound requirements management plan. According to the PMBOK® Guide, you should include the following factors in the plan (and you are always free to add more than those noted here):

■ How planning, tracking, and reporting of requirements activities will occur

■ How changes to the requirements will be requested, tracked, and analyzed along with other configuration management activities

■ How requirements will be prioritized

■ What metrics will be used to trace product requirements

■ What requirements attributes will be documented in the traceability matrix (the last output of this process)

■ What elements to include on the traceability matrix

Collecting Requirements Now we are getting into the meat of the Planning processes. In the Collect Requirements process, we define what the final product or service of the project will look like. You will recall that scope management describes what is and what is not included in the project scope. In this case, we’re starting off by defining what is included in the work of the project.

Exam Spotlight

The PMBOK® Guide notes that not all of the requirements gathered during this process will be included in the end result of the project. The Define Scope process is where you will determine which of the requirements gathered here will be included in the final project. We will look at Define Scope later in this chapter.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Collecting Requirements 109

Requirements describe the characteristics of the deliverables. They might also describe functionality that a deliverable must have or specific conditions a deliverable must meet to satisfy the objective of the project. Requirements are typically conditions that must be met or criteria that the product or service of the project must possess to satisfy the objectives of the project. Requirements quantify and prioritize the wants, needs, and expectations of the project sponsor and stakeholders. According to the PMBOK® Guide (and lots of personal experience), you must be able to measure, trace, and test requirements. It’s important that they’re complete and accepted by your project sponsor and key stakeholders.

Requirements can take many forms. According to the PMBOK® Guide, requirements can be classified into the categories listed here, which may also assist you in elaborating them further:

■ Business

■ Stakeholder

■ Solution

■ Functional

■ Nonfunctional

■ Transition

■ Project

■ Quality

The primary purpose of the Collect Requirements process is to define and document the project sponsor’s, the customer’s, and the stakeholder’s expectations and needs for meeting the project objectives. In my experience, understanding, documenting, and agreeing on requirements are critical factors to project success. Recording the requirements and attaining stakeholder approval of the requirements will help you define and manage their expectations throughout the project.

Exam Spotlight

Requirements must be documented, analyzed, and quantified in enough detail that they can be measured once the work of the project begins. Requirements become the basis for developing the WBS and are essential in estimating costs, developing the project schedule, and quality planning.

You’ve already learned about four of the five inputs to this process: the scope management plan, requirements management plan, project charter, and the stakeholder register. We will discuss the fifth, the stakeholder management plan, in Chapter 5, “Developing the Project Budget and Communicating the Plan,” so we’ll move on to tools and techniques.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

110 Chapter 3 ■ Developing the Project Scope Statement

using the Tools and Techniques of the collect requirements Process Your communication skills are about to come in handy. Gathering and documenting requirements is not a task for the faint of heart. Because defining and producing requirements are so critical to the success of the project, I recommend using team members with excellent communication skills to perform this task. If they have the ability to read minds, all the better. Stakeholders almost always know what they want the end product to look like but often have difficulty articulating their needs. An expert communicator can read between the lines and ask probing questions that will draw the information out of the stakeholder.

Business process owners are those people who are experts in their particular area of the business. They are invaluable resources to the project manager and in gathering requirements for the project. They are usually the midlevel managers and line managers who still have their fingers in the day‐to‐day portion of the business. For example, it takes many experts in various areas to produce and market a great bottle of beer. Machinists regulate and keep the stainless steel and copper drums in top working order. Chemists check and adjust the secret formulas brewing in the vats daily. Graphic artists must develop colorful and interesting labels and ads to attract the attention of those thirsty patrons. Of course, those great TV commercials advertising the tasty brew are produced by yet another set of business experts and managers at all levels review and approve the work. These are the kinds of people you’ll interview and ask to assist you in identifying requirements.

There are several tools and techniques in this process you can use to help identify the requirements of the project. Some of these tools and techniques can also be used during the Identify Risks process and the Plan Quality Management process. We’ll cover those processes in Chapter 6, “Risk Planning,” and Chapter 7, “Planning Project Resources,” respectively. The following tools and techniques are used for the Collect Requirements process:

Interviews Interviews are typically one‐on‐one conversations with stakeholders. Interviews can be formal or informal and generally consist of questions prepared ahead of time. The advantages to this tool are that subject matter experts and experienced project participants can impart a lot of information in a short amount of time and typically have a good understanding of the features and functions needed from the project deliverables. You should record the responses during the interviews, and don’t be afraid to ask spontaneous questions as they occur to you during the interview.

Focus Groups Focus groups are usually conducted by a trained moderator. The key to this tool lies in picking the subject matter experts and stakeholders to participate in the focus group.

Facilitated Workshops Cross‐functional stakeholders come together in a facilitated workshop to discuss and define requirements that affect more than one department. For example, in the information technology industry, you can use a technique called joint application design/development (JAD) to define requirements. Suppose you’re implementing

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Collecting Requirements 111

a software package that impacts several business units. You’ll need representatives from each unit together in a workshop so that all of their needs are represented and prioritized. This way, all the participants understand the needs of other departments involved in the project and have a facilitated forum to discuss and resolve their issues. Other industries have similar techniques to bring together customers and/or business subject matter experts, such as Quality Function Deployment (QFD) sessions used in the manufacturing industry.

Exam Spotlight

The primary difference between focus groups and facilitated workshops is that focus groups are gatherings of prequalified subject matter experts and stakeholders, and facilitated workshops consist of cross‐functional stakeholders who can define cross‐functional requirements. Differences among stakeholders can be resolved more quickly and consensus is more easily attained in a facilitated workshop environment.

Group Creativity Techniques Group creativity involves several techniques, like brainstorming, the Nominal Group technique, affinity diagrams, and multicriteria decision analysis. We will cover each of these techniques in either the Identify Risks process (Chapter 6) or the Plan Quality Management process (Chapter 7).

Idea/mind mapping is a another group creativity technique in which participants first use brainstorming techniques to record their ideas. Whiteboards and flip charts are great tools to use with this process. The facilitator uses the whiteboard to map ideas and, using a mind‐mapping layout, group similar topics together. There are a few mind‐mapping software packages available on the market that can greatly assist with this process. Mind mapping allows the participants to gain an understanding of common ideas and themes, create new ideas, and understand differences.

Group Decision‐Making Techniques According to the PMBOK® Guide, there are many methods groups can use to reach decisions. These methods can also be used with the group creativity techniques. The four methods mentioned are unanimity, where everyone agrees on the resolution or course of action; majority, where more than 50 percent of the members support the resolution; plurality, where the largest subgroup within the group makes the decision if majority is not reached; and dictatorship, where one person makes the decision on behalf of the group.

Questionnaires and Surveys This technique involves querying a large group of participants via questionnaires or surveys. These tools allow you to gather information quickly and apply statistical analysis, if needed, to the results.

Observations This technique is typically a one‐on‐one experience where an observer sits side by side with the participant to observe how the participant interacts with the product or service. This technique is also known as job shadowing. For example, you may use this technique to determine requirements for an upgrade to a software product. Sitting

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

112 Chapter 3 ■ Developing the Project Scope Statement

with users and watching their interactions with the product enables observers to uncover requirements they would not have ordinarily discovered. This technique can also involve participant observers who perform the job themselves in order to ascertain requirements.

Prototypes Prototyping is a technique that involves constructing a working model or mock‐up of the final product with which the participants can experiment. The prototype does not usually contain all the functionality the end product does, but it gives participants enough information that they can provide feedback regarding the mock‐up. This is an iterative process where participants experiment and provide feedback and the prototype is revised and the cycle starts again.

Benchmarking This technique is used in the Quality processes as well and involves comparing measurements against standards to determine performance. It can also compare processes, operations, management practices, and so on against other departments, organizations, or industries to help refine and promote best practices or come up with ideas to improve current practices.

Context Diagrams Context diagrams use actors and business processes or equipment to visually show how interactions between them take place. Actors are people who use or interact with the business processes or equipment, which in turn produce outputs used by the actors.

Document Analysis Document analysis comes into play when it’s important to consider the organization’s business plans, marketing plans, contracts, business rules, strategic plans, and so on when determining requirements.

documenting requirements Now that you’ve employed the tools and techniques of this process to gather requirements, you’ll want to record them in a requirements document. Stakeholders sometimes have short memories, particularly on long‐term projects, so documenting requirements and obtaining their approval is essential for project success. You will use the requirements documentation throughout the project to manage stakeholder and customer expectations. This is a lot easier to accomplish when they’ve agreed to the requirements ahead of time and you have their approval documented.

I’ve already mentioned the first output of this process, which is requirements documentation. The other output of this process is the requirements traceability matrix. I’ll describe each in detail next.

requirements documentation As I mentioned earlier, requirements quantify and prioritize the wants, needs, and expectations of the project sponsor and stakeholders to achieve the project objectives. Requirements typically start out high level and are progressively elaborated as the project progresses. You must be able to track, measure, test, and trace the requirements of the project. You never want to find yourself at the end of the project (or phase) and discover

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Collecting Requirements 113

you have no way to validate the requirements. If you can’t measure or test whether the requirement satisfies the business need of the project, the definition of success is left to the subjective opinions of the stakeholders and team members.

You’ve worked hard to gather and define requirements and you don’t want all that effort going to waste. This output involves recording the requirements in a requirements document. The PMBOK® Guide does not dictate the format of this document and acknowledges that it can be formal with lots of detail or a simple list categorized by stakeholder and priority. However, it does state that the requirements document should include at least the following elements:

■ Business need for the project and why it was undertaken

■ Objectives of the project and the business objectives the project hopes to fulfill

The first two items in this list—business need for the project and objectives—are also needed for the traceability matrix.

■ Functional requirements

■ Nonfunctional requirements

Functional requirements is a term used often in software development. It typically describes a behavior, such as calculations or processes that should occur once data is entered. In non‐software terms, functional requirements might describe specifications, quantities, colors, and more. Nonfunctional requirements refers to elements that are related to the product but doesn’t describe the product directly. In the case of a software product, this could be a security requirement or performance criteria.

■ Quality requirements

■ Acceptance criteria

■ Transition requirements for the operations area or customer receiving the end result of the project

■ Business rules

■ Organizational areas and outside entities impacted

■ Support and training requirements

■ Assumptions and constraints

One of the most important elements of the requirements document that isn’t in the preceding list is the signatures of the key stakeholders indicating their acceptance of the requirements. They will also sign the scope statement, which we’ll talk about in the section “Defining Scope” later in this chapter.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

114 Chapter 3 ■ Developing the Project Scope Statement

requirements Traceability Matrix The last output of the Collect Requirements process is the requirements traceability matrix. The idea behind the traceability matrix is to document where the requirement originated, document what the requirement will be traced to, and then follow it through to delivery or completion. Table 3.1 shows a sample traceability matrix with several attributes that identify the requirement.

Ta b lE 3 .1 Requirements traceability matrix

unique id description of requirement source Priority

Test scenario owner status

001 Requirement one

Project objective

B User acceptance

HR specialist Approved

Each requirement should have its own unique identifier. You could devise a numbering system that defines both the category of the requirement and a unique, ascending number— for example, HR (for human resources) 001—or a simple numbering system as shown in this example may suffice.

The description should be brief but have enough information to easily identify the requirement.

The source column refers to where the requirement originated. Requirements may come from many sources, including project objectives, business needs, product design, the work breakdown structure, deliverables, and so on.

Priority refers to the priority of the requirement. You can use any prioritization process, like a simple numbering system or an alpha system as the example shows here. The definition of a “B” priority should be included in the requirements management plan. Perhaps an “A” is essential to project success and a “B” is highly desirable.

The test scenario in this example is where you record how the requirement will be tested (or during which project phase) and the owner of the test item, who will also decide if the test scenario passes or fails.

Status may capture information about the requirement that refers to whether the requirement has been approved to be included in the project; if it was added, deferred, or canceled; and so on.

Exam Spotlight

According to the PMBOK® Guide, the requirements traceability matrix helps assure that business value is realized when the project is complete because each requirement is linked to a business and project objective.

The next process in the Planning process group is the Define Scope process. We’ll look at that next.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Defining Scope 115

Defining Scope Now that you’ve documented the project requirements, you’re ready to further define the needs of the project in the Define Scope process. Scope can refer to product scope (the features and characteristics that describe the product, service, or result of the project) or project scope (the project management work). We’ll look at both product and project scope in this part of the chapter. The project scope statement (an output of this process) is what you’ll use to develop and document a detailed description of the deliverables of the project and the work needed to produce them. This process is progressively elaborated as more detail becomes known.

Exam Spotlight

You’ll want to pay particular attention to the accuracy and completeness of this process. Defining project scope is critical to the success of the project because it spells out exactly what the product or service of the project looks like. Conversely, poor scope definition might lead to cost increases, rework, schedule delays, and poor morale.

First, you’ll examine the inputs and tools and techniques of this process. The inputs to the Define Scope process are as follows:

■ Scope management plan

■ Project charter

■ Requirements documentation

■ Organizational process assets

Some of the important elements from the project charter that you’ll want to consider when writing the project scope statement (we’ll cover this output later) are the project description, project objectives, the characteristics of the product of the project, and the process for approving the project.

Objectives are quantifiable criteria used to measure project success. They describe “what” you’re trying to do, accomplish, or produce. Quantifiable criteria should at least include schedule, cost, and quality measures. You might use business measures or quality targets as well. These objectives will be broken down shortly into deliverables that will describe the objectives outlined in the charter.

The requirements documentation is a starting point for developing the scope statement. During the Define Scope process, you will determine which requirements will be included in the final product, service, or result of the project. They will be progressively elaborated and then documented in detail in the scope statement. The idea here is that you know some information when the charter is being written and more information comes to light when you hold brainstorming sessions or other meetings with stakeholders to discover the requirements of the product of the project (during the Collect Requirements process).

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

116 Chapter 3 ■ Developing the Project Scope Statement

Finally, those requirements are decided on, further elaborated, and documented (again) in much more detail in the scope statement. Keep in mind that not all of the requirements that you gathered and documented in the Collect Requirements process may be included in the scope statement. You will reexamine those requirements here and determine which ones are keepers and which ones are not.

Some of the other important information you’ll want to key in on from these inputs are historical information, the product description, and the project assumptions and constraints. I’ll cover each of these in the section “Writing the Project Scope Statement” later in this chapter.

Exam Spotlight

If the project charter is missing or was not created, you’ll need to develop the information normally found in the charter (or obtain it from other sources) to use as the foundation for creating the project scope statement.

You’ll see some new tools and techniques in this process:

■ Expert judgment

■ Product analysis

■ Alternatives generation

■ Facilitated workshops

You learned about expert judgment in Chapter 2 and about facilitated workshops earlier in this chapter. I’ll discuss product analysis and alternatives generation in the following sections.

Product analysis Product analysis goes hand in hand with the product scope description and, therefore, is most useful when the project’s end result is a product. Product analysis is a method for converting the product description and project objectives into deliverables and requirements. According to the PMBOK® Guide, product analysis might include performing value analysis, product breakdown, systems‐engineering techniques, systems analysis, and value‐engineering techniques to further define the product or service.

Exam Spotlight

It’s beyond the scope of this book to go into the various analysis techniques used in product analysis. For exam purposes, remember that product analysis is a tool and technique of the Define Scope process and memorize the list of analysis techniques that might be performed in this process.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Defining Scope 117

alternatives generation Alternatives generation is a technique used for discovering different methods or ways of accomplishing the work of the project. For example, brainstorming might be used to discover alternative ways of achieving one of the project objectives. Perhaps the project’s budget doesn’t allow for a portion of the project that the stakeholders think needs to be included. Brainstorming might uncover an alternative that would allow the needed portion to be accomplished.

Lateral thinking is a form of alternatives generation that can be used to help define scope. Edward de Bono created this term and has done extensive research and writing on the topic of lateral thinking. The simplest definition is that it’s thinking outside the box. Lateral thinking is a process of breaking apart the problem (or in our case the components of project scope, which are the deliverables and requirements), looking at them from angles other than their obvious presentation, and encouraging team members to come up with ways to solve problems or look at scope that are not apparently obvious.

Outside the box

Lateral thinking is a way of reasoning and thinking about problems from perspectives other than the obvious. It challenges our perceptions and assumptions. Consider these two examples of lateral thinking that I crafted based on some puzzles I found at this website: www.folj.com/lateral/. Use your favorite search engine and run a query on “lateral thinking puzzles” to find many more examples.

Question: How could your pet Yorkie fall from the window of an 18‐story building and live?

answer: The question asks how your pet could fall from an 18‐story building and live; however, the question doesn’t state that your pet fell from the 18th floor. So, your pet Yorkie fell from the basement‐level window.

Question: Eight chocolates are arranged in an antique candy dish. Eight people each take one chocolate. There is one chocolate remaining in the dish. How can that be?

answer: If there are eight chocolates in an antique dish, how can the last person take the last chocolate yet one remains in the dish? Well, the last person to take a chocolate took the dish as well—therefore, the last chocolate remained in the dish.

Remember these examples the next time you’re defining scope or looking for alternative answers to a problem.

The use of pairwise comparisons is another alternatives generation technique. This is much like it sounds in that you compare any number of items against each other to determine which is preferred. This technique typically uses quantitative measures to determine the preferred option.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

http://www.folj.com/lateral/

118 Chapter 3 ■ Developing the Project Scope Statement

Writing the Project Scope Statement The purpose of the project scope statement is to document the project objectives, deliverables, and the work required to produce the deliverables so that it can be used to direct the project team’s work and as a basis for future project decisions. The scope statement is an agreement between the project management team and the project customer that states precisely what the work of the project will produce. Simply put, the scope statement tells everyone concerned with the project exactly what they’re going to get when the work is finished.

Exam Spotlight

Understand that the purpose of the scope statement, according to the PMBOK® Guide, is to provide all the stakeholders with a foundational understanding of the project and product scope. It describes the project deliverables in detail. Also remember that the scope statement defines and progressively elaborates the work of the project. It guides the work of the project team during the Executing process, and all change requests will be evaluated against the scope statement. If the change request is outside the bounds of the project scope as documented in the project scope statement, it should be denied.

Since the scope statement serves as a baseline for the project, if questions arise or changes are proposed later in the project, they can be compared to what’s documented in the scope statement. Making change decisions is easier when the original deliverables and requirements are well documented. You’ll also know what is out of scope for the project simply because the work isn’t documented in the scope statement (or conversely, deliverables or other elements are documented and noted as being specifically out of scope). The criteria outlined in the scope statement will also be used to determine whether the project was completed successfully. I hope you’re already seeing the importance of documenting project scope.

understanding the scope statement components According to the PMBOK® Guide, the project scope statement should include all of the following:

■ Product scope description

■ Acceptance criteria

■ Project deliverables

■ Project exclusions

■ Project constraints

■ Project assumptions

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Writing the Project Scope Statement 119

If the details surrounding these are spelled out in other documents, you don’t have to reenter all the information in the scope statement. Simply reference the other document in the scope statement so that readers know where to find it.

Exam Spotlight

You may be thinking that the project scope statement has some of the same information as the project charter. Keep in mind the project charter is a high‐level description of the project (and it names the project manager) whereas the project scope statement is a detailed description of the project and product scope and describes how the final product or result of the project will be accepted, along with the other items mentioned earlier.

Product scope description The product scope description describes the characteristics of the product, service, or result of the project. I talked about this in Chapter 2. If the product scope description is contained in the project charter, you can reference the project charter in the project scope statement, or you can copy and paste the information from the project charter into the scope statement. It won’t hurt anything to have it in both places and will make reading the scope statement easier.

Exam Spotlight

You’ll use the project management plan as your measurement of project scope completion, and product scope completion will be measured against product requirements.

acceptance criteria Acceptance criteria include the process and criteria that will be used to determine whether the deliverables and the final product, service, or results of the project are acceptable and satisfactory. Acceptance criteria help you describe project success because it defines the specifications the deliverables must meet in order to be acceptable to the stakeholder. Acceptance criteria might include any number of elements, such as quality criteria, fitness for use, and performance criteria. This component should also describe the process stakeholders will use to indicate their acceptance of the deliverables.

Project deliverables Deliverables are measurable outcomes, measurable results, or specific items that must be produced or performed to consider the project or project phase completed. Deliverables should be specific and verifiable. For example, one of your deliverables might include

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

120 Chapter 3 ■ Developing the Project Scope Statement

widgets with a 3" diameter that will in turn be assembled into the final product. This deliverable, a 3" diameter widget, is specific and measurable. However, if the deliverable was not documented or not communicated to the manager or vendor responsible for manufacturing the widgets, there could be a disaster waiting to happen. If they deliver 2" widgets instead of the required 3" version, it would throw the entire project off schedule or perhaps cause the project to fail. This could be a career‐limiting move for the project manager because it’s the project manager’s responsibility to document deliverables and monitor the progress of those deliverables throughout the project. Most projects have multiple deliverables. As in this example, if you are assembling a new product with many parts, each of the parts might be considered independent deliverables.

A project deliverable is typically a unique and verifiable product or result or a service that’s performed. The product or service must be produced or performed in order to consider the project complete. The deliverables might also include supplementary outcomes such as documentation or project management reports.

The bottom line is this: No matter how well you apply your project skills, if the wrong deliverables are produced or the project is managed to the wrong objectives, you will have an unsuccessful project on your hands.

Critical Success Factors

Deliverables and requirements are sometimes referred to as critical success factors. Critical success factors are those elements that must be completed in order for the project to be considered complete. For example, if you’re building a bridge, one of the deliverables might be to produce a specific number of trusses that will be used to help support the bridge. Without the trusses, the bridge can’t be completed; in fact, the bridge might not stand without them. The trusses, in this case, are critical success factors. Not all deliverables are necessarily critical success factors, but many of them will fall into this category and should be documented as such.

Documenting All the Deliverables and Requirements

One of the project manager’s primary functions is to accurately document the deliverables and requirements of the project and then manage the project so that they are produced according to the agreed‐upon criteria. Deliverables describe the components of the goals and objectives in a quantifiable way. Requirements are the specifications of the deliverables. (Remember for the exam that requirements are documented in the Collect Requirements process that occurs before the Define Scope process.)

The project manager should use the project charter as a starting point for identifying and progressively elaborating project deliverables, but it’s possible that only some of

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Writing the Project Scope Statement 121

the deliverables will be documented there. Remember that the charter was signed by a manager external to the project, and it was the first take at defining the project objectives and deliverables. As the project manager, it’s your job to make certain all the deliverables are identified and documented in the project scope statement. That’s because the scope statement (not the project charter) serves as the agreement among stakeholders— including the customer of the project—regarding what deliverables will be produced to meet and satisfy the business needs of the project.

Interview the stakeholders, other project managers, project team members, customers, management staff, industry experts, and any other experts who can help you identify all the deliverables of the project. Depending on the size of the project, you might be able to accomplish this in a group setting using simple brainstorming techniques, but large complex projects might have scope statements for each deliverable of the project. Remember that the project scope statement is progressively elaborated into finer detail and is used later to help decompose the work of the project into smaller tasks and activities.

Project exclusions Project exclusions are, as you’d guess, anything that isn’t included as a deliverable or work of the project. You’ll want to note the project exclusions in the project scope statement so that you can continue to manage stakeholder expectations throughout the project.

Project constraints Constraints are anything that either restricts the actions of the project team or dictates the actions of the project team. Constraints put you in a box. (I hope you’re not claustrophobic.) As a project manager, you have to manage to the project constraints, which sometimes requires creativity.

In my organization—and I’m sure the same is true in yours—we have far more project requests than we have resources to work on them. In this case, resources are a constraint. You’ll find that a similar phenomenon occurs on individual projects as well. Almost every project you’ll encounter must work within the triple constraint combination of scope, time, and cost. The quality of the project (or the outcomes of the project) is affected by how well these three constraints are managed. Usually, one or two triple constraints apply (and sometimes all three), which restricts the actions of the project team. You might work on projects where you have an almost unlimited budget (don’t we wish!) but time is the limitation. For example, if the president mandated that NASA put an astronaut on Mars by the end of 2020, you’d have a time‐constrained project on your hands.

Other projects might present the opposite scenario. You have all the time you need to complete the project, but the budget is fixed. Still other projects might incorporate two or more of the project constraints. Government agencies are notorious for starting projects that have at least two and sometimes all three constraints. For example, new tax laws are passed that impact the computer programs, requiring new programs to calculate and track the tax changes. Typically, a due date is given when the tax law takes effect, and

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

122 Chapter 3 ■ Developing the Project Scope Statement

the organization responsible is required to implement the changes with no additions to budget or staff. In other words, they are told to use existing resources to accomplish the objectives of the project, and the specific requirements, or scope, of the project are such that they cannot be changed to try to meet the time deadline.

As a project manager, one of your biggest jobs is to balance the project constraints while meeting the expectations of your stakeholders. In most projects, you usually will have to balance only one or two of the triple constraints. For example, if one of the project objectives is to complete the project by the end of the year and stay within a certain budget, you will need to balance the other two triple constraints: time and cost. As the saying goes, “I can give it to you fast or I can give it to you cheap, but I can’t give it to you fast and cheap.”

Constraints can take on many forms and aren’t limited to time, cost, and scope. Anything that impedes your project team’s ability to perform the work of the project or specifically dictates the way the project should be performed is considered a constraint. Constraints can come from inside or outside the project or organization. Let’s say to fulfill some of the deliverables of your project you’ll have to purchase a large amount of materials and equipment. Procurement processes may be so cumbersome that ordering supplies for a project adds months to the project schedule. The procurement process itself becomes a constraint because of the methods and procedures you’re required to use to get the materials.

You’re likely to encounter the following constraints on your future projects:

Time Constraints As I said, time can be a project constraint. This usually comes in the form of an enforced deadline, commonly known as the “make it happen now” scenario. If you are in charge of the company’s holiday bash scheduled for December 10, your project is time constrained. Once the invitations are out and the hall has been rented, you can’t move the date. All activities on this project are driven by the due date.

Budget Constraints Budgets, or cost, are another element of the classic triple constraint. Budgets limit the project team’s ability to obtain resources and might potentially limit the scope of the project. For example, component X cannot be part of this project because the budget doesn’t support it.

Scope Constraints Scope is the third element of the original triple constraints. Scope defines the deliverables of the project, and you may have situations where scope is predefined by your project sponsor. Alternatively, sometimes budget constraints will impact the scope of the project and require you to cut back on the deliverables originally planned.

Quality Constraints Quality constraints typically are restricted by the specifications of the product or service. The specifications for those 3" widgets we talked about earlier could be considered a quality constraint. Most of the time, if quality is a constraint, one of the other constraints—time or budget—has to have some give. You can’t produce high quality on a restricted budget and within a tightly restricted time schedule. Of course, there are exceptions—but only in the movies.

Schedule Constraints Schedule constraints can cause interesting dilemmas for the project manager. For example, say you’re the project manager in charge of building a new football stadium in your city. The construction of the stadium will require the use of cranes—and

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Writing the Project Scope Statement 123

crane operators—at certain times during the project. If crane operators are not available when your schedule calls for them, you’ll have to make schedule adjustments so that the crane operators can come in at the right time.

Resource Constraints Resources could be a constraint from a few different perspectives, including availability of key resources both internally and in the marketplace, skill levels, and personality. You may also have availability issues or quality problems with nonhuman resources, like materials and goods. Human resources constraints are something I deal with on every project.

Technology Constraints Technology is marvelous. In fact, how did humans survive prior to the invention of computers and cell phones? However, it can also be a project constraint. For example, your project might require the use of new technology that is still so new it hasn’t been released on a wide‐scale basis or hasn’t been adequately tested to determine stability in production. One impact might be that the project will take an additional six months until the new technology is ready and tested.

Directive Constraints Directives from management can be constraints as well. Your department might have specific policies that management requires for the type of work you’re about to undertake. This might add time to the project, so you must consider those policies when identifying project constraints. When you’re performing work on contract, the provisions of the contract can be constraints.

Constraints, particularly the classic triple constraints, can be used to help drive out the objectives and requirements of the project. If it’s difficult to discern which constraint is the primary constraint, ask the project sponsor something like this: “Ms. Sponsor, if you could have only one of these two alternatives, which would you choose? The project is delivered on the date you’ve stated, or we don’t spend one penny more than the approved budget.” If Ms. Sponsor replies with the date response, you know your primary constraint is time. If push comes to shove during the project Planning processes for this project, the budget might have to give because time cannot.

You’ll want to understand what the primary constraint is on the project. If you assume the primary constraint is budget when in actuality the primary constraint is time, in the immortal words of two‐year‐olds worldwide, “Uh‐oh.” Understanding the constraints and which one carries the most importance will help you later in the project Planning process group with details such as scope planning, scheduling, estimating, and project management plan development. That’s assuming your project gets to the project Planning processes, which brings me to the next topic: project assumptions.

Project assumptions You’ve probably heard the old saying about the word assume, something about what it makes out of “u” and “me.” In the case of project management, however, throw this old saying out the window, because it’s not true.

Assumptions, for the purposes of project management, are things you believe to be true. For example, if you’re working on a large construction project, you might make assumptions about the availability of materials. You might assume that concrete,

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

124 Chapter 3 ■ Developing the Project Scope Statement

lumber, drywall, and so on are widely available and reasonably priced. You might also assume that finding contract labor is either easy or difficult, depending on the economic times and the availability of labor in your locale. Each project will have its own set of assumptions, and the assumptions should be identified, documented, and updated throughout the project.

It’s essential to understand and document the assumptions you’re making, and the assumptions your stakeholders are making, about the project. It’s also important to find out as many of the assumptions as you can up front. Projects can fail, sometimes after lots of progress has been made, because an important assumption was forgotten or the assumption was incorrect. Defining new assumptions and refining old ones are forms of progressive elaboration.

Let’s say you make plans to meet your buddy for lunch at 11:30 on Friday at your favorite spot. When Friday rolls around, you assume he’s going to show up, barring any catastrophes between the office and the restaurant. Project assumptions work the same way. For planning purposes, you presume the event or thing you’ve made the assumptions about is true, real, or certain. You might assume that key resources will be available when needed on the project. Document that assumption. If Sandy is the one and only resource who can perform a specific task at a certain point in the project, document your assumption that Sandy will be available and run it by her manager. If Sandy happens to be on a plane for Helsinki at the time you thought she was going to be working on the project, you could have a real problem on your hands.

Other assumptions could be factors such as vendor delivery times, product availability, contractor availability, the accuracy of the project plan, the assumption that key project members will perform adequately, contract signing dates, project start dates, and project phase start dates. This is not an exhaustive list, but it should get you thinking in the right direction. As you interview your stakeholders, ask them about their assumptions and add them to your list. Use brainstorming exercises with your team and other project participants to come up with additional assumptions.

Think about some of the factors you usually take for granted when you’re trying to identify assumptions. Many times they’re the elements everyone expects will be available or will behave in a specific way. Think about factors such as key team members’ availability, access to information, access to equipment, management support, and vendor reliability.

Try to validate your assumptions whenever possible. When discussing assumptions with vendors, make them put those assumptions in writing. In fact, if the services or goods you’re expecting to be delivered by your suppliers are critical to the project, include a clause in the contract to assure a contingency plan in case your suppliers fail to perform. For example, if you’re expecting 200 computers to be delivered, configured, and installed by a certain date, require the vendor to pay the cost of rental equipment in the event the vendor can’t deliver on the promised due date.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Writing the Project Scope Statement 125

Remember, when assumptions are incorrect or not documented, it could cause problems partway through the project and might even be a project killer.

approving and Publishing the Project scope statement Just like the project charter, the project scope statement should be approved, agreed upon, published, and distributed to the stakeholders, key management personnel, and project team members. This isn’t an official output of this process, nor is it noted in the PMBOK® Guide. You can accomplish this with a formal sign‐off procedure that’s documented as part of the approval requirements section of the scope statement. When stakeholders sign off and agree to the scope statement, they’re agreeing to the deliverables and requirements of the project. As with the project charter, their agreement and endorsement of the project requirements and deliverables will likely sustain their participation and cooperation throughout the rest of the project. That doesn’t mean they’ll agree to everything as the project progresses, but it does mean the stakeholders are informed and will likely remain active project participants.

updating the Project documents The last output of this process is project documents updates. When you’re in the midst of defining deliverables, you’ll often find that changes to the original project objectives, requirements, or stakeholder register will occur. This may require updates to the stakeholder register, the requirements documentation, and requirements traceability matrix. Changes to scope may also occur later in the project. When the changes are approved, you’ll need to update the scope statement and notify stakeholders that changes have been made.

Mountain Streams Services

Maria Sanchez is the CEO of Mountain Streams Services. She recently accepted a prestigious industry award on behalf of the company. Maria knows that without the dedication and support of her employees, Mountain Streams Services wouldn’t have achieved this great milestone.

Maria wants to host a reception for the employees and their guests in recognition of all their hard work and contributions to the company. Maria has appointed you to arrange the reception.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

126 Chapter 3 ■ Developing the Project Scope Statement

The reception is scheduled for April 12, and Maria has given you a budget of $125 per person. The company employs 200 people. The reception should be semiformal.

You’ve documented the deliverables as follows:

■ Location selection

■ Food and beverage menu

■ Invitations

■ Entertainment

■ Insurance coverage

■ Decorations

■ Photographer

■ Agenda

In addition to the deliverables, you want to go over the following requirements with Maria to be certain you are both in agreement:

■ The location should be in the downtown area.

■ Employees are encouraged to bring one guest but no children.

■ There will be an open bar paid for by Maria.

■ The agenda will include a speech by Maria, followed by the distribution of bonus checks to every employee. This is to be kept secret until the reception.

■ The decorations should include gold‐trimmed fountain pens with the company logo at every place setting for the attendees to keep.

Once you’ve documented all the particulars, you ask to speak with Maria to go over this project scope statement and get her approval before proceeding with the project.

Creating the Work Breakdown Structure Have you ever mapped out a family tree? In the Create WBS process, you’ll construct something like it called a work breakdown structure (WBS). It maps the deliverables of the project with subdeliverables and other components stemming from each major deliverable in a tree or chart format. Simply put, a WBS is a deliverable‐oriented hierarchy that defines and organizes the entire scope of work of the project and only the work of the project. The items defined on the WBS come from the approved scope statement. Like the scope statement, the WBS serves as a foundational agreement among the stakeholders and project team members regarding project scope.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Creating the Work Breakdown Structure 127

Exam Spotlight

Subdividing deliverables into smaller components is the purpose of the Create WBS process. The PMBOK® Guide calls this decomposition, which is also a tool and technique of this process.

The WBS will be used throughout many of the remaining Planning processes and is an important part of project planning. As you probably have concluded, everything you’ve done so far builds on the previous step. The project charter, requirements documentation, and project scope statement outline the project objectives, requirements, and deliverables. Now you’ll use that comprehensive list of requirements and deliverables to build the framework of the WBS.

I can’t stress enough the importance of the work you’ve done up to this point. Your WBS will be only as accurate as your list of requirements and deliverables. The deliverables will become the groupings that will form the higher levels of the WBS from which activities will be derived later in the Planning processes.

The WBS should detail the full scope of work needed to complete the project. This breakdown will smooth the way for estimating project cost and time, scheduling resources, and determining quality controls later in the Planning processes. Project progress will be based on the estimates and measurements assigned to the WBS segments. So, again, accuracy and completeness are required when composing your WBS.

Before you begin constructing the WBS, you’ll need to gather and review some important project documents. You’ll look at those next.

gathering the wBs inputs The inputs to the Create WBS process aren’t new. They are as follows:

■ Scope management plan

■ Project scope statement

■ Requirements documentation

■ Enterprise environmental factors

■ Organizational process assets

The scope management plan outlines how you will create the WBS from the elements listed in the scope statement, and it also describes how to obtain approval for and maintain the WBS. The important aspect to note about the inputs to this process is that the approved project scope statement is the document you will use to define and organize the work of

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

128 Chapter 3 ■ Developing the Project Scope Statement

the project in the WBS. Make certain you’re using the most current version of the scope statement. Also note that the WBS, just like the project scope statement, contains the work of the project and only the work of the project.

decomposing the deliverables The Create WBS process consists of two tools and techniques, decomposition and expert judgment. Decomposition involves breaking down the deliverables into smaller, more manageable components of work. The idea here is to break down the deliverables to a point where you can easily plan, execute, monitor and control, and close out the project deliverables. Decomposition typically pertains to breaking deliverables down into smaller deliverables, or component deliverables, where each level of the WBS (or each level of decomposition) is a more detailed definition of the level above it.

This breaking‐down or decomposing process will accomplish several tasks for you, one of which is improving estimates. It’s easier to estimate the costs, time, and resources needed for individual work components than it is to estimate them for a whole body of work or deliverable. Using smaller components also makes it easier to assign performance measures and controls. These give you a baseline to compare against throughout the project or phase. Finally, assigning resources and responsibility for the components of work makes better sense because several resources with different skills might be needed to complete one deliverable. Breaking them down assures that an assignment, and the responsibility for that assignment, goes to the proper parties.

According to the PMBOK® Guide, decomposition is a five‐step process:

1. Identify the deliverables and work. This step involves identifying all the major project deliverables and related work. You can use the expert judgment technique to analyze the project scope statement and identify the major deliverables.

2. Organize the WBS. This step involves organizing the work of the project and determining the WBS structure. (I’ll talk more about constructing the WBS in the next section.)

3. Decompose the WBS components into lower‐level components. WBS components, like the deliverables and requirements, should be defined in tangible, verifiable terms so that performance and successful completion (or delivery) are easily measured and verified. Each component must clearly describe the product, service, or result in verifiable terms, and it must be assigned to a unit in the organization that will take responsibility for completing the work and making certain of its accuracy.

4. Assign identification codes. This step is a process where you assign identification codes or numbers to each of the WBS components.

I’ll talk more about the process in step 4 later in this chapter in the section “Understanding the Unique WBS Identifiers.”

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Creating the Work Breakdown Structure 129

5. Verify the WBS. This step is a verification step. Examine the decomposition to determine whether all the components are clear and complete. Determine whether each component listed is absolutely necessary to fulfill the requirements of the deliverable, and verify that the decomposition is sufficient to describe the work.

Of course you won’t perform this process alone. That’s where the expert judgment tool and technique comes into play. You’ll work with others such as team members, stakeholders, other experts with specific training or industry knowledge, those who have worked on similar projects in the past, and industry aids such as templates.

You can now plug the components you and the team have identified into the WBS. This all sounds like a lot of work. I won’t kid you—it is, but it’s essential to project success. If you don’t perform the WBS process adequately and accurately, you might end up setting yourself up for a failed project at worst or for lots of project changes, delayed schedules, and increased costs at best—not to mention all those team members who’ll throw up their hands when you return to them for the third or fourth time to ask that they redo work they’ve already completed. I know you won’t let this happen, so let’s move on to constructing the WBS.

The Create WBS process has several outputs, one of which is the WBS. You’ll look at the specifics of how to create the WBS next.

constructing the wBs There is no “right” way to construct a WBS. In practice, the chart structure is used quite often. (This structure resembles an organization chart with different levels of detail.) But a WBS could be composed in outline form as well. The choice is yours. You’ll look at a couple of ways shortly, along with some figures that depict the different levels of a WBS.

According to the PMBOK® Guide, you can organize the WBS in several ways:

Major Deliverables and Subprojects The major deliverables of the project are used as the first level of decomposition in this structure. If you’re opening a new store, for example, the deliverables might include determining location, store build‐out, furnishings, product, and so on. I’ll talk about subprojects next.

Subproject That May Be Executed Outside the Project Team Another way to organize the work is by subprojects. Perhaps you’re expanding an existing highway and several subprojects are involved. Some of your first level of decomposition might include these subprojects: demolition, design, bridgework, and paving. Each of the subproject managers will develop a WBS for their subproject that details the work required for that deliverable. When subproject work is involved, oftentimes the subproject work is contracted out. In this example, if you contracted out the bridgework deliverable, this subproject requires its own WBS, which the seller (the bridgework subcontractor) is responsible for creating as part of the contract and contract work.

Project Phases Many projects are structured or organized by project phases. For example, let’s say you work in the construction industry. The project phases used in your industry might include project initiation, planning, designing, building, inspection, and turnover. A

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

130 Chapter 3 ■ Developing the Project Scope Statement

feasibility study might be a deliverable under the project initiation phase, blueprints might be a deliverable under the planning phase, and so on. Each phase listed here would be the first level of decomposition (that is, the first level of the WBS); their deliverables would be the next level, and so on.

We’ll take a look at some example WBS structures next.

understanding the various wBs levels Although the project manager is free to determine the number of levels in the WBS based on the complexity of the project, all WBS structures start with the project itself. Some WBS structures show the project as level one. Others show the level under the project, or the first level of decomposition, as level one. The PMBOK® Guide notes that level one is the project level, so I’ll follow that example here.

The first level of decomposition might be the deliverables, phases, or subprojects, as I talked about earlier. (Remember that the first level of decomposition is actually the second level of the WBS because the project level is the first level.) The levels that follow show more and more detail and might include more deliverables followed by requirements. Each of these breakouts is called a level in the WBS. The lowest level of any WBS is called the work package level. The goal is to construct the WBS to the work package level where you can easily and reliably estimate cost and schedule dates. Keep in mind that not all of the deliverables may need the same amount of decomposition. Also realize that performing too much decomposition can be as unproductive as not decomposing enough. My rule of thumb is, when the work outlined in the work package level is easily understood by team members and can be completed within a reasonable length of time, you’ve decomposed enough. If you decompose to the point where work packages are describing individual activities associated with higher‐level elements, you’ve gone too far.

Exam Spotlight

Remember that each descending level of the WBS is a more detailed description of the project deliverables than the level above it. Each component of the WBS should be defined clearly and completely and should describe how the work of the project will be performed and controlled. Collectively, all the levels of the WBS roll up to the top so that all the work of the project is captured (and no additional work is added). According to the PMBOK® Guide, this is known as the 100‐percent rule.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Creating the Work Breakdown Structure 131

There is some controversy among project managers over whether activities should be listed on the WBS. In practice, I often include activities on my work breakdown structure for small projects only because it facilitates other Planning processes later. In this case, the activities are the work package level. However, you should realize that large, complex projects do not include activities on the WBS. For the exam, remember that you will decompose activities during the Define Activities process that I’ll talk about in Chapter 4, “Creating the Project Schedule,” and that activities are not part of the WBS.

The easiest way to describe the steps for creating a WBS is with an example. Let’s suppose you work for a software company that publishes children’s games. You’re the project manager for the new Billy Bob’s Bassoon game, which teaches children about music, musical rhythm, and beginning sight reading. The first box on the WBS is the project name; it appears at the top of the WBS, as shown in Figure 3.1, and is defined as WBS level one.

F i gu R E 3 .1 WBS levels one and two

Billy Bob's Bassoon

Requirements De�nition

Design Speci�cations

Program Modules

WBS Level Two

WBS Level One

The next level is the first level of decomposition and should describe the major deliverables for the project. In this example, some of the deliverables might be requirements definition, design specifications, and programming. This isn’t an exhaustive list of deliverables; in practice, you would go on to place all of your major deliverables into the WBS as level‐two content. For illustration purposes, just look at a slice of the WBS for this project. Refer to Figure 3.1 to see the WBS with level‐one and level‐two detail added.

Level‐three content might be the component deliverables that are further broken out from the major deliverables of level two, or it might be the products or results that contribute to the deliverable. The Billy Bob’s Bassoon example shows further deliverables as level‐three content. See Figure 3.2 for an illustration of the WBS so far.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

132 Chapter 3 ■ Developing the Project Scope Statement

F i gu R E 3 . 2 WBS levels one, two, and three

Billy Bob's Bassoon

Requirements De�nition

Game Requirements

Software Requirements

Software Design

Hardware Design

Code Requirements

Testing Requirements

Design Speci�cations

Program Modules

WBS Level Two

WBS Level One

WBS Level Three

Large, complex projects are often composed of several subprojects that collectively make up the main project. The WBS for a project such as the Billy Bob’s Bassoon game would show the subprojects as level‐one detail. These subprojects’ major deliverables would then be listed as level‐two content, perhaps more deliverables as level three, and so on.

The goal here is to eventually break the work out to the point where the responsibility and accountability for each work package can be assigned to an organizational unit or a team of people. In Figure 3.3, I’ve decomposed this WBS to the fourth level to show an even finer level of deliverable detail. Remember that activities are not usually included in the WBS. An easy way to differentiate between deliverables and activities is to use nouns as the deliverable descriptors and verbs as activity descriptors (we’ll talk about activities in Chapter 4). Reaching way back to my grade‐school English, I recall that a noun is a person, place, or thing. In this example, the deliverables are described using nouns. When we get to the activity list, you might use verbs like define, design, and determine to describe them.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Creating the Work Breakdown Structure 133

F i gu R E 3 . 3 WBS levels one, two, three, and four

Character Definition

Instruments Design

Platform

System Description

Screen Design

Use Case Design

Speaker Design

Case Design

Module 1 Design

Module 1 Development

Unit Test Design

System Test Design

Billy Bob's Bassoon

Requirements Definition

Game Requirements

Software Requirements

Software Design

Hardware Design

Code Requirements

Testing Requirements

Design Specifications

Program Modules

WBS Level Two

WBS Level One

WBS Level Three

WBS Level Four

You can see from these illustrations how a poorly defined scope or inadequate list of deliverables will lead to a poorly constructed WBS. Not only will this make the WBS look sickly, but the project itself will suffer and might even succumb to the dreaded premature project demise. The final cost of the project will be higher than estimated, and lots of rework (translation: late nights and weekends) will be needed to account for the missing work not listed on the WBS. You can construct a good WBS and maintain a healthy project by taking the time to document all the deliverables during the Define Scope process.

WbS Templates

Work breakdown structures can be constructed using WBS templates or the WBS from a similar, completed project. Although every project is unique, many companies and industries perform the same kind of projects repeatedly. The deliverables are similar from project to project, and they generally follow a consistent path. WBS templates can be used in a case like this as a tool to simplify the WBS process, saving the project manager time.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

134 Chapter 3 ■ Developing the Project Scope Statement

Don’t get too carried away when creating a WBS. The object is to define the work of the project so you can easily plan, manage, monitor, and control the work. But you don’t want to take this too far. If you decompose the work to the point that you’re showing every minute detail, you’ve ventured into inefficiency and will find it more difficult to plan and manage. In addition, you’re potentially stifling the creativity of the people working on the project because everything is so narrowly defined.

Sometimes, particularly when working on large projects that consist of several subprojects, some of the subprojects might not be scheduled until a future date. Obviously, it makes sense to develop the WBS in detail at that future date when the deliverables and subprojects are better known and more details are available. This technique is called rolling wave planning. The idea behind this technique is that you elaborate the work of the project to the level of detail you know about at the time. If a subproject or deliverable is scheduled sometime in the future, the only component that might appear on the WBS today is the subproject itself. As you get closer to the subproject, you’ll elaborate the details of the subproject and record them on the WBS.

Exam Spotlight

Understand that rolling wave planning is a process of elaborating deliverables, project phases, or subprojects in the WBS to differing levels of decomposition depending on the expected date of the work. Work in the near term is described in more detail than work to be performed in the future.

understanding the unique wBs identifiers Each element at each level of the WBS is generally assigned a unique identifier according to the PMBOK® Guide. This unique identifier is typically a number, and it’s used to sum and track the costs, schedule, and resources associated with the WBS elements. The numbers are usually associated with the corporation’s chart of accounts, which is used to track costs by category. These codes are known as control accounts, and collectively, the control accounts are known as the code of accounts. The unique identifiers for the requirements definition branch of the WBS might look something like this:

10‐1 Billy Bob’s Bassoon

10‐2 Requirements Definition

10‐3 Game Requirements

10‐3‐1 Character Definition

10‐3‐2 Instruments Design

10‐4 Software Requirements

10‐4‐1 Platform

10‐4‐2 System Description

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Creating the Work Breakdown Structure 135

defining work Packages Work packages are the components that can be assigned to one person, or a team of people, with clear accountability and responsibility for completing the assignment, and they can be monitored and controlled throughout the project. Assignments are easily made at the work package level but can be made at any level in the WBS. The work package level is where time estimates, cost estimates, and resource estimates are determined.

As mentioned earlier, the project manager is free to determine the number of levels in the WBS based on the complexity of the project. You need to include enough levels to accurately estimate project time and costs but not so many levels that it’s difficult to distinguish between the components. Regardless of the number of levels in a WBS, the lowest level in a WBS is called the work package level.

Work package levels on large projects can represent subprojects that are further decomposed into their own work breakdown structures. They might also consist of project work that will be completed by a vendor, another organization, or another department in your organization. If you’re giving project work to another department in your organization, you’ll assign the work packages to individual managers, who will in turn break them down into activities during the Define Activities process later in the Planning process group.

Work packages might be assigned to vendors or others external to the organization. For example, perhaps one of the deliverables in your project is special packaging and a vendor is responsible for completing this work. The vendor will likely treat this deliverable as a project within its own organization and construct its own WBS with several levels of decomposition. However, for your project, it’s a deliverable listed at the work package level of the WBS.

This might seem self‐evident, but work packages not shown on the WBS are not included in the project. The same holds true for the project scope statement—if the deliverable isn’t noted there, it isn’t part of the project.

The lincoln Street Office building

Flagship International has just purchased a new building to house its growing staff. The folks at Flagship consider themselves very lucky to have won the bid on the property located in a prime section of the downtown area. The building is a historic building and is in need of some repairs and upgrades to make it suitable for office space. Constructing the renovations will require special handling and care, as outlined in the Historical Society Building Revisions Guide.

Alfredo Martini is the project manager assigned to the renovation project. Alfredo has already determined the deliverables for this project. In so doing, he has discovered

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

136 Chapter 3 ■ Developing the Project Scope Statement

that he will not be able to manage all the work himself. He will need several subproject managers working on individual deliverables, all reporting to him. Alfredo calls a meeting with the other project managers to develop the WBS. Let’s eavesdrop on the meeting.

“As you all know, we’re planning to move into the Lincoln Street building by November 1. There is quite a bit of work to do between now and then, and I’m enlisting each of you to manage a segment of this project. Take a look at this WBS.”

Here’s how a portion of the WBS that Alfredo constructed looks.

Lincoln Street Building Renovation

2.0 Facility Safety

2.1 Sprinkler System

2.2 Elevators

2.3 Emergency Evacuation Plans

3.0 Asbestos Abatement

3.1 Inspection and Identification

3.2 Plans for Removal

4.0 Office Space

4.1 Building Floor Plans

4.2 Plans for Office Space Allocation

4.3 Plans for Break Room Facilities

4.4 Plans for Employee Workout Room

Alfredo continues, “I’m going to manage the Facility Safety project. Adrian, I’d like you to take the Asbestos Abatement project, and Orlando, you’re responsible for the Office Space project.”

“Alfredo,” Adrian says, “asbestos abatement is going to take contractors and specialized equipment. We don’t have staff to do these tasks.”

“I understand. You’ll need to take charge of securing the contractor to handle this. Your responsibility will be to manage the contractor and keep them on schedule,” Alfredo answers.

Orlando reminds Alfredo that he has missed a deliverable on the WBS. “Part of the Office Space project needs to include the network communications and telecommunications equipment rooms. I don’t see that on here.”

“Good point, Orlando,” Alfredo says. “The level‐two and level‐three elements of this WBS are not complete. Each of you has been assigned to the subproject level, level one. Your first assignment is to meet back here in two weeks with a WBS for your subproject. I’d like to see some ideas about the staff assignments you’d make at the work package level and how long you think these components will take. We’ll refine those after we meet next.”

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Creating the Work Breakdown Structure 137

creating wBs Process outputs The Create WBS process has two outputs: the scope baseline and project documents updates. We’ll look at both of these next.

scope Baseline Remember how I said that everything you’ve done so far has built upon itself? This is an important concept you should know for this output. The scope baseline for the project is the approved project scope statement, the WBS, and the WBS dictionary. (You’ll recall from Chapter 2 that the project scope statement serves as a baseline for future project decisions because it helps the team determine whether requested changes are inside or outside of scope.) In other words, these documents together describe in detail all the work of the project. From these documents, you’ll develop schedules, assign resources, and monitor and control the work of the project according to what’s described here. We’ve already talked about the project scope statement and the WBS, but let’s look at the WBS dictionary.

Exam Spotlight

The scope baseline is defined as the approved version of the detailed project scope state- ment, the WBS, and the WBS dictionary. Understand this concept for the exam. This process does not name the WBS as an output; the WBS is included as part of the scope baseline output.

wBs dictionary

The WBS dictionary, an element of the scope baseline, is where work component descriptions listed on the WBS are documented. According to the PMBOK® Guide, the WBS dictionary should include the following elements for each component of the WBS:

■ Code of accounts identifier

■ Description of the work of the component

■ Organization responsible for completing the component

■ List of schedule milestones

■ Schedule activities associated with the schedule milestones

■ Required resources

■ Cost estimates

■ Quality requirements

■ Criteria for acceptance

■ Technical references

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

138 Chapter 3 ■ Developing the Project Scope Statement

■ Contract or agreements information

■ Constraints and assumptions

Let’s look at an example of what some of the elements of a WBS dictionary entry might look like. You’ll use the work package level called Inspection and Identification defined in the sidebar “The Lincoln Street Office Building” earlier. The WBS dictionary entry for this might look like the following:

3.1 Inspection and Identification

Description of work—Inspect the building for asbestos, and identify all areas where it’s found. Update the plan for removal (WBS 2.2) with each location identified.

Responsible organization—Adrian in facilities will hire and oversee a contractor to perform this work.

Schedule milestones—Inspection and identification to start after contractor is identified and hired (no later than July 1). Work should be completed no later than September 15.

Contract information—Two contractors have been identified as qualified and experienced in this type of work. Contract process should close no later than June 12.

If the WBS and the WBS dictionary are constructed well, you’ve given yourself a huge helping hand with the remaining Planning processes. The completion of many of the remaining processes depends on the project scope statement and WBS being accurate and complete. You’ll use the work packages created here to further elaborate the work into activities. From there, you can estimate costs, develop schedules, and so on. The WBS is an essential tool for project planning, so keep it handy.

Project documents updates Project documents updates might include updates to the requirements document, which can come about as a result of changes that occur when you’re creating the WBS. You can see from the examples you’ve walked through in this chapter how new deliverables or requirements might surface as a result of working on the WBS. These requested changes should be reviewed and either approved or denied using your change control processes. The approved changes will likely change the project scope statement, the project management plan, and other project documents. These documents should be updated to reflect the approved changes.

I recommend reviewing Practice Standard for Work Breakdown Structures, Second Edition, published by PMI, to see examples of industry‐specific WBS templates, or you can modify the templates for particular business areas that may not be represented.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Creating the Work Breakdown Structure 139

Project Case Study: New Kitchen Heaven Retail Store

The project charter kickoff meeting was held and well attended. You’re ready to start gathering requirements and writing the project scope statement, and you have a question or two for Dirk. You knock on his door, and he invites you in.

“Shoot,” he says.

“I’m ready to define the deliverables and requirements for this project. I want to make sure I get the right folks involved in the meeting. Who are key stakeholders you recommend I speak with?”

“I can think of a few people right off that you don’t want to miss. There’s Jake Peterson over in facilities. He’s in charge of store furnishings, shelving, things like that—any supplies for the stores that aren’t retail products. He can help out with store build‐outs too. He supervised our last eight stores and did a terrific job.”

“Anyone else?” you ask.

“You should also talk to Jill Overstreet, the director in charge of retail products. She can help with the initial store stocking, and once the store is open, her group will take over the ongoing operations. All the district managers report to Jill.”

You thank Dirk and tell him you’re going to contact Jake and Jill and set up a brainstorming session to determine requirements.

A few days later.

You review your notes and reread the first draft of the project scope statement you’ve prepared for the Kitchen Heaven retail store before looking for Dirk. After your meetings with the stakeholders, you were better able to refine the project objectives and deliverables.

“Dirk, I’m glad I caught you. I’d like to go over the project scope statement with you before I give it to the stakeholders. Do you have a few minutes?”

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

“The project objective is to open the 50th Kitchen Heaven store in Colorado Springs by February 1. When I met with Jake, he confirmed it takes 120 days to do the store build‐ out. That includes having the shelves set up and in place, ready to stock with inventory.”

Dirk asks whether Jake told you about his store location idea.

“Yes, Jake gave me a contact name of the leasing agent, and I’ve left her a voicemail. The sooner we can get that lease signed, the better. It takes Jake 120 days to do the build‐out, and Jill said she needs two weeks lead time to order the initial inventory and stock the shelves. That puts us pretty close to our February 1 deadline, counting the time to get the lease papers signed.”

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

140 Chapter 3 ■ Developing the Project Scope Statement

“Sounds good so far,” Dirk replies. “What else?”

You continue, “I’ve included an updated description of the products and services the new store will offer, based on the documentation that was written from the last store opening. Jill reviewed the updates to the description, so we should be in the clear there. The store will include some new lines that we’ve decided to take on—cookware from famous chefs, that kind of thing.

“Jake has already made contact with a general contractor in Colorado Springs, and he is ready to roll once we’ve signed the lease.

“One more thing, Dirk. Since we’re including the big bash at the grand opening as part of the deliverables, I talked to some of your folks in marketing to get some ideas. They are thinking we should have some great giveaways as door prizes and that we will want the food catered. They also thought having some live cooking demonstrations with some local chefs would be a good attraction.”

“Sounds like you’re on the right track. So, what’s next?” Dirk asks.

“Once you approve the scope statement, I’d like to send a copy to the stakeholders. My next step is to break down the deliverables and requirements I’ve documented here into the WBS so we can get rolling on the work of the project.”

Project Case Study Checklist

The main topics discussed in the case study are as follows:

stakeholder analysis for requirements gathering: Jake Peterson and Jill Overstreet interviewed. Needs, wants, and expectations recorded and requirements prioritized.

organizational structure: Functional organization with a separate projectized department.

constraints: February 1 date to coincide with Garden and Home show.

assumptions: These are the assumptions:

■ A store build‐out usually takes 120 days.

■ Jill Overstreet will help with the initial store stocking.

■ Jake Peterson will provide supplies for the stores that aren’t retail products, such as store furnishings, shelving, and so on, and can help with the store build‐out as well.

■ The budget for the project will be between $1.5 and $2 million.

The project scope statement includes the following:

Project objectives: Open 50th store by February 1 in Colorado Springs.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Understanding How This Applies to Your Next Project 141

Project deliverables:

■ Build out storefront, including shelving.

■ Retail product line will be delivered two weeks prior to grand opening.

■ Have grand‐opening party with cooking demos.

Project requirements:

■ Sign lease within 14 days.

■ Offer new line of gourmet food products.

■ Have classroom space in back of store for cooking demos and classes.

constraints: February 1 date will coincide with Garden and Home Show.

fund limitations: Spend no more than $2 million on the project.

assumptions: (These are the same as listed earlier.) Decomposed deliverables into a WBS.

The WBS includes the following:

■ Level one is the project.

■ Level two is subprojects or deliverables.

■ Level three is deliverables.

■ Last level of WBS is the work package level, where time and cost estimates can be defined in the next process.

Understanding How This Applies to Your Next Project In this chapter, you dealt with the realities of life on the job. The reality is, many project managers I know are managing several projects at once as opposed to one large project. Although every concept presented in this chapter is a sound one, it’s important to note that you have to balance the amount of effort you’ll put into project management processes against the size and complexity of the project.

As a manager who prides herself and her team on excellent customer service, I have once or twice gotten my team into precarious situations because I was so focused on helping the customer that I hurt them and our department in the process. If you’re wondering how that happened, it was because we didn’t take the time to document the scope of the project and the final acceptance criteria. In one case, in the interest of getting the project completed quickly because of our customer’s own internal deadlines, we decided the project was straightforward enough that we didn’t need to document deliverables.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

142 Chapter 3 ■ Developing the Project Scope Statement

The customer promised to work side by side with us as we produced the work of the project. Unfortunately, that wasn’t the case, and we didn’t meet the expectations of our customer. Further, after we did implement the project (two months behind schedule), we went through another six weeks of “fixes” because of the miscommunication between the customer and the project team on what constituted some of the features of the final product. There’s always a great reason for cutting corners—but they almost always come back to haunt you. My advice is to always create a scope statement and a requirements document and get stakeholder signatures on both. (In practice, small projects can include both the deliverables and requirements within the scope statement.)

Decomposing the deliverables is the first step toward determining resource requirements and estimates. A WBS is always a good idea, no matter the size of the project. I have to admit I have cheated a time or two on small projects and used the project schedule as the WBS. In all fairness, that worked out fine when the team was small and there weren’t more than three or four people working on the project. If you get many more than four people on the project team, it can be a little cumbersome to track deliverables with a schedule only. The WBS is the perfect tool to use to assign names to work packages, and it’s the foundation for determining estimates for the work of the project.

The five‐step process outlined by the PMBOK® Guide works very well. Starting with the 50,000‐foot view, the team determines the major deliverables of the project. From there, the deliverables are decomposed into ever smaller units of work. The trick here is to break the work down into measurable units so that you can verify the status of the work and the completion and acceptance of the work when you’re finished. If you have “fuzzy” WBS levels or work packages, you won’t be able to determine status accurately. In the information technology field, we have a saying about the status of projects: “It’s 90 percent complete.” The problem is it always seems that the last 10 percent takes twice as long to complete as the first 90 did. If you’ve taken the time to document a WBS, you’ll have a much better idea of what that 90 percent constitutes. The last step is the verification step where you determine whether everything you’ve identified in the WBS is absolutely necessary to fulfill the work of the project and whether it’s decomposed enough to adequately describe the work. It has been my experience that documenting the WBS will save you time later in the Planning processes, particularly developing the project schedule and determining the project budget.

I believe the most important idea to take from this chapter is a simple one: Always use a scope statement and requirements document, and always get them signed.

Summary This chapter started you on the road to project planning via the Develop Project Management Plan process, the Plan Scope Management process, the Collect Requirements process, the Define Scope process, and the Create WBS process. We covered a lot of material in this chapter. Everything you’ve learned so far becomes the foundation for further project planning.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Exam Essentials 143

The output of the Develop Project Management Plan process is the project management plan, which is concerned with defining, coordinating, and integrating all the ancillary project plans and baselines. The purpose of this plan is to define how the project is executed, how it’s monitored and controlled, and how it’s closed.

The primary output of the Plan Scope Management process is the scope management plan. This plan is an element of the project management plan that describes how the project team will go about defining project scope, validating the work of the project, and managing and controlling scope.

The Collect Requirements process involves gathering and documenting the requirements of the project. It’s important that requirements be measurable, traceable, testable, and so on. Measurement criteria for project requirements are agreed upon by the stakeholders and project manager. Additionally, requirements should be tracked in a traceability matrix that documents where they originated, the results of the tests, the priority of the requirement, and more.

The project scope statement is produced during the Define Scope process. It describes the project deliverables. The scope statement, along with the WBS and WBS dictionary, forms the scope baseline that you’ll use to weigh future project decisions, most particularly change requests. The scope statement contains a list of project deliverables that will be used in future Planning processes.

The project scope statement contains many elements, including product scope description, product acceptance criteria, deliverables, exclusions from scope, constraints, and assumptions.

Constraints restrict or dictate the actions of the project team. Constraints usually involve time, cost, and scope but can also include schedules, technology, quality, resources, risk, and more.

Assumptions are things believed to be true. You’ll want to document project assumptions and validate them as the project progresses.

A WBS is a deliverable‐oriented hierarchy of project essentials. The highest levels of the WBS are described using nouns, and the lowest levels are described with verbs. Each element in the WBS has its own set of objectives and deliverables that must be met in order to fulfill the deliverables of the next highest level and ultimately the project itself. In this way, the WBS validates the completeness of the work.

The lowest level of the WBS is known as the work package level. This breakdown allows the project manager to determine cost estimates, time estimates, resource assignments, and quality controls.

Exam Essentials

Be able to state the purpose of the Develop Project Management Plan process. It defines, coordinates, and integrates all subsidiary project plans.

Understand the purpose of the project scope statement. The scope statement serves as a common understanding of project scope among the stakeholders. The project objectives

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

144 Chapter 3 ■ Developing the Project Scope Statement

and deliverables and their quantifiable criteria are documented in the scope statement and are used by the project manager and the stakeholders to determine whether the project was completed successfully. It also serves as a basis for future project decisions.

Be able to define project constraints and assumptions. Project constraints limit the options of the project team and restrict their actions. Sometimes constraints dictate actions. Time, budget, and scope are the most common constraints. Assumptions are conditions that are presumed to be true or real.

Be able to describe the purpose of the scope management plan. The scope management plan has a direct influence on the project’s success and describes the process for determining project scope, facilitates creating the WBS, describes how the product or service of the project is validated and accepted, and documents how changes to scope will be handled. The scope management plan is a subsidiary plan of the project management plan.

Be able to define a WBS and its components. The WBS is a deliverable‐oriented hierarchy. It uses the deliverables from the project scope statement or similar documents and decomposes them into logical, manageable units of work. The first level of decomposition is the major deliverable level or subproject level, the second level of decomposition is a further elaboration of the deliverables, and so on. The lowest level of any WBS is called a work package.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Review Questions 145

Review Questions You can find the answers to the questions in Appendix A.

1. You are a project manager for Laredo Pioneer’s Traveling Rodeo Show. You’re heading up a project to promote a new line of souvenirs to be sold at the shows. You are getting ready to write the project management plan and know that all the following are true regarding the PMIS except for one. Which of the following is not true?

a. The PMIS is a tool and technique of this process.

B. The configuration management system is a subsystem of the PMIS.

c. The PMIS includes a change control system.

d. The PMIS is an automated system.

2. Which of the following is true?

a. You are a project manager for Laredo Pioneer’s Traveling Rodeo Show. You’re heading up a project to promote a new line of souvenirs to be sold at the shows. You’re ready to document the processes you’ll use to perform the project as well as define how the project will be executed, controlled, and closed. You are working on the project scope management plan.

B. You are a project manager for Laredo Pioneer’s Traveling Rodeo Show. You’re heading up a project to promote a new line of souvenirs to be sold at the shows. You’re ready to document the processes you’ll use to perform the project as well as define how the project will be executed, monitored, and controlled. You are working on the product scope statement.

c. You are a project manager for Laredo Pioneer’s Traveling Rodeo Show. You’re heading up a project to promote a new line of souvenirs to be sold at the shows. You’re ready to document the processes you’ll use to perform the project as well as define how the project will be executed and controlled and how changes will be monitored and controlled. You are working on the project management plan.

d. You are a project manager for Laredo Pioneer’s Traveling Rodeo Show. You’re heading up a project to promote a new line of souvenirs to be sold at the shows. You’re ready to document the processes you’ll use to perform the project as well as define how the project will be executed, controlled, and closed. You are working on the project scope statement.

3. You are a project manager responsible for the construction of a new office complex. You are taking over for a project manager who recently left the company. The prior project manager completed the scope statement and scope management plan for this project. In your interviews with some key team members, you conclude which of the following?

a. The scope statement assesses the stability of the project scope and outlines how scope will be verified and used to control changes. The team members know that project scope is measured against the product requirements and that the scope management plan is based on the approved project scope.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

146 Chapter 3 ■ Developing the Project Scope Statement

B. The scope management plan describes how project scope will be managed and controlled and how the WBS will be created and defined. They know that product scope is measured against the product requirements and that the scope management plan is based on the approved project scope.

c. The scope management plan is deliverables oriented and includes cost estimates and stakeholder needs and expectations. They understand that project scope is measured against the project management plan and that the scope management plan is based on the approved project charter.

d. The scope statement describes how the high‐level deliverables and requirements will be defined and verified. They understand that product scope is measured against the project management plan and that the scope management plan is based on the approved project charter.

4. Unanimity, majority, plurality, and dictatorship are four examples of which of the following techniques?

a. Group creativity techniques, which is a tool and technique of the Collect Requirements process

B. Interviews, which is a tool and technique of the Define Scope process

c. Facilitated workshops technique, which is a tool and technique of the Define Scope process

d. Group decision‐making techniques, which is a tool and technique of the Collect Requirements process

5. Which of the following is true regarding the project scope statement?

a. The project scope statement includes a change control system that describes how to make changes to the project scope.

B. The project scope statement further elaborates the details from the Initiating and Planning processes and serves as a basis for future project decisions.

c. The project scope statement describes how the team will define and develop the work breakdown structure.

d. The project scope statement assesses the reliability of the project scope and describes the process for verifying and accepting completed deliverables.

6. You are a project manager for an agricultural supply company. You have interviewed stakeholders and gathered requirements. Which of the following is true regarding the process to which this question refers?

a. The requirements document lists the requirements and describes how they will be analyzed, documented, and managed throughout the project.

B. Requirements documentation consist of formal, complex documents that include elements such as the business need of the project, functional requirements, nonfunctional requirements, impacts to others inside and outside the organization, and requirements assumptions and constraints.

c. The requirements documentation details the work required to create the deliverables of the project, including deliverables description, product acceptance criteria, exclusions from requirements, and requirements assumptions and constraints.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Review Questions 147

d. The requirements traceability matrix ties requirements to project objectives, business needs, WBS deliverables, product design, test strategies, and high‐level requirements and traces them through to project completion.

7. Which of the following makes up the scope baseline?

a. The approved project scope statement

B. The approved scope management plan and WBS

c. The WBS, approved project scope statement, and WBS dictionary

d. The approved scope management plan, the WBS, and the WBS dictionary

8. Which of the following statements is true regarding brainstorming and lateral thinking?

a. They are forms of expert judgment used to help define and develop requirements and develop the project scope statement.

B. They are tools and techniques used to elaborate the product scope description.

c. They are group decision‐making techniques, which are a tool and technique of the Collect Requirements process.

d. They are alternatives generation techniques, which are a tool and technique of the Define Scope process.

9. Your company, Kick That Ball Sports, has appointed you as project manager for its new Cricket product line introduction. This is a national effort, and all the retail stores across the country need to have the new products on the shelves before the media advertising blitz begins. The product line involves three new products, two of which will be introduced together and a third one that will follow within two years. You are ready to create the WBS. All of the following are true except for which one?

a. The WBS may be structured using each product as a level‐one entry.

B. The WBS should be elaborated to a level where costs and schedule are easily estimated. This is known as the work package level.

c. Rolling wave refers to how all levels of the WBS collectively roll up to reflect the work of the project and only the work of the project.

d. Each level of the WBS represents verifiable products or results.

10. You are a project manager for Giraffe Enterprises. You’ve recently taken over for a project manager who lied about his PMI® certification and was subsequently fired. Unfortunately, he did a poor job of defining the scope. Which of the following could happen if you don’t correct this?

a. The stakeholders will require overtime from the project team to keep the project on schedule.

B. The poor scope definition will adversely affect the creation of the work breakdown structure, and costs will increase.

c. The project management plan’s process for verification and acceptance of the deliverables needs to be updated as a result of the poor scope definition.

d. The project costs could increase, there might be rework, and schedule delays might result.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

148 Chapter 3 ■ Developing the Project Scope Statement

11. You are the project manager for Lucky Stars nightclubs. They specialize in live country and western band performances. Your newest project is in the Planning processes group. You are working on the WBS. The finance manager has given you a numbering system to assign to the WBS. Which of the following is true?

a. The numbering system is a unique identifier known as the WBS dictionary, which is used to assign quality control codes to the individual work elements.

B. The numbering system is a unique identifier known as the WBS dictionary, which is used to track the descriptions of individual work elements.

c. The numbering system is a unique identifier known as the code of accounts, which is used to track time and resource assignments for individual work elements.

d. The numbering system is a unique identifier known as the code of accounts, which is used to track the costs of the WBS elements.

12. You are a project manager working on a large, complex project. You’ve constructed the WBS for this project, and all of the work package levels are subprojects of this project. You’ve requested that the subproject managers report to you in three weeks with their individual WBSs constructed. Which statement is not true regarding your WBS?

a. The work package level is decomposed to create the activity list.

B. The work package level is the lowest level in the WBS.

c. The work package level facilitates resource assignments.

d. The work package level facilitates cost and time estimates.

13. You are a project manager working on a new software product your company plans to market to businesses. The project sponsor told you that the project must be completed by September 1. The company plans to demo the new software product at a trade show in late September and, therefore, needs the project completed in time for the trade show. However, the sponsor has also told you that the budget is fixed at $85,000, and it would take an act of Congress to get it increased. You must complete the project within the given time frame and budget. Which of the following is the primary constraint for this project?

a. Budget

B. Scope

c. Time

d. Quality

14. Which of the following statements about decomposition is the least true?

a. Decomposition involves structuring and organizing the WBS so that deliverables are always listed at level one.

B. Decomposition requires a degree of expert judgment and also requires close analysis of the project scope statement.

c. Decomposition is a tool and technique used to create a WBS.

d. Decomposition subdivides the major deliverables into smaller components until the work package level is reached.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Review Questions 149

15. You are in the process of translating project objectives into tangible deliverables and requirements. All of the following are techniques used in the product analysis tool and technique of the Define Scope process except which one?

a. Value engineering and value analysis

B. Product configuration and specification analysis

c. Systems analysis and systems engineering

d. Product breakdown and functional analysis

16. You are a project manager for a documentary film company. In light of a recent regional tragedy, the company president wants to produce a new documentary on the efforts of the heroic rescue teams to air as soon as possible. She’s looking to you to make this documentary the best that has ever been produced in the history of this company. She guarantees you free rein to use whatever resources you need to get this project done quickly. However, the best photographer in the company is currently working on another assignment. Which of the following is true?

a. The primary constraint is time because the president wants the film done quickly. She told you to get it to air as soon as possible.

B. Resources are the primary constraint. Even though the president has given you free rein on resource use, you assume she didn’t mean those actively assigned to projects.

c. The schedule is the primary constraint. Even though the president has given you free rein on resource use, you assume she didn’t mean those actively assigned to projects. The photographer won’t be finished for another three weeks on his current assignment, so schedule adjustments will have to be made.

d. The primary constraint is quality because the president wants this to be the best film ever produced by this company. She’s given you free rein to use whatever resources are needed to get the job done.

17. Your project depends on a key deliverable from a vendor you’ve used several times before with great success. You’re counting on the delivery to arrive on June 1. This is an example of a/an ___________________.

a. Constraint

B. Objective

c. Assumption

d. Requirement

18. What limits the options of the project team?

a. Technology

B. Constraints

c. Deliverables

d. Assumptions

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

150 Chapter 3 ■ Developing the Project Scope Statement

19. Your company provides answering services for several major catalog retailers. The number of calls coming into the service center per month has continued to increase over the past 18 months. The phone system is approaching the maximum load limits and needs to be upgraded. You’ve been assigned to head up the upgrade project. Based on the company’s experience with the vendor who worked on the last phone upgrade project, you’re confident they’ll be able to assist you with this project as well. Which of the following is true?

a. You’ve made an assumption about vendor availability and expertise. The project came about because of a business need.

B. Vendor availability and expertise are constraints. The project came about because of a business need.

c. You’ve made an assumption about vendor availability and expertise. The project came about because of a market demand.

d. Vendor availability and expertise are constraints. The project came about because of a market demand.

20. Which of the following is not a major step of decomposition?

a. Identify major deliverables.

B. Identify resources.

c. Identify components.

d. Verify correctness of decomposition.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed