 |
4
Implementing Project Integration Management
|
CERTIFICATION OBJECTIVES
What the heck is project integration management? Project integration management is the heart of project management and is made up
of the day-to-day processes the project manager relies on to ensure that all of the
parts of the project work together.
Put simply, project integration management is the way the gears of the project work
together.
Within any project are many moving parts: time management, cost management, schedule
conflicts, human resource issues, iterative planning, and much, much more. Project
integration management is the art and science of ensuring that your project moves
forward and that your plan is fully developed and properly implemented. Project integration
management requires that your project—regardless of its size and impact—meshes with
the existing operations of your organization. This knowledge area encompasses integrated
change control, too; you’ll need to manage changes that are bound to happen within
your project.
Project integration management requires finesse. As the project manager, you will
have to negotiate with stakeholders to resolve competing project objectives. This
requires organization, since you’ll have to develop, coordinate, and record your project
plan. It requires the ability to accomplish your project plan. It requires leadership,
record keeping, and political savvy, given you’ll have to deal with potential changes
throughout your project implementation. And, perhaps most importantly, it requires
flexibility and adaptability throughout the project plan execution.
In this chapter, we’ll cover the big topics you have to master to pass your PMP exam,
as well as the skills necessary to implement projects successfully out in the real
world. These topics include the following:
Developing the project charter Developing the project plan
Directing and managing the project work
Monitoring and controlling the project work
Managing integrated change control
Closing the project or the project phase
As you’ve learned already, all projects need a project plan—it’s up to the project
manager and the project team to create one. Then the project manager must work with
the project team to ensure the work is being completed as planned. Finally, the project
manager must work throughout the project to control changes across all facets of the
project. Figure 4-1 shows the complete picture of project integration management.
FIGURE 4-1 Project integration management coordinates the project from launch to close.
CERTIFICATION OBJECTIVE 4.01
Developing the Project Charter
Let’s not linger. You know what the project charter is and what it does: It authorizes
the project and allows the project manager to assign resources to the project work.
It’s all about power. The project manager is officially identified in the project
charter, though the project manager should be selected as early as possible during
the project—hopefully while the charter is being developed.
The project manager, however, doesn’t issue the project charter. Nope. The project
charter, which the PMBOK may call the “project initiator,” comes from outside of the
project. Specifically, the project charter should be issued outside the confines of
the project by any of the following:
An enterprise
A government agency
A company
A program organization
A portfolio organization
An authorized organizational representative
And the reason why a project is chartered? It can be because of opportunities, problems
that need to be solved, business requirements, and lots of other reasons. The project
manager or business analyst may create a business case that defines why a project
needs to be chartered. A business case determines whether the investment is worth
making in the project. The business case will define the project purpose and characteristics,
such as the following:
Market demand
Business need
Customer request
Technological advance
Legal requirements
Ecological impacts
Social need
Remember that the project charter does not have to come from the project sponsor.
It can come from a manager outside of the project or some other initiator. It may
work differently where you serve as a project manager, but on your exam, the charter
comes from any entity outside of the project confines that has autonomy over the resources
needed in the project.
Creating the Project Charter
The point of the charter, other than authorizing the project and the project manager,
is to launch the project officially and allow the project manager to go about the
business of getting the project work planned and then finished. The charter gives
the project a definite start and maps out the high-level objectives for the project.
The project charter needs to communicate all of the following directly or through
references to other documents:
Project purpose The charter needs to answer why the project is being launched and why it’s important
to the organization.
Project requirements for satisfaction The charter must identify what it’ll take to complete the project—in other words,
it should identify the metrics for success.
High-level requirements The charter should identify the high-level purpose of the project, the business
need the project aims to accomplish, and/ or the product requirements the project
will create.
High-level risks Any of the known risks should be referenced in the project charter.
Milestone schedule Milestones are timeless events that show the progress within a project.
Summary budget The charter should have a summary budget.
Stakeholder list The charter needs to identify the stakeholders who will influence the project.
Project approval requirements The project charter needs to state clearly what it takes for the project to be
successful and who signs off on project deliverables, project decisions, and project
completion.
Project manager The project charter defines who the project manager is and what level of power
the project manager has in the project.
Project sponsor The project charter defines who the project sponsor is; if the project sponsor
is not the person signing the project charter, it should define who is authorizing
the project (it’s almost always the project sponsor who signs the charter).
Functional organizations Functional organizations, such as departments, communities, agencies, and other
stakeholders, should be identified and their expected level of participation should
be addressed.
Contract If the project is being completed for another entity that is an external customer,
a contract is also needed. We’ll discuss contracting in detail in Chapter 12. Until then, curb your excitement.
Assumptions should be documented whenever they are used. This includes estimates,
planning, scheduling, and so on. Assumptions can be considered risks, because false
assumptions can alter the entire project.
Relying on the Project Statement of Work
The statement of work (SOW) is a summary of what the project will provide and is an
input to creating the project charter. For organizations completing an internal project,
the SOW provides the business needs of the project, the product the project must create,
or the service the project will create. For organizations that complete projects for
external customers, the SOW is typically provided by the customer to the vendor. The
vendor then responds with a proposal, quote, or bid—depending on what the customer
asked for. In either case, the SOW includes the following:
The business need for the project
The product scope description
How the project fits within the strategic plan
Document Project Agreements and Contracts
If your company is completing projects for other entities, your contract will probably
define what your company will provide for the client and what the client will pay
for the work, contribute to the work, and other terms. Your project charter may reference
the details of the contract directly, define the agreements of the contract, or just
list a memorandum of understanding. Your company might also use this approach if you’re
operating in a functional environment and completing work for other lines of service
within your business. In any case, if there’s an agreement, written or verbal, between
the project initiators and the project customer, it should be documented and referenced
as part of the project charter.
Considering Enterprise Environmental Factors
Project managers know that many things influence a project’s success; it’s not all
planning, execution, and good luck. Projects take place within organizations, and
many components of any organization can, and will, affect a project’s success. These
are enterprise environmental factors that have to be considered throughout the project
and that should be identified in the project charter. Enterprise environmental factors
include the following:
Organizational cultures and structures
Government and industry standards
Organizational infrastructures, such as facilities and equipment (or the lack thereof)
The availability of human resources and their competencies
Personnel administration
A work authorization system
Marketplace conditions
Stakeholder risk tolerances
Standardized cost estimating databases
Project management information system (PMIS)
Examining the Project Selection Criteria
Project selection methods are about resolving the unknown, predicting the likelihood
of project success, and determining the expected value of that project’s success—or
the cost of its failure. The process of selecting those projects to keep and those
to discard is based on the following two methods:
Benefit measurement methods
Constrained optimization methods
Benefit measurement methods are the most common approaches to project selection. Benefit
measurement methods are tools that allow management and key stakeholders to examine
the benefits of a project and how the project completion will contribute to the organization.
Constrained optimization methods are also tools for selecting projects, but their
approach is much more scientific and math-driven. Don’t worry—you won’t need to know
much, if anything, about constrained optimization on the PMP exam. We’ll examine both
selection types later in this chapter.
Project selection is also known as “Go/No Go decision-making.” Projects with many
variables are excellent candidates for phase gates. The project is allowed a Go decision
to the end of the first phase. Another Go/No Go decision happens at the end of each
phase based on the performance and deliverables.Meet Tracy. Tracy has a great project she’d like to see authorized. She has to “sell”
the project to management in order to have it authorized. She needs to determine what’s
so great about her project and why management should buy into it. She is looking for
project selection criteria—reasons why her project should be authorized. Following
are some possible considerations Tracy can include:
Return on investment
Realized opportunities
Market share
Customer perspective
Demand for the product
Social needs
Increased revenues
Reduced costs
Regulatory compliance
Historical Information
Has anyone ever done something like this before? Historical information is an organizational
process asset that resource project managers can use to make decisions about their
current projects. Historical information provides proven documentation of the success
or failure of performance and can be referenced for project selection criteria. For
instance, has management squelched similar projects for specific reasons? Historical
information can be referenced for comparable projects and how they performed through
to execution, as well as how the deliverables of the project performed according to
prediction.
In addition, historical information is one of the key elements in determining whether
an existing project should move forward into the next project phase. If the completed
project phase has proven successful and provided some merit or value, it’s likely
to move forward. Projects that don’t prove valuable—based on the performance of the
phase or less-than-desirable phase results—will likely be axed.
Historical information is always a key source for project information—even more important
than project team members’ opinions. Why? Because historical information is proven
and documented, and it comes from reliable sources. If you must choose, choose historical
information as a key input.
Examining Benefit Measurement Methods
The various benefit measurement methods are all about comparing values of one project
against the values of another. As you might expect, the projects with higher, positive
values typically get selected over projects with low values. The following sections
describe some common benefit measurement methods you may encounter.
Murder Boards
Murder boards are committees of folks who ask every conceivable negative question about the proposed
project. Their goal is to expose strengths and weaknesses of the project—and kill
the project if it’s deemed unworthy of organizational commitment. It’s not a pleasant
decision-making process.
Scoring Models
Scoring models (sometimes called weighted scoring models) use a common set of values for all of
the projects up for selection. For example, values can be profitability, complexity,
customer demand, and so on. Each of these values has a weight assigned to it—values
of high importance have a higher weight, while values of lesser importance have a
lower weight. The projects are measured against these values and assigned scores by
how well they match the predefined values. The projects with high scores take priority
over projects with lower scores. Figure 4-2 demonstrates the scoring model.
FIGURE 4-2 The weighted model bases project selection on predefined values.
Benefit/Cost Ratios
Just like they sound, benefit/cost ratio (BCR) models examine the cost-to-benefit ratio. For example, a typical measurement is the
cost to complete the project plus the cost of ongoing operations of the project product
compared against the expected benefits of the project. For example, consider a project
that will require $575,000 to create a new product, market the product, and provide
ongoing support for the product for one year. The expected gross return on the product,
however, is $980,000 in year one. The benefit of completing the project is greater
than the cost to create the product.
The Payback Period
How long does it take the project to “pay back” its costs? For example, the AXZ Project
will cost the organization $500,000 to create over five years. The expected cash inflow
(income) on the project deliverable, however, is $40,000 per quarter. From here, it’s
simple math: $500,000 divided by $40,000 is 12.5 quarters, or a little over three
years to recoup the expenses.
This selection method, while one of the simplest, is also the weakest. Why? The cash
inflows are not discounted against the time it takes to begin creating the cash. This
is the time value of money. The $40,000-per-quarter five years from now is worth less
than $40,000-in-your-pocket today. Remember when sodas were a quarter? It’s the same
idea. The soda hasn’t gotten better; a quarter is just worth less today than it was
way back then.
I originally said that sodas were a nickel and my editor corrected me. Whoever remembers
soda being a nickel? Gee-whiz, do I feel like an old man. The lesson learned, however,
is that time does change the value, or the perceived value, of the project’s worth.
And I’m not an old man; I was just thinking from my brother’s perspective.
See the video “Future Value and Present Value.”Considering the Discounted Cash Flow
Discounted cash flow accounts for the time value of money. If you were to borrow $100,000
from your uncle for five years, you’d be paying interest on the money, yes? (If not,
you’ve got a great uncle.) If the $100,000 were invested for five years and managed
to earn a whopping 6 percent interest per year, compounded annually, it’d be worth
$133,822.60 at the end of five years. This is the future value of the money in today’s
terms.
The magic formula for future value is FV = PV (1 + i)n, where
FV is future value
PV is present value
i is the interest rate
n is the number of time periods (years, quarters, and so on)
Here’s the formula with the $100,000 in action:
1. FV = 100,000(1 + .06)5
2. FV = 100,000(1.338226)
3. FV = 133,822.60
The future value of the $100,000 five years from now is worth $133,822.60 today. So
how does that help? Now we’ve got to calculate the discounted cash flow across all
of the projects up for selection. The discounted cash flow is really just the inverse
of the preceding formula. We’re looking for the present value of future cash flows:
PV = FV ÷ (1 + i)n.
In other words, if a project says it’ll be earning the organization $160,000 per year
in five years, that’s great. But what’s $160,000 five years from now really worth
today? This puts the amount of the cash flow in perspective with what the projections
are in today’s money. Let’s plug it into the formula and find out (assuming the interest
rate is still 6 percent):
1. PV = FV ÷ (1 + i)n
2. PV = 160,000 ÷ (1.338226)
3. PV = $119,561
So… $160,000 in five years is worth only $119,561 today. If we had four different
projects with various times to completion, costs, and we expected project cash inflows
at completion, we’d calculate the present value and choose the project with the best
PV, since it’ll likely be the best investment for the organization.
Calculating the Net Present Value
The net present value (NPV) is a somewhat complicated formula, but it allows a more precise prediction of project
value than the lump-sum approach of the PV formula. NPV evaluates the monies returned
on a project for each time period the project lasts. In other words, a project may
last five years, but there may be a return on investment in each of the five years
the project is in existence, not just at the end of the project.
For example, a retail company may be upgrading the facilities at each of its stores
to make shopping and purchasing easier for customers. The company has 1000 stores.
As each store makes the conversion to the new facility design, the project deliverables
will begin, hopefully generating cash flow as a result of the project deliverables.
(Uh, we specifically want cash inflow from the new stores, not cash outflow. That’s
some nerdy accounting humor.) The project can begin earning money when the first store
is completed with the conversion to the new facilities. The faster the project can
be completed, the sooner the organization will see a complete return on its investment.
In this example, an interest rate of 6 percent per year is assumed.
The following outlines how the NPV formula works:
1. Calculate the project’s cash flow per time unit (typically quarters or years).
2. Sum the cash flows for all time units; this yields the total cash flow.
3. Calculate the present value of each cash flow.
4. Sum the present value of each time unit; this yields the total present value.
5. Subtract the investment for the project from the total present value, this yields
the NPV.
6. Take two aspirins.
7. Examine the NPV value. An NPV greater than zero is good and the project should be
approved. An NPV less than zero is bad and the project should be rejected.
When comparing two projects, the project with the greater NPV is typically better,
although projects with high returns (PV) early in the project are better than those
with low returns early in the project. The following is an example of an NPV calculation:
I bet you’re wishing you could try some of these out for yourself, right? You’re in
luck. I’ve created for you a Microsoft Excel file called “Time Value of Money” that
has a few exercises and all of the formulas to test your work. Enjoy!Considering the Internal Rate of Return
The last benefit measurement method is the internal rate of return (IRR). The IRR is a complex formula used to calculate when the present value of the cash
inflow equals the original investment. Don’t get too lost in this formula—it’s a tricky
business, and you won’t need to know how to calculate the IRR for the exam. You will
need to know, however, that when comparing multiple projects’ IRRs, projects with
high IRRs are better choices than projects with low IRRs. This makes sense. Would
you like an investment with a high rate of return or a low rate of return?
Examining Constrained Optimization Methods
Constrained optimization methods are complex mathematical formulas and algorithms that are used to predict the success
of projects, the variables within projects, and the tendencies to move forward with
selected project investments. For the exam, thankfully, all you need to know about
these selection methods is that they are not typically used for most projects, being
instead utilized for multiphase, complex projects. The following are the major constrained
optimization methods:
Linear programming
Nonlinear programming
Integer algorithms
Dynamic programming
Multiobjective programming
Adopting a Project Plan Methodology
A project plan methodology is a structured approach to developing the project plan. Methodologies can be simple
or complex and based on the project type, the requirements of the performing organization,
or multiple inputs. Organizations can use hard or soft tools to lead the project plan
methodology. In its choice of hard tools, one organization may require that the project
team create a project plan based on a checklist of plan requirements, while another
organization may require that project teams complete a computer-based project template.
Soft tools include project meetings, business analysts to investigate and research
all facets of the problem or opportunity, and subject matter experts’ interviews of
stakeholders and project team members. A methodology used in creating the project
plan can include the following:
Project templates
Paper and electronic forms
Monte Carlo simulations for risk management
Project simulations for expected results
The design of experiments
Project startup meetings
Interviews
The point of the project plan is to communicate something to someone at some time.
When stakeholders ask questions about the project, what does the project plan say?
When project team members have questions about the project work, what does the project
plan say? The only exception to this “rule” can occur with vendor disputes. With vendor
disputes, refer to the contract, since it’s the legal document for the client-vendor
relationship.
Relying on Expert Judgment
Have you ever heard the expression, “To be successful, surround yourself with smarter
people than yourself”? That’s the idea of expert judgment. When it comes to project
selection, another tool that management (and the project manager throughout the project)
can rely on is expert judgment. Expert judgment is referenced over and over as a tool
and technique in the PMBOK. So, what is it? Expert judgment is a technique to rely
on the experts within your organization, consultants, stakeholders (including the
project customers), professional associations, or industry groups for advice. These
experts can contribute to the project selection method by offering their opinion,
research, and experience.
CERTIFICATION OBJECTIVE 4.02
Developing the Project Management Plan
The project plan is not a museum piece. You’ll use, wrinkle, update, and depend on
your project plan like a Super Bowl coach depends on the playbook. The project plan
is developed with the project team, stakeholders, and management. It is the guide
to how the project should flow and how the project will be managed, and it reflects
the values, priorities, and conditions influencing the project.
Project plan development requires an iterative process of progressive elaboration.
The project manager will revise and update the plan as research and planning reveal
more information and as the project develops. For example, an initial project plan
may describe a broad overview of what the project entails, what the desired future
state should be, and the general methods used to achieve the goals of the plan. Then,
after research, careful planning, and discovery, the project plan will develop into
a concise document that details the work involved in, and the expectations of, the
project; how the project will be controlled, measured, and managed; and how the project
should move. In addition, the project plan will contain all of the supporting details,
specify the project organization, and allow for growth in the plan through a disciplined
change control process.
The project plan guides the project manager through the execution and monitor and
control process groups. The project plan is designed to control the project. As a
whole, the point of the project plan is to communicate to the project team, stakeholders,
and management how the project will be managed and controlled. The project management
plan is the foundation and guideline for all project work.
Understanding the Project Plan’s Purpose
The project plan is more than a playbook to determine what work needs to be accomplished.
The project plan is a fluid document that will control several elements.
Provide structure The project plan is developed to provide a structure that advances the project
toward completion. It is a thorough but concise collection of documents that will
serve as a point of reference throughout the project execution, monitoring and controlling,
and project or phase closing.
Provide documentation “Noggin plans”—the kind between your ears—are not good. A documented project plan
is needed for truly successful projects. They provide a historical reference and the
reasoning for why decisions were made. A project plan must provide documentation of
the assumptions and constraints influencing the project plan development. The size
of the project, the application the project exists within, and enterprise environmental
factors can all affect the depth of detail the project management plan provides.
Provide communication Project plans are documents that provide the information, explanations, and reasoning
underlying the decisions made for the project. The project plan serves as a source
of communication among stakeholders, the project team, and management regarding how
the project plan will be controlled.
Provide baselines A project plan contains several baselines. As the project moves toward completion,
management, stakeholders, and the project manager can use the project plan to see
what was predicted as far as costs, scheduling, quality, and scope—and then see how
these predictions compare with what is being experienced.
Preparing to Develop the Project Plan
To develop the project plan effectively, the project manager and the stakeholders
must be in agreement with the project objectives. For this agreement to exist, the
project manager works with the stakeholders to negotiate a balance of expectations
and required objectives. Competing objectives is a recurring theme in project management
(and on the PMP exam). Project managers must be able to negotiate among stakeholders
for the best solution to the problem or opportunity. The project plan is created based
on the organization’s project management methodology, the nature of the work to be
implemented, and the overall scope of the project.
To develop the project management plan, you’ll need the project charter, enterprise
environmental factors, organizational process assets, and outputs from other processes.
Because the project management planning is an iterative process, you won’t know everything
as you begin the creation of the plan. Outputs from other processes, such as risk
identification, will then require you to go back to your project management plan and
update it accordingly. All of the ten knowledge areas (project integration management,
scope, time, cost, quality, human resources, communications, risk, procurement, and
stakeholder management) will have processes that contribute to the comprehensive project
management plan.
The triple constraints of project management—time, cost, and scope—provide an excellent
negotiation tool. No side of the equilateral triangle can change without affecting
the other sides. The goal is for all sides of the triangle to remain even. Want to
change the project end date to something sooner rather than later? Okay, but you’ll
have to add more resources to get it done—which means a bigger budget. Don’t have
enough cash in the old budget to complete the work? Okay, then just reduce the project
scope. This type of triangle is sometimes called the “Iron Triangle.”
Applying Tools and Techniques for Project Plan Development
All the planning is done, right? Of course not. The planning processes are iterative
and allow the project manager and the project team to revisit them as needed. But
at what point do we push back from the planning buffet and move on with a working,
feasible plan? Every project is different when it comes to planning, but a project
team will continue in the planning stage until it is knowledgeable about the project
work and has a clear vision of what needs to be done.
Figure 4-3 depicts the evolution of the planning to action process for a typical technology
project. Once the business and the functional requirements have been established through
iterations and revisions, the planning processes move into the specifics. Recall that
the business requirements establish the project vision and that the functional requirements
establish the goals for the project. The technical requirements and the design plan
shift the focus onto the specifics the project will accomplish.
FIGURE 4-3 The planning processes require documentation and a logical, systematic approach.
All of the inputs to the project plan should be readily available for the project
manager, because he or she may need to rely on this information for additional planning.
With all of the “stuff” the project manager has to work with, it should be a snap
to create the actual project plan, right? Well, not exactly. The tools and techniques
for developing the project management plan are simply expert judgment and facilitation
techniques. Expert judgment isn’t just the project manager’s job, but involves several
stakeholders: the project manager, the project team, stakeholders, and management
will work together to finalize the project plan. The contributions from each include
the following:
Project manager Leadership, facilitation, organization, direction, and expert judgment
Project team members Knowledge of the project work and time estimates; also influence the schedule,
provide advice and opinions on risk, as well as expert judgment
Customer Objectives, quality requirements, expert judgment, and some influence over budget
and schedule
Management Influence budget, resources, project management methodology, quality requirements,
and project plan approval
Facilitation techniques require the project manager to direct and control the planning
meetings use different techniques to encourage participation among the stakeholders
participating in the planning. Common facilitation techniques are brainstorming, problem-solving,
conflict resolution, and good meeting management to help the stakeholders reach a
consensus on what should be included in the project management plan.
Using a Project Management Information System
The PMBOK will repeatedly recommend using a PMIS. Here’s the scoop: It’s an automated
system to create, manage, and streamline the project management processes quickly.
In the development portion of the project, the PMIS can be used to help the project
management team create the schedule, estimates, and risk assessments, and to gather
feedback from stakeholders.
The PMIS also includes a configuration management system. Configuration management
is an approach for tracking all approved changes, versions of project plans, blueprints,
software numbering, and sequencing. A configuration management system aims to manage
all of the following:
Functional and physical characteristics of the project deliverables
Control, track, and manage any changes to the project deliverables
Track any changes within the project
Allow the project management team to audit the project deliverables to confirm conformance
to defined criteria for acceptance
The configuration management system also includes the change control system. The change
control system defines all of the rules and procedures for how a change may enter
the project or be declined, and how each proposed change is documented.
Let’s say that, for the moment, the project manager and the project team have finished
their project plan. Before the project team can set about implementing it, the plan
must be approved. Let’s hear that again: The project plan is a formal, documented
plan that must be approved by management. Once management has signed off on the project
plan, the work is truly authorized to begin.
Examining the Typical Project Plan
The project plan is actually a bunch of plans and documents. Which ones, you ask?
Well, let’s take a peek.
The Project Scope Management Plan
The scope management plan details how the project scope should be maintained and protected
from change, as well as how a change in scope may be allowed. The plan also provides
information on how likely it is that the project scope will change, and if changes
do occur, how drastic those changes may be. We’ll discuss scope management and change
control in Chapter 5.
The Change Management Plan
Changes are likely to happen within a project, so you’ll need a clearly defined plan
that describes how to manage the changes. Ideally, all changes follow the change control
process before they’re implemented in the project, but some changes do bypass the
process, and this can mean corrective actions for the unapproved change. The change
management plan also addresses the change control board (CCB), if your company uses
one, and how stakeholders can submit and query changes to the project. Changes can
affect the entire project, but they stem from four specific areas: scope, costs, schedule,
and contract.
The Configuration Management Plan
Configuration management ensures consistency and ensures that the customer receives
exactly what was expected and defined. Configuration management is concerned with
controlling and documenting the features and functions of the product the project
is creating. This plan defines the elements of the product that are configurable and
that will require change control should the elements change or be desired to be changed.
This plan is tightly linked to the change management plan and the project’s scope
management plan.
Requirements Management Plan
The requirements management plan works in tandem with the scope management plan. It
defines how requirements will be identified, prioritized, documented, and then managed
throughout the project. This plan also addresses the process for when changes are
approved for a requirement and how the project team will manage new changes within
the project. We’ll discuss scope management and change control in Chapters 5, 6, 7, and 12.
The Schedule Management Plan
The project plan details the scheduled work, milestones, and target completion dates
for the project phases and the project itself. The schedule management plan, on the
other hand, identifies circumstances that may change the project schedule, such as
the completion of project phases or reliance on other projects and outside resources.
The schedule management plan identifies the likelihood that the schedule will change
and the impact of such changes, should they occur. Finally, the schedule management
plan details the approval and accountability process for changes within the project.
Along with the schedule management plan, the project manager creates the schedule
baseline. We’ll discuss the schedule management and schedule baseline in Chapter 6.
The Cost Management Plan
The project plan includes the project budget, the cash-flow forecast, and procedures
for procurement and contract administration. The subsidiary cost management plan explains
how variances to the costs of the project will be managed. This plan may be based
on a range of acceptable variances and the expected response to variances over a given
threshold. The cost management plan also includes a cost performance baseline to measure
accuracy of estimates and budgeting. Variances are revealed by comparing the actual
project costs to the original cost performance baseline. We’ll cover cost management
in Chapter 7.
The Quality Management Plan
The quality management plan describes how the project will operate and meet its quality
expectations. It details the quality improvement and quality controls, and how the
project will map to the quality assurance program of the performing organization.
The quality management plan provides information on the required resources and time
to meet the quality expectations. We’ll discuss quality management in Chapter 8.
The Process Improvement Plan
No project is perfect, but the process improvement plan strives to find ways to make
the project better. It identifies methods to track and eliminate waste and non–value-added
activities in order to reduce the work and deliverables that don’t contribute to the
project value. We’ll discuss this plan in Chapter 8.
Human Resources Plan
The project plan includes information on the resources needed to complete the project
work. The human resources plan, however, provides details on how the project team
members will be brought onto the project and released from the project. For example,
a project may have a need for an electrical engineer for three months during a ten-month
project. The human resources plan will then determine how the engineer’s time is accounted
for on the project and how the employees can be released when they’re no longer needed
on the project. We’ll discuss staffing management in Chapter 9.
The Communication Management Plan
It’s been said that project managers spend 90 percent of their time communicating.
When you consider all of the different requirements and communications of a project,
it’s easy to believe that statistic. The communication management plan describes the
required communications and how they will be fulfilled. It also explains the methods
used for gathering, storing, and dispersing information to appropriate parties.
In addition, the communication management plan maps out the schedule of when the expected
communication needs will be met. For example, milestone reports, timely status reports,
project meetings, and other expected communication events are included in the communications
management plan. The communication schedule also includes accepted procedures to update,
access, and revise communications between scheduled communication events. We’ll discuss
communications in Chapter 10.
The Risk Management Plan
The risk management plan details the identified risks within the project, the risks
associated with the constraints and project assumptions, and how the project team
will monitor, react, or avoid the risks. The risk management plan, and the processes
to create it, will be detailed in Chapter 11.
The Procurement Management Plan
If the project includes vendors, the project plan needs a procurement management plan.
This plan describes the procurement process from solicitation to source selection.
The plan may also include the requirements for selection as set by the organization.
The selected offers, proposals, and bids from vendor(s) should be incorporated into
the procurement management plan. We’ll discuss procurement processes in Chapter 12.
The Stakeholder Management Plan
Stakeholders need to be managed, engaged, and included in communication throughout
the project. This plan defines the approach the project manager and the project team
will take with the project stakeholders. The stakeholder management plan defines the
level of engagement, the interrelationships among stakeholders, communications requirements,
and the timing of stakeholder engagement. This plan may contain sensitive information
about the project stakeholders, so it’s often guarded rather than openly distributed
to all of the project stakeholders.
Loads of project plans and documents are covered in this chapter. I highly recommend
that you remember all of the project plans and documents. Knowing these documents
will help you in all of the other knowledge areas, too, as you’ll see these plans
there. Keep at it—if it were easy, everyone would do it.
The Project Baseline Documents
The project management plan also includes three baselines. The most prevalent baseline
is the project’s scope baseline. This baseline is made up of the project’s scope document,
the project work breakdown structure (WBS), and the WBS dictionary. These three documents
are used to compare what was promised to the project customer and what the project
actually delivered. A difference between the two can mean quality errors or scope
validation rejections.
The cost baseline and the schedule baseline help show project performance. The cost
baseline reflects the project’s accumulative costs in relation to the project’s predicted
cost. Like the cost baseline, the schedule baseline also is used to compare the project’s
planned schedule against the actual progress. A difference between what was planned
and what was experienced is called a variance. Variances mean that the project is losing money, off schedule, or both.
Project Documents and Files
In addition to the compilation of project management subsidiary plans, you’ll rely
on many project documents that help you plan and execute the project. These are not
officially part of the project plan, but you should be familiar with them for your
PMP exam.
Project charter Every project needs a charter, which authorizes the project and gives the project
manager power over the project resources.
Milestone list This is a listing of the project milestones and anticipated completion dates.
Forecasts Throughout the project, the project manager will create forecasts about the expected
project completion date and projected project costs.
Activity list This is a shopping list of all the activities the project team must complete in
order to satisfy the project. This list is an input to the project network diagram.
Activity attributes Activities with special conditions, requirements, risks, and other conditions should
be documented.
Activity cost estimates The cost of resources, including materials, services, and, when warranted, labor
should be estimated.
Project funding requirements In larger projects, this document identifies the timeline of when capital is required
for the project to move forward. This document defines the amount of funds a project
needs to reach its objectives and when the project funds are needed.
Activity duration estimates This document includes a prediction of how long the project activities will take
to complete.
Supporting detail for estimates This document shows how time and cost estimates were created.
Resource calendars This document indicates when people and facilities are available or scheduled to
work on the project.
Project calendar You’ll need to define when the project work will take place. This includes any
special accommodations, such as working weekends or after hours, holidays, or pauses
in the project so as not to interfere with operations.
Schedule The project’s schedule of when the tasks are to take place, the schedule network
diagram, and data about the estimated duration and the actual duration of activities
are all project documents.
Resource requirements The identification of what resources are needed to complete the project work is
required as a supporting document for planning. This includes people, materials, equipment,
facilities, and services.
Resource breakdown structure This chart identifies the resources utilized in the project in each section of
the WBS.
Responsibility assignment matrix This table maps roles to responsibilities in the project.
Roles and responsibilities This maps project roles, such as carpenter, to project activities, such as framing
the house. It helps to define the staff assignments.
Teaming agreement This contractual agreement defines the roles, responsibilities, considerations,
and partnerships of two or more organizations that work together in a project. It’s
not unlike a partnership or subcontractor relationship.
Sellers list This is a listing of the vendors an organization does business with. You might
know this document as a preferred vendors list in your company.
Source selection criteria This predefined listing shows the criteria used to determine how a vendor will
be selected—for example, cost, experience, certifications, and the like.
Statement of work This document defines the work that a vendor is to complete for the buyer. Statement
of work documents accompany procurement documents so vendors can bid, quote, or create
proposals for the project work. Internally, statement of work documents define the
requirements of the project.
Requirements traceability matrix This table identifies all of the project requirements, when the requirements are
due, when the requirements are created, and any other pertinent information about
the requirements.
Procurement documents All of the documents for purchasing, such as request for quotes, invitation to
bid, request for proposal, and the responses, are stored as part of the project documentation.
Proposals Proposals are an exposé on ideas, suggestions, recommendations, and solutions to
an opportunity provided by a vendor for a seller. Proposals include a price for the
work and document how the vendor would provide the service to the buyer.
Contracts This legally binding agreement between the buyer(s) and seller(s) defines the roles
and responsibilities of all parties in the agreement.
Assumption log This document clearly identifies and tracks assumptions that are made in the project.
All assumptions need to be tested for their validity, and the outcome of the test
should be recorded.
Issue log Issues are decisions that are usually in disagreement among two or more parties.
They are recorded in the issue log, along with an issue owner designation, an issue
date for resolution, and the eventual outcome of the issue.
Risk register A risk is an uncertain event or condition that can have a positive or negative
effect on the project. All risks, regardless of their probability or impact, are recorded
in the risk register, and their status is kept current.
Change log As changes to the project time, cost, or scope enter the project, they should be
recorded in the change log for future reference.
Change requests All change requests must be documented and follow the project’s change control
system.
Work performance reports These formal reports define how the project is performing on time, cost, scope,
quality, and any other relevant information.
Work performance information The current status of the project work includes the results of activities, corrective
and preventive action status, forecasts for activity completion, and other relevant
information. You might know this information as a status report.
Work performance measurements These are predefined metrics for measuring project performance, such as cost variances,
schedule variances, and estimate to complete.
Quality control measurements Quality control is an inspection-driven process; quality control measurements are
predefined values that signal problems with quality within the project deliverables.
These can vary, based on the discipline the project centers on—for example, manufacturing
or information technology.
Quality metrics These are predefined values that the results of project work should match in order
to be acceptable for the project deliverables and project performance.
Quality checklists These are ideal for repetitive activities to ensure that each activity is done
identically to the other activities in the project. They are also ideal for safety
procedures.
Project organizational structure This document defines the reporting relationships within and without the project.
This is especially useful for large virtual project teams.
Stakeholder analysis This is an examination and documentation of the project stakeholders and their
requirements for the project deliverables.
Stakeholder register All stakeholders, their position within the project, contact information, and other
characteristics are recorded in this document.
Stakeholder requirements As a result of stakeholder analysis, the stakeholder requirements are identified.
These can be project deliverables, approval requirements, and communication demands.
Stakeholder management strategy Larger projects will generally have more stakeholders than smaller projects. The
attitude and position of the project stakeholders will affect how the project manager
communicates and manages the project stakeholders.
Team performance assessments Often at the end of project phases and the end of the project, the project manager
reviews the project team members’ performance and contribution to the project’s success
or failure.
Open issues are acceptable, as long as they are not related to major decisions that
will prevent the project from moving forward. For example, conflicting objectives
and requirements between stakeholders can’t be an open issue. A resolution and agreement
on project requirements has to be in place before the project work can begin.
CERTIFICATION OBJECTIVE 4.03
Directing and Managing the Project Work
So you’ve got a project plan—great! Now the work of executing the project plan begins.
The project manager and the project team will go about completing the promises made
in the project plan to deliver, document, measure, and complete the project work.
The project plan will communicate to the project team, the stakeholders, management,
and even vendors what work happens next, how it begins, and how it will be measured
for quality and performance.
The product of the project is created during these execution processes. The largest
percentage of the project budget will be spent during the project execution processes.
The project manager and the project team must work together to orchestrate the timings
and integration of all the project’s moving parts. A flaw in one area of the execution
can have ramifications in cost and additional risk and can cause additional flaws
in other areas of the project.
As the project work is implemented, the project manager refers to the project plan
to ensure that the work is meeting the documented expectations, requirements, quality
demands, target dates, and more. The completion of the work is measured and then compared
against the cost, schedule, and scope baselines as documented in the project plan.
Should there be—GASP!—discrepancies between the project work and the scope, time,
and cost baselines, prompt and accurate reactions are needed to adjust the slipping
components of the project.
Executing the project plan includes the following:
Doing the work to satisfy the project objectives
Spending funds to satisfy the project objectives
Managing, training, and leading the project team
Completing procurement requirements and managing the vendors and buyers
Acquiring, managing, and using resources such as materials, tools, facilities, and
equipment to get the project work completed
Managing risks
Incorporating approved changes into the project
Managing communications
Collecting project data on schedules, costs, quality, and overall project progress—and
then reporting on these components
Managing the project stakeholders to keep them engaged and supportive of the project
work
Completing lessons-learned documentation
Applying Corrective Action
Things go awry. Corrective actions are methods the project manager and the project
team can undertake to bring the project back into alignment with the project plan—for
example, a delay in the project work has shifted the project schedule by a month.
The project manager, the project team, and even the stakeholders can examine the project
schedule to see what possible changes can be made in the schedule to complete the
project on time. Solutions may include adding resources, fast-tracking, changing the
order of work packages, and so on. Corrective actions bring the project performance
back in line with the project plan. In addition to communicating, project managers
spend a great deal of their time applying corrective actions.
Considering Preventive Actions
Do you wear your seatbelt? Take an umbrella when there’s a chance of rain? These are
preventive actions against some risk. Not all preventive actions can eliminate the
risk, but it can reduce or eliminate the impact or probability of the risk event.
In project management, preventive actions are steps the project manager and the project
team can take to reduce and prevent the negative outcome of possible risk events.
Preventive actions are documented methods to avoid risks and keep them from influencing
the project success in a negative way. Preventive actions take risk events out of
play.
Managing Defect Repair
Sometimes the project team will screw up. Defect repair is the action required to
fix the problem and to fix it correctly. The project manager will need to ensure that
the actions taken to fix the problem have indeed corrected the defect and allowed
the project to move forward as planned. Sometimes when a project team member faces
a defect, he or she will rush through the defect repair, causing more errors and waste.
The project manager must work with the project team to ensure that the defect is fixed
efficiently and properly.
Managing Change Requests
As the project team completes the work, the project manager will be faced, challenged,
or even bombarded with change requests. Part of project execution is to evaluate the
worthiness of the proposed change, feed the change through the change control system,
and then act on the approval or denial of the change request. All change requests
are documented for future reference, while approved changes are incorporated into
the project plan.
Project Management Methodology
Every performing organization has rules and regulations that are specific to the industry
within which it operates. In addition, the performing organization will likely have
standard operating procedures that determine the order, approach, and autonomy of
the project manager and the project team.
For example, an organization operating within the construction industry must operate
according to the laws and regulations of the country, state (or province), and city.
In addition, the performing organization may require its construction crew to adhere
to its safety standards, quality inspections, and other company rules that are not
mandated by a government agency. The project manager must work within not only the
law, but also the additional constraints the organization has added to the project.
Implementing Tools and Techniques for Project Execution
You have completed a workable, approved project plan. Now it’s time to implement the
thing. This is the heart of project management: taking your project plan and putting
it into action. You’ll act, do, adjust, and repeat. The project manager will use several
tools and techniques to execute the project plan.
Using Expert Judgment
It should come as no surprise that one of the leading tools and techniques required
to direct and manage the project work is expert judgment. You’ll use your experience,
savvy, and management abilities to communicate what actions need to take place in
the project based on current project conditions. But it’s not all up to you—you’ll
also rely on guidance and know-how from your project team, as they’re closest to the
work being performed. Project managers may also seek expert judgment for this process
from lines of service within your company, consultants, professional organizations
to which you subscribe, and project stakeholders.
Employing a PMIS
A PMIS is typically a computer-driven system (though it can be paper-based) to aid
a project manager in the development of the project. It is a tool for, not a replacement
of, the project manager. A PMIS can calculate schedules, costs, expectations, and
likely results. It cannot, however, replace the expert judgment of the project manager
and the project team.
The goal of the system is to automate, organize, and provide control of the project
management processes. A typical PMIS software system offers the following:
Work breakdown structure creation tools
Calendaring features
Scheduling abilities
Work authorization tools
Earned value management controls
Quality control charts, program evaluation and review technique (PERT) charts, Gantt
charts, and other charting features
Calculations for the critical path, EVM, target dates based on the project schedule,
and more
Resource tracking and leveling
Reporting functionality
Don’t worry too much about PMIS brand names such as Microsoft Project and Primavera.
The exam doesn’t fall in love with any PMIS systems—they’re just tools for the project
manager to work with.
Collaborative PMIS packages can also serve as a work authorization system—if they
are configured and used properly. Any PMIS, electronic or paper-based, is only as
good as the person (or persons) keeping the information up to date.
Meeting to Execute Project Work
Project managers need to meet with the project team, vendors, managers from other
business units in the organization, and other stakeholders as the work is being executed.
Meetings help the project manager, the project team, and other key stakeholders come
together and form a consensus on how the work in the project management plan is about
to commence. As a project manager, you’ll go to lots of meetings to discuss the project
work, ensure communication, and maintain stakeholder buy-in for the project. It’s
best for all meetings to have an agenda and for someone to keep minutes to ensure
that documentation exists regarding what’s to be discussed and what was accomplished
in the meeting.
Examining the Outputs of Project Plan Execution
The project is being completed, and you have visible evidence that it is moving toward
the desired future state. Inspections by the project manager and scope verification
by the customer also prove the project team is completing their work as planned. Status
meetings provide opportunity for the project team to report their work and evaluate
it against the WBS and the network diagram. Things are moving along smoothly.
And then it happens. The project team begins to slip on the quality of the project
work. Team members begin to take longer than what was scheduled to complete their
project work. The scope verification with the clients takes longer—and their satisfaction
with the project work begins to wane. What’s a project manager to do?
This scenario is typical of project plan execution. The team completes the work, and
then the project manager reviews the work and makes adjustments to bring the project
back into alignment with the baselines created in the project plan. Several major
components of project plan execution happen throughout project execution, not just
at the end:
Project deliverables
Change requests
Project management plan updates for approved change requests
Work performance information
Project document updates
Project management plan updates
Examining the Project Work Results
The team completes their work based on the project plan. The end result of the work
should be measured against the quality metrics, scope requirements, and expected outcomes
of the work as defined in the project plan. In addition, the project manager must
examine the time and cost required to reach the work results and compare them against
the baselines recorded in the project plan. Any difference between what was experienced
and what was planned is a variance.
Work results are not always physical, tangible things: the creation of a service,
the completion of a training class, the completion of a certification process—these,
too, can be measured as work results.
Examining Change Requests
How many times have stakeholders begged, pleaded, or demanded a change in the project
scope? Probably more times than you can count, right? Change requests are any requested
deviation from, or addition to, the project scope, schedule, budget, quality, or staffing.
Change requests will predominantly trickle (or flood) in to the project manager during
project plan execution. Change requests almost always affect one of four facets of
a project:
Schedule This is a desire to shorten or lengthen the project duration—for example, a key
stakeholder would like the project to be completed before a particular business cycle
begins. If the project can’t be completed by that time, the project will be delayed
until the business cycle has completed, so the project won’t interfere with the business
operations.
Cost This is a reduction or increase in the project’s budget. For example, the project’s
priority has been reduced in the organization, so the budget may, unfortunately, be
reduced as well. Budgets can also be increased: A functional manager may want to spend
the entire remaining departmental budget at the end of the fiscal year so that next
year’s budget may meet or exceed the current year’s budget. In this questionable instance,
additional funds, new features, and more resources, needed or not, are added to a
project’s budget to “help” the functional manager spend the budget.
Scope This is the most common instance of change. Stakeholders may request additional
features, different features, or small changes to the project product. Each change
must be evaluated against the project plan, the project scope, and supporting details
to determine the cost, time, and risks implied.
Combination This is a change made to the schedule, cost, or scope that may affect more than
one facet of the project. This goes back to the idea of the “Triple Constraints of
Project Management.” For example, a change to finish the schedule more quickly may
be reasonable if more resources are applied to the project. More resources, in turn,
mean more money.
Change requests do include changes for corrective actions, preventive actions, defect
repair, and updates to the project plans and documentation.
Updating the Project Documents
Change is expected in projects, though not always welcome. When changes are approved,
the project management plan should be updated to reflect the approved changes. This
means that the project management scope baseline, schedule baseline, and the cost
baseline should all be updated to reflect the new project deliverables. You’ll also
need to update the project activities lists to reflect the new activities the project
changes will require, and, in turn, you’ll update the project network diagram. Finally,
changes can cause a ripple effect into the project management subsidiary plans and
the project documents that all need to be updated to reflect the changes in the project.
CERTIFICATION OBJECTIVE 4.04
Monitoring and Controlling the Project Work
Sure, sure, it’d be nice to have a project plan and a team that follows orders and
to have all the work requests completed on budget and on time every time—but this
isn’t fiction. One of the key activities for the project manager is to monitor the
project team and control the work that they complete as part of the project. This
is the hands-on portion of the project management career.
The project manager, with the project management plan in hand, will examine what was
promised in the plan and what’s been executed by the project team. This means the
project manager needs work information—work results—to inspect in order to ensure
that the project is being completed as planned. The project manager will examine the
forecasted schedule milestones, cost estimates, the changes that have been approved
for the project scope, and the actual project deliverables as part of this process.
Using Monitoring and Controlling Tools and Techniques
Recall that the product scope is the vision of what the customer expects, while the
project scope is the work completed by the project team to create the product scope.
This means that if the project team is completing activities outside of the project
scope, they are not contributing to the project scope, which in turn means they’re
creating a product scope that’s different from what the customer is expecting. Not
a good thing. This leads to waste, frustration, delays, and unhappy customers—and
unhappy project managers. We don’t want this. We want control and accuracy.
Using a Methodology
A project management methodology is more than just a philosophy for project management.
It’s an approach to project management that follows a documented, proven model for
completing projects. Many organizations have a project management methodology that
requires the project manager to complete checklists, follow standards, and report
on the accuracy of the project completion. The goal of the project management methodology
is to assist all project managers within an organization to execute the project management
plan accurately.
Another tool that complements the project management plan is the PMIS, which can automate
some of the procedures, questions, and prompts to assist all project managers within
an organization to ask the right questions in order to retrieve answers, status, and
information on task completion. A PMIS does not replace the project manager—it assists
the project manager.
Relying on Analytical Techniques
Based on current conditions in the project, you might be able to forecast future performance
and outcomes in the project. Analytical techniques are methods to help the project
manager and experts predict the likelihood of success, or failure, based on what’s
happened in the project to date. For the PMP, you should be topically familiar with
these analytical techniques:
Regression analysis This forecasting tool measures and predicts the link between two variables within
a project. For example, you could use regression analysis to determine whether the
years of experience of each project team member is relevant to the frequency of errors
the team members make doing a similar, repetitive task. You might predict that the
more experienced team member make fewer mistakes, but this analysis would help prove
or disprove your hypothesis and trace the number of errors relative to experience.
Root cause and causal analysis This approach aims to determine what activities, people, organizational processes,
or other factors are contributing to an effect in the project. Through analysis, which
is really detective work, you’ll determine contributing causes and causal factors.
This approach helps to identify actual causes, not just symptoms of the cause, so
that you can make recommended corrective and preventive actions. One approach is to
ask “why?” five times to help lead you to the root cause.
Forecasting methods These methods help you predict future instances based on past instances, analysis,
and trends. A common approach is the time-series method, which examines past experiences
to define patterns that are likely to be repeated in the future. Simulations practice
or test hypotheses of what may happen in a lab environment to predict what’s likely
to happen in an actual project environment.
Failure mode and effect analysis (FMEA) This analytical technique is used to identify the severity of something that has
failed within the project and the likelihood that the failure will occur again.
Fault tree analysis This approach uses deductive reason to start very broad with the identified fault
and then narrow down the likely causes to most likely causes. Fault tree analysis
helps define the faults from minimal to most severe and can help the project manager
avoid potential disasters in the project, save expensive changes, and extrapolate
a series of faults to predict what may happen in the project.
Reserve analysis A contingency reserve for risk events should be periodically reviewed to ensure
that the amount of funds left in the contingency reserve is adequate for the remaining
risks and their probabilities in the project. If too many risk events happen early
in the project, you might deplete the contingency funds and not have sufficient monies
to cover the risk events later in the project. We’ll discuss contingency reserve calculations
in Chapter 11.
Trend analysis This analysis technique examines recurring problems, threats, and even opportunities,
so you can react to the situation based on the trends you’ve identified.
Host Meetings
You’ll host meetings to discuss and review the status and conditions within the project.
In these meetings, you’ll be reviewing the project, issues, and any problems that
must be addressed. Most likely, you’ll be using expert judgment, too. Recall that
expert judgment is simply relying on a resource that’s smarter in one or more areas
than the project manager to help the project manager make the best decision. Expert
judgment can come from many different sources:
Third-party consultants
Subject matter experts
Project team members
Stakeholders
Individuals within the organization who may not be directly affected by the project
Examining the Results of Project Work
As a project moves toward completion and the project manager monitors and controls
the project, there will be evidence of the project’s success, failures or, at a minimum,
some results of the work as performed by the project team. Here’s the business you
can expect to be tested on when it comes to the PMP exam:
Requested changes Yep, change requests can come out of monitoring and controlling. Change requests
usually mean that the project scope will widen—although in some instances, the project
scope may be trimmed due to lack of funds, time, or other possibilities. We’ll talk
more about scope change control in Chapter 5.
Recommended corrective actions Corrective actions must be followed to bring future project results into alignment
with expected project performance. These require documented change requests to implement.
Recommended preventive actions These actions ensure that mistakes don’t get repeated within a project. For example,
if a piece of equipment fails because it gets too hot, the project manager and the
project team will take action to ensure that the equipment doesn’t overheat and delay
the project work. These require documented change requests to implement.
Recommended defect repair Quality control is an inspection-driven process of finding mistakes or errors with
the project work results before the customer does. When a defect is found, the project
manager should document the defect and then, usually, require the project team to
fix the problem. Defects require documented change requests to implement.
Forecasts Forecasts are harbingers of things to come. They provide information based on current
and past project performance to predict when a project may finish and what the estimate
at completion (the project’s final costs) and the estimate to complete (how much more
the project will cost) the project will be. EVM is an example of a tool that can provide
forecasts.
Project document updates When project work changes, the project manager has to update the corresponding
project documents and project plans. This is a recurring theme throughout project
management, so you can bet dollars to donuts you’ll see this concept on your PMP exam.
CERTIFICATION OBJECTIVE 4.05
Performing Integrated Change Control
Integrated change control examines a change request to determine the total effect
the change may have on all parts of the project. It determines the value of the change
on the project to help determine whether the change should actually be approved, declined,
or postponed. Integrated change control examines changes that stem from scope, cost,
schedule, and contract, though scope changes are the most common (and we’ll discuss
these in detail in Chapter 5).
When changes are proposed to the project, the project manager must route the proposed
changes through a change control system (CCS). The CCS may also include the review
of proposed changes through a change control board (CCB). Changes may be discarded
or approved on the basis of different criteria, such as benefit/cost ratios (BCRs),
value-added changes, risk, and political capital.
When changes are approved, the project manager must then update the project baselines,
as changes will likely affect a combination of scope, cost, and time. The updated
baselines allow the project to continue with the new changes incorporated into the
project and provide for accurate measurement of the performance of the project as
changed.
This is an important concept: Update the project baselines. Consider a project scope to which requirements have been added but for which the
schedule baseline has not been updated: The project’s end date will thus be sooner
than what is possible, because the project baseline does not reflect the additional
work that should extend that date. In addition, a failure to revise the project baseline
could skew reporting, variances, future project decisions, and even future projects.
Consider a project manager who does not update the project baseline after a change.
The completion of the project goes into the archives and can serve as historical information
for future projects. In such cases, the historical information would be skewed, since
it doesn’t accurately account for the added work and the projected end date or budget.
Changes, small or large, must be accounted for throughout the project plan. Notice
how the integrated change control processes influence the communications of the change,
including the change approval or denial. That’s the whole point: to integrate proposed
changes into the project processes. Figure 4-4 details integrated change control.
FIGURE 4-4 All change requests must pass through integrated change control.
Implementing Tools and Techniques for Integrated Change Control
Given that changes, or requests for change, are likely to happen during the project,
what tools are available to squelch, evaluate, and approve the proposed changes? And
how can the project manager organize change requests in an orderly system so he or
she is not constantly evaluating change requests instead of focusing on project completion?
And how do change requests get approved, worked into the project plan, and accounted
for in costs, schedule, and risk?
Many tools can be applied to requests for change: consistency, scope comparison, BCRs,
risk analysis, and the estimate of the time and cost to incorporate the change, among
others. The tools will guide the project manager, the project team, and the stakeholders
through the process of approving and declining changes. The best approach for integrated
change control is a constant, purposeful process of reviewing, considering, and evaluating,
followed by a decision as to whether the change is needed.
A seemingly tiny change in costs, schedule, scope, or a contract can mushroom into
large problems throughout the project. Integrated change control examines a change
to determine what effect it will have on all parts of the project:
Project scope
Project schedule
Project costs
Project quality
Project human resources
Project communications
Project risks
Project procurement
Project stakeholder management
Relying on a Change Control System
A change control system is a formal process of documenting and reviewing proposed
changes. It establishes the flow of change from proposal to decision. The CCS process
describes how project performance will be monitored, how changes may occur, and then
how the project plan may be revised and sent through versioning when the changes are
approved.
A CCS is a collection of documented activities, factors for decisions, and performance
measurements—it is not a computer program. Although many electronic project management
information systems offer a CCS, know that a CCS is a documented approach to change,
not an automated approval structure.
INSIDE THE EXAM
What must you know from this chapter to pass the exam? Know the purpose of the project
plan: to guide the project manager through the execution and control groups. The project
plan is also in place to provide communication to the project team, stakeholders,
and management. Additionally, it will guide all future project decisions.
You should know all of the components of the project plan. Know what each of the subsidiary
project plans are used for, how they can be updated, and what their objectives are.
Remember that the point of planning is to create the project plan. The project plan,
then, provides leadership and direction for the project execution and control processes.
It is a formal, management-approved document—and once it’s approved, work can begin.
Remember the WBS? It’s a major piece of the PMP exam. Know the attributes of the WBS:
It serves as an input to the planning process and execution, and it requires input
from the project manager and the project team. The WBS is an input to seven processes:
Develop the project management plan and other project documents.
Define the project activities.
Estimate the project costs.
Determine the project budget.
Validate the project scope.
Identify the project risks.
Complete qualitative risk analysis.
After the WBS, historical information is another big factor on the exam. Why? Historical
information is proof from other project managers. It allows the project manager to
rely on what has been proven, what has been accomplished, and what has been archived
for reference. And remember that the current project plan will become a future historical
reference.
Assumptions and constraints are present on every project. Assumptions are beliefs
held to be true but not proven to be true. They should be documented in the project plan, while constraints are
restrictions within which the project must operate. The Triple Constraints of Project
Management—time, cost, and scope—will visit you on exam day, as will other internal
and external constraints.
To begin the project, you need a project charter. Project charters come from a manager
external to the project. Once the charter is present, the project manager is named.
The project manager then assembles the project team and begins the planning processes.
The primary output of any planning is a project plan, and its execution cannot begin
until management approves the plan. All work described in the project plan must pass
through a work authorization system, either formal on a larger project or informal
on smaller projects.
Integrated change control requires the evaluation of change requests to determine
their worthiness for approval—or lack thereof for denial. Change requests must be
documented and may originate from stakeholders or external sources such as government
agencies, laws, or industry mandates.
Some organizations may have a CCS that is used across all projects and maps to common
guidelines within the organization. If the performing organization does not have a
CCS, it is the responsibility of the project manager and the project team to create
one. A CCS is mandatory for effective project management.
Within a CCS may be a collection of management, key stakeholders, and project team
members that review the changes for approval or denial. This board is defined in the
project plan, and its roles and responsibilities are defined prior to project plan
execution. Common names for the board include the following:
Change control board (CCB)
Schedule change control board
Technical review board (TRB)
Technical assessment board (TAB)
Engineering review board (ERB)
Implementing Configuration Management
Configuration management focuses on controlling the characteristics of a product or
service. It is a documented process of controlling the features, attributes, and technical
configuration of any product or service. When it comes to project management, configuration
management has a focus on the project deliverables. In some organizations, configuration
management is a part of the CCS, but in other industries, such as manufacturing, configuration
management refers to the control of existing operations. In a general sense, configuration
management consists of the following:
Configuration identification The documentation and labeling of the features, characteristics, and functions
of a product or service.
Configuration status accounting The management and coordination of efforts to change the product or service. This
includes status of proposed changes, both pending and implemented.
Configuration verification and audit The process of documenting any changes to the product or service. It is the ongoing
auditing of products and services to ensure their conformance to documented requirements,
including tracking approved changes to the product’s features and functions.
Applying Performance Measurement
The end result of project plan execution must be measured to determine whether the
implementation of the plan meets the expected results of the project plan. The most
common measurement of project plan execution is earned value. Earned value is a collection of formulas that measure the project worth, performance, and likelihood
of the project completing on time and on budget. The results of performance measurement
may prompt the project manager to create a performance report on the project’s key
objectives.
You might need to create a burnup or burndown chart as part of your work performance
information report. A burndown chart predicts when the project will be completed—it
burns down to completion. Your burnup chart can also show scope changes throughout
the project and how these changes contributed to the project as a whole. A burnup
chart graphs the work accumulating in an upward curve to predict project completion.
Revisiting Planning Processes
Planning is iterative. Because a project rarely, if ever, happens exactly the way
the project team and project manager planned it, the project freely moves between
the controlling, executing, and planning processes. This is most evident when changes
enter the project scene. The project manager and the project team must evaluate the
proposed changes for additional cost, time, and risk concerns.
If the project work slips from the expected performance, quality, or schedule, adjustments
are needed. These adjustments will require the consideration of project activities,
the critical path, resources, cost, sequence of activities, and other refinements
to the project plan.
Evaluating the Outputs of Integrated Change Control
As the project follows the project plan and changes are presented, the project manager
will implement integrated change control. Some changes will be denied, documented,
and archived for reference if needed. Other changes will be approved and factored
into the project scope and have their time, cost, and risks documented and accounted
for. All changes, approved or declined, should be documented in a project’s change
log for reference and supporting detail. The process of integrated change control
is ongoing until project closure. Integrated change control can spur the following:
Approved change requests
Rejected change requests
Project plan updates
Change log updates
Project management plan updates
Project scope statement updates
Approved corrective actions
Approved preventive actions
Approved defect repair
Project deliverables
CERTIFICATION OBJECTIVE 4.06
Closing the Project or Phase
The project management plan defines what the project or phase is, how the project
or phase will be completed, and finally—the good part—how the project or phase will
be closed. The close project processes are activities that the project manager, the
project management team, vendors, and the organization’s management will undertake
to close out the project work. If a project has multiple phases, as most projects
do, the closing processes will be implemented at the end of each phase.
Preparing to Close the Project or Phase
The project manager must rely on several documents to prepare the close project processes.
Specifically, the project manager relies on the project management plan to guide the
required actions needed to close out the project. Of course, other components contribute
to the start of the closing processes:
Project management plan The project management plan includes the project scope, the project requirements,
and expectations for the project objectives. When a project is being completed for
another organization, the contract serves as a guide for how the project may be closed.
The project plan may also reference the enterprise environmental factors to consider
as part of project closing.
Organizational process assets An organization may have procedures and processes that every project manager must
follow to close a phase or project. These can include financial, reporting, and human
resource obligations.
Deliverables The project has to create something, so it’s no surprise that the deliverables
serve as input to the project closing processes.
Formally closing the project or phase involves documenting and archiving all of the
work necessary to formalize the closing process. The formal closing process updates
the organizational process assets as the current information of the project’s performance,
lessons learned, and other documents becomes future historical information. This requires
more than just the project manager, instead involving the project team, the project
sponsor, key stakeholders, and vendors. Administrative closure includes all of the
following activities:
Collecting and assembling all project records
Analyzing the project’s success or failure
Gathering lessons-learned documentation
Archiving project information for future reference
At the end of the project, project teams and the project manager are often rewarded.
How will you reward yourself for finishing the project to pass your PMP exam? Set
a reward for earning your PMP—you’ll deserve it!
CERTIFICATION SUMMARY
Project integration management is an ongoing process the project manager completes
to ensure that the project moves from start to completion. It is the gears, guts,
and grind of project management—the day-in, day-out business of completing the project
work. Project integration management takes your project plans; coordinates the activities,
project resources, constraints, and assumptions; and massages them into a working
model.
Of course, project integration management isn’t an automatic process; it requires
you, the project manager, to negotiate, finesse, and adapt to the project’s circumstances.
Project integration management relies on general business skills such as leadership,
organizational skills, and communication to get all the parts of the project working
together.
The process of project management can be broken down into three chunks.
Developing the project plan Project plan development is an iterative process that requires input from the project
manager, the project team, the project customers, and other stakeholders. It details
how the project work will accomplish the project goals. The project plan provides
communication.
Executing the project plan After the plan has been created, it can be executed. The project execution processes
authorize the work to begin, manage procurement and quality assurance, host project
team meetings, and manage conflict between stakeholders. On top of managing all these
moving parts, the project manager must actively work to develop the individuals on
the project to work as a team for the good of the project.
Managing changes to the project Changes can kill a project. Change requests must be documented and sent through
a formal change control system to determine their worthiness for implementation. Integrated
change control manages changes across the entire project. Change requests are evaluated
and considered for impacts on risk, costs, schedule, and scope. Not all change requests
are approved—but all change requests should be documented for future reference.
As the project moves from start to completion, the project manager and the project
team must update the lessons-learned documentation. The lessons learned serve as future
historical information to the current project and to other future projects within
the organization. The project manager and project team should update the lessons learned
at the end of project phases, when major deliverables are created, and at the project’s
completion.
Project Integration Management
Project integration management relies on project plan development, project plan execution,
and integrated change control. Integrated change control manages all the moving parts
of a project.
Project integration management is a fancy way of saying that the project components
need to work together—and the project manager sees to it that they do. Project integration
management requires negotiation between competing objectives.
Project integration management calls for general management skills, effective communications,
organization, familiarity with the product, and more. It is the day-to-day operations
of the project execution.
Planning the Project
On your exam, you’ll need to know that planning is an iterative process and that the
results of planning are inputs to the project plan. The project plan is a fluid document,
authorized by management, and it guides all future decisions on the project.
The project plan is a fluid work in progress. Updates to the plan reflect changes
to the project, discoveries made during the project plan execution, and conditions
of the project. The project plan serves as a point of reference for all future project
decisions, and it becomes future historical information to guide other project managers.
When changes occur, the cost, schedule, and scope baselines in the project plan must
be updated.
All project managers should know what the WBS is—a tool for listing, organizing, and
decomposing the project work. You should know that the WBS is an input to many of
the planning, execution, and control processes. If you’re stumped on a question and
one of the answers is WBS, hedge your bets and choose WBS. The WBS is part of the
scope baseline.
Project Constraints
Projects have at least one or more constraints: time, cost, and scope. These are known
as the Triple Constraints of Project Management. Constraints are factors that can
hinder project performance:
Time constraints include project deadlines, availability of key personnel, and target milestone
dates. Remember that all projects are temporary: they have a beginning and an end.
Cost constraints are typically predetermined budgets for project completion. It’s usually easier
to get more time than more money.
Scope constraints are requirements for the project deliverables, regardless of the cost or time to
implement the requirements (safety regulations or industry mandates are examples).
Managing Integrated Change Control
Integrated change control is the process of documenting and controlling the features
of a product, measuring and reacting to project conditions, and revisiting planning
when needed.
Projects need change control systems to determine how changes will be considered,
reviewed, and approved or declined. A change control system is a documented approach
to how a stakeholder may request a change and then what factors are considered when
approving or declining the requested change. There are four project change control
systems: scope, schedule, cost, and contract.
Configuration management is part of change control. It is the process of controlling
how the characteristics of the product or service the project is creating are allowed
to be changed.
KEY TERMS
If you’re serious about passing the PMP exam, memorize these terms and their definitions.
For maximum value, create your own flashcards based on these definitions and review
them daily.
activity attributes Activities that have special conditions, requirements, risks, and other conditions
should be documented.
activity cost estimates The cost of resources, including materials, services, and, when warranted, labor
should be estimated.
activity list A shopping list of all the activities the project team must complete in order to
satisfy the project. This list is an input to the project network diagram.
assumption log A document that clearly identifies and tracks assumptions that are made in the
project. All assumptions need to be tested for their validity, and the outcome of
the test should be recorded.
benefit/cost ratio Shows the proportion of benefits to costs; for example 4:1 would equate to four
benefits and just one cost.
benefit measurement methods Project selection methods that compare the benefits of projects to determine into
which project the organization should invest its funds.
burndown chart A graph that tracks the project’s completeness, including scope changes, in a downward
curve against the project timeline.
burnup chart A graph that tracks the project’s completeness in an upward curve against the project
timeline.
causal analysis Causal analysis is the analysis of why a problem exists and understanding the real
reason why the problem is happening. Root cause analysis defines the problem, or the
effect you’re trying to resolve, and then identifies all of the causal factors that
may be independently or collaboratively contributing to the defect.
change control board A group of decision-makers that review proposed project changes.
change control system A predefined set of activities, forms, and procedures that establish how project
change requests may proceed.
change log As changes to the project time, cost, or scope emerge during the project, they
should be recorded in the change log for future reference.
communications management plan Defines the required communications and how they will be fulfilled; it explains
the methods used for gathering, storing, and dispersing information to appropriate
parties. In addition, it maps out the schedule of when the expected communication
needs will be met.
configuration management The control and documentation of the project’s product features and functions.
constrained optimization methods Complex mathematical models used to determine the likelihood of a project’s success
and to determine whether the organization should invest its funds into the project.
constraints Anything that limits the project manager’s options; time, cost, and scope are always
project constraints.
contract A legally binding agreement between the buyer(s) and seller(s) that defines the
roles and responsibilities of all parties in the agreement.
cost management plan Explains how variances to the costs of the project will be managed. The plan may
be based on a range of acceptable variances and the expected response to variances
over a given threshold.
duration estimates The prediction of how long the project work will take to complete.
earned value management A suite of formulas to measure the project’s overall performance for time and costs.
failure mode and effect analysis (FMEA) An analytical technique used to identify the severity of something that has failed
within the project and the likelihood that the failure will occur again.
fault tree analysis Deductive reason to start very broad with the identified fault and then narrow
the likely causes into most likely causes.
forecast Throughout the project, the project manager will create forecasts about the expected
project completion date and projected project costs.
future value A formula to predict the current amount of funds into a future amount of funds.
The formula is Future Value = Present Value(1+i)n, where i is the interest rate and n is the number of time periods.
grouping methods Classify observations into groups by analysis, characteristics, experienced outcomes,
or other trends. Three common grouping methods are cluster analysis, discriminant
analysis, and exploratory study. Note that the PMBOK Guide mentions only exploratory
study.
historical information Any information created in the past that can help the current project succeed.
human resources plan Details on how the project team members will be brought onto and released from
the project.
integrated change control The analysis of a change’s effect on all components of the project. It examines
the proposed change and how it may impact scope, schedule, costs, quality, human resources,
communications, risk, procurement, and stakeholder management.
internal rate of return A benefit measurement formula to calculate when the present value of the cash inflow
equals the project’s original investment.
issue log Issues are decisions that are usually in disagreement among two or more parties.
They are recorded in the issue log, along with an issue owner designation, an issue
date for resolution, and the eventual outcome of the issue.
lessons learned Ongoing collection of documentation about what has and has not worked in the project;
the project manager and the project team participate in lessons-learned creation.
murder board A group of decision-makers who may determine to “kill” a proposed project before
it is officially launched, based on the board’s findings on the likelihood of the
project’s success.
net present value A benefit measurement formula that provides a precise measurement of the present
value of each year the project generates a return on investment.
payback period The duration of time it takes a project to earn back the original investment.
performance reports Formal reports that define how the project is performing with regard to time, cost,
scope, quality, and other relevant information.
present value A benefit measurement formula to determine what a future amount of funds is worth
today. The formula is Present Value = Future Value/(1+i)n, where i is the interest rate and n is the number of time periods.
process improvement plan Identifies methods to track and eliminate waste and non–value-added activities.
procurement documents All of the documents for purchasing, such as request for quotes, invitation to
bid, request for proposal, and the responses, are stored as part of the project documentation.
procurement management plan Describes the procurement process from solicitation, to source selection. The plan
may also include the requirements for selection as set by the organization.
project baselines Three baselines in a project are used to measure project performance: cost, schedule,
and scope.
project charter A document that authorizes the project, defines the high-level requirements, identifies
the project manager and the project sponsor, and provides initial information about
the project.
project funding requirements In larger projects, this document identifies the timeline of when capital is required
for the project to move forward. This document defines the amount of funds a project
needs and when the project funds are needed in order to reach its objectives.
project integration management The art and science of ensuring that your project moves forward and that your plan
is fully developed and properly implemented. Ten knowledge areas (project integration
management, scope, time, cost, quality, human resources, communications, risk, procurement,
and stakeholder management) have processes that contribute to the comprehensive project
management plan.
project management information system A PMIS is typically a software system, such as Microsoft Project, used to assist
the project manager in managing the project.
project plan A comprehensive document comprising several subsidiary plans that communicates
the intent and direction of the project.
proposal An exposé on ideas, suggestions, recommendations, and solutions to an opportunity
provided by a vendor for a seller. Proposals include a price for the work and document
how the vendor would provide the service to the buyer.
quality management plan Details the quality improvement, quality controls, and how the project will map
to the quality assurance program of the performing organization.
regression analysis A forecasting tool to measure and predict the link between two variables within
a project.
requirements management plan Defines how project requirements will be identified, prioritized, documented, and
managed throughout the project.
requirements traceability matrix A table that identifies all of the project requirements, when the requirements
are due, when the requirements are created, and any other pertinent information about
the requirements.
reserve analysis A contingency reserve for risk events should be periodically reviewed to ensure
that the amount of funds left in the contingency reserve is adequate for the remaining
risks and their probabilities in the project.
resource breakdown structure A chart that identifies the resources utilized in the project in each section of
the work breakdown structure.
resource calendar Indicates when people and facilities are available or scheduled to work on the
project.
resource requirements A planning document that identifies what resources are needed to complete the project
work. This includes people, materials, equipment, facilities, and services.
responsibility assignment matrix A table that maps roles to responsibilities in the project.
risk An uncertain event or condition that can have a positive or negative effect on
the project.
risk management plan Details the identified risks within the project, the risks associated with the
constraints and project assumptions, and how the project team will monitor, react,
or avoid risks.
risk register All risks, regardless of their probability or impact, are recorded in the risk
register, and their status is kept current in the issue log.
roles and responsibilities Maps project roles to responsibilities within the project; roles are positions
on the project team, and responsibilities are project activities.
schedule management plan Identifies circumstances that may change the project schedule, such as the completion
of project phases or the reliance on other projects and outside resources. The plan
details the approval and accountability process for changes within the project.
scope management plan Details how the project scope should be maintained and protected from change, as
well as how a change in scope may be allowed.
scoring models A project selection method that assigns categories and corresponding values to
measure a project’s worthiness of investment.
sellers list A list of the vendors with which an organization does business. Also called preferred
vendors list.
source selection criteria A predefined listing of the criteria to determine how a vendor will be selected—for
example, cost, experience, certifications, and the like.
stakeholder management plan Defines the level of engagement, the interrelationships among stakeholders, communications
requirements, and the timing of stakeholder engagement.
statement of work A document that defines the project work that is to be completed internally or
by a vendor.
supporting detail for estimates The project manager should document how time and cost estimates were created.
teaming agreement A contractual agreement that defines the roles, responsibilities, considerations,
and partnerships of two or more organizations that work together in a project. It’s
not unlike a partnership or subcontractor relationship.
trend analysis Examines recurring problems, threats, and even opportunities so you can react to
the situation based on the trends you’ve identified.
work performance information The current status of the project work; includes the results of activities, corrective
and preventive action status, forecasts for activity completion, and other relevant
information.
work performance measurements Predefined metrics for measuring project performance, such as cost variances, schedule
variances, and estimates to complete work.
TWO-MINUTE DRILLDeveloping the Project Charter
The project charter authorizes the project and names the project manager. The project charters not authorized by the project manager, but by a person or party
that has the power to grant the project manager the authority over the project resources.
The project charter defines the high-level requirements for the project and the
conditions for success.
Developing the Project Management Plan
The project plan is a collection of subsidiary project plans.
The project plan communicates the intent of the project.
Project planning is an iterative process that may require updates to the project
plan and other project documents.
Directing and Managing the Project Work
The project team executes the project plan in order to create the requirements of
the project.
The majority of the project’s time and budget are spent during project execution.
Team development and team management are executing processes.
The procurement requirements are completed during project execution.
Monitoring and Controlling the Project Work
Monitoring and controlling processes happen in tandem with the project execution
processes.
Earned value management (EVM) is a suite of formulas that can help the project management
team monitor the project performance.
Expert judgment comes from someone with more experience, who helps the project manager
make the best decision.
Change requests include scope changes, recommended corrective actions, recommended
preventive actions, and defect repair.
Performing Integrated Change Control
Integrated change control examines the effect of a change on the entire project.
All changes from scope, schedule, costs, and contract must pass through integrated
change control to determine whether the changes can be permitted in the project.
Changes, approved or declined, are documented in the project’s change control log.
Closing the Project or Phase
Closing the project or phase requires the project manager to follow the guidelines
of the organization and the project plan.
The project’s contract documentation can help guide the procedures for closing a
project or phase when the project is being completed by a vendor for a buyer.
Project documentation should be archived as part of project closure.
SELF TEST
1. You are a project manager for your organization. Management has asked you to help
determine which projects should be selected for implementation. In a project selection
model, which of the following is the most important factor?
A. Business needs
B. The type of constraints
C. The budget
D. The schedule
2. Beth is the project manager of a software development project. She and her project
team are done with a phase and Beth needs to make certain the lessons-learned documentation
is complete before moving the project onto the next phase. On any project, the lessons-learned
document is created by which of the following?
A. The customers
B. The project sponsor
C. The project team
D. The stakeholders
3. Your project is moving ahead of schedule. Management elects to incorporate additional
quality testing into the project to improve the quality and acceptability of the project
deliverable. This is an example of which one of the following?
A. Scope creep
B. Change control
C. Quality assurance
D. Integrated change control
4. You are the project manager of a new website design project. There are 45 stakeholders
with this project and you are anticipating change requests in the project. Which of
the following is not true about change requests?
A. They happen while the project work is being done.
B. They always require additional funding.
C. They must be documented.
D. They can be requested by a stakeholder.
5. You are the project manager for a pharmaceutical company. You are currently working
on a project for a new drug your company is creating. A recent change in a law governing
drug testing will change your project scope. Since the project must be completed within
two years, what’s the first thing you should do as project manager?
A. Create a documented change request.
B. Proceed as planned, since the project will be grandfathered beyond the new change
in the law.
C. Consult with the project sponsor and the stakeholders.
D. Stop all project work until the issue is resolved.
6. During project execution activities, a project sponsor’s role in a functional organization
can best be described as doing which one of the following?
A. Acting as a sounding board for the project stakeholders
B. Helping the project manager and stakeholders resolve any issues ASAP
C. Deflecting change requests for the project manager
D. Showing management the project progress and status reports
7. You are the project manager for the HALO Project. You and your project team are
preparing the project plan. Of the following, which one is a project plan development
constraint you and your team must consider?
A. The budget as assigned by management
B. Project plans from similar projects
C. Project plans from similar projects that have failed
D. Interviews with subject matter experts (SMEs) who have experience with the project
work in your project plan
8. You are the project manager of HYH Project for your company, and you’re working
with the project team and several key stakeholders to develop the project management
plan. Which of the following is the primary purpose of the project management plan?
A. To define the work to be completed to reach the project end date
B. To define the work needed in each phase of the project life cycle
C. To prevent any changes to the scope
D. To define how the project is executed, monitored, controlled, and then closed
9. Of the following, which is an input to project plan development?
A. The project scope statement
B. Project planning methodology
C. EVM
D. Business needs
10. You are examining the project management plan and its components with the project
team. The team doesn’t understand why so much information is needed for the project.
What is the difference between a project baseline and a project plan?
A. Project plans change as needed, while baselines change only at milestones.
B. Project plans and baselines do not change—they are amended.
C. Project plans change as needed, while baselines are snapshots of the project plan.
D. Baselines are control tools, while project plans are execution tools.
11. Which one of the following is not beneficial to the project manager during the
project plan development process?
A. Gantt charts
B. PMIS
C. The project management methodology
D. Stakeholder knowledge
12. Yoli is the project manager for her company and she’s reviewing the project budget
with management. Management is concerned about the capital expenses in the project
and they’d like more information about when Yoli will actually spend the project budget.
Which one of the following represents the vast majority of a project’s budget?
A. Project planning
B. Project plan execution
C. Labor
D. Cost of goods and services
13. The project plan provides a baseline for several things. Which one of the following
does the project plan not provide a baseline for?
A. Scope
B. Cost
C. Schedule
D. Control
14. Natasha is the project manager for her organization. She is meeting with her project
stakeholders to review the project plan and the different elements she’ll use as part
of project execution. Which of the following can best help Natasha during project
execution?
A. Stakeholder analysis
B. Change control boards
C. PMIS
D. Scope verification
15. You are the project manager for your organization. When it comes to integrated
change control, you must ensure that which one of the following is present?
A. Supporting detail for the change exists
B. Approval of the change from the project team
C. Approval of the change from an SME
D. Risk assessment for each proposed change
16. Jeff is the project manager of the Bridge Construction Project for his company.
This project requires strict change control because of government regulations, the
cost of the project deliverables, and the approved scope. The project plan provides
what with regard to project changes?
A. A methodology to approve or decline CCB changes
B. A guide to all future project decisions
C. A vision of the project deliverables
D. A fluid document that may be updated as needed based on the CCB
17. You are the project manager for the DGF Project. This project is to design and
implement a new application that will connect to a database server. Management of
your company has requested that you create a method to document technical direction
on the project and to document any changes or enhancements to the technical attributes
of the project deliverable. Which one of the following would satisfy management’s
request?
A. Configuration management
B. Integrated change control
C. Scope control
D. The change management plan
18. Baseline variances, a documented plan to management variances, and a proven methodology
to offer corrective actions to the project plan are all part of which process?
A. Change management
B. The change control system
C. The scope change control
D. Integrated change control
19. One of the requirements of project management in your organization is to describe
your project management approach and methodology in the project plan. You can best
accomplish this requirement through which one of the following actions?
A. Establishing a project office
B. Establishing a program office
C. Compiling the management plans from each of the knowledge areas
D. Creating a PMIS and documenting its inputs, tools and techniques, and outputs
20. You have just informed your project team that each team member will be contributing
to the lessons-learned documentation. Your team does not understand this approach
and wants to know what the documentation will be used for. Which one of the following
best describes the purpose of the lessons-learned documentation?
A. Offers proof of concept for management
B. Offers historical information for future projects
C. Offers evidence of project progression as reported by the project team
D. Offers input to team member evaluations at the project conclusion
21. Which one of the following is a formal document to manage and control project execution?
A. WBS
B. The project management plan
C. The organizational management plan
D. The work authorization system
22. Configuration management is a process for applying technical and administrative
direction and surveillance of the project implementation. Which activity is not included
in configuration management?
A. Controlling changes to the project deliverables
B. Scope verification
C. Automatic change request approvals
D. Identification of the functional and physical attributes of the project deliverables
23. You are preparing to enter into the project work with your project. As part of
your preparation, you’ll rely on your project management plan and several tools and
techniques. Which of the following contains parts of the project plan execution?
A. PMIS, WBS, and EVM
B. General management skills, status review meetings, and EVM
C. Project management methodology and the PMIS
D. General management skills, status review meetings, and interpersonal skills
24. You are the project manager of the GHQ Project for your company. Management has
required that you utilize earned value management as part of your project and their
enterprise environmental factors. EVM is used during the _______________.
A. Controlling processes
B. Executing processes
C. Closing processes
D. Entire project
25. You are the project manager for your organization. Management would like you to
use a tool that can help you plan, schedule, monitor, and report your findings on
your project. Which of the following is the correct tool to use?
A. PMIS
B. EVM
C. Status review meetings
D. Project team knowledge and skill set
SELF TEST ANSWERS
1. You are a project manager for your organization. Management has asked you to help
determine which projects should be selected for implementation. In a project selection
model, which of the following is the most important factor?
A. Business needs
B. The type of constraints
C. The budget
D. The schedule
A. Projects are selected based on business needs first.
B is incorrect because project constraints are typically not an issue when a project
is selected, but the feasibility of a project to operate within the project constraints
may be. C, the project budget, is incorrect, because the project budget is a project constraint.
D is incorrect because the project schedule is also a constraint.
2. Beth is the project manager of a software development project. She and her project
team are done with a phase and Beth needs to make certain the lessons-learned documentation
is complete before moving the project onto the next phase. On any project, the lessons-learned
document is created by which of the following?
A. The customers
B. The project sponsor
C. The project team
D. The stakeholders
C. The project team contributes to the lessons-learned document. The project manager
also contributes, or leads, the creation, but this is not a choice in the question.
A is incorrect because the customers do not contribute to the lessons-learned document.
B is incorrect because the project sponsor does not contribute to the lessons-learned
document. D is incorrect because stakeholders, other than the project manager and the project
team, do not contribute.
3. Your project is moving ahead of schedule. Management elects to incorporate additional
quality testing into the project to improve the quality and acceptability of the project
deliverable. This is an example of which one of the following?
A. Scope creep
B. Change control
C. Quality assurance
D. Integrated change control
D. Additional quality testing will require additional time and resources for the project.
This is an example of integrated change control.
A is incorrect because scope creep includes small, undocumented changes to the project
execution. B, change control, is incorrect because change control falls within integrated change
control. C is incorrect because QA is an organization-wide program.
4. You are the project manager of a new website design project. There are 45 stakeholders
with this project and you are anticipating change requests in the project. Which of
the following is not true about change requests?
A. They happen while the project work is being done.
B. They always require additional funding.
C. They must be documented
D. They can be requested by a stakeholder.
B. Change requests do not always require more money. Approved changes may require more
funds, but not always. The change request may be denied, so no additional funds are
needed for the project.
A, C, and D are all incorrect choices because these are characteristics of change requests during
a project. For more information, see Section 4.6 in the PMBOK.
5. You are the project manager for a pharmaceutical company. You are currently working
on a project for a new drug your company is creating. A recent change in a law governing
drug testing will change your project scope. Since the project must be completed within
two years, what’s the first thing you should do as project manager?
A. Create a documented change request.
B. Proceed as planned, since the project will be grandfathered beyond the new change
in the law.
C. Consult with the project sponsor and the stakeholders.
D. Stop all project work until the issue is resolved.
A. A formal, documented change request is the best course of action for a change request
stemming from a law or regulation.
B is incorrect because the law or regulation will likely override any existing project
implementation. C is incorrect because the project manager should first document the change through
a change request. D is incorrect because all project work shouldn’t stop just because of a change request.
6. During project execution activities, a project sponsor’s role in a functional organization
can best be described as doing which one of the following?
A. Acting as a sounding board for the project stakeholders
B. Helping the project manager and stakeholders resolve any issues ASAP
C. Deflecting change requests for the project manager
D. Showing management the project progress and status reports
B. The project sponsor can help the project manager and the stakeholders resolve issues
during project execution.
A is incorrect because the project sponsor is going to have an active rather than passive
role in the process of integration management. C is incorrect because the project sponsor will guide changes through the change control
system. D is not a valid choice because the project sponsor is part of management and will
do more than report the status to other management roles.
7. You are the project manager for the HALO Project. You and your project team are
preparing the project plan. Of the following, which one is a project plan development
constraint you and your team must consider?
A. The budget as assigned by management
B. Project plans from similar projects
C. Project plans from similar projects that have failed
D. Interviews with subject matter experts (SMEs) who have experience with the project
work in your project plan
A. If management has assigned the project the constraint of a fixed budget, the project
manager and the project team must determine how the project can operate within that
constraint.
B describes historical information, not a project constraint. C also is historical information and not a project constraint, so it, too, is incorrect.
D is a valuable tool to use as input into the project plan development, but it is not
a constraint.
8. You are the project manager of HYH Project for your company, and you’re working
with the project team and several key stakeholders to develop the project management
plan. Which of the following is the primary purpose of the project management plan?
A. To define the work to be completed to reach the project end date
B. To define the work needed in each phase of the project life cycle
C. To prevent any changes to the scope
D. To define how the project is executed, monitored, controlled, and then closed
D. Of all the choices presented, D is the best choice. Project management plans communicate to the project team, the
project sponsor, and stakeholders how the entire project will operate.
A and B are incorrect because they do not define the primary purpose of the project plan.
C is also incorrect because the project plan is intended not to prevent changes, but
to communicate the project management life cycle.
9. Of the following, which is an input to project plan development?
A. The project scope statement
B. Project planning methodology
C. EVM
D. Business needs
A. Of the choices, the project scope statement is the only input to the project plan
development.
B is incorrect because it describes a tool and technique used to develop the project
plan. C is also a tool and technique to develop the project plan and does not serve as input
to the plan. D is incorrect because it is an input to the planning processes.
10. You are examining the project management plan and its components with the project
team. The team doesn’t understand why so much information is needed for the project.
What is the difference between a project baseline and a project plan?
A. Project plans change as needed, while baselines change only at milestones.
B. Project plans and baselines do not change—they are amended.
C. Project plans change as needed, while baselines are snapshots of the project plan.
D. Baselines are control tools, while project plans are execution tools.
D. A project baseline serves as a control tool. Project plan execution and work results
are measured against the project baselines.
A is incorrect, given that baselines are changed with the project plan. B is incorrect because project plans and baselines do change. C is incorrect because baselines are more than snapshots of the project plans—they
are expectations of how the work should be performed.
11. Which one of the following is not beneficial to the project manager during the
project plan development process?
A. Gantt charts
B. PMIS
C. The project management methodology
D. Stakeholder knowledge
A. Gantt charts are excellent tools to measure and predict the project progress, but
they are not needed during the project plan development process.
B, C, and D are needed and expected during the development of the project plan.
12. Yoli is the project manager for her company and she’s reviewing the project budget
with management. Management is concerned about the capital expenses in the project
and they’d like more information about when Yoli will actually spend the project budget.
Which one of the following represents the vast majority of a project’s budget?
A. Project planning
B. Project plan execution
C. Labor
D. Cost of goods and services
B. The project plan execution represents the majority of the project budget.
A, project planning, does not reflect the majority of the project budget, although it
may contain the most project processes. C, labor, does not reflect the biggest project expense in all projects. D, cost of goods and services, is incorrect because the procurement of the goods and
services will fall within the project plan execution. In addition, not every project
will procure goods and services.
13. The project plan provides a baseline for several things. Which one of the following
does the project plan not provide a baseline for?
A. Scope
B. Cost
C. Schedule
D. Control
D. Control is not a baseline.
A, B, and C describe the project baselines contained within the project plan. Incidentally, scope,
cost, and schedule are also the attributes of the Triple Constraints of Project Management.
14. Natasha is the project manager for her organization. She is meeting with her project
stakeholders to review the project plan and the different elements she’ll use as part
of project execution. Which of the following can best help Natasha during project
execution?
A. Stakeholder analysis
B. Change control boards
C. PMIS
D. Scope verification
C. A PMIS can assist the project manager the most during project execution. It does
not replace the role of the project manager, however.
A is incorrect because stakeholder analysis should have been completed during the project
planning processes. B also is incorrect because CCBs can assist the project manager, but not as much as
the control and assistance offered through a PMIS. D is incorrect because scope verification is proof of the project work and does not
assist the project manager.
15. You are the project manager for your organization. When it comes to integrated
change control, you must ensure that which one of the following is present?
A. Supporting detail for the change exists
B. Approval of the change from the project team
C. Approval of the change from an SME
D. Risk assessment for each proposed change
A. Integrated change control requires detail for implementing the change. Without evidence
of the need for the change, there is no reason to implement it.
B is incorrect because the project team’s approval is not necessary for changes. C is incorrect because a subject matter expert isn’t always needed to determine the
need for change. D is also incorrect because although risk assessment is needed for changes, some changes
may be discarded based on reasons other than risk.
16. Jeff is the project manager of the Bridge Construction Project for his company.
This project requires strict change control because of government regulations, the
cost of the project deliverables, and the approved scope. The project plan provides
what with regard to project changes?
A. A methodology to approve or decline CCB changes
B. A guide to all future project decisions
C. A vision of the project deliverables
D. A fluid document that may be updated as needed based on the CCB
B. The project plan serves as a guide to all future project decisions.
A is incorrect because the project plan details more than how changes may be approved
or denied. Recall that the change control board (CCB) approves and declines changes.
C is also incorrect because the project plan describes how to obtain the project vision,
not just what the project vision may be. D does describe the project plan but not as fully as choice B. In addition, the project
plan can be updated without changing the project scope.
17. You are the project manager for the DGF Project. This project is to design and
implement a new application that will connect to a database server. Management of
your company has requested that you create a method to document technical direction
on the project and to document any changes or enhancements to the technical attributes
of the project deliverable. Which one of the following would satisfy management’s
request?
A. Configuration management
B. Integrated change control
C. Scope control
D. The change management plan
A. Configuration management is the documentation of the project product, its attributes,
and its changes to the product.
B is incorrect because integrated change control describes how to incorporate all of
the project changes across the knowledge areas. C is incorrect because scope control describes how to manage changes, or potential
changes, to the project scope. D is also incorrect because the change management plan does not describe the project
product, its features, or changes to the product.
18. Baseline variances, a documented plan to management variances, and a proven methodology
to offer corrective actions to the project plan are all part of which process?
A. Change management
B. The change control system
C. The scope change control
D. Integrated change control
D. Integrated change control is a system to document changes, their impact, the response
to those changes, and performance deficits.
A is incorrect because change management does not respond to performance deficits as
integrated change control does. B is incorrect because the change control system is a documented procedure to manage
change requests. C is incorrect because scope change control is the process of managing changes that
affect the work only in the project scope.
19. One of the requirements of project management in your organization is to describe
your project management approach and methodology in the project plan. You can best
accomplish this requirement through which one of the following actions?
A. Establishing a project office
B. Establishing a program office
C. Compiling the management plans from each of the knowledge areas
D. Creating a PMIS and documenting its inputs, tools and techniques, and outputs
C. The management approach is best described as a compilation of the individual plans
in the project plan.
A is incorrect because a project office is not needed to describe the management approach.
B is incorrect for the same reason. D may be a good practice for project control, but it does not describe management approach
and methodologies.
20. You have just informed your project team that each team member will be contributing
to the lessons-learned documentation. Your team does not understand this approach
and wants to know what the documentation will be used for. Which one of the following
best describes the purpose of the lessons-learned documentation?
A. Offers proof of concept for management
B. Offers historical information for future projects
C. Offers evidence of project progression as reported by the project team
D. Offers input to team member evaluations at the project conclusion
B. The lessons-learned document offers historical information for future projects.
A is incorrect because proof of concept likely comes early in the project’s planning
processes. C is also incorrect because lessons learned may offer evidence of project progression,
but it is not the purpose of the lessons-learned document. D is also incorrect, given that lessons learned offers historical information for future
projects.
21. Which one of the following is a formal document to manage and control project execution?
A. WBS
B. The project management plan
C. The organizational management plan
D. The work authorization system
B. The project management plan is the formal document used to manage and control project
execution.
A is incorrect—the WBS is an input to the project plan. C is incorrect because the organizational management plan is part of the project plan.
D is incorrect because the work authorization system allows work to be approved and
for new work to begin.
22. Configuration management is a process for applying technical and administrative
direction and surveillance of the project implementation. Which activity is not included
in configuration management?
A. Controlling changes to the project deliverables
B. Scope verification
C. Automatic change request approvals
D. Identification of the functional and physical attributes of the project deliverables
C. Hopefully, automatic change request approvals are not included in any project. They
are not a part of configuration management.
A, B, and D all describe attributes of configuration management.
23. You are preparing to enter into the project work with your project. As part of
your preparation, you’ll rely on your project management plan and several tools and
techniques. Which of the following contains parts of the project plan execution?
A. PMIS, WBS, and EVM
B. General management skills, status review meetings, and EVM
C. Project management methodology and the PMIS
D. General management skills, EVM, status review meetings, and interpersonal skills
C. The project management methodology and the PMIS are the tools and techniques used
for project execution.
A is incorrect because EVM and the WBS are not part of the tools used in the project
plan execution. B is incorrect because it includes EVM. D is incorrect because it also includes EVM.
24. You are the project manager of the GHQ Project for your company. Management has
required that you utilize earned value management as part of your project and their
enterprise environmental factors. EVM is used during the _______________.
A. Controlling processes
B. Executing processes
C. Closing processes
D. Entire project
D. EVM, earned value management, is used throughout the project processes. It is a planning
and control tool used to measure performance.
A, B, and C are correct in that EVM is used during these processes, but none of these answers
is as good a choice as D.
25. You are the project manager for your organization. Management would like you to
use a tool that can help you plan, schedule, monitor, and report your findings on
your project. Which of the following is the correct tool to use?
A. PMIS
B. EVM
C. Status review meetings
D. Project team knowledge and skill set
A. PMIS is the best answer because it helps the project manager plan, schedule, monitor,
and report findings.
B is incorrect because EVM does not help the project manager schedule. C is incorrect because status review meetings do not help the project manager schedule.
D is incorrect because the project team’s knowledge and skills do not necessarily help
the project manager plan, schedule, monitor, and report findings.
