PM Framework

• Organizational Project Management (OPM): Provides a strategic framework

to use and guide portfolio, program, and project management to achieve the
organization’s strategic goals
• PMO
• Supportive: provides policies, methodologies, templates, etc. Low level of
control over projects
• Controlling: provides support and guidance on how to manage projects.
Trains PMs. Doesn’t provide the PMs or manage the project. Medium level of
control over projects
• Directive: Provides the PM for projects. Manages all of the projects. High level
of control over projects.
• Assumption log includes both assumptions and constraints. Assumptions
might also be considered “expectations” because stakeholders might not
realize they are making assumptions
• Project lifecycle: What you need to do to do the work.
• Project management process (or lifecycle): What you need to do to manage
the work.
• Sponsor: Project manager works with the sponsor to address internal
political and strategic issues that may affect the team or the viability or
quality of the project.
• EEF keywords: Can be internal or external. Conditions not under immediate
control of the team, that influence, constrain, or direct the project, program
or portfolio. Here are the keywords to focus on in order to figure out if it’s an
EEF.
o Culture
o Commercial databases
o Systems
o Industry standards
o Company work authorization systems
o Employee capabilities/availability/location/distribution
• OPA keywords: Think “P”. Plans, Processes, policies, procedures (and
knowledge) that are specific to and used by the performing organization.
o Plans, policies, procedures
o Product and project lifecycles
o Lessons learned and historical information
o Templates
o Monitoring and reporting methods
o Cost control tools
o Previous project files
• Major categories of project selection methods
o Benefit measurement methods (comparative)
o Constrained optimization methods (mathematical)
• We set up baselines at the end of planning. Then we move into execution.
Knowledge Areas

Integration Management

• All about the high-level work a project manager has to do

• The seven processes in this knowledge area focus on the larger, macro things
that must be performed in order for the project to work and for the
organization to learn from it. This knowledge area is about the “whole forest”
as opposed to the individual trees.
• Integration management is the practice of making certain that every part of
the project is coordinated.
• It takes a high-level view of the project from start to finish.
• This knowledge area is specific to project managers. Whereas specialists may
manage other knowledge areas, the accountability of Project Integration
Management cannot be delegated or transferred. The project manager is the
one who combines the results in all other knowledge areas and has the
overall view of the project. The project manager is ultimately responsible for
the project as a whole.
• Balancing all of the processes in all of the knowledge areas with each other.
• Present Value: PV = FV/(1+r)^n; where r=interest rate and n=number of
time periods
• Net Present Value (NPV): The larger the better. Time period doesn’t matter if
it’s already calculated for you.
• Internal Rate of Return (IRR): The larger the better. Won’t have to calculate
it.
• Cost-Benefit Analysis: Looks only at revenue. NOT profit.
o 1: Benefit greater than the cost
o =1: Benefit and cost are equal
o <1: Cost is greater than the benefit
• Configuration Management: storage and retrieval system for changes? Keeps
track of versions. Related to naming conventions, version control processes.
Scope Management

• Project Scope: Requirements. The features and functions that characterize a

product, service, or result. Completion of the project scope is measured
against the project management plan. Ex: Lessons learned is part of project
scope, but not product scope because it does not have anything to do with
producing the product.
• Product Scope: Deliverables. The work performed to deliver a product,
service, or result with the specified features and functions. Includes the
product scope. Completion of the product scope is measures against the
product requirements.
• The Project Scope is the work the project team will do to deliver the product
of the project; it encompasses the product scope. It includes things such as
planning, coordination, and management activities (meetings and reports)
that ensure the product scope is achieved.
• The Scope Management Process includes the following steps
o Develop a plan for how you will plan, validate, and control scope and
requirements on the project.
o Determine requirements, making sure all requirements support the
project’s business case as described in the project charter.
o Sort and balance the needs of stakeholders to determine scope.
o Create WBS to break the scope down into smaller, more manageable
pieces and define each piece in the WBS dictionary.
o Checking the work being done against the scope to ensure that it is
complete.
o Ensuring that all of what is “in scope” and only what is “in scope” is
completed and that changes were properly managed.
o Obtain validation (signed acceptance) that the completed scope of
work is acceptable to the customer or sponsor.
o Measure scope performance, and adjust as needed.
• The overall goals of scope management are the define the need, to set
stakeholder expectations, to deliver to the expectations, to manage changes,
and to minimize surprises so that the product will ultimately gain approval.
• For adaptive/agile, three processes (Collect Requirements, Define Scope,
Create WBS) are repeated for each iteration. Likewise, the processes Validate
Scope and Control Scope are repeated for each iteration with the sponsor or
customer. And finally, adaptive/agile uses backlogs to reflect their current
needs.
• For predictive, Collect Requirements, Define Scope, Create WBS processes
are performed at the beginning of the project and updated as necessary,
using the integrated control process. Likewise, Validate Scope and Control
Scope occurs with each deliverable or phase review and control scope is an
ongoing processes. And finally for predictive, the scope baseline for the
project is the approved version of the project scope statement, WBS and WBS
dictionary. A baseline can be changed only through formal change control
 procedures and is used as a basis for comparison while performing Validate
Scope and Control Scope processes as well as other controlling processes.
• Scope is completeness while quality is correctness.
Schedule Management

• Theory of constraints: Identifying the most limiting factor (bottleneck).

Systematically improving that constraint until it is no longer the limiting
factor.
• The topics of scope, schedule, and cost are particularly tightly linked.
Changes made in one area will almost certainly have direct impacts on the
other two.
• By starting with the WBS, you can define the work that must be carried out in
order to produce the deliverables. The individual schedule activities are then
sequenced, and the resource and duration estimates are applied to these
activities.
Cost Management

• Costs should be tied to activities and resources and estimates should be built
from the bottom up.
• Scope first, schedule second, budget third
• At the point in the process where budgets are created, you should have a
well-defined WBS, an activity list with resource and duration estimates for
each activity, and a schedule.
• The budget is then created by applying rates and dates against those
resources and activities to create activity cost estimates and a cost baseline.
• Life Cycle Costing: Looking at costs over the entire life of the product, not just
the cost of the project to create the product.
• Value Analysis: Sometimes referred to as value engineering. The focus is on
finding a less costly way to do the same work. Answers the question, “How
can we decrease cost on the project while maintaining the same scope?”
Finding ways to provide required features at the lowest overall cost without
loss of performance.
• Cost Risk: Involves cost, risk, and procurement management. It means cost-
related risk. Ex: Who has the cost risk in a fixed price contract—the buyer or
the seller? The seller. Cost risk is the risk that the project costs could go
higher than planned.
Quality Management

• Quality is defined as the degree to which the project fulfills requirements.

• Quality is more than just about the quality of the product. It is also about the
quality of the process.
• Used to rely heavily on inspection. Now, we focus on precention.
• Therefore requirements’ gathering during scope management is very
important for plan-driven, predictive projects.
• Quality Management includes creating and following organizational policies
and procedures and tailoring them to ensure the project also meets the needs
of the customer. It also means ensuring a project is completed in compliance
with the project requirements.
• In adaptive, change-driven environments, we capture quality requirements
and acceptance criteria in user stories.
• Plan, Do, Check, Act: Deming Cycle. Takes an iterative and incremental
approach to quality management which can reduce variations in the process,
thus improving quality and reducing waste.
• Quality Costs
o Prevention: Quality Assurance: Delivery of the exact scope and the
expected quality. Do it right.
o Appraisal: Quality Control/Inspection. Cost of measuring, testing,
auditing
o Failure: Scrap and rework.
• Ideally, organizations not only inspect their deliverables for quality before
they reach the customer, but also evaluate and adjust their quality
management processes in an effort to identify the cause of defects, as well as
planning quality into projects.
• Always better to plan in quality rather than inspect to find quality problems.
• Important to know in advance what the definition of “acceptable quality” is
and how it will be measured on a project.
• Quality Management in the real world
o The customer determines their requirements
o The project team clarifies those requirements
o The project team defines what work will be done to meet those
requirements (project scope)
o The project manager determines the existing standards, policies, and
procedures that might be available for the project. The quality
department might assist in identifying the relevant standards
o The project manager creates other standards and processes that may
be needed
o The project manager develops the quality management plan,
encompassing relevant standards and processes.
o The project manager integrates quality with other knowledge area
plans to get an approved project management plan.
o The team begins executing the project management plan
 § The team or the quality department evaluates the quality of
project deliverables against planned metrics and standards
(Control Quality).
§ The team or the quality department audits the project work
periodically as part of the executing process, looking for
indications that the standards, policies, plans, and procedures
are not being followed or need to be changed. (Manage
Quality)
§ Results are analyzed.
o Deliverables are verified
o Lessons learned are documented and shared
o Change request, including corrective and preventive action and defect
repair, are sent to integrated change control.
o Change requests, including corrective and preventive action and
defect repair, are approved or rejected in integrated change control.
o The team adjusts plans as needed to accommodate approved or
rejected changes and returns to step 7 until project deliverables are
complete and verified.
o New organizational process assets, including lessons learned, are
shared with the organization.
o Verified deliverables are accepted by the customer, the project is
completed, quality targets are reached, and the customer is happy.
• Actions required to ensure quality on a project (formal actions)
o Review the project management plan, particularly the project
baselines, and relevant project documents as they relate to quality on
the project
o Make sure you know and understand the customer’s definition of
quality
o Identify the desired levels of performance in the product and
components of the product
o Identify at what level you should control the project (for example, the
work package, activity, or a more detailed level)
o Identify any quality standards and processes that are applicable to the
project
o Identify the required level of quality for the project management
activities
o Determine the quality standards and processes to use, when and on
what parts of the project
o Set standards to reach the level of desired performance for activities
and the project
o Set metrics to measure quality from the customer’s and organization’s
perspective
o Decide what you will do to make sure the processes are followed and
the standards are met
o Determine how you will improve the processes on the project
o Test the validity of assumptions before they result in problems
 o Make sure team members understand what quality means for their
work
o Review problems, errors, and complaints to determine what can be
done to prevent them from reoccurring on the project.
o Have the team follow planned efforts to evaluate the project to look
for quality improvements
o Inspect work as it is being done, not after
o Perform quality reviews
o Measure performance against standards
o Hold meetings, issue reports, measure and perform calculations to
evaluate variances
o Reassess the quality standards
o Evaluate the effectiveness of the quality control system
o Manage quality with the same effort as time, cost, or scope
o Request changes, including corrective and preventive actions and
defect repairs
o Update organizational process assets with information and data
learned from process improvement and control efforts
o Include quality issues in lessons learned
o Feed lessons learned back into the project.
• Quality terms
o Continuous Improvement/Kaizen: Continuously looking for ways to
improve the quality of work, processes, and results. W. Edwards
Deming. Six Sigma.
o TQM: Total Quality Management. Everyone in the company is
responsible for quality and able to make a difference.
o JIT: Being inventory down to zero (or near zero).
o ISO 9000
• For the exam, if given a situation
o If it is looking forward in time, it is most likely a planning function in
Plan Quality Management.
o If it is looking back in time at processes and procedures, it is most
likely part of Manage Quality
o If it is looking back in time at project results it is mot likely part of
Control Quality.
Resource Management

• Emotional Intelligence (EI): Project managers should be able to identify,

assess, and manage their personal emptions as well as the emotions of a
group of stakeholders.
• Creating a recognition and reward system is an important resource
management function
• Project manager is responsible for improving the competencies of team
members so they are able to perform the work on the project most
effectively.
• Projects are planned by the team and coordinated by the project manager
• The project manager must continually confirm resource availability.
• On large projects, the project manager might have some team members help
with project management activities. These people are called the “project
management team”. So the project team consists of the project manager, the
project management team, and the other members of the team who will be
doing the work of the project.
• Project manager responsibilities
o Determine what human and physical resources you will need
o Negotiate with resource managers for the optimal available resources
o Work with the procurement department if necessary
o Confirm availability of assigned resources
o Create a project team directory
§ Documented list of team members, their project roles, and
communication info (phone, email). Different from project
team assignments which is a wider document that may contain
the project team directory and additional information such as
specific responsibilities of and activities assigned to each team
member as well as their knowledge, skills, and abilities.
o Create project job descriptions for team members and other
stakeholders
o Make sure all roles and responsibilities on the project are clearly
assigned.
o Understand the team members’ training needs related to their work
on the project, and make sure team members get any necessary
training
o Create a formal plan—the resource management plan—covering
topics such as how the team will be involved in the project and what
roles they will perform
o Send out letters of commendation to team members and their
managers to recognize exceptional performance of project work.
o Make sure the needs of all team members are acknowledged and
considered
o Create recognition and reward systems.
o Use emotional intelligence (EI)
o In a change-drive environment, encourage self-organizing teams and
provide support as needed.
o Plan for and manage communications challenges specific to virtual
teams
o Tailor the resource management plan as appropriate to the need of
the project
o Encourage collaboration among team members
o Determine what physical resources will be needed on the project, and
when they will be needed.
o Determine the quality, grade, and amount of physical resources
needed on the project
o Plan ahead to ensure physical resources are available and accessible
when needed
o Use resources efficiently
o Look for ways to improve resource utilization
o Evaluate and select appropriate methods of managing physical
resources.
Communication Management

• Internal: Focus on stakeholders within the project and within the

organization
• External: Focus on external stakeholders such as customers, vendors, other
projects, organizations, government, the public, and environmental
advocates
• Project manager’s most important skillset is the ability to communicate
effectively.
• 90% of project manager’s time is communicating. 50% of that time is
communicating with the team.
• Formal: Reports, formal meetings (both regular and ad hoc), meeting
agendas and minutes, stakeholder briefings, and presentations
• Requires that you accurately report on the project status, performance,
change, and earned value.
• Formal and informal, written and verbal.
• Informal: General communications activities using emails, social media,
websites, and informal ad hoc discussions
• Hierarchical focus: the position of the stakeholder or group with respect to
the project team will affect the format and content of the message in the
following ways
o Upward: Senior management stakeholders
o Downward: The team and others who will contribute work to the
project
o Horizontal: Peers of the project manager or team
• Official: Annual reports; reports to regulators or government bodies
• Unofficial: communications that focus on establishing and maintaining the
profile and recognition of the project and building strong relationships
between the project team and its stakeholders using flexible and often
informal means
• Written and oral: Verbal and nonverbal, social media, and websites, media
releases
Risk Management

• A project manager’s work should not focus on dealing with problems; it

should focus on preventing them.
• Effective risk management helps to increase the probability and/or impact of
positive risk, or opportunities. When you eliminate threats and increase
opportunities, project schedule and cost estimates can be deceased,
reflecting the results of risk management efforts.
• Risk Management: The process of identifying evaluating, and planning
responses to events, both positive and negative that might occur throughout
the course of a project. Through risk management, you increase the
probability and impact of opportunities on the project (positive events)
while decreasing the probability and impact of threats to the project
(negative events)
• Individual project risk: Threatens an objective. Ex: a decision is made to
move something from a local server into the cloud in order to save money
and improve uptime. There might be an individual risk associated with that.
If the move could not be carried out, it might threaten the objectives of
saving money and increasing uptime, but it could still be moved back to the
local server and continue the project.
• Overall project risks: Things that threaten the success of the project.
• Threats and opportunities: Negative and positive impact
• Risk factors: when assessing risk, it’s necessary to determine the following:
o The probability that a risk event will occur (how likely)
o The range of possible outcomes (impact or amount at stake)
o Expected timing for it to occur in the project life cycle (when)
o The anticipated frequency of risk events fro that source (how often)
• Risk appetite (risk tolerance): The level of risk and individual or group is
willing to accept.
• Risk threshold: The specific point at which risk becomes unacceptable.
• Risk averse: Someone who does not want to be negatively impacted by
threats.
• Risk management process (results of)
o There are no longer huge “fires” to put out every day—they are
eliminated with risk response plans
o Risks are reviewed in every meeting, triggers are monitored, and risks
are addressed before they happen
o Normally, if a risk event does occur, there is a plan in place to deal
with it. Hectic meetings to develop responses are a rarity, and are only
needed when an unknown risk even occurs and requires the
development of a workaround.
o As a result, the project manager has time for efforts such as
§ Monitoring and controlling the various aspects of the project,
looking for deviations and trends to find them early
§ Implementing a reward system
 § Developing the team
§ Keeping stakeholders informed of project progress
§ Staying ahead of the project
• Utility function: An organization’s tolerance for risk
• Contingency Reserve: calculated with a probability/impact matrix.
%probable x Impact (either – or +). Add all up for contingency reserve.
• One way to deal with a schedule that needs to be compressed is to first
review risks
• Non-event risks
o Variability risk: Uncertainty exists about some key characteristics of a
planned event or activity or decision. Ex: Productivity ay be above or
below target, unseasonal weather conditions may occur during the
construction phase. Can be addressed using Monte Carlo analysis.
o Ambiguity risk: Uncertainty exists about what might happen in the
future. Ex: areas of the project where imperfect knowledge might
affect the project’s ability to achieve it’s objectives.
Procurement Management

• Typical steps
o Prepare the procurement statement of work (SOW) or terms of
reference (TOR)
o Prepare a high-level cost estimate to determine the budget
o Advertise the opportunity
o Identify a short list of qualified sellers
o Prepare and issue bid documents
o Prepare and submit proposals by the seller
o Conduct a technical evaluation of the proposals including quality
o Perform a cost evaluation of the proposals
o Prepare the final combined quality and cost evaluation to select the
winning proposal
o Finalize negotiations and sign contract between the buyer and the
seller.
• The basic procurement management skills required of a project manager
include being able to help create, read, and manage contracts and any
supporting documentation.
• Seller can be a contractor, vendor, service provider or supplier.
• Contract: Can be written or verbal, typically created with someone outside
the company and involve an exchange of goods or services for some type of
compensation. Forms the legal relationship between the entities; it is
mutually binding and provides the framework for how a failure by one side
will be addressed.
• Agreement: encompasses documents or communications that outline
internal or external relationships and their intentions. A contract is a type of
agreement, but an agreement isn’t necessarily a contract. Agreements can be
used to express and outline the intentions of projects. The charter and
project management plan are examples of agreements that are not contracts.
They are internal agreements. Other examples: service level agreements.
• Procurement process is used to acquire necessary resources that are outside
the project team and involve legal documents between the buyer and seller,
therefore, we are likely dealing with contracts and not agreements.
• When a project is planned, the scope is analyzed to determine whether the
entire project scope can be completed internally or if any of the work,
deliverables, materials, equipment, etc. will need to be outsourced. This
analysis results in make-or-buy decisions. If one or more procurements are
needed, the procurement department (a/k/a “contracting”, “purchasing”,
“legal department” gets involved in the project to manage the procurement
process.
• When a decision has been made to procure goods or services from an outside
source, the project manager will facilitate the creation of a plan for the
overall procurement process (a procurement management plan), a plan for
how each contract will be managed (a procurement strategy), and a
 description of the work to be done by each seller (a procurement statement
of work).
• The procurement SOW should be combined with the contract terms to make
up the finalized bid documents (RFP, RFI, RFQ) that are sent to prospective
sellers.
• General rules for answering procurement questions
o Contracts require formality. What this means is that any
correspondence, clarification, and notifications related to the
contracts should be formal written communication, which can be
followed up with verbal communication, if necessary. If issues develop
that require arbitration, mediation, or litigation, the formal written
communications will be more enforceable and supportable than
verbal communications.
o All product and project management requirements for the
procurement work should be specifically stated in the contract.
o If it is not in the contract, it can only be required to be done if a formal
change order to the contract is issued
o If it is in the contract, it must be done or a formal change order to
remove it must be approved by both parties
o Changes to contracts must be submitted and approved in writing.
o Contracts are legally binding; the seller must perform as agreed in the
contract, or face the consequence of breach of contract.
o Contracts should help diminish project risks
o Most governments back all contracts that fall within their jurisdiction
by providing a court system for dispute resolution.
o Assume a centralized contracting environment for exam questions. In
such an environment, the procurement manager reports
organizationally to the head of the procurement department, not to
the project manager.
Stakeholder Management

• Stakeholder Management: The creation and maintenance of relationships

with the aim to satisfy needs
• Throughout a project you should do the following with stakeholders:
o Identify all of them as soon as early as possible because stakeholders
identified later in a project will likely request changes which can
impact the project and leads to delays.
o Determine their requirements
o Determine their expectations
o Determine their interest
o Determine their level of influence
o Determine their level of authority
o Plan to engage stakeholders
o Plan how you will communicate with them
o Manage their expectations, influence, and engagement
o Communicate with them
o Monitor communications and stakeholder engagement
• How project manager should involve stakeholders on the project
o List all stakeholders by name
o Determine all stakeholders’ requirements
o Determine stakeholders’ interest in being involved in the project and
in the outcomes of the project
o Determine stakeholders’ level of influence on the project
o Determine stakeholders’ expectations, and turn them into
requirements as appropriate
o Determine when stakeholders will be involved in the project and to
what extent
o Get stakeholders to sign off that requirements are finalized
o Access stakeholders’ knowledge and skills
o Analyze the project to evaluate whether stakeholders’ needs will be
met
o Let stakeholders know which requirements will be met, which
requirements and expectations will not be met, and why
o Get and keep stakeholders involved in the project by assigning them
project work or responsibilities, such as the role of risk response
owner
o Manage and influence the stakeholders’ involvement, engagement,
and expectations.
o Make the best use of stakeholders’ expertise
o Communicate to stakeholders what they need to know and when they
need to know it
o Make sure stakeholders know what they need to communicate to the
project manage and other stakeholders
o Involve stakeholders as necessary in change management and
approval
o Involve stakeholders in the creation of lessons learned
o Get stakeholders’ sign-off and formal acceptance of interim
deliverables during the project and at project or phase closing
o Reassess stakeholders involvement and make changes throughout the
project as needed
o Ensure a common understanding of the project objectives
deliverables, work, and acceptance criteria
o Ask stakeholders to le you know about problems in project
communications and relationships.
Process Groups

Initiating

The PM determines whether the business case (an economic feasibility study) and
benefits management plan can be achieved and does some high level planning to
verify the project can likely be completed within the constraints of scope, schedule,
cost, etc.

The Benefits owner has the responsibility to monitor, record, and report on the
realized benefits of the project.

Some activities such as estimating, product scope descriptions, etc. start in the
initiating process group and then are iterated or refined into plans that can be used
to manage the project. This is Progressive Elaboration.

Similarly, Rolling Wave Planning is a form of progressive elaboration. The earliest

parts of the project are planned in sufficient detail for work to begin. Later phases of
work are planned at a high level. As the project progresses, and more information
impacting the work becomes available, plans are elaborated in sufficient detail to
accomplish the work.

High level planning is done during initiating. Such planning may include creating a
high level WBS, performing order of magnitude estimating, and doing high level risk
identification. This needs to be done so we can determine whether the product of
the project can be delivered by the end date and within the budget.
Develop Project Charter (Integration Management)

Develop Project Charter process’ objective is to formalize the project existence.

In addition to provide the project manager with an authorization document to have
access to resources required for the project.

The process of Develop Project Charter is performed once at the earliest stage of
project initiation to facilitate the work of the project manager. The key deliverable
of this process includes the project charter. The project charter is a document that is
derived from the project business case and benefits management plan processed in
light of relevant contracts, agreements, and processes to the project. Companies
usually use the project charter document for internal projects authorization. On the
other hand, companies use contracts instead when dealing with external customers
projects due to the involved legal consequences. The project charter document
mainly contains the project objectives, high-level requirements and project exit
criteria.

Also Develop Project Charter process provides the assumptions log. Assumptions
log contains project high-level assumptions and constraints.

The project is formally authorized when the sponsor signs the project charter.

Requires the following actions:

• Usually written by the sponsor

• Identifying stakeholders
• Meeting with key stakeholders to confirm high-level requirements, project
scope, risks, assumptions, and issues.
• Defining product scope
• Defining project objectives, constraint, and success criteria
• Documenting risks

At its highest level, the project charter ensures a common understanding by the
stakeholders of the key deliverables, milestones, and the roles and responsibilities
of everyone involved in the project.

• Charter can include

o Requirements
o Business needs
o Summary schedule
o Assumptions and constraints
o Business case, including return on investment
o Summary budget
o Success criteria
 o Approval requirements (different from acceptance criteria for
deliverables which is specified in the scope statement)
o Exit criteria (who will sign off on the project)
• Project selection criteria
o Benefit Cost Ratio (BCR). How much you get for every dollar spent
o Economic Value Add (EVA)
o Internal Rate of Return (IRR)
o Opportunity Cost
o Payback Period
o Present Value (PV): Time value of money
o Net Present Value (NPV): Same as Present Value except you subtract
cost. The higher the better.
o Return on Investment (ROI): Percentage that shows what return an
organization makes.
o Return on Invested Capital (ROIC): For every dollar of cash I invest in
a project, how much should I expect in return?
• Once created, it would be rare to change the charter since it contains the
project objectives. We can go through the process Develop Project Charter at
the start of each phase, but in general, once the charter is developed in the
first phase, in subsequent phases, we are only asking if it still makes sense.
• Business documents: Business Documents are documents that are generally
originated outside of the project and are used as inputs to the project. Ex:
Business Case, Benefits Management Plan.
o Business case: Economic feasibility study. Sponsor is accountable
(though not necessarily responsible)
o Benefits management plan: Defines the process for creating,
maximizing, and sustaining the benefits provided by the project.
• Input
o Business case: Usually contains
§ Cost/Benefit Analysis
§ Business need
• Outputs
o Project charter
o Assumption log
• Business case: Has the complete cost-benefit analysis for the project. It can
provide the project manager with all the initial information used to justify
the project.
• Benefits Management Plan: Explains the process for creating, maximizing,
and sustaining the benefits provided by a project or program. It outlines the
benefits of all projects and how they are to be maintained beyond the
completion of the project.
Identify Stakeholders (Stakeholder Management)

This is the process of defining the people or group of people with interest in
the project and its outcome, as well as the people who might impact its
deliverables or be impacted by them.

• Key
o Output
§ Stakeholder Register
o Technique
§ Stakeholder Analysis
• This process is done along with the project team.
• A stakeholder would be anyone who creates or causes a need, is affected by
the need, or would be affected by the solution.
• Should be done at the start of the project (along with the project charter) and
at least at the start of each phase and when significant change in the project
or organization occurs.
• Tools and techniques
o Stakeholder analysis (stakes)
§ Interest
§ Rights
§ Ownership
§ Knowledge
§ Contribution
§ Power/Interest: Power is level of authority; Interest is level of
concern
§ Power/Influence: Influence is active involvement
§ Influence/Impact: Impact is ability to effect change
§ Salience: includes power, urgency and legitimacy; Urgency is
need for immediate attention; legitimacy is their involvement
is appropriate.
o Stakeholder mapping: Groups stakeholders into categories
§ Power/interest grid
§ Stakeholder cube
§ Salience model: groups stakeholders based on need for
attention, authority, or level of involvement.
§ Directions of influence
• Upward: Senior management of the performing
organization, sponsor, and steering committee
• Downward: The team or specialists contributing to the
knowledge or skills in temporary capacity
• Outward: Stakeholder groups and their representatives
outside the project team, such as suppliers, government
departments, the public, end-users, and regulators
 • Sideward: The peers of the project manager, such as
other project managers, or middle managers who are in
competition for scarce project resources or who
collaborate with the project manager in sharing
resources or information.
• Outputs
o Stakeholder register
Planning

The project manager and the team perform a detailed analysis of whether the
objectives in the project charter and the expected business benefits can be achieved.
They then decide how the project objectives will be accomplished, addressing all
appropriate project management processes and knowledge areas. This means
determining what processes are appropriate for the needs of the project and
tailoring them to the needs of the project.

Throughout the project it may be necessary to revisit project planning.

• If a stakeholder is identified and their requirements need to be analyzed after

work has begun
• If a new risk that needs to be analyzed using qualitative analysis is identified
in a risk review
• If rolling wave planning needs to take place.
• New info becomes available through progressive elaboration.

Although the project management plan is finalized in the Planning process group,
activities such as detailed estimates and project scope and product scope
descriptions may be clarified as the work is being done during the executing and
monitoring and controlling process. This is called progressive elaboration.

Similarly, Rolling Wave Planning is a form of progressive elaboration. The earliest

parts of the project are planned in sufficient detail for work to begin. Later phases of
work are planned at a high level. As the project progresses, and more information
impacting the work becomes available, plans are elaborated in sufficient detail to
accomplish the work.

Everyone is involved in the planning process.

• There is a management plan for each knowledge area.

• When creating a management plan you ask yourself, “How will I define, plan,
manage (execute), and control [scope/schedule/cost/quality, etc.] for the
project?”
• You think ahead and document how you will plan for each knowledge area
(and ultimately, the project) based on its particular needs, how you will
manage each knowledge area during executing, and how you will monitor
and control each knowledge area.
• “Project Documents” refers to any project-related documents that are not
part of the project management plan. They include the assumption and issu
logs, cost and duration estimates, lessons learned register, project schedule
and resource calendars, quality reports, resource requirements along with
requirements documentation, etc. Most of these docs are created by the
project manager and not necessarily shared with the sponsor.
Develop Project Management Plan (Integration Management)

The Develop Project Management Plan process objective is to combine all project
plans into a single integrated project management plan. The process is vital to
project planning since it’s meant to rectify any misalignment between component
plans. In that sense, this process is crucial for project success. Even if there are
expert planners taking care of component plans, the project manager must be on top
of this process.

The key output of this process is the project management plan, an integrated and
aligned version of all project sub plans approved and signed by key stakeholders.
Note that, project management processes are documented and controlled by the
help of templates.

When the Project Management Plan includes the appropriate amount of detail it is
approved by the sponsor.

• Key
o Output
§ Project management plan
• Planning should lead to a realistic, bought-into, approved, and formal project
management plan that is updated throughout the project to reflect approved
changes.
• The project management plan defines how the project is executed, monitored
and controlled, and closed. Who, what, when, where, how.
• The plan is progressively elaborated. Developed, refined, revisited, updated.
Only assembled after the subsidiary plans have been created.
• The Project Management Plan includes all of the knowledge area plans
(scope, schedule, cost, quality, resources, communications, risk,
procurement, and stakeholder management).
• This Project Management Plan also includes
o Performance Measurement Baseline which includes the Scope Baseline
(the project scope statement, WBS and WBS dictionary), the Schedule
Baseline (agreed upon schedule), and the Cost Baseline.
o Requirements Management Plan (part of the scope management
process. a/k/a “Business Analysis Plan”)
o Change Management Plan: describes how changes will be managed
and controlled. The “How”
o Change Control System and Configuration Management System: Part
of PMIS. Includes standardized forms, reports, etc.
o Configuration Management Plan: The “What”. Because of all of the
documents and the changes that are likely to occur, the Configuration
Management Plan conveys what version of the scope, schedule and
other components of the project management plan is the latest
version. Defines the naming conventions, version control system,
 document storage and retrieval system. It also identifies which
artifacts (ex: scope, schedule, cost, etc.) if changed could alter the
project or product outcome.
• Although subject to change, it should be as complete as possible when project
executing begins.
• The planning processes involve planning how you will determine (or
determining how you will plan) the scope, schedule, cost, quality, resources,
communications, risk, procurement, and stakeholder engagement as well as
how you will manage and control those knowledge areas.
• The Project Management Plan contains Management Plans from the various
knowledge areas, Project Baselines, Project life cycle, and Development
Approach. These are the documents that describe how the project will be
executed, monitored and controlled, and closed. Project documents are other
documents that are NOT included in the Project Management Plan, but are
necessary to manage the project.
• The plan must be presented and approved once all of the knowledge area
plans are completed. This is typically done right before project execution.
Therefore, once approved, the next step in the project is to begin an
execution process group process.
Plan Scope Management (Scope Management)

The main purpose of this process is to set the way to plan, manage control and
assess project scope. The key deliverable of the Plan Scope Management process is
scope management plan. It guides the project team on how to deal with the project
scope in different stages of the project.

• Key
o Output
§ Scope Management Plan
§ Requirements Management Plan
• The output of the Plan Scope Management process
o Scope Management Plan
§ Scope Management Plan details how scope will be planned,
executed, and controlled. It defines
• How to achieve the scope
• What tools to use to plan how the project will
accomplish the scope
• How to create the WBS
• How scope will be managed and controlled to the
project management plan
• How to obtain acceptance of deliverables.
o Requirements Plan.
§ Requirements Management Plan (a/k/a “business analysis
plan”) describes the methods you intend to use to identify
requirements. The plan should answer the following questions:
• Once I have all the requirements what will I do to
analyze, prioritize, manage, and track changes to them?
• What should I include in the requirements traceability
matrix?
Collect Requirements (Scope Management)

Collect Requirements process aims to gather project requirements from

different people concerned with the project. As well as managing and organizing
these requirements in a way that helps the project in meeting its objective. The main
output of this process is requirements traceability matrix a document that acts as a
tracker for gathered requirements.

• Key
o Output
§ Requirements documentation
§ Requirements Traceability Matrix
• The process puts the Scope Management Plan and the Requirements
Management Plan into action.
• Scope emerges from requirements
• Need to make sure the requirements can be met within the project
objectives. If they cannot, you need to look for options to adjust the
competing demands of scope, time, cost, quality, resources, risk, and
customer satisfaction.
• Some tools and techniques
o Brainstorming
o Interviews
o Focus groups
o Questionnaires and surveys
o Benchmarking
o Voting
o Multi-criteria decision analysis: stakeholders quantify requirements
using a decision matrix
o Affinity diagrams: ideas are grouped into categories.
o Mind maps
o Nominal Group Technique: question posed, participants write down
answer and ideas are ranked
o Facilitation: Ex: QFD (Quality Function Deployment) which helps
determine the critical characteristics by collecting customer needs
and objectively sorting and prioritizing them. Usually conducted in a
facilitated workshop.
o Context diagrams: Uses symbols like database and systems.
o Observation
§ Job shadowing
§ Participant observer: You do the job to gain understanding. Ex:
“Chef for a week”.
o Prototypes: can be mockups or story boards. Or early versions of the
product.
• Two outputs
o Requirements Documentation
 § A great question to ask stakeholders is, “How will we know if
the work we do will meet this requirement?”
§ Requirements must be clear, complete, and measureable.
§ Requirements must be described in such a way that associated
deliverables can be tested or measured against the
requirements in the Validate Scope process to confirm that the
deliverables are acceptable.
§ Requirements documentation describes how individual
requirements meet the business need for the project. It does
not contain the fully documented scope of the project but does
contain product or service specifications and the requirements
collected as part of project scope management.
o The Requirements Traceability Matrix is an output of this process.
§ Links requirements throughout the validation process. The
purpose of the Requirements Traceability Matrix is to ensure
that all requirements defined for a system are tested.
• Six requirement categories are often used to classify, organize, and document
each project requirement
o Business: Describe the higher-level needs of the organization as
whole.
o Stakeholder: Describe the needs of the stakeholder.
o Solution: Describe features, functions, and characteristics of the
product, service, or result that will meet the business and stakeholder
requirements
o Transition or readiness
o Project: Ex: milestone dates, contractual obligations, constraints, etc.
o Quality
Define Scope (Scope Management)

The main purpose of this process is to provide a complete detailed description of

the scope of the project and product as well as the work the project team needs to
perform to produce the product. At the same time, it defines the boundaries of
project work and the acceptance criteria of this work. A project scope statement
emerges from this process. Constraints and assumptions are refined and defined in
detail during this process.

• Key
o Technique
§ Product Analysis: A technique which analyze project objectives
and product description stated by the customer to turn them
into deliverables, it make sure product and project scope is
well understood.
§ Output
• Scope Statement
• This process is primarily concerned with what is and is not included in the
project and its deliverables.
• This process is completed by the project team only—not other stakeholders
or the sponsor.
• Since all of the requirements identified in Collect Requirements may not be
included in the project, the Define Scope process selects the final project
requirements documentation developed during the Collect Requirements
process. It essentially culls that list of requirements.
• This process is ongoing throughout the project.
• Purpose of this process to determine what scope is and is not in the project.
• Product Analysis: Detailed analysis of the project’s product, service, or result
with the intent of improving the project team’s understanding of the product
and helping to capture that understanding in the form of requirements. For
projects that have a product as a deliverable, product analysis can be used as
a tool to define the scope of the project. Some common tools
o Product breakdown
o Requirements analysis
o Systems analysis
o Systems engineering
o Value engineering: Evaluation of value for product, service, or process
that is in design.
o Value analysis: Performed after value engineering. Identify the
functions of a product or service and provide those functions at the
lowest possible costs. Used in manufacturing.
• Alternatives analysis: Used to evaluate the requirements identified from
Collect Requirements.
• Output of this process is the Project Scope Statement. This document in effect
says, “Here is what we will do on this project and what we will NOT do on the
project”
o The project scope statement, along with the WBS and WBS dictionary
comprise the scope baseline, which is part of the project management
plan.
o The project scope statement is the description of the project scope,
major deliverables, and exclusions. It defines the entire scope
including the project and product scope. It describes the project’s
deliverables in detail. All and Only.
o The difference between the project charter and the project scope
statement is that the project charter contains high-level information
while the project scope statement contains a detailed description of
the scope components. These components are progressively
elaborated throughout the project. Project charger is high level—it’s
about authority versus project scope which is specific about
deliverables.
o The project scope statement may include the following
§ Product scope. Kept up to date during the project.
Progressively elaborated.
§ Project scope, including a description
§ Deliverables of the project
§ Acceptance criteria
§ What is not part of the project
§ Assumptions and constraints
Create WBS (Scope Management)

Create WBS process refers to the activities of breaking down project work into
smaller pieces of work so it can be more manageable. The result of performing this
process is a framework of the required deliverables and all related information to
this work.

• Key
o Output
§ Scope Baseline (scope statement, WBS, WBS dictionary.
o Technique
§ Decomposition
• The WBS is essentially a decomposed scope statement. A hierarchical
structure of the scope statement.
• A common way to represent the WBS
o With the project name or release as the single top-level box.
o Using phases of the project life cycle as the second level of
decomposition with the product and project deliverables inserted at
the third level OR using major deliverables as the second level of
decomposition and incorporating subcomponents that may be
developed by organizations outside the project team.
• Every level is the detailed explanation of the level above it.
• Each level of the WBS is mutually exclusive and cumulatively exhaustive,
meaning that there are no gaps and no overlap in the work packages. No
piece of scope is eliminated, and nothing is duplicated.
• 100% Rule: The WBS should represent all of the work and only the work of
the project.
• The project team, and not just the project manager created the WBS. Could be
a team building exercise.
• The “Work” in “Work Breakdown Schedule” refers NOT to an activity, but to
the work products or deliverables that result from an activity or group of
activities. So each work package should consist of nouns—things
(deliverables), rather than actions (activities). A WBS is deliverable-oriented.
This does not mean that only customer deliverables are included. The
complete scope of a project, including product scope, project scope, and
project management efforts are included as well.
• You should expect to manage to the activity level. Tasks are smaller
components of work that make up an activity.
• Scope is broken down until the work package level is reached. This occurs
when the deliverables
o Can be realistically and confidently estimated (including the activities,
duration, and cost)
o Can be completed quickly
o Can be completed without interruption and without the need for more
info
 o May be outsourced
• A “Control Account” level on the WBS (normally at higher levels) is a tool that
allows you to collect and analyze work performance data regarding costs,
schedule, and scope. Each work package is part of a control account. A
control account has two or more work packages, though each work package
is associated with a single control account.
• As planning progresses, the team breaks down the work packages from the
WBS into the activities that are required to produce the work packages. This
is done in the “Define Activities” process.
• Everything else done in planning, after creation of the WBS is related to the
WBS. For example, project costs and schedules are estimated at the work
package or activity level, and not for the project as a whole. Work packages
are assigned to individuals or parts of the performing organization.
• Planning package: A control account may include one ore more planning
packages. A planning package is a work breakdown structure component
below the control account and above the work package with known work
content but without detailed schedule activities. Larger than work pakcages,
but cannot be broken down into work packages at this time.
• Outputs. The WBS is not actually an output of this process even though it is
the main work of this process.
o The WBS Dictionary is an output of this process. It provides a
description of the work to be done for each WBS work package, and it
lists the acceptance criteria for each deliverable.
o The Scope Baseline. Baselines are the final and approved versions of
certain pieces of the project management plan. For Scope, the
baseline is made up of the final versions of the WBS, the WBS
dictionary, and the project scope statement.
• Decomposition is used in the Define Activities process in Schedule
Management, as well as in the Create WBS process in Scope Management.
When you see the term used on the exam, it is important to look at the
context of what is being decomposed. When deliverables are being
decomposed into smaller deliverables, or work packages, you know the
question is referring to the Create WBS process. When work packages are
being decomposed into the activities to produce them, the question is
referring to the Define Activities process.
• Organizational Breakdown Structure (OBS): While the WBS shows a
breakdown of the project deliverables, an OBS is arranged according to an
organization’s existing departments, units, or teams, with the project
activities or wok packages listed under each department. An operational
department can see all of its project responsibilities by looking at its portion
of the OBS.
Plan Schedule Management (Schedule Management)

This process is mainly concerned with defining guidelines for the planning and
controlling project schedule activities. Thus the end product of the process is a
guide of how to plan and how to control project schedule.

• Key
o Output
§ Schedule Management Plan
• Answers questions such as, “Who will be involved, and what approach will
we take to plan the schedule for the project?”, and “What processes and
procedures will we use to create the schedule?”
• The project management team selects a scheduling method, such as critical
path.
• May use data analysis techniques such as “alternative analysis”
• Might need to review the project charter or hold meetings that include the
project sponsor, team members and other stakeholders.
• Key output is the Schedule Management Plan.
o Can be formal or informal
o Part of the Project Management Plan
o Helps make the estimating and schedule development process faster
by specifying
§ The scheduling methodology and scheduling software to be
used on the project
§ Rules for how estimates should be stated (ex: hours, days,
weeks); Should the estimator include the effort (the amount of
labor) and duration (the amount of work periods the effort will
span)
§ A schedule baseline for measuring as part of project
monitoring and controlling
§ A threshold for acceptable variance.
§ Performance measures that will be used on the projects to
identify variances early
§ A plan for how schedule variances will be managed
§ A process for determining whether a variance must be acted
upon
§ Identification of schedule change control procedures
§ Types of reports required on the project relating to schedule
§ Formats and frequency of project reporting
§ The length of releases and iterations (in an adaptive life cycle)
Define Activities (Schedule Management)

Define Activities process refers to the activities of identifying exact actions to

perform in order to produce the project deliverables. Thus its main output is a
list of all activities required to produce the project final product.

• Key
o Technique
§ Rolling Wave Planning
o Output
§ Activity list
§ Activity attributes
§ Milestone list
• In this process, as planning progresses, the team breaks down the work
packages from the WBS into the activities that are required to produce the
work packages.
• This process is often performed as soon as the scope has been base-lined. In
other words, it is common to create the activity list after the requirements
documentation, project scope statement, work breakdown structure, and the
WBS dictionary have been created and are in a stable form.
• If the project is being performed under procurement, this planning process
will most likely be performed by the subcontracting organization, with the
results being provided to the organization that is responsible for the
management of the overall project.
• Activities should be at a level small enough to estimate, schedule, monitor,
and control.
• The difference between work packages in a WBS and an activity list is that
the activity list is more granular and is decomposed into individual schedule
activities. Work packages will often contain bundles of related activities that
may involve multiple groups of people. Work packages are deliverables-
based. An activity is focused on the work that needs to be done in order to
execute the work packages.
• This process defines the final outputs as activities rather than deliverables.
• It is important to note that a line exists between the work breakdown
structure and the activity list. Although the activity list is an extension of the
work breakdown structure, it is not part of the WBS. The WBS belongs to the
scope baseline, while the activity list is more closely related to the project
schedule.
• These activities are then sequenced in the next process (“Sequence
Activities”).
• Some PMs take care of this process when they create the WBS. In other
words, they do not stop at the level of the work package.
• Decomposition is used in the Define Activities process in Schedule
Management, as well as in the Create WBS process in Scope Management
(both from the Planning process group). When you see the term used on the
 exam, it is important to look at the context of what is being decomposed.
When deliverables are being decomposed into smaller deliverables, or work
packages, you know the question is referring to the Create WBS process.
When work packages are being decomposed into the activities to produce
them, the question is referring to the Define Activities process.
• One of the best sources for expertise in decomposing a work package into an
activity is the person who will ultimately be responsible for executing the
work package or the schedule activity, or someone who has performed
something similar in the past.
• If there are too many unknown components, you might really have more than
one project, or it might simply be a project for which it is better to not plan
the entire project to the smallest detail in advance, but instead to plan to a
higher level and then develop more detailed plans when the work is to be
done. This is known as Rolling Wave Planning. It is a form of progressive
elaboration. This does not eliminate the need to ensure all the scope that can
be known is known before starting work.
• This process also involves determining milestones to use on the project.
Milestones are significant evens within the project schedule. They are not
work activities, and have no duration. For example, customer-imposed due
dates for interim deliverables or a company-required checkpoint, phase gate
or stage gate could be a milestone. Initial milestones are documented in the
project charter. The project manager can also insert milestones as
checkpoints to help control the project.
• When completed, the Define Activities process results in an activity list,
which includes all activities required to complete the project, and activity
attributes or details regarding project activities. At this time, known
attributes may be limited to the activity name and ID number. As the project
progresses, additional attributes—such as planned completion date, leads
and lags, and predecessor and successor activities may be added.
• Activity attributes may be stored with the activity list or in a separate
document and are typically added after the initial activity list has been
created.
• The Activity attributes are the primary data source for use in estimating the
team (human) and physical resources required for each activity on the
activity list including, for physical resources, the activity location.
• Each activity in the list should map back to one and only one work package. A
work package, however, typically has more than one activity belonging to it.
• This is one of only a few planning processes with an output of “change
requests” because of rolling wave planning. As the project progresses, early
planning efforts may need to be iterated potentially resulting in changes to
the project baselines.
Sequence Activities (Schedule Management)

This schedule management process is concerned with identifying the

relationships between different project activities as well as any dependencies
or relationships with activities outside the project. Due to the predictive
projects nature, this process becomes vital for project success since performing it
effectively leads to the reduction of sudden slippages in time.

• Key
o Output
§ Schedule network diagrams
o Technique
§ Precedence Diagraming Method (PDM)
§ Lead
§ Lag
• This process concentrates on converting the project activities from a list to a
diagram to act as a first step to publish the schedule baseline. The result is a
network diagram
• In its pure form, during the sequence activities process, the network diagram
shows just dependencies.
• If activity duration estimates (estimates) and leads and lags are added to the
diagram later in the schedule management process, it can also show the
critical path.
• We use the Precedence Diagramming Method (PDM). Four types of logical
relationships
o Finish to Start (FS): An activity must finish before the successor can
start. This is the most common. Example: You must finish digging a
hole before you can start the next activity of planting a tree.
o Start to Start (SS): An activity must start before the successor can
start. Example: You must start designing and wait for two weeks’ lag
in order to have enough of the design completed to start coding. Or,
level concrete (successor) cannot begin until pour foundation
(predecessor) begins.
o Finish to Finish (FF): Ac activity must finish before the successor can
finish. Example: You must finish testing before you can finish
documentation. Or writing a document (predecessor) is required to
finish before editing the document (successor) can finish.
o Start to Finish (SF): An activity must start before the successor can
finish. Ex: a new accounts payable system (successor) has to start
before the old accounts payable system can be shut down. This
dependency is rarely used.
• Two activities can have two logical relationships at the same time (ex: SS and
FF). Multiple relationships between the same activities are not recommended
so a decision has to be made to select the relationship with the highest
impact.
• The sequence of activities is determined based on the following
dependencies
o Mandatory dependency (hard logic): Inherent in the nature of the
work. Example: you must design before you can construct or is
required by the contract. Identified by the project team. Must be done
in that order. For example, it is impossible to erect the superstructure
until after the foundation has been built.
o Discretionary dependency (preferred, preferential, or soft logic): This
is the way an organization has chosen to have work performed. There
are other ways it could be done, but this is the preferred approach.
Can be done in any order. Whereas you cannot easily change the other
types of dependencies, you can change a discretionary dependency if
necessary. Important when analyzing how to compress the schedule
to decrease the project duration. Identified by the project team.
o External dependency: Based on the needs or desires of a party outside
the project. Example: government or suppliers. Identified by the
project manager.
o Internal dependency: Based on the needs of the project and may be
something the project team can control. Identified by the project
manager. A type of hard logic. Ex: the team cannot test a machine
until they assemble it.
• More than one dependency can be identified for the same work.
• Leads and Lags. Duration estimates do not include any leads or lags.
o Lead may be used to indicate that an activity can start before its
predecessor activity is completed. Example: a web page design might
be able to start five days before the database design is finished. This
would be shown as a finish-to-start with a 5-day lead. Lead is often
represented as a negative value for lag in scheduling software. Leads
are used in limited circumstances to advance a successor activity with
respect to the predecessor activity. Leads to not do away with the
finish-to-start relationship that exists. Instead it simply “cheats” that
relationship. Leads increase risk and the rationale behind them
should be clearly explained and documented.
o Lag is waiting time inserted between activities such as needing to wait
three days after pouring concrete before constructing the frame for a
house. This would be shown as a start-to-start relationship with a 3-
day lag. Lags are used in limited circumstances where processes
require a set period of time to elapse between the predecessors and
successors without work or resource impact. During lag, there is no
work being performed by the organization against the activity; no
resources are being expended. They are simply waiting.
• When project activities are first being sequenced, the duration of the
activities and required leads and lags may be uncertain.
• Project Schedule Network Diagram: an image depicting the flow of project
activities in the logical order in which they will be performed. Also referred
to as “network diagrams” or “activity network diagrams”. The logical
relationships are also called dependencies.
Estimate Activity Durations (Schedule Management)

Estimate Activity Durations process refers to the actions and activities the project
team performs to set durations (estimating the number of work periods) for
each project activity. These durations helps to form the entire project timeline
once it’s combined with the rest of project schedule components.

• Key
o Technique
§ One-point estimating
§ Analogous estimating
§ Parametric estimating
§ Three-point estimating
o Output
§ Duration estimates
§ Basis of estimates
• Whenever possible, estimating should be done by the person doing the work
(or the person most familiar with the work.
• There is an important difference between duration and level of effort. This
process focuses on determining duration.
• Management plans provide the approach for estimating
• Estimating should be based on a WBS.
• This process takes the Activity List and Activity Attributes as in an input from
the Define Activities process.
• Also takes the resource breakdown structure, resource requirements, project
team requirements, project team assignments, resource calendar, risk
register.
• Types of estimates. Can be used for both time and cost estimates.
o One-Point Estimating: Estimator submits one estimate per activity.
Usually based on expert judgment, historical information, or a guess.
This technique is problematic but might be used on the exam for
simplicity.
o Analogous Estimating (Top-Down): Uses expert judgment and
historical information. Less costly and less time consuming, but less
accurate. This can be useful for the project charter.
o Parametric Estimating: Involves creating a mathematical equation
(algorithm) using data from historical records or other sources such
as industry requirements or standard metrics. For example, time per
line of code, time per linear meter or time per installation. Can use
regression analysis (scatter diagram), learning curve, heuristics (a
generally accepted rule. Ex: cost per line of code and cost per square
foot of floor space). Durations can be quantitatively determined by
multiplying the quantity of work to be performed by the number of
labor hours per unit of work. For example, duration on a design
 project is estimated by the number of drawings multiplied by the
number of labor hours per drawing.
o Regression analysis: Used to create a parametric estimate.
o Three-Point Estimating: Optimistic (O), Pessimistic (O), Most Likely
(M)
§ Triangular Distribution (Simple Average, A/K/A, “simple” or
“straight”): (P+O+M)/3. If you encounter three-point
estimating on the exam, use the formula for triangular
distribution by default.
§ Beta Distribution (Weighted Average, A/K/A Program
Evaluation and Review Technique, PERT, A/K/A, “weighted”):
(P + 4M + O)/6
o For activity estimate ranges, we would be given the “beta estimated
activity duration (EAD) and the beta activity standard deviation (SD).
You calculate the range using beta EAD +/- SD. The start of the range
is EAD-SD and the end of the range is EAD+SD.
o Greater the standard deviation, the greater the risk because is causes
the range to be wider.
o Bottom-Up Estimating: Involves creating detailed estimates for each
part of an activity (if available) or work package (if activities are not
defined). Requires an accurate WBS.
• When activity estimates are not acceptable within the constraints of the
project, alternative analysis is used to look more closely at the variables that
impact the estimate. For example, considering outsourcing the work versus
completing it internally
• Reserve Analysis: Estimating helps to identify more risks. Risk management
reduces the uncertainty in time and costs estimates. Risk management saves
the project time and money.
o Contingency Reserves (a/k/a “schedule reserves): Known unknowns.
Allocated for risks remaining after the Plan Risk Responses.
Significant risks to critical path activities may be managed by
allocating a specific amount of schedule reserve. Contingency reserves
are the estimated duration within the schedule baseline, which is
allocated for identified risks that are accepted. May be a percentage of
the estimated activity duration or a fixed number of work periods. As
more precise information about the project becomes available, the
contingency reserve may be used, reduced, or eliminated.
o Management Reserves: Additional funds and time to cover unforeseen
risks that could impact the project’s ability to meet the schedule.
Unknown Unknowns. Not included in the schedule baseline, but is
part of the overall project duration requirements.
o Padding an estimate vs. creating reserves: In creating reserves, the
project manager has the information necessary to reliably calculate
what additional time or funds the project may need whereas with
padding, team members arbitrarily determine how much pad to use.
 o If there are costs savings during a project, the savings can be taken as
a profit or can be added to the contingency reserves.
• Factors for consideration when estimating duration include
o Law of diminishing returns
o Number of resources
o Advances in technology
o Motivation of staff
• Outputs:
o The key output is the Duration Estimates
o Basis of Estimates: This is the supporting detail that shows how the
activity duration estimates were derived and what tradeoffs and
alternatives were considered.
Develop Schedule (Schedule Management)

This schedule management process refers to the efforts of combining different

project schedule components to produce a realistic project timeline. In other
words, Develop Schedule involves multiple activities including analyzing defined
activities sequences, estimated durations, and resource requirements and
constraints.

• Key
o Technique
§ Lead
§ Lag
§ Critical Path Method
§ Critical Chain Method: This method uses a network diagram
and critical path to develop a schedule by assigning each
activity to occur as late as possible to still meet the end date ,
you add resource dependencies to the schedule , and then
calculate the critical chain , starting at the end date , you build
buffers for resource limitations and risks into the chain at
critical milestones.
§ Schedule compression
§ Resource optimization
§ Monte Carlo Analysis
o Output
§ Schedule baseline
§ Project schedule: Shows when each activity is scheduled to
begin and end. It also shows a planned start and finish date for
the entire project. Usually represented as a Gantt chart. Also
shows the type quantity and amount of time that a resource
will be available.
§ Project Calendars: Shows the schedule, hours, and shifts for all
activities. Shows the working days and shifts that are available
for each scheduled activity.
§ Schedule data
• Project Schedule is a “living” document, whereas Schedule Baseline is
“frozen”
• Project Schedule is the “actual” whereas Schedule Baseline is the “plan”
• Project Schedule is a Project Document, whereas Schedule Baseline is a part
of the Project Management Plan
• Project Schedule is updated as the project is being executed, whereas
Schedule Baseline is revised only as a result of an approved change request
• Schedule performance is measured by comparing the actual (Project
Schedule) vs the baseline (Schedule Baseline)
• At the beginning of project execution, the Project Schedule is the same as the
Schedule Baseline. As work is done on the project, the actual progress is
 updated on the project schedule. At any given date, the latest version of the
actual (project) schedule is referred to as the “Project Schedule”.
• Schedule Model: Consists of all the project data that will be used to calculate
the schedule, such as the activities, duration estimates, dependencies, and
leads and lags. The project schedule is the output of the schedule model—
consolidates the schedule data that becomes the schedule baseline and part
of the project management plan.
• Project calendars Schedule network analysis: is the overarching technique
used to generate the project schedule model. It employs several other
techniques such as critical path method, resource optimization techniques
and modeling techniques.
• Critical Path Method: Used to estimate the minimum project duration and
determine the amount of flexibility. Calculates the early start, early finish,
late start, and late finish dates without regard for any resource limitations.
• Critical Path: Longest duration path through the network diagram;
determines the shortest time it can take to complete the project. There can be
more than one critical path, but that is not desired since it increases project
risk.
• Near-Critical Path: The path closest in duration to the critical path. The closer
in length the critical path and near-critical path, the more risk the project
has.
• Float: Schedule flexibility
o Total Float: amount of time an activity can be delayed without
delaying the project end date or milestone. It is possible to have
negative float. It means you are behind. It means the estimated
completion date is after the desired date).
o Free Float: amount of time an activity can be delayed without delaying
the early start date of its successor(s).
o Project Float: also referred to as “positive total float”) is the amount of
time a project can be delayed without delaying the externally imposed
project completion date required by the customer or management. Ex:
You have a project that will take 30 days to complete, but you have 90
days to complete it.
o You would never leave a project in negative float which means the
project is behind. You would either utilize ways to compress the
schedule to meet the date or request a change to the baseline.
• Schedule Compression: a way to utilize float by fast tracking activities that
are on the critical path. During project planning, schedule compression can
help a project manager determine if the desired completion date can be met,
and if not, what can be changed to meet the requested date. Later in the
project, schedule compression may be used during Perform Integrated
Change Control and Control Schedule to evaluate options to manage the
impacts of changes. The objective of this technique is to manage the schedule
without changing the schedule baseline. This isn’t always possible, but we
try.
 o Fast Tracking: Taking critical path activities that were originally
planned in series and doing them in parallel for some or all of their
durations. Often results in rework and usually increases risk because
discretionary dependencies are necessarily being ignored.
o Crashing: Adding or adjusting resources in order to compress the
schedule while maintaining the original scope. Always results in
increased costs and may increase risk. It trades time for money.
• For questions about changes to the network diagram, make sure you look for
shifts to new critical paths caused by the changes to the network diagram or
to activity durations.
• If you need to shorten the duration of a project and you need to shorten an
activity to do so, it needs to be on the critical path in order for it to make a
difference. In such scenarios, always choose the earliest activity.
• Resource Optimization
o Resource Leveling: Lengthens the schedule and increases cost to deal
with a limited number of resources. Allows you to level the peaks and
valleys of the schedule from one month to another resulting in a more
stable number of resources on your project. Ex: Everything above 40
hours of work, you need to do it next week. Often extends project
schedule.
o Resource Smoothing: Modified form of resource leveling where
resources are leveled only within the limits of the float on their
activities so the completion dates of activities are not delayed. Same
is leveling except the cap doesn’t apply to activities on the critical
path.
• The project schedule can be shown with or without dependencies and can be
in any of the following presentations created from the schedule model
o Network Diagram: Useful because it shows interdependencies
between activities)
o Milestone Chart: Only shows major events with no durations or
interdependencies. Good as a report to senior management
o Bar Chart (a/k/a Gantt Charts): Shows duration but not
interdependencies. Good to track progress and report to the team.
• Schedule must be approved by stakeholders before being considered final.
• Critical Chain Method: Provides a way to view and manage uncertainty when
building the project schedule. Modifies the CPM by estimating each activity as
aggressively as possible, building the schedule network, and then adding one
lump-sum buffer to the end of the network before the finish date. The team is
not made aware of the buffers and therefore they are kept on an aggressive
schedule.
• Monte Carlo Analysis can be performed in this activity. The computer
evaluates probabilities by considering a huge number of simulated
scheduling possibilities or a few selected likely scenarios and identifies the
highest risk activities that ay not otherwise be apparent, showing the impact
of these changes on the schedule.
• Outputs of Develop Schedule process is the project schedule, schedule
baseline, schedule data, change requests, and updates to any related project
documents. Bar charts (Gantt charts) and milestone charts may also be an
output. The project schedule is usually displayed via network diagrams, bar
charts (Gantt), or Milestone charts.
Plan Cost Management (Cost Management)

Plan Cost Management Process defines the guidelines on how to estimate,

manage and monitor project costs.

• Key
o Output
§ Cost Management Plan
• Answers the questions, “How will I go about planning cost for the project”
and “How will I effectively manage the project to the cost baseline, control
costs, and manage cost variances?”
• Determinations on who will fund the project can be made using net present
value, return on investment, payback period, and internal rate of return
calculations. These calculations were used during Integration when they
were used as project selection measures, and they are also useful in planning
cost management. As we get detailed estimates and develop the budget, we
will use them to evaluate whether the project is still feasible within the
charter and whether the measureable project objectives can be reached.
• Discounted Cash Flow can also be used. This technique is used in project
selection to estimate the attractiveness of an investment by predicting how
much money will be received in the future and then discounting to its current
value. In cost management planning it is used to evaluate the potential
revenue to be earned from specific project work.
• Output of this process is the Cost Management Plan (a/k/a “Budget
Management Plan” or “Budget Plan”).
o Can be formal or informal
o Part of the Project Management Plan
o An example of how management plans are used after they are created:
The cost management plan may include what is known as a “Control
Threshold”. Control Thresholds are the amount of variation allowed
before you need to take action. If an actual cost comes in higher than
expected, will you need to take action? What if it’s a two-dollar
difference?
o Could include what unit of measure to use, level of precision
(rounding rules), level of accuracy (ex: +/- 10%), etc.
o The Cost Management Plan identifies the WBS level at which earned
value will be calculated.
Estimate Costs (Cost Management)

This process involves calculating the monetary resources needed to complete

project work based on available cost information. So, these calculations take into
consideration cost trade-offs and risks in order for the estimates to be realistic.

• Key
o Technique
§ One-point estimating
§ Analogous estimating
§ Parametric estimating
§ Three-point estimating
§ Cost of Quality (COQ): The cost of the work related to quality
added to the project.
o Output
§ Cost estimates
§ Basis of estimates
• This process could also be thought of as “Estimate Activity Costs”
• Involves coming up with cost estimates for all project activities and
resources required to complete them.
• This is different than the Determine Budget process because Estimate Costs
is only concerned about each work package or activity whereas Determine
Budget allocates the costs over the life of the project to determine the
periodic and total funding requirements.
• Need to reconcile the cost estimate with the funding limits to make sure it’s
doable.
• These estimates are then combined into one time-phased spending plan in
the next process: Determine Budget.
• Need to estimate the costs of all the efforts to complete the project. This
includes costs directly associated with the project, such as labor, equipment,
materials, and training for the project, as well as the following:
o Costs of quality efforts
o Cost of risk efforts
o Cost of the project manager’s time
o Costs of project management activities
o Expenses for physical office spaces used directly for the project
o Overhead costs, such as management salaries and general office
expenses.
o When the project involves procurement, the buyer estimates the
amount of profit they are paying the seller when purchasing goods or
services. The seller estimates the amount of profit to build into the
cost of providing the goods or services.
• Types of cost
o Variable costs: These costs change with the amount of production or
the amount of work. Ex: The cost of material, supplies, and wages.
 o Fixed costs: These costs do not change as production changes. Ex: the
cost of setup, rent, utilities, etc.
o Direct costs: These costs are directly attributable to the work on the
project. Ex: team wages, team travel, cost of material used on the
project.
o Indirect costs: overhead items or costs incurred for the benefit of
more than one project. Ex: taxes, fringe benefits, and janitorial
services.
• Costs can be estimated using the same techniques as in Schedule
Management
o One-point estimating
o Analogous estimating
o Parametric estimating
o Bottom up estimating
o Three-point estimating
• Reserve analysis is also used here as it is used in Schedule Management.
Contingency Reserves (known unknowns) and Management Reserves
(unknown unknowns). This is done at the activity level.
• Estimate ranges
o Rough Order of Magnitude (ROM): Usually made during project
initiating. Typical range is -25 to +75%.
o Budget estimate (a/k/a “Preliminary budget”): As a best practice, it is
a good idea to narrow the range of the estimate before you begin
iterating the plan. A budget estimate is in the range of -10 to +25%
o Definitive estimate: As project planning progresses, the estimate will
become even more refined. +/- 10% or -5 to +10%
• When completed, the Estimate Costs process results in cost estimates and an
explanation of how those estimates were derived (known as the “basis of
estimates”). Could result in changes or updates to project documents such as
the risk register, assumption log, and lessons learned register.
• The cost estimate includes contingency amounts to account for identified
risks and management reserve to cover unplanned work.
• Cost of Quality (COQ): Looks at all of the costs that will be realized in order to
achieve quality. This tool is also used in Plan Quality Management.
• Outputs
o Cost Estimates: How much it will cost to complete each schedule
activity on the project along with a contingency reserve amount.
Might include labor, materials, taxes, fees, and indirect costs. Basically,
if there is a cost anticipated to complete something, it should be
reflected in the cost estimate.
o Basis of Estimates: Details on how you derived the activity cost
estimates.
Determine Budget (Cost Management)

Determine Budget Process is concerned with consolidating and aggregating costs

estimates of all project activities or work packages to produce formal cost
baseline. Also, this process involves considering different risk reserves types
including management reserve and contingency reserve, as well as, the limitation
over company budget and cash-flow.

• Key
o Technique
§ Cost aggregation: o create budget, activity costs are rolled up to
work packages cost , work package costs are then rolled up to
control accounts costs and finally to project costs , this process
called cost aggregation.
§ Funding limit reconciliation: Once the project budget is clear, it
is the time to check the cash flow, funding, may be not available
causing changes to other parts of the project. Then
reconciliation with any cost constraints in the charter, if the
project estimates exceeds the constraints the project manager
has to meet with management to decrease costs.
o Output
§ Cost baseline
§ Project funding requirements
• This is different than the Estimate Costs process because Estimate Costs is
only concerned about each work package or activity whereas Determine
Budget allocates the costs over the life of the project to determine the
periodic and total funding requirements.
• A budget takes the estimates project expenditures and maps them back to
dates on the calendar. Likewise, the Determine Budget process time-phases
the cost estimates so that the performing organization will know how to plan
for cash flow and likely expenditures over time. This is why it is performed
after activities have been defined and estimate activity durations and
estimate activity resources has been performed and after Develop Schedule
since that is where the project’s time line is determined. And since it is based
on the activity cost estimates, it should be performed after the process of
Estimate Costs.
• Output:
o Cost Baseline (a/k/a “the budget”, a/k/a “performance measurement
baseline”): Goal is to establish an authorized cost baseline.
o Cost baseline specifies what costs will be incurred and when they are
anticipated.
• The project manager calculates the total cost of the project to determine the
amount of funds the organization needs to have available for the project. The
result of this calculation is the budget.
• The cost baseline is the portion of the budget the project manager will have
control over.
• In estimating the total cost of a project (determining the project’s budget), a
project manager must perform risk management activities and include
reserves in their estimates.
• The cost baseline includes the contingency reserves; it represents the funds
the project manager has authority to manage and control.
• The cost budget is the cost baseline plus the management reserves
(management reserves are NOT included in the cost baseline, but
contingency reserves are)
• To create a budget
o Activities cost estimates are rolled up to work package cost estimates.
o Work package costs are then rolled up to control account costs and
finally to project costs.
o This process is called cost aggregation.
o Contingency reserves are then added to determine the cost baseline.
Note that contingency reserves can also be added at the activity level.
If this is the case, then there is not a lump sum contingency reserve
inserted into the cost baseline. It would already be there since the cost
baseline consists of the work package estimates + contingency
reserves.
o The next thing is to check cash flow. Funding may not be available
when it is needed on the project. The cost baseline, therefore is time-
phased (distribution of costs over a period of time) and may be shown
as an s-curve.
o Before the cost baseline and cost budget can become final, the project
manager must reconcile with any cost constraints in the charter. If the
project estimate still exceeds the constraints, the project manager
must meet with management, explain why their cost requirement
cannot be met and propose options to decrease costs.
• When the Determine Budget process is complete, the cost baseline, including
all funding requirements is established.
Plan Quality Management (Quality Management)

Plan Quality Management process involves the identification of quality

standards, requirements, and metrics relevant to the project deliverables.
Also, it’s concerned with how the project will show compliance with quality
requirements and/or standards. This process focuses on defining quality for the
project, the product, and project management, and planning how it will be achieved.

• Key
o Technique
§ Cost of Quality (COQ): The cost of the work related to quality
added to the project.
§ Cost benefit analysis: Used to weight the benefits versus the
costs of quality efforts to determine the appropriate quality
level.
§ Cause & Effect diagram (Ishikawa, Fishbone)
§ Flowchart (process map)
§ Check sheet (tally sheet): Mainly gathers data , used to track of
data such quality problems , its primary purpose to gather
data.
§ Pareto chart
§ Histogram
§ Scatter diagram
§ Control chart
§ Design of Experiment
§ Statistical sampling
o Output
§ Quality Management Plan
§ Quality metrics: areas on the project that are important to
measure and decide what measurements are acceptable
§ Quality checklist: a list of items to inspect , a list of steps to be
performed or a picture of the item to be inspected With spaces
to notes of defects if any.
§ Process improvement plan
• This process answers the questions, “What is quality?” and “How will we
ensure it?”
• Process includes
o Review management plans and project documents to understand
quality requirements on the project.
o Identify quality practices as well as internal and external standards
relevant to product, project, and project management efforts (OPAs
and EEFs)
o Create additional project specific processes, standards, and metrics
o Determine the processes that will be used on the project
o Determine what work you will do to meet the standards
 o Determine how you will measure to make sure you meet the
standards
o Plan for process improvement.
o Perform cost of quality, cost-benefit, and other analysis work to make
certain the appropriate level of quality will be planned in.
o Determine roles and responsibilities for achieving quality
requirements and objectives
o Plan for testing and inspection to check that requirements,
performance, reliability, and quality goals and objectives are achieved
o Interface the quality management plan with other management plans
to balance the needs of quality with scope, cost, time, risk, resources,
and customer satisfaction requirements.
o Finalize a quality management plan as part of the project management
plan.
• No reason to negatively impact project scope, time, or cost if higher quality is
not required on the project. Cost of quality. Evaluating the cost of quality
means making sure the project is not spending too much to achieve a
particular level of quality.
• Cost of quality (COQ)
o Prevention costs: Costs related to the prevention of poor quality in the
products, deliverables, or services of the specific project. This is a cost
of conformance. Money spent during the project to avoid failures.
o Appraisal costs: Costs related to evaluating, measuring, auditing, and
testing the products, deliverables, or services of the specific project.
This is a cost of conformance. Money spent during the project to avoid
failures.
o Failure costs (internal/external): Costs related to nonconformance of
the products, deliverables, or services to the needs or expectation of
the stakeholders. This is a cost of nonconformance. Money spent
during and after the project because of failure.
• The optimal COQ is one that reflects the appropriate balance for investing in
the cost of prevention and appraisal to avoid failure costs.
• Quality standards might be outlined in an agreement (contract) or need to be
discovered as part of the Collect Requirements process. Ex: acceptable
number of software bugs per module, the strength of concrete, or the average
time per installation.
• Marginal analysis: focused on finding the point at which the benefits or
revenue to be received from improving quality equals the incremental cost to
achieve that quality.
• Quality Management Plan usually includes
o The quality practices and standards that apply to the project
o Who will be involved in managing quality, when, and what their
specific duties will be
o What processes will be followed to help ensure quality
o A review of earlier decisions to make sure those decisions are correct
 o The meetings that will be held regarding quality
o The reports that will address quality
o What metrics will be used to measure quality
o What parts of the project or deliverables will be measured and when.
• Quality metrics: project manager needs to think through the areas on the
project that are important to measure and decide what range of variation is
acceptable. Some examples of quality metrics
o The number of changes
o The variance related to resources utilization
o The number of items that fail inspection
o The variance of the weight of a product produced by the project
compared to the planned weight.
o The number of bugs found in software that is developed as part of the
project.
• Logical data model: Contains a description of the quality needs of the project
and is used to understand the requirements, clarify business rules, and
define processes.
• Tools
o Interviews: to help identify appropriate ways to measure quality on
the project along with the metrics or processes to be used.
o Brainstorming: to help identify appropriate ways to measure quality
on the project along with the metrics or processes to be used.
o Benchmarking: Focuses on measuring an organization’s performance
against that of other organizations in the same industry. Very time
consuming and expensive.
o Cost-Benefit Analysis: The project manager analyzes the benefits
versus the costs of quality efforts to determine the appropriate quality
level and requirements for the project.
o Matrix diagram: A visual representation of the relationship between
two or more sets of items. Can be used here to sort quality
requirements and identify the requirements that are most critical to
the project.
o Mind Mapping
o Flowcharts: One common model is SIPOC which shows the
connections between the supplier, input, process, output, and
customer in a process. In this process, flowcharts can help determine
the cost of quality by mapping the expected monetary value of
pursuing paths of conformance and nonconformance to quality. Can
also be used here to visualize a process and find potential quality
problems or quality control issues.
• Outputs
o Quality Management Plan
o Quality Metrics: Objective. Ex: number of defects, amount of overtime
logged, hours spent on rework, etc.
Plan Resource Management (Resource Management)

This pan encompasses the management of human resources as well as physical

resources.

• Key
o Tool
§ Organization structures
• Responsibility Assignment Matrix (RAM)
• RACI chart
• Organizational breakdown structure
• Position descriptions
o Output
§ Resource Management Plan
§ Team charter
• For both types of resources, the plan must answer questions such as the
following:
o What resources are required?
o What quantity of each type of resource is needed to complete the
work of the project?
o When and for how long will each resource be needed?
o How will the resources be acquired?
o Are these resources available internally, or will the procurement
department need to be involved?
o What will be the cost of these resources?
o Is there a limited time during which the resources will be available for
the project?
o How will resources be managed throughout the project?
• In this process, project manager uses the following
o Project charter: it includes high-level info including pre-assigned
resources.
o Project Management Plan:
§ Will help plan human resource management
§ Scope baseline includes descriptions of the project
deliverables, which helps the project manager determine the
resources needed to create those deliverables.
§ The quality management plan includes the agreed-upon level
of quality and grade of physical resources needed to satisfy the
requirements of the project.
§ The stakeholder engagement plan incudes the approach to
involving stakeholders—including the team.
§ The procurement management plan describes how the project
manager should interact with that department to facilitate the
procurement of needed human or physical resources for the
project.
 o Enterprise Environmental Factors: Refers to the company culture and
existing systems the project will have to deal with or can make use of.
§ What organizations will be involved in the project?
§ Are there hidden agendas?
§ Is there anyone who does not want the project?
§ Are assigned and potential team members collocated or based
in different offices and/or countries?
§ What is the availability of contract help?
§ What is the availability of training for project team members?
• Tools and Techniques
o Responsibility Assignment Matrix (RAM): Cross-references team
members with the activities or work packages they are to accomplish.
May use “P” for primary responsibility; “S” for secondary
responsibility
o RACI chart (Responsible, Accountable, Consult, Inform): Defines role
assignments more clearly than the RAM.
o Organizational Breakdown Structure (OBS)
o Resource Breakdown Structure: breaks the work down by type of
resource (people, material, equipment)
o Work Breakdown Structure: Ensures that each work package has an
“owner”—a team member responsible to complete that work.
o Position Descriptions
o Physical resource documentation
o Organizational Theory: This analysis helps the organization develop
effective resource management policies and procedures for the
acquisition, management, and evaluation of human and physical
resources.
o Tuckman Ladder
§ Forming
§ Storming
§ Norming
§ Performing
§ Adjourning
• Outputs
o Resource Management Plan. Includes the following components
§ Identification of resources
• Human Resources (a/k/a “Team management plan”)
• Physical Resources (a/k/a, “Physical resource
management plan”)
§ Plan for acquiring resources: How and when the project will be
staffed, how and when the staff will be released.
§ Staffing roles and responsibilities
§ Often includes a Resource Histogram which shows the
resource usage for a given period of time.
§ Staff training needs
 § Rewards systems
o Team Charter: A working agreement developed by members of the
project team.
Estimate Activity Resources (Resource Management)

• Key
o Output
§ Resource requirements
§ Basis of estimates
§ Resource Breakdown Structure (RBS)
• The project manager and the team determine the type and quality of all
resources needed to complete the project work (activities).
• This process is performed sometime after Define Activities and before
Develop Schedule
• This includes human resources to perform the work packages that were
created in the WBS and broken down in the activity list
• It also includes any equipment or materials needed, space in which to meet
and perform project work, and anything else needed to fulfill the
requirements of the project.
• At the end of the process, the team will have determined resource
requirements for project activities, including the cost, quantity, and
availability of human and physical resources.
o This can be documented in a Resource Breakdown Structure (RBS).
The RBS is used in Plan Resource Management to break down the
work by the type of resource required. As planning continues, and
more detailed is gathered, the RBS is expanded and augmented in the
Estimate Activity Resources process.
• Estimating techniques to estimate resources
o Bottom-up estimating: Same technique as was used in the Estimate
Activity Duration process, except this time we are aggregating
individual resource estimates. Topmost node on the WBS should
contain all of the estimated resources for the project.
o Analogous estimating
o Parametric estimating
o Alternatives analysis: The above tools can be used to generate
estimates for various options—such as the costs to make versus buy
software for a project, etc. Alternatives analysis can then be used to
assess the impact of each option on the project constraints such as
schedule, cost, quality, and risk.
o Resource histogram: a way to visualize resource requirements, and
compare needed resources and their availability to better enables
estimating. It’s a bar chart that shows the number of resources needed
per time period. It also illustrates where there is a spike in the need
for resources. If the materials, equipment, or human resources are not
available when they are needed, the project manager must evaluate
available options.
§ Resource leveling: a technique to change the project to
minimize the peaks and valleys of resource usage. Project
 manager can use a resource histogram to help in performing
resource leveling.
• Outputs
o Resource Requirements: Resources required for each scheduled
activity
§ Kind of resource
§ Number of resource
o Basis of Estimates: All three of the estimating processes that are tied
to activities (Estimate Activity Resources, Estimate Costs, Estimate
Activity Durations) include the Basis for Estimates along with the
estimates themselves. Including this supporting detail is always a
good idea.
o Resource Breakdown Structure (RBS)
Plan Communications Management (Communications Management)

It is the process of producing a guide of how to conduct proper communication

within the project taking into account the project stakeholders needs.

• Output
o Communication Management Plan
• Includes planning what information will be communicated, to whom, when,
using what method, and how frequently.
• The Communications Management Plan will guide the project manager and
the team in managing and monitoring communications to ensure information
is getting to the people who need it, is clear and understandable, and allows
stakeholders to take action as necessary.
• Tools
o Communication Requirements Analysis: The goal of this technique is
to identify which stakeholders should receive project
communications, what communications they should receive and how
often they should receive them. Ex:
§ Who: Steering committee
§ What: Status reports
§ How: Meetings, email
§ When: Monthly
• Five C’s of communication
o Correct grammar and spelling
o Concise and well-crafted
o Clear and purposeful
o Coherent and logical
o Controlled flow of words and ideas
• Types of communication
o Formal written: Project management plan, other formal
documentation (such as project charter), and reports; can be both
physical and electronic
o Formal verbal: Planned meetings and stakeholder briefings; can be
face-to-face or remote
o Informal written: Email, handwritten notes, text messages, instant
messaging, social media, and websites
o Informal verbal: Unscheduled meetings, conversations, and other
casual discussions
• Interactive communication: includes three main components
o Sender (encode message)
o Receiver (decode message) and then confirms receipt
o Sender and receiver both confirm that the message is correctly
understood by the receiver. The Sender should ask for feedback by
asking the receiver to rephrase in their own words.
• Non-verbal: Gestures, facial expressions, and body language
• Verbal
o Words and phrases the sender chooses which can be obscured by the
accompanying nonverbal factors
o Pith and tone of voice also help to convey a spoken message
• Effective listening: Receiver confirms they are listening, expresses agreement
or disagreement, and asks for clarification when necessary.
• Communications technology. To determine the appropriate technology to use
ask questions
o Would it be better to communicate this information in person or
virtually?
o Would it be better to communicate the information through an email
or a phone call?
o What technology is the team familiar and comfortable with?
o How quickly does the information need to be communicated?
o Are there security or confidentiality issues that should be considered
when choosing a means of communicating information?
o Would a letter sent through the mail get more attention?
• Communication Methods
o Interactive: This method is reciprocal and involves two or more
people. One person provides information; others receive it and then
respond to the information. Examples of interactive communication
include conversations, phone calls, meetings, instant messaging, and
video calls.
o Push: One-way stream of information. Sender provides information to
the people who need it but does not expect feedback from the
recipients. Ex: Status reports, emailed updates, blogs, company
memos.
o Pull: Sender places information in a central location. Recipients are
then responsible for retrieving the information from that location.
• Communications Requirement Analysis helps you to correctly understand
stakeholders’’ information requirements. Use the following
o Stakeholder register
o Stakeholder engagement plan
o Locations of stakeholders
o Number of communication channels
• Communication channels: n(n-1)/2. If question doesn’t mention the project
manager, may need to add yourself.
Plan Risk Management (Risk Management)

Involves creating a user guide for the project manager on how to conduct risk
management activities for a project.

It is only after risk management planning is completed that the final cost and
schedule can be determined.

Risk management could also result in iterations to the scope, the deliverables, the
project resources, the sequence in which activities are performed and almost all
other parts of the project.

• Output
o Risk Management Plan
• While in this process, your main task is to create the risk management plan.
When performing Plan Risk Management, you usually are not concerned with
specific project risks.
• Usually takes place very early in the project because it is high-level in nature.
It is performed early on because the result of this and other risk processes
can significantly influence decisions made about scope, time, cost, quality,
and procurement.
• The project manager, sponsor, team, customer, other stakeholders, and
experts may be involved in this process. They define how risk management
will be structured for the project.
• Because risk management is so important to the success of a project, it is
wise to think about how you will approach risk management before you do it.
This is the purpose of this process.
• Plan Risk Management answers the question of how much time should be
spent on risk management based on the needs of the project. This includes
the risk appetite of management and other key stakeholders.
• This process also identifies who will be involved and how the team will go
about performing risk management.
• Outputs
o Risk strategy: This is the overall approach to managing risk
throughout the life of the project.
o Methodology: This section of the plan defines how risk management
will be performed to meet the needs of the specific project. Low-
priority projects will warrant less of a risk management effort than
high priority projects.
o Roles and responsibilities: This section explains who will do what risk
management work.
o Funding: The cost of the risk management process. This section also
includes a plan for utilizing reserves in response to risks on the
project.
 o Timing: When to do risk management for the project. Should start as
soon as you have the appropriate inputs and should be repeated
throughout the life of the project, since new risks can be identified as
the project progresses and the degree of risk can change over the
course of the project.
o Risk categories (a/k/a “sources of risk”). Can be structured via a Risk
Breakdown Structure (RBS). We are not breaking down the actual
risks (they won’t all be known until we perform the Identify Risks
process). Instead, we are breaking down the categories of risks that
we will evaluate.
§ External: Regulatory, environmental, or governmental issues;
market shifts; problems with project sites, etc.
§ Internal: Changes to schedule or budget; scope changes;
inexperienced team members; issues with people; staffing,
materials, and equipment, etc.
§ Technical: Changes in technology, technical processes, or
interfaces, etc.
§ Commercial: Customer stability, terms and conditions within
contracts, vendors, etc.
§ Unforeseeable: Only a small portion of risks (~10%) are
actually unforeseeable.
o Stakeholder risk appetite/thresholds
o Definitions of probability and impact. Could use a probability and
impact matrix.
o Reporting: Describes reports related to the risk management effort on
the project that will be created.
o Tracking: Describes how the risk management process will be audited
and how the results of risk management efforts will be documented.
• Types of risk
o Business risk: Risk of a gain or loss
o Pure (insurable) risk: Only a risk of loss (such as fire, theft, personal
injury, etc.)
• Non-event risks
o Variability: Risks caused by the inability to predict future changes
o Ambiguity: Risks caused by a lack of understanding.
Identify Risks (Risk Management)

Involves the efforts the project team exerts to identify all possible individual
risks and overall project risk.

• Key
o Technique
§ Cause & Effect diagram (Ishikawa, Fishbone)
§ Flow chart (process map)
§ SWOT analysis
o Tool
§ Influence diagram
§ Assumptions analysis
§ Checklist analysis: Used to identify specific risks within each
category
§ Documentation reviews
o Output
§ Risk register: Detailed database of all risks ever captured and
related info (like qualitative and quantitative analysis).
§ Risk report: Summary information on overall project risk and
opportunities for a select audience (normally senior
management). As the name suggests, it is a communication
tool.
• Best to use a combination of tools and techniques to identify risks as opposed
to just one.
• Assumptions are analyzed here (or could be Plan Risk Management)
• The effort of identifying risks should involve all stakeholders and might even
include literature reviews, research, and communicating with non-
stakeholders.
• If you get a question on the exam about who should be involved in risk
identification, the best answer is “everyone”.
• Project managers should begin looking for risks as soon as a project is first
discussed.
• An assessment of overall project risk is included in the project charter,
however, the major risk identification effort occurs during planning.
However, risks should be continually reassessed including during integrated
change control, when working with contracts, when working with resources,
and when dealing with project issues.
• Risk workshop: specialized meeting undertaken for the purposes of
identifying risks.
• Prompt Lists: A list of categories that have been identified as possible
sources of risk to the project. Overall project risks subscribe to one of three
common types of prompt lists
o VUCA: Volatility, Uncertainty, Complexity, Ambiguity
o TECOP: Technical, Environmental, Commercial, Operational, Political
 o PESTLE: Political, Economic, Social, Technological, Legal,
Environmental
• Root cause analysis: Using Ishikawa (fishbone) diagrams or the 5 why
technique (asking “why” five times to uncover root causes) to trace risk
events back to identify the underlying factors that led to them.
• Constraint analysis: Constraints such as schedule or budget limitations are
examined to determine the level of risk they pose.
• SWOT analysis: Examines the project to identify its strengths and
weaknesses as well as opportunities and threats that could originate from
those strengths and weaknesses.
• Outputs
o Risk Register: One document for the entire risk management process
that will be constantly updated with information as the risk
management processes are completed. The risk register is an output
of several of the risk management processes. It contains different
information at different points in the risk management process. At
this point, after the Identify Risks process, the risk register includes
§ List of risks
§ Potential risk owners
§ Potential risk responses
§ Root causes if risks
§ Updated risk categories
o Risk Report: This report is generated and disseminated to
stakeholders to keep them apprised of risk management efforts and
outcomes.
Perform Qualitative Risk Analysis (Risk Management)

Refers to the process of assessing risks probability, impact, and other risk
parameters in order to set risk priorities.

• Key
o Tool
§ Risk data quality assessment
§ Risk urgency assessment
§ Risk categorization
§ Sensitivity analysis
§ Decision tree analysis (Expected Monetary Value: EMV)
• Subtract the cost from the revenue of each opportunity
• Then multiple the result by the percentage and add.
o Output
§ Risk register
§ Risk report
• At the start of this process, we should have a long list of risks documented in
the risk register.
• Too expensive and too time consuming to plan responses to all these risks.
• This process allows you to subjectively analyze the risks, including their
probability and potential impact on the project, to determine which ones
warrant a response, which results in a shortened list of the previously
identified project risks. This shortened list is then further analyzed in the
Perform Quantitative Risk Analysis process or they may move into the Plan
Risk Responses process.
• This process is repeated, as new risks are uncovered throughout the project.
• To perform this analysis the following must be determined
o The probability of each risk occurring, using a standard scale
(common subjective analysis scales include Low, Medium, High, and 1
to 10)
o The impact (the amount at stake or the positive or negative
consequences) of each risk occurring, using a standard scale, such as
Low, Medium, High, or 1 to 10)
• Risk Data Quality Assessment: Garbage in equals garbage out. Before you can
use the risk information collected on the project, you must analyze the
precision of the data. You assess the accuracy and reliability of the data, and
determine if the risk is valid and whether more research is needed to
understand the risk. Such an assessment may include determining the
following for each risk:
o Extent of the understanding of each risk
o Data available about the risk
o Quality of the data
o Reliability and integrity of the data
• Risk Categorization: Regrouping risks by categories, by source, by work
packages. Useful to show which work packages, processes, people or other
potential causes have the most risk associated with them.
o RBS: Categorization by sources of risk
o WBS: Categorization by area of the project affected
• Probability and Impact Matrix: Data representation technique.
• Where risks have been categorized using more than two parameters, the
probability and impact matrix cannot be used and other graphical
representations are required. Ex: bubble chart displays three dimensions of
data, where each risk is plotted as a disk and the three parameters are
represented by the x-axis value, the y-axis value, and the bubble size.
• Risk Parameters Assessments: Identifying risks that should move more
quickly through the process than others due to factors that are referred to as
risk parameters.
o Urgency: How much time you have to respond to a risk event. A short
amount of time does not necessarily make the risk important, but it
does make it urgent. Lower is better.
o Proximity: How much time you have before the risk impacts project
goals. Lower proximity is more desirable.
o Dormancy: How much time will likely pass after the risk has occurred
but before it is detected. A home water leak in a rarely-used room
might have more dormancy than a water leak in the kitchen. Lower is
better.
o Manageability and controllability: How easily a risk’s impact can be
managed and changed. Higher is better
o Strategic impact: How likely the risk event is to impact the
organization’s strategic goals. Lower strategic impact is better.
o Connectivity: Many negative project events that occur are
combinations of numerous risk events. Domino effect. Lower is better
o Propinquity: The measure of how important the project’s
stakeholders perceive this risk to be. Lower is better.
• Outputs
o Risk register. Updated to include
§ Risk ranking for the project compared to other projects
§ List of prioritized risks and their probability and impact
ratings
§ Results of other risk parameter assessments
§ Risks grouped by categories
§ List of risks for additional analysis and response (these are the
risks that will move forward into quantitative risk analysis
and/or risk response planning
§ List of risks requiring additional analysis in the near term
§ Watch list (non-critical risks)
o Risk Report Updates: Includes the results of risk prioritization and a
list of the highest-ranking risks.
• Qualitative risk analysis can be used to determine whether the project should
be continued or terminated.
• Can also be used to determine whether to proceed to the Perform Qualitative
Risk Analysis or Plan Risk Responses process.
Perform Quantitative Risk Analysis (Risk Management)

It is the process of setting a numerical value to risk parameters as a mean to

further prioritization. This process has great value when it comes to assessing risk
responses feasibility.

• Key
o Technique
§ Monte Carlo Analysis
o Output
§ Risk report
• This is a more objective and numerical evaluation than the Perform
Qualitative Risk Analysis. For example, a rating for a risk in qualitative risk
analysis might be a 5, that same risk might be quantified as a $40,000 cost
impact in quantitative risk analysis.
• Usually expressed as time or cost.
• Might not be necessary for all projects (though qualitative risk analysis is). It
may be skipped in favor of moving onto risk response planning. Only do this
process if it’s worth the time and money.
• Involves numerically analyzing the probability and impact of risks that
ranked highest in the qualitative risk analysis.
• Also looks at how risks could affect the objectives of the project.
• Purpose of Perform Quantitative Risk Analysis
o Determine which risk events warrant a response
o Determine overall project risk (risk exposure)
o Determine the quantified probability of meeting project objectives
(for example, we only have an 80% chance of completing the project
within six months)
o Determine cost and schedule reserves
o Identify risks requiring the most attention
o Create realistic and achievable cost, schedule, or scope targets
• Simulations: A Monte Carlo analysis is a computer program that uses the
network diagram and schedule or costs estimates to “perform” the project
many times and to simulate the cost or schedule results of the project. This
could determine for example, that even if the project were done 5,000 times,
there is only a low probability that the end date they desire would be met.
Can identify tasks that, if delayed or their budget exceeded, the whole project
may be adversely affected.
• Sensitivity Analysis: a technique to analyze and compare the potential
impacts of identified risks. Sensitivity to risk factors. A tornado diagram may
be used to graphically depict the results of this analysis.
• Decision Tree Analysis: Models of real situations that are used to make
informed decisions about things like, “Which option should I choose?” by
taking into account the associated risks, probabilities, and impacts.
o Analyzed by calculating the value of each branch.
 o EMV (Expected Monetary Value for Cost) or EV (Expected Value for
Schedule) = P (probability) x I (impact).
§ For opportunities, EMV (or EV) is positive; for threats, EMV (or
EV) is negative
§ For cost (EMV), the risk is in dollars; for schedule (EV), the risk
in calendar days.
• Output
o Risk Register updates: Updated to add the results of quantitative risk
analysis including:
§ Prioritized list of quantified individual project risks
§ The quantified probability of meeting project objectives
§ Trends in quantitative risk analysis
§ Initial contingency time and cost reserves needed
§ Assessment of overall project risk exposure
§ Possible realistic and achievable completion dates and project
costs, with confidence levels versus the time and cost
objectives for the project.
§ Recommended risk responses
o Risk Report: Updated to include the results of the quantitative
analysis.
Plan Risk Responses (Risk Management)

This process includes developing options, selecting strategies, and agreeing on

actions to deal with individual project risks.

• Output
o Risk register
o Risk reports
• This process involves figuring out, “What are we going to do about each top
risk?”
• In this process, we are creating a detailed plan for how each risk will be
handled, but this process is also about taking action. It’s an action plan that
assigns specific tasks and responsibilities to specific team members.
• This process is about finding ways to reduce or eliminate threats, and find
ways to make opportunities more likely or increase their impact.
• Risk responses may include doing one or a combination of the following for
each top risk:
o Do something to eliminate the threats before they happen.
o Do something to make sure the opportunities happen.
o Decrease the probability and/or impact of threats.
o Increase the probability and/or impact of opportunities.
• For residual threats that cannot be eliminated:
o Do something if the risk happens (contingency plans). Contingency
plans should be measureable so you can evaluate their effectiveness.
o Do something if contingency plans are not effective or are only
partially effective (fallback plan).
• For the exam, assume that all major potential problems that could have been
identified in advance as risks were determined before they occurred and that
there was a plan for each of these risks. Therefore the best answer to a
question describing a major problem on the project will be the choice that
talks about implementing a contingency plan rather than one that involves
discussing possible solutions to a problem after it has occurred.
• All threats can be eliminated and all opportunities exploited, but it would not
be worth the time and money
• Risk management is very iterative. Need to review risks throughout the
project including while the project work is being done or when checking
results. When new risks are identified, need to spend time analyzing them
and planning responses. Risk ratings and response strategies for existing
risks can change, as more info about the risks becomes known.
• Primary input to this process:
o Risk Register. It has been updated throughout the risk management
process and now includes a list of risks that have been qualitatively
(and possibly quantitatively) analyzed. The risks have been
prioritized based on their probability and impact. These are risks for
which responses will be planned.
 o Cost baseline: Describes the contingency reserve that will be used in
addressing identified risks.
• Risk response strategies
o Avoid: Eliminate the threat by eliminating the cause, such as removing
the work package or changing the person assigned to do the work.
Might even involve expanding the scope of the project in order to
avoid the threat. Used for high priority, high-impact risks.
o Mitigate: Reduce the probability and/or the impact of an individual or
overall project threat, thereby making it a smaller risk and possibly
removing it from the list of top risks on the project. Used for high
priority, high-impact risks.
o Transfer (deflect, allocate): Make a party outside of the project
responsible for the threat by purchasing insurance, warranties, etc. or
by outsourcing the work. Connection between risk and procurement.
Appropriate for low-priority, low-impact risks as well as those with
higher impact. Response to pure risks.
• Opportunities response strategies
o Exploit (reverse of “avoid”): Add work or change to the project to
make sure the opportunity occurs.
o Enhance (reverse of “mitigate”): Increase the likelihood (probability)
and/or positive impacts of the opportunity occurring.
o Share: Allocate ownership or partial ownership of the individual or
overall project opportunity to a third party that is best able to achieve
the opportunity.
• Response strategies for Risks and Opportunities
o Escalate: A threat or an opportunity should be escalated if it is outside
the scope of the project or beyond the project manager’s authority.
Any risks that are escalated will typically be managed at the program
or portfolio level—not at the project level. Risk is then no longer
monitored at the project level. It is someone else’s responsibility.
o Accept: Passive acceptance means to do nothing and essentially say,
“If it happens, it happens”. This leaves actions to be determined as
needed (workarounds) if the risk occurs. Active acceptance involves
creating contingency plans to be implemented if the risk occurs and
allocating time and cost reserves to the project.
• Risk response strategies must be communicated to the sponsor,
management, and stakeholders. These parties need to know you are in
control of the project even if there is a problem, and they may need to
approve the resources to make the risk response strategies happen.
• Contingent Response Strategies: Contingency plan/fallback plan is one where
the project team may make one decision related to risk, but make that
decision contingent upon certain conditions.
• Cost benefit analysis and multi-criteria analysis are techniques to evaluate
and rank potential risk responses.
• Outputs
 o Project Management Plan Updates
o Risk Register updates: Updated to include the results of the risk
response planning including:
§ Residual risks: Risks that remain after risk response planning.
After you have avoided, exploited, mitigated, enhanced,
transferred, shared, escalated, and accepted risks (and created
related contingency plans and fallback plans), there will still be
risks that remain.
§ Contingency plans: Plans describing the specific actions that
will be taken if the opportunity or threat continues.
§ Fallback plans: Specific actions that will be taken if the
contingency plans are not effective.
§ Risk owners: Each risk is assigned to someone
§ Secondary risks: Any new risks created by the implementation
of selected risk responses.
§ Risk triggers: Events that trigger the contingency response.
§ Contracts: Any contracts issued to deal with risks are noted in
the risk register
§ Reserves (contingency): Reserves for time and cost for known
unknowns identified in risk management. Reserves are not an
additional cost to a project. The risk management process
should result in a decrease to the project’s estimated time and
cost. As threats are eliminated or their probability or impact
reduced, there should be a reduction to the project’s schedule
and budget
• Cost budget: $1,423
Management reserves: $68
Cost baseline: $1355
Contingency reserves: $105
Project estimates: $1,250
• Calculating contingency reserve: Add the threats and subtract the
opportunities to arrive at the total EMV or EV.
• Non-critical risks: Put them on a watch list and revisit them periodically
• Risk management activities done during execution of a project
o Watching out for watch-listed (non-critical) risks that increase in
importance, and looking for new risks
o Implement contingency plans if triggers indicate the risk is about to
occur or is occurring
• Most important item to address in project team meetings: Risk!
• How to address risk in project meetings: Simply ask, “What is the status of
risks? Is there any change to the order of importance?”
Plan Procurement Management process (Procurement Management)

• Output
o Procurement management plan
o Procurement strategy
o Bid documents
o SOW
o Source selection criteria
o Make-or-buy decision
o Independent cost estimates
• The process answers these questions:
o How will make-or-buy analysis be performed?
o What goods and services do we need to buy for this project?
o How will we purchase them?
o Who are the potential sellers to consider?
• The process includes putting together the bid documents (RFPs, RFQs, RFIs,
IFBs) that will be sent to prospective sellers describing the buyer’s need, how
to respond, and the criteria the buyer will use to select a seller.
• This process includes the following activities:
o Performing make-or-buy analysis
o Creating a procurement management plan
o Creating a procurement strategy for each procurement
o Creating a procurement statement of work for each procurement
o Selecting the appropriate contract type for each procurement
o Creating the bid documents
o Determining the source selection criteria
• Preapproved Seller List (input into this process): A list of preapproved
sellers. a/k/a “prequalified seller list”. Similar is a “master service
agreement” which are contracts between two parties including standard
terms that will govern future transactions. Useful when a buyer frequently
works with the same seller.
• Two primary types of analysis that can be useful during the Plan
Procurement Management process
o Make-or-Buy Analysis: Completed early in the planning process to
avoid wasted time planning work that will ultimately be outsourced.
§ Economic models
• Payback period
• Return on investment
• Internal rate of return
• Discounted cash flow
• Net present value
• Cost-benefit analysis
§ Calculate difference between out-of-pocket (OOP) expenses
and divide that by the difference in the monthly fees.
• Example
 o Build: $65,000 w/monthly fee of $8,500.
o Buy: $52,000 w/monthly fee of $10,500.
o (65,000 - 52,000) / (10,500 – 8,500) = 6.5
months. Meaning that after 6.5 months, leasing
will be more expensive.
o Source Selection Analysis: Criteria that will be used to select a seller.
Project constraints must be analyzed. Could be lowest price if a
commodity item is being purchased. Or it can be number of years in
business, financial stability, understanding of need, price or life cycle
cost, technical expertise, quality of past performance, ability to
complete the work on time. If the organization has a preferred seller
list or a master service agreement with an outside source, that
information is also considered when analyzing source selection
options
§ Least cost
§ Qualifications only
§ Quality based/highest technical proposal score
§ Quality and cost-based
§ Sole source
§ Fixed budget: Disclosing available budget to sellers in the RFP.
• Procurement Strategy: Developed for each procurement after the make-or-
buy analysis has been completed and the goods or services to be acquired
from outside the organization have been identified.
o How goods or services will be delivered to the buyer. Ex: will the
procurement include any subcontractors or an outside service
provider)
o What type of contract will be used. Ex: fixed-price or cost plus.
o How procurement will be carried out throughout each phase
• Contract Types: Considered Organization Process Assets. Type depends on
the following considerations:
o What is being purchased (a product or a service)
o The completeness of the statement of work
o The level of effort and expertise the buyer can devote to managing the
seller
o Whether the buyer wants to offer the seller incentives
o The marketplace or economy
o Industry standards for the type of contract used
• Categories of contracts
o Fixed-price (FP)
§ For well-defined specs or requirements.
§ Buyer has least risk. Seller bears any additional costs
§ Risk for the buyer is that claims or disputes over what is in and
out of the contract create higher risk of cost overruns or delay
§ Seller most concerned with the procurement statement of
work (SOW) in a fixed-price contract. This helps the seller to
 accurately estimate time and cost for the work involved and
allow them to determine a price that includes a fair and
reasonable profit.
§ Profit is not disclosed to the buyer
§ Not always the best choice even though buyer may prefer as a
way to control costs
§ Advantages
• Requires less work for buyer to manage
• Seller has strong incentive to control costs
• Companies usually have experience with this type of
contract
• Buyer knows the total price before the work begins
§ Disadvantages
• If seller underprices the work, they may try to make up
profits by charging more than is necessary on change
orders.
• Seller may try to not complete some of the procurement
statement of work if they begin to lose money.
• Requires more work for the buyer to write the
procurement SOW.
• Can be more expensive than a cost-reimbursable
contract if the SOW is incomplete. In addition, the seller
needs to add to the price of a fixed-based contract to
account for the increased risk.
§ Types of fixed-price contracts
• Firm Fixed-Price (FFP): Fixed total price is set for the
project, all requirements have been clearly described
and changes to scope should not occur.
• Fixed Price Incentive Fee (FPIF): Profits or financial
incentives can be adjusted based on the seller meeting
specified performance criteria such as getting the work
done faster, cheaper, or better.
o Ex: Contract = $1,100,000. For every month early
the project is finished, an additional $10,000 is
paid to the seller
• Fixed Price Award Fee (FPAF): The buyer pays a fixed
price plus an award amount (bonus) based on
performance. Similar to FPIF except the total possible
award amount is determined in advance and
apportioned based on performance. Ex: the buyer might
say there is a max $50,000 award fee available.
o Ex: Contract = $1,100,000. For every month that
performance exceeds the planned level by more
than 15% an additional $5,000 is awarded to the
seller with a max award of $50,000.
 • Fixed Price w/ Economic Price Adjustments (FPEPA):
For multiyear contracts, there may be uncertainties
about future economic conditions. Future costs and
equipment the seller might be required to provide may
not be predictable. a/k/a “Fixed Price w/ Prospective
Price Redetermination”
o Ex:
§ Contract = $1,100,000, but a price
increase will be allowed in year two
based on the US Consumer Price Index
report for year one.
§ Contract = $1,100,000, but a price
increase will be allowed in year two to
account for increases in specific material
costs.
• Purchase Order: Simplest type of fixed-price contract.
Unilateral (signed by one party). Used for simple
commodity procurements. Purchase orders become
contracts when the buyer accepts the terms.
o Ex: Contract = 30 linear meters of wood at $9 per
meter.
o Time and Materials (T&M)
§ Buyer pays on a per-hour or per item-basis
§ Frequently used for service efforts, which the level of effort
cannot be defined when the contract is awarded.
§ Includes elements of a fixed-price contract (fixed price per
hour) and cost-reimbursable contract (the material costs and
the fact that the total cost is unknown).
§ Terms and conditions are usually simple.
§ Seller has no incentive to get the work done quickly or
efficiently since profit is already built into the rate.
§ Best used for work valued at small dollar amounts and lasting a
short amount of time.
§ To make sure costs do not become higher than budgeted, buyer
may add a “Not to Exceed” clause.
§ Buyer has medium cost risk
§ Ex:
• Contract = $100 per hour plus expenses or materials at
cost
• Contract = $100 per hour plus materials at $5 per linear
meter of wood
§ Advantages
• Can be created quickly, because SOW may be less
detailed.
• Contract duration is brief
 • Good choice when you are hiring “bodies” or people to
augment your staff.
§ Disadvantages
• Profit for the seller in every hour or unit billed
• Seller has no incentive to control costs
• Appropriate only for work involving a small level of
effort
• Requires a great deal of day-to-day oversight from
buyer.
o Cost-reimbursable (CR)
§ Used when the exact scope of work is uncertain and therefore,
costs cannot be estimated accurately enough for a fixed-price
contract.
§ Buyer pays the seller allowable incurred costs to the extent
prescribed in the contract.
§ Usually include an additional fee or award amount added to
the cost to allow for seller profit.
§ Advantages
• Allows for a simpler SOW
• Requires less work to define the scope
• Less costly than a fixed-priced contract because the
seller does not have to add as much for risk.
§ Disadvantages
• Requires auditing the seller’s invoices
• Requires more work for the buyer to manage
• Seller has only moderate incentive to control costs
• Total price is unknown
§ Types of Cost-reimbursable contracts
• Cost Contract: The seller receives no fee (profit). It is
appropriate for work performed by nonprofit
organizations.
o Ex: Contract = Cost for work and materials.
There is no profit.
• Cost Plus Fixed Fee (CPFF): Provides for payment to the
seller of actual costs plus a negotiated fee (the seller’s
profit, usually a percentage of the estimated cost of the
project) that is fixed before the work begins. The fee
does not vary with the actual costs; thus the seller does
not have an incentive to increase or inflate costs. Fee
may be adjusted as a result of changes to the
procurement SOW.
o Ex: Contract = Cost plus a fee of $100,000
• Cost Plus Incentive Fee (CPIF): Provides for the seller to
be paid for actual costs plus a fee that will be adjusted
based on whether specific performance objectives
 stated in the contract are met. An original estimate of
the total cost is made (target cost) and a fee for the
work is determined (target fee). Seller gets a percentage
of the savings if the actual costs are less than the target
costs, or shares the cost overrun with the buyer. The
ratio is often 80% to the buyer and 20% to the seller.
o Ex: Contract = $500,000 target cost plus $50,000
target fee. The buyer and seller share any cost
savings or overruns at 80% to the buyer and
20% to the seller.
• Cost Plus Award Fee (CPAF): Buyer pays all costs and a
base fee plus an award amount (a bonus) based on
performance. Similar to the CPIF contract, except the
incentive is a potential award, and there is no possibility
of a penalty. The award amount in a CPAF contract is
determined in advance and apportioned depending on
performance. This is a type of incentive contract. The
buyer may decide not to award.
o Ex: Contract = Cost plus a base fee plus award for
meeting buyer-specified performance criteria.
Maximum award available is $50,000.
• Cost Plus Fee (CPF) or Cost Plus Percentage of Costs
(CPPC): Requires buyer to pay for all costs plus a
percentage of costs as a fee. Bad for buyers because if
seller profit is based on a percentage of everything
billed to the buyer for the project, what incentive is
there to control costs? Requires buyer to carefully
monitor and control all invoices.
o Ex: Contract = Cost plus 10% of costs as fee
• Point of Total Assumption (PTA): The cost point in the contract where a
subcontractor assumes responsibility for all additional costs.
o Formula: Target cost + (ceiling price – target price) / Buers % shre of
cost overruny
• Procurement Statement of Work (SOW): Project manager facilitates the
creation of a SOW to be done on each procurement. This is done by breaking
down the project scope baseline into the work the project team will do and
the work that will be purchased from a seller. Should describe what you
want, when you want it and how good it should be.
• Source Selection Criteria: Source selection analysis results in finalized source
selection criteria. Often assigned numerical percentage values (weighted) to
enable evaluation of proposals based on each criterion.
• Independent Cost Estimates: Buyer may prepare an internal estimate or use
the input of experts to come up with a benchmark against which to validate
the bids provided by outside sellers during Conduct Procurements.
• Bid Documents: After the contract type is selected and the SOW has been
created, the buyer can put together the bid document. Types of bid
documents
o Request for Proposal (RFP): Detailed proposal w/price
o Invitation to Bid (IFB): Similar to RFP, but the work described in the
SOW is detailed enough that the bidder only provides a total price
o Request for Quotation (RFQ): Request a price quote per item, hour,
meter, or other unit of measure
o Request for Information (RFI): Might be used before bid documents
are created. Responses to the RFI help the buyer identify which
companies are qualified to handle the procurement. May also be used
by the buyer to determine what work is possible for later inclusion in
RFPs or IFBs.
• Letter of Intent: Not a contract, but simply a letter stating that the buyer
intends to hire the seller.
• Non-competitive procurement process
o Single source: There are other sellers, but you contract directly with
your preferred seller without going through the full procurement
process.
o Sole source: There is only one seller.
• Change requests: Procurements may not begin for months or years after
initial project planning is completed. Therefore, the procurement
management plan is likely to be iterated and possible changed through
integrated change control, as each procurement is needed. This is often
accomplished through change requests.
o The results of procurement management planning may impact
existing components of the project management plan. For example, it
may be determined in procurement planning that the current budget
is not adequate to cover the cost of a procurement, requiring a change
request to the cost management plan and baseline. As another
example, clarifying needs for physical resources may require changes
to elements of the project management plan, such as the resource
management plan and schedule and cost baselines.
• Outputs
o Procurement Management Plan
o Procurement Strategy
o Bid documents
o Procurement SOW
o Source selection criteria
o Make-or-buy decisions
o Independent cost estimates
Plan Stakeholder Engagement process (Stakeholder Management)

The process concerned with planning for how to approach different

stakeholders as well as gathering stakeholders needs and manage their
expectations.

• Key
o Output
§ Stakeholder engagement plan
• Need to determine which stakeholders will require most of your time and
effort.
• You need details on what has already been planned and documented in plans
including resource and communications management, information from the
stakeholder register, and any relevant information from past similar projects.
• Stakeholder Engagement Assessment Matrix
o Data representation tool used to compare stakeholders’ current and
desired level of engagement. Bar chart (“No engagement” to “Highly
Engaged” along y axis and stakeholder names along x axis.
o Stakeholder engagement plan documents how adjustments to the
stakeholders’ level of engagement will be achieved.
o This matrix is revisited as the project progresses, to evaluate ongoing
stakeholder engagement.
o Analysis of updates to this matrix may indicate the need to further
plan or alter the stakeholder engagement strategy.
• Assumption and Constraint Analysis and Root Cause Analysis
o Evaluating assumptions about stakeholders’ attitudes toward the
project enables the team to determine actions necessary to adjust
stakeholders’ levels of engagement to benefit the project.
o Analysis of project constraints can provide insight into determining
strategies to adjust stakeholders’ levels of engagement.
o Root cause analysis is a way for the project manager and team to
analyze the cause of the current level of stakeholder support and
engagement. Doing so will help them determine how best to facilitate
a change to bring the stakeholders’ engagement level to what is
desired.
• Output
o Stakeholder Engagement Plan
§ Documents the existing and desired levels of engagement for
all stakeholders, including plans to achieve the desired levels.
§ Also provides details about ways in which stakeholders will be
involved in the project, and includes guidelines and metrics for
monitoring and evaluating how well the plan is meeting the
needs of stakeholders and the project.
§ Includes a component that addresses how communication will
be used on the project to help manage stakeholder
 engagement. Somewhat similar to the communications
management plan but with a different focus. Communications
management plan emphasizes the details about the technology,
methods, and models of communication—the what, when, and
how of communication (ex: What: Status reports; When:
Weekly; How: Email). The stakeholder engagement plan
explains the why of communications—why stakeholders need
to receive certain information, and how the sharing of that
information will help in managing stakeholder engagement
and expectations. How often and in what detail will they
receive information. Portions of these two plans are often
created together.
§ Provides guidance and strategies on how to engage the various
stakeholders.
Executing

• The focus of executing is managing people, physical resources, and work to

accomplish the project as planned
• Work Performance Data includes the initial measurements and details abut
activities in this process.
• Team completes the work according to the processes and procedures in the
Project Management Plan.
• Executing means working with the latest revision of the project management
plan. That means, you enter the executing process group once project
planning is completed and/or again if integrated change control results in a
changed project management plan.
Direct and Manage Project Work (Integration Management)

This process refers to leading and controlling the project work activities. The
key outputs of this process are the finished work deliverables and change requests
for project work. This process aims to increase the probability of project success.

• Key
o EEF
§ Work Authorization System (WAS): Defines approval levels
needed to issue work authorization , it helps preventing scope
creep as formal approval must be available before work begins
o Output
§ Deliverables
§ Work performance data
§ Issue log
• Project Manager integrates all the executing work into one coordinated effort
to accomplish the project management plan and produce the deliverables.
• Most of the project’s time, cost and resources are expended in this process.
It’s where roads get built, software gets written, buildings get constructed,
and products roll off the assembly line.
• This process occurs any and every time you are following the project
management plan to create project deliverables.
• Approved change requests are an input into this process.
• Available resources are allocated, their efficient use is managed, and changes
in project plans stemming from analyzing work performance data and
information are carried out.
• This process requires review of the impact of all project changes and the
implementation of approved changes: corrective action, preventive action,
and/or defect repair.
• Work Performance Data is gathered and communicated to the applicable
controlling processes for analysis.
• Work performance data analysis provides information about the completion
status of deliverables and other relevant details about project performance.
• The work performance data will also be used as an input to the Monitoring
and Controlling Process Group.
• Issue Log is created. The issue log is then updated as a result of the managing
and controlling processes throughout the project.
• Changes requested
• Completing work as a result of approved change requests
• Project Manager also takes time to focus on managing the schedule, budget,
risks, quality and all other knowledge areas. The PMIS helps with this.
• Work Authorization System (part of the PMIS) is the project manager’s
system for authorizing the start of work packages or activities.
• Outputs
o Deliverables.
 o Work performance data
o Issue log
o Change requests
• This is the sequence after each deliverable is produced:
o After each deliverable is produced, it is first evaluated for correctness
in the Control Quality process. Once deemed correct in terms of
quality, the deliverable is considered a verified deliverable
o It then passes to the Validate Scope process as an input
o The customer or sponsor inspects the verified deliverable, comparing
it against the acceptance criteria defined in the scope statement of the
scope baseline
o If the deliverable meets the criteria, it becomes an accepted
deliverable and formal documentation is sent to the Close Project or
Phase process.
Manage Project Knowledge (Integration Management)

This process aims to improve the project product and results using existing
knowledge. In addition to the previous objective, Manage Project Knowledge
process also helps to update company and project team knowledge. Also, Manage
Project Knowledge outputs help to improve future phases of the project as well as
future project results.

• Key
o Inputs
§ Deliverables: Deliverables will shape the learning that needs to
be captured.
o Technique
§ Information management technique: Used to create and
connect people to information, they are effective for sharing
simple , codified explicit knowledge .
§ Knowledge management technique: It connect people to work
together so that they can discover new knowledge. Share tacit
knowledge and integrate the knowledge of various team
members.
o Output
§ Lessons learned register (created in this process)
• Knowledge management
o Explicit knowledge: Fact based. Easily communicated.
o Tacit knowledge: Involves ability, experience. More difficult to
communicate.
• Can be shared through team training, shadowing, seminars, workshops.
• Also referred to as “lessons learned”. What was done right. What was done
wrong. What would be done differently if the project could be redone.
• Knowledge management is about making sure the skills, experience, and
expertise of the project team and other stakeholders are used before, during,
and after the project. Because knowledge resides in the minds of people and
people cannot be forced to share what they know, the most important part of
knowledge management is creating an atmosphere of trust.
• Lessons Learned Register is one of the outputs as well as project
management plan updates and OPA updates.
Manage Quality (Quality Management)

This project quality management process includes the activities of turning the
quality management plan into actionable tasks and activities to integrate the
quality policies of the company into the project.

• Key
o Technique
§ Affinity diagram
§ Interrelationship diagrams: maps relationship between
different issues.
§ Matrix diagram
§ Prioritization diagrams: Useful for decision analysis about
process improvement and quality management plan
components that may need to change, you prioritize both
issues and solutions.
§ Quality audit
§ Process analysis
o Output
§ Quality reports: Contain information about the quality
management issues that have been escalated by the team and
any corrective actions that have been recommended and/or
implemented.
§ Test and evaluation documents: These describe quality
activity. Used to evaluate the achievement of quality objectives
and typically include checklists and other documents such as
requirements traceability matrix. Input to Control Quality.
• Manage quality is performed while the project is being done.
• Different than Control Quality.
• The idea is to inspect work as it is being done, not after
• Manage Quality is sometimes called quality assurance.
• Common for problems to be uncovered in this process.
• The focus of Manage Quality is on the processes used in the project. About
using project processes effectively.
• Manage quality is considered the work of everybody—the project manager,
the project team, the project sponsor, the management of the performing
organization, and even the customer.
• A group outside the project team, such as a quality department often handles
this work.
• The efforts of this process focus on making certain that the project work, the
processes followed, and the deliverables that are produced conform to the
quality management plan.
• Processes to ensure quality standards will be met are reviewed to make sure
they are effective and are being followed correctly.
• Quality audits, failure analysis, and design experiments may be done to see if
the quality management plan with the standards, metrics, processes, and
procedures may need to change.
• Quality audits are a necessary part of the Manage Quality process. They help
you assess whether the processes are being followed correctly on the project.
• Test and evaluation documents, for use in Control Quality, are prepared as
part of Manage Quality.
• This process answers the following questions
o Are the quality requirements, organizational policies, and processes
identified in the quality management plan giving us the results we
intended?
o Based on what we know now, is the work we planned the right quality
work for this project and the right work to meet customer
requirements?
o Are we following the procedures and processes as planned?
o Are they giving us the intended results?
o Can the processes and procedures be improved?
o How can we increase efficiency and prevent problems?
o Will we meet the quality objectives?
• Process includes
o Use measurements from Control Quality to confirm that
§ Policies and processes are being followed
§ Policies, metrics, and processes are still appropriate for the
project
§ Policies and processes are effective in achieving planned
quality results.
o Use data-representation techniques to analyze results of quality
testing
o Determine the root cause of quality problems/variances from plan
o Perform continuous improvement to increase efficiency and
effectiveness
o Create test and evaluation documents for use in Control Quality
o Determine if project activities comply with organizational and project
policies, processes and procedures—perform a quality audit.
o Solve problems
o Produce reports
o Share good practices with others in the organization
o Submit change requests
o Update the project management plan and project documents.
• The work performed in Manage Quality will uncover any processes that may
be resulting in a level of quality that is not acceptable to the quality
management plan.
• Process Analysis: part of continuous improvement effort focuses on
identifying improvements that might be needed in project processes.
• Tools
 o Checklists: In this process, a checklist can be used to confirm that the
steps of a process have all been completed. May also be used to
analyze defects discovered in quality inspections, looking for issues
within the process, and to assess whether a deliverable meets the
acceptance criteria.
o Cause-and-Effect (Fishbone, Ishikawa, or Why-Why): Can be used to
confirm that policies and procedures are being followed and that
metrics are being used correctly, and that they were adequate to
produce the required level of quality in project deliverables.
o Histograms: In this process, histograms are used to analyze the type
and frequency of defects in order to identify where the quality plan
and processes may need improvement as the project moves forward.
o Scatter Diagrams: Tracks two variables to determine their
relationship to the quality of the results.
o Alternative Analysis: Consider all the ways to solve an issue or
problem.
§ Design of experiments: Experimentation is performed to
determine statistically what variables will improve quality. Ex:
DOE can be used to look for ways to deliver the same level of
quality for less cost. Fast and accurate technique. Ex: designers
might use DOE to see which combinations of materials,
structure, and construction will produce the highest quality
product.
o Flowcharts: In this process may be used to study the steps of a
process leading up to a quality defect.
o Affinity Diagrams: In this process can help you organize and group the
results of root cause analysis.
o Audits
o Design for X: Not everything can be a top priority. Need to decide
which is most important.
§ DfC: Design for Cost
§ DfA: Design for Assembly
§ DfM: Design for Manufacturing
• Outputs
o Test and evaluation documents (later used in Control Quality)
o Quality Reports
o Change requests and project management plan updates
o Project document updates.
Acquire Resources (Resource Management)

• Output
o Physical resources
o Project team assignments
§ Includes the number and experience level of individuals who
have been committed to the project.
o Resource calendars
§ Identifies when and how long a resource is available for your
project. Useful for shared resources (human and physical).
Identifies the working days, shifts, start and end of normal
business hours when each specific resource is available. Could
be at the project or activity level.
• The key process that carries out the Resource Management Plan.
• This process involves following the resource management plan to secure the
human and physical resources needed for the project.
• Carried out throughout the project
• To understand why it’s in the executing process group, think of a large
project that lasts several years and requires hundreds of people and lots of
physical resources. A planning team is acquired early in the planning to help
the project manager. However many of the people and other resources
needed to do the work may not be needed until long after planning starts.
The final list of resources might include contractors, sellers, and people who
will work on the project years into the future.
• Might help to read the process name as “Acquire Final Resources”.
• Acquiring project resources includes
o Knowing which resources are pre-assigned to the project and
confirming their availability.
o Negotiating for the best possible resources
o Hiring new employees
o Hiring resources through the contracting process from outside the
performing organization (outsourcing)
o Using JIT, Lean, or other methods as required by the organization
o Managing the risk of resources becoming unavailable.
• Types of teams
o Dedicated
o Part-time
o Partnership: when several organizations undertake a project
o Virtual
• How a project manager can obtain resources
o Pre-assignment: sometimes resources are assigned before the project
begins. Pre-assigned resources would be documented in the project
charter
o Negotiation: Could be from within your organization and through
procurement situations.
o Virtual teams
o Multi-criteria decision analysis: When acquiring resources, the project
manager may establish a set of criteria to help choose potential team
members or physical resources. Factors that address the needs of the
project, such as availability, cost, experience, location, and/or
required skill set, are weighted by importance, and potential
resources are evaluated based on the selected criteria.
o Outputs
§ Physical resource assignments
§ Project team assignments
§ Resource calendars
Develop Team (Resource Management)

Develop Team process refers to the efforts of the project management team in
improving team resources skills, abilities, and teamwork.

• Output
o Team performance assessments: Evaluate the team’s effectiveness so
that actions can be taken to address any issues that may be affecting
the team’s efficacy. The project manager may decide that more team
building is required as a result of the assessment of the team.
• Ongoing process throughout project work.
• Most important process in Resource Management that focuses on building a
sense of team and improving its performance.
• Performed at the same time as the Manage Team process.
• Make sure the team is motivated and well managed.
• Accomplished through efforts to create an environment conducive to
building trust and cooperation, and providing training and support to the
team.
• Motivation theories: Understand what motivates people and reward them
accordingly.
o McGregor’s Theory of X and Y
§ X: People need to be watched every minute. Employees are
incapable, avoid responsibility, and avoid work whenever
possible
§ Y: People are willing to work without supervision, and want to
achieve.
o Maslow’s Hierarchy of Needs: People are not most motivated to work
by security or money. Instead, the highest motivation for most people
is to contribute and to use their skills (self-actualization). A person
cannot ascend to the next level until the levels below are fulfilled
(Physiological, Safety, Social, Esteem, Self-actualization).
o McClelland’s Theory of Needs (Acquired Needs Theory): People are
most motivated by one of three needs, and they need to be managed
differently in each category
§ Achievement: Give them projects that are challenging but
reachable
§ Affiliation: Work best when cooperating with others. They seek
approval rather than recognition
§ Power: Effective leaders and should be allowed to manage
others. They like to organize and influence others.
o Herzberg’s Two-Factory Theory of Motivation
§ Hygiene factors: Working conditions, Salary, Personal life,
Relationships at work, Security, Status
§ Motivating agents: Responsibility, Self-actualization,
Professional growth, Recognition
 o Contingency Theory: The leader’s effectiveness is contingent upon
two sets of factors. The first measures whether the leader is task
orientated or relationship oriented. The second set evaluates
situational factors in the workplace such as how stressful the
environment is.
o Team building
o Training
o Project performance appraisals: Performed as part of Manage Team
process. The rewards or additional training as a result of the appraisal
would be given as part of Develop Team.
o Recognition and rewards: Performance is appraised and rewards and
recognition is provided.
• Outputs
o Results of team performance assessments (input into the Manage
Team process)
Manage Team (Resource Management)

Manage Team process involves tracking team performance, interacting and

facilitating the resolution of the issues. Also, this process aims to realign the
project team performance to the desired level.

• Output
o Project team assignments
• Performed simultaneously with Develop Team process.
• Involves all the day-to-day management activities
• This process also deals with managing conflicts
• Project manager should perform the following activities to help challenge
team members to be part of a high performing team
o Tracking and evaluating team performance
o Providing leadership
o Dealing with team issues
o Facilitating conflict resolution
o Negotiating and influencing
o Adjusting plans based on performance data
o Managing risks to team success
o Observing what is happening
o Using an issue log to track resolution
o Actively looking for and helping to resolve conflicts that team
members cannot resolve on their own.
• Primary leadership styles
o Directing: The project manager uses their expertise to guide team
members in what to do.
o Facilitating: The project manager enables communication and helps
remove roadblocks
o Coaching: The project manager advises and makes recommendations,
helping the team and other stakeholders achieve their goals.
o Supporting: The project manager encourages and provides assistance
to team members and stakeholders in working through the situations
they encounter.
o Influencing: The project manager emphasizes teamwork, team
building, and team decision-making and works with their team to
influence collaborative, successful project implementation.
o Delegating: The project manager establishes goals and then gives the
project team sufficient authority to complete the work.
• Leaderships styles effective for resolving conflict
o Consultative: Bottom up. Uses influence to achieve results. The project
manager considers others’ opinions and acts as the servant-leader for
the team
o Consensus: The project manager encourages problem-solving in a
group and makes decisions based on group agreement
 o Democratic or participative: This style involves encouraging team
participation in the decision making process.
o Bureaucratic: Focuses on following procedures exactly. Appropriate
when specific safety or other regulations must be strictly adhered to.
o Analytical: Analytical managers often make the technical decisions for
the project and then communicate those decisions to their teams.
• Leadership styles that can lead to problems
o Charismatic: Charismatic managers energize and encourage their
teams into performing project work. Project success may become
dependent on the presence of the charismatic leader.
o Autocratic: Top down approach. The manager may coach or delegate,
but everyone does what the manager tells them to do.
o Consultative-autocratic: The project manager solicits input from the
team members, but retains decision-making authority
o Laissez-faire: The project manager is not directly involved in the work
of the team.
o Driver: Constantly giving directions.
• Project management powers: or, how to get cooperation from the team and
stakeholders
o Formal (legitimate): Based on your position. “I understand you
disagree, however, after careful evaluation, I believe my decision is in
the best interest of the team, and this is what we are going to do”
o Reward: Ability to give rewards. “I understand that you want to
participate in the acceptance testing of this project. Because of your
performance, I will assign you as part of that team”. Best form of
power.
o Penalty (coercive): This power comes from the ability to penalize
team members. “If this does not get done on time, I will remove you
from the group traveling to the customer meeting”.
o Expert: This power comes from being the technical or project
management expert. “This project manager has been successful on
other projects. Let’s give her a chance!”. Best form of power.
o Referent: This power comes from another person liking you,
respecting you, or wanting to be like you. You buy something
endorsed by a celebrity.
• Conflict
o Is an inevitable consequence of organizational interactions
o Can be beneficial
o Is resolved through openness, identifying the causes, and problem-
solving by the people involved and their immediate managers.
• Seven sources of conflict in order of frequency
o Schedules (unrealistic, resources no available)
o Project priorities
o Resources
o Technical opinions
 o Administrative procedures
o Cost
o Personality
• When you have questions on the exam relating to conflict management, make
sure you first think, “Who has authority over the situation described in this
question?” or, “What resolution of this problem would best serve the
customer’s interests?”. Also ask yourself, “What is the urgency with which I
need to solve the conflict?”. Would it be best to let everyone cool down before
intervening? Or is this something that must be resolved immediately? What
would happen if you didn’t get involved? What will be the long-term
repercussions if you involve yourself in the conflict?
• Conflict resolutions techniques
o Collaborating (problem-solving): The parties openly discuss
differences and try to incorporate multiple viewpoints to arrive at a
consensus. Collaboration leads to a win-win situation. Most effective
way to resolve conflict.
o Compromising (reconciling): Involves finding solutions that bring
some degree of satisfaction to both parties. This is a lose-lose
situation since no party gets everything. Second best choice to
collaborating. You should always try to solve the problem first—you
should forge a compromise only after you’ve tried every other way to
solve the real problem.
o Withdrawal (avoidance): The parties retreat or postpone a decision
on a problem. Dealing with problems is important, so this is not
usually the best choice to resolve conflict though there may be
situations where it is necessary. People get so frustrated, angry or
disgusted that they just walk away from the argument. “You guys are
being totally unreasonable, and we’re just not going to talk about it
anymore”.
o Smoothing (accommodating): Includes making some concessions and
it emphasizes agreement rather than differences of opinion. It does
not result in a permanent or complete resolution of the conflict. You
play down the problem and make it seem like it’s not so bad.
Temporary, but sometimes necessary to keep tempers from flaring
and give people some space to step back and really figure out what’s
going on. “C’mon guys , I know this seems like the end of the world,
but it’s really not such a big deal”
o Forcing (directing): Involves pushing one viewpoint at the expense of
another. It is a win-lose situation. Putting your foot down and making
a decision. “I’m in charge here and I’ve made my decision…and you’re
just going to have to live with it”.
• Other terms
o Expectancy theory: Employees who believe their efforts will lead to
effective performance and who expect to be rewarded for their
 accomplishments will remain productive as rewards meet their
expectations.
o Arbitration: Neutral party hears and resolves disputes
o Perquistes (perks): Some employees receive special rewards such as
assigned parking spaces, corner office, etc.
o Fringe benefits: Standard benefits formally given to all employees.
Manage Communications (Communications Management)

Includes the activities of ensuring that project information is properly

collected, distributed and recorded.

• Key
o Tool
§ Performance reporting
o Output
§ Project communications
• This process goes beyond the distribution of relevant information and seeks
to ensure that the information being communicated to project stakeholders
has been appropriately generated and formatted, and received by the
intended audience. It also provides opportunities for stakeholders to make
requests for further information, clarification, and discussion.
• Here we execute the communications management plan. Here is where the
bulk of project communications take place.
• This process may start quite early, but it typically elevates in importance and
activity during the construction (executing) phases of the project.
• Here, Work Performance Information turns into Work Performance Reports.
The reports are circulated to the project stakeholders through this process as
defined in the communications management plan.
o Status reports
o Progress reports
• Types of reports
o Status report: where the project currently stands
o Progress report: what has been accomplished
o Trend report: examines project results over time to see if
performance is improving or deteriorating
o Forecasting report: predicts future project status and performance
o Variance report: compares actual results to baselines
o Earned value report: integrates scope, cost, and schedule
measurements to assess project performance
o Lessons learned documentation: reports on performance are used as
lessons learned for future projects.
Implement Risk Responses (Risk Management)

Refers to the efforts of executing the planned risk responses.

• Output
o Risk register
o Risk reports
• Throughout the project, the risk register and risk report are reviewed
regularly, ensuring everyone is aware of potential risks and ready to
implement the planned responses as needed. Information on triggers enables
the project manager, risk owner, and the team to recognize indications that a
risk even is imminent. At that point, the risk owner, supported by the project
manager leads previously assigned resources in performing risk activities.
• When risk responses don’t go as planned, the unforeseen results are
managed through change requests to the cost and schedule management
plans.
• Output: The key output is Change Requests since it is the main point of this
process. After risks have been identified, analyzed and the responses
planned, the change requests are the primary way those responses are
implemented.
• If asked what to do if a planned risk is realized, then implement the risk
response before you submit a change request. The information from the risk
register should be reviewed first followed by the implementation of the
agreed-upon response plan. The response plan may include the submission
of a change request as an element.
Conduct Procurements (Procurement Management)

• Output
o Selected sellers
o Agreements
• Involves getting the bid documents, including the SOW and other documents
created in the Plan Procurement Management process to prospective sellers,
answering the sellers’ questions, and receiving and evaluating sellers’
responses. You will select a seller using the source selection criteria specified
in the procurement management plan, and then negotiate a contract.
• Obtain sellers responses, select seller, award contract.
• Buyers use advertising or bidder conferences (a/k/a “pre-bid conferences”)
to attract sellers. Project manager should attend the bidder conference.
• Proposal (Price Quote or Bid): Sellers response to the bid documents.
o Proposal: Response to RFP
o Quote: Response to RFQ
o Bid: Response to IFB
• Potential seller’s response to an RFI may trigger the buyer’s creation of an
RFP or RFQ.
• Proposal evaluation: Use the source selection criteria identified in the Plan
Procurement Management process.
• Weighting system: Used to evaluate proposals
o Which is more important? Price? Competence? Availability? Selection
criteria are assigned values based on their relative importance. Each
criteria is given a weight (percentage) and then a rating from 1-100
and then scored by multiplying the weight and the rating.
• Independent Cost Estimates are done here to compare the seller’s proposed
cost with an estimate created in-house or with outside assistance during
procurement planning efforts.
• Negotiations: project manager should be involved, though usually lead by the
procurement manager. Main items to address would be scope, schedule,
price. Other items include risk, responsibilities, authority, payment schedule,
quality, etc.
• Outputs:
o Selected Sellers
o Agreement (contract). Changes to contract must be made formally in
writing and submitted to integrated change control. The contract
includes the SOW.
o Change requests: Sometimes during project executing, problems that
arise related to the procurement process (ex: seller not performing)
or to other areas of he project (such as risk, quality, schedule, or scope
management) require re-evaluation of the procurement management
plan and make-or-buy decisions. So it may be necessary to revisit the
work previously done in the Plan Procurement Management which
can lead to a decision to contract for resources or goods and make
other changes to the project management plan or other aspects of the
project.
Manage Stakeholder Engagement (Stakeholder Management)

The process of engaging stakeholders and managing their expectations,

interests, and potential impact on the project.

• Output
o Stakeholder register
• This process revolves around using change and the issue logs to help ensure
that the right stakeholders are involved at the right level and in the right
way.
• Stakeholder satisfaction may be the single most significant ingredient in
project success.
• The process Manage Communications is the process by which Manage
Stakeholder Engagement is carried out.
• Outputs
o Change requests
o Project Management Plan updates
o Project document updates (issue log)
Monitoring & Controlling

• Monitoring requires the project manager to focus their attention on how the
project is progressing.
• The function of each process in this process group is to control changes.
• Controlling requires evaluating hard data on how the project is conforming
to the plan and taking action to address variances that are outside of
acceptable limits—by recommending changes to the way the work is being
done, or possibly adjusting baselines to reflect more achievable outcomes.
• Controlling scope, schedule, and cost means controlling scope, schedule, and
cost to their baselines.
• Controlling means Measuring. You measure against the plan. You need to stay
in control of your project and know how it is performing compared to the
plan.
• Monitoring and Controlling efforts go beyond measuring; they also involve
taking corrective and preventive action over and over again during the life of
the project to keep the project in line with the plan.
• The focus of monitoring and controlling is ensuring the project is progressing
according to plan, and approving necessary changes to the plan to meet the
organization’s strategic objectives and deliver the expected benefits.
• When a project has been planned appropriately, most control efforts result in
information that process work is being done according to the plan and that
scope is being produced to the agreed-upon standards and metrics.
• Work Performance Data is analyzed to make sure it conforms to the Project
Management Plan. It then turns into Work Performance Information and/or
reports.
• While the work is being done in Executing, the work results (or work
performance data) are fed into this process to make sure the project is
progressing according to the baseline established in the project management
plan.
• If variances from the plan require changes, the change requests are evaluated
in the Perform Integrated Change Control process. For approved changes
that require adjustments to the baselines and Project Management Plan, a re-
planning effort (within the Perform Integrated Change Control process) must
be completed before the team can start working from the updated version of
the plan and baselines in executing. The revised plan is provided to the team
in the Executing process and the project is executed according to the updated
plan and monitored and controlled to the updated baselines.
• All of the work of the project and project management must be monitored
and controlled. Throughout the life of the project, you’ll be monitoring and
measuring the outcomes of the project and any project management efforts
and analyzing them to help identify variances from the plan.
• The project management plan and project documents updates are outputs of
every monitoring and controlling process.
 •

Monitor and Control Project Work (Integration Management)

Monitor and Control Project Work process refers to the activities of assessing,
reviewing and documenting project work. Its main objective is to provide a clear
status of the project work, identify performance issues and improvement areas.
Also, the main deliverable of this process is work performance reports.

• Output
o Work performance reports
• What has been done on the project vs. what has been planned
• Controlling processes compare some plan with the results to see where they
differ and take action if it is required.
• Takes a look at all of the work that is being performed and makes sure the
deliverables and the way in which they are being produced are in line with
the project plan and meet the objectives.
• Tracking, reviewing, and reporting the overall progress to meet the
performance objectives defined in the project management plan.
• Key benefits of this process are that it allows stakeholders to understand the
current state of the project, to recognize the actions taken to address any
performance issues, and to have visibility into the future project status with
cost and schedule forecasts.
• Significant amount of time measuring performance and implementing
corrective actions.
• Work Performance data is gathered through work execution and passed to
the controlling processes. To become work performance information, the
work performance data are compared with the project management plan
components, project documents and other project variables. This comparison
indicates how the project is performing.
• Work Performance Information is aggregated from monitoring and
controlling knowledge area processes to evaluate and assess how their
individual process results are impacting the other knowledge areas and their
plans and baselines. For example, scope may be completed on a project but
the quality may not be acceptable.
• Encourages a holistic view of the project performance and enables the
project management to take appropriate action to keep the project on track.
• Change requests can result from this process (corrective action, preventive
action, defect repair).
• Corrective actions are undertaken to adjust performance within the existing
project baselines; the actions do not change the baselines.
• Preventive action is dealing with anticipated or possible deviations from the
performance measurement baseline and other metrics. Typically such
changes do not change the baseline.
• Defect repair Is another way of saying “rework”.
• For changes that would affect the project management plan, baselines,
policies, or procedures, charter, contracts or statements of work, would need
the approval of the change control board or sponsor as outlined in the
change management plan.
• Work Performance Reports is one of the outputs. Ex: dashboards, heat
reports, burn-down charts, etc. The reports should be actionable.
Perform Integrated Change Control (Integration Management)

This process is concerned with managing change requests effectively

throughout the project lifecycle. Also, Perform Integrated Change Control process
takes care of change requests documentation. Besides that, the process focuses on
assessing its impact on different project aspects including scope, cost, time and
other project variables. As a result of performing this process in the right manner,
project results improve dramatically.

• Output
o Approved change requests
o Change log
• Main input is a Change Request. This could be for three categories:
o Corrective action
o Preventive action
o Defect repair
• Approved changes are implemented in Direct and Manage Project Work,
Control Quality, and Control Procurements.
• Change requests can be made by any stakeholder in the project during any
point in the project.
• Requested changes to areas that have not yet been finalized do not need to go
through Integrated Change Control.
• Whenever a change is proposed that affects one of the project constraints,
the first thing to do would be to evaluate the change for impacts on all other
constraints.
• Whenever a change is proposed from a high level, here are the next steps the
project manager should take
o Evaluate the impact
o Identify options (crashing, fast-tracking, re-estimating, etc)
o Get the change request approved internally
o Get customer buy-in (if required) via the communications
management plan
• The detailed process for making changes
o Prevent the root cause of changes
o Identify the need for change. PM should be actively looking for
changes since changes identified earlier are easier to deal with.
o Evaluate the impact for change within the knowledge area. If it is a
scope change, how will it affect the rest of the scope of the project? If
it is a schedule change, how will it affect the rest of the schedule for
the project?
o Create a change request (recorded in the change log)
o Perform integrated change control. How will the change affect all the
other project constraints?
§ Assess the change. Any change for which a reserve has been
created (a previously identified risk event) would be
 accounted for in the project management plan as part of risk
management efforts and should be handled as part of the
Implement Risk Responses process rather than Perform
Integrated Change Control).
§ Identify options: Actions to decrease threats or increase
opportunities include compressing the schedule through
crashing or fast tracking, changing how the work is performed,
adjusting quality, or cutting scope so that the effect of the
change will be minimized.
§ The change is approved, rejected, or deferred
§ Update the status of the change in the change log
§ Adjust the project management plan, project documents, and
baselines as necessary
o Manage stakeholder’s expectations by communicating the change to
stakeholders affected by the change.
o Manage the project to the revised project management plan and
project documents.
• For questions asking what should a project manager do, the project manager
needs to analyze first, create options to deal with the change, and then let
management, the sponsor, the customer or other parties know the impacts of
their request.
• From PM PrepCast: One may argue that evaluating the change should come
before submitting the change request. We had an extensive debate on the
subject of change requests in general and on this question in particular. The
reason being is that the PMBOK Guide does not do a good job in explaining
the exact process in detail. We have discussed this process among our team
of certified project management professionals and have concluded that the
first thing that should be done when a change is requested on a project is the
physical creation of the change request. Otherwise, on what basis would a
project manager and the project team spend time evaluating a request that is
not even documented?
• Approved change requests can require new or revised cost estimates, activity
sequences, schedule dates, resource requirements, and/or analysis of risk
response alternatives.
• Schedule compression may be used during Perform Integrated Change
Control and Control Schedule to evaluate options to manage the impacts of
changes. The objective of this technique is to manage the schedule without
changing the schedule baseline. This isn’t always possible, but we try.
• Change requests that have an impact on the project baselines should
normally include information about the cost of implementing the change,
modifications in the scheduled dates, resource requirements, and risks.
• Output: Approved or Rejected change request
o Approved change requests are channeled back to Direct and Manage
Project Work.
Validate Scope (Scope Management)

Validate Scope process aims to confirm and formalize accepting project outputs
and deliverables. As a result of this, the probability of customer accepting final
product increases. In addition, it helps the project manager in detecting variance
between requirements and expectations and actual work early.

• Inputs
o Verified deliverables: Verified deliverables flow out of the Control
Quality process and into this one. Validate Scope is all about
comparing the deliverables with the documented scope to ensure that
everything was completed.
o Work Performance Data: Important because it tells us how the
deliverables were created which needs to be considered along with
the product itself. Ex: Did the team produce a working deliverable, but
at the expense of working 70 hour weeks?
• Outputs
o Accepted deliverables
o Work performance info
• Generally performed by the project manager, the sponsor, the customer, and
the functional manager.
• Helps to think of the customer as being involved in this process.
• Involves frequent, planned meetings with the customer or sponsor to gain
formal acceptance of deliverables during project monitoring and controlling.
• Can be used during monitoring and controlling for deliverables that require
approval in the middle of the phase or project.
• The difference between Validate Scope and Control Quality:
o Control Quality is generally done first since we want to make sure the
deliverable meets the requirements before it is shown to the
customer. While they both check for the correctness of work, in
Control Quality, the quality control department checks to see if the
requirements specified for the deliverables are met and makes sure
the work is correct. In Validate Scope, the customer checks and
hopefully accepts the deliverables.
o Validate Scope is primarily concerned with completeness while
Control Quality is primarily concerned with correctness.
o Validate Scope is concerned with the acceptance of the product by the
project manager, the sponsor, the customer and others, while Control
Quality is concerned with adherence to the quality specification.
• This is the sequence after each deliverable is produced:
o After each deliverable is produced, it is first evaluated for correctness
in the Control Quality process. Once deemed correct in terms of
quality, the deliverable is considered a verified deliverable
o It then passes to the Validate Scope process as an input
 o The customer of sponsor inspects the verified deliverable, comparing
it against the acceptance criteria defined in the scope statement of the
scope baseline
o If the deliverable meets the criteria, it becomes an accepted
deliverable and formal documentation is sent to the Close Project or
Phase process.
• If the project is canceled before completion, Validate Scope should be
performed to document where the product was in relation to the scope at the
point when the project ended.
• Outputs
o Accepted Deliverables: Formal, written acceptance by the appropriate
stakeholders
o Work Performance Information: Work Performance Data flowed into
this process and the more refined Work Performance Information
flows out. The WPI tells about how something was created, including
whether it was on time, within budget, how the resources used
compared with estimates, and other metrics of interest.
Control Scope (Scope Management)

This process’ key concern is to confirm the project team is doing all scope of
work according to the planned scope. Also, Control Scope ensures proper
management of change requests related to the scope of work. Accordingly, the result
of performing this process effectively is maintaining healthy scope without any
slippage in scope or resources. This is an extremely proactive process that includes
thinking about where changes to scope are coming from and what can be done to
prevent or remove the need for any more changes from that source. Testing is an
important aspect of the Control Scope process.

• Output
o Work performance info
• Process
o Follow change management plan
o Measure scope performance against the performance measurement
baseline.
o Influence the factors that cause changes
o Control scope changes and the impact of those changes
o Analyze work performance data and variances
o Request changes
o Update the scope baseline, other parts of the project management
plan, and requirements documentation with approved changes.
o Validate changes to make sure they do not over or under correct
problems
o Document lessons learned.
• Control Scope is about maintaining control of the project by preventing scope
change requests from overwhelming the project and also about making
certain that scope change requests are properly handled. This ensures that
the scope baseline is always kept current.
• The process begins as soon as the scope baseline is created. Until that point,
the scope is not considered stable or complete enough to control.
• Inputs
o Work Performance Data: Ex: volume of change requests flowing into
the project.
• Outputs
o Work Performance Information
o Change requests: as changes are made to the scope baseline, these
must be factored into updates to the WBS. If the change represents a
new piece of scope, the work must be decomposed in the WBS down
to work package level and then brought into the other appropriate
processes.
Control Schedule (Schedule Management)

This process involves all activities the project team performs to ensure that the
project schedule is not changed improperly. Also, it involves making sure
updating the project schedule with completion of activities and reviewing change
requests impact on schedule. They key benefit of this process is that the schedule
baseline is maintained throughout the project.

• Output
o Work performance info
o Schedule forecasts
• Follow the change management plan
• Measure schedule performance against the performance measurement
baselines
• Influence the factors that cause changes
• Control schedule changes and the impacts of those changes
• Analyze work performance data and variances
• Request changes
• Update the schedule baseline, other parts of the project management plan,
and the schedule-related documentation with approved changes
• Document lessons learned
• Manage the schedule reserve
• Use earned value analysis to create schedule forecasts
• Validate change to make sure they do not over or under correct problems.
• Schedule compression may be used during Perform Integrated Change
Control and Control Schedule to evaluate options to manage the impacts of
changes. The objective of this technique is to manage the schedule without
changing the schedule baseline. This isn’t always possible, but we try.
• Schedule control means looking for things that are causing changes and
influencing the sources or root causes of change. It’s more than just issuing
updated schedules. Think of protecting the hard work of all those involved in
planning to make sure what was planned occurs as close to the plan as
possible. Think of being constantly on the lookout for anything that might be
affecting the schedule.
• This process may use Earned Value Analysis and iteration burn-down charts.
• Whenever a large number of changes occur on a project, it is wise to confirm
that the business case, as stated in the project charter, is still valid.
Control Costs (Cost Management)

This process refers to the efforts of monitoring the status of the project to
update the project costs and manage changes to the cost baseline. Also, this
process serves as a catalyst for cost and schedule performance review.

• Output
o Work performance info
o Cost forecasts
• Process
o Follow the cost management plan and the change management plan
o Measure cost performance against the performance measurement
baseline
o Influence the factors that cause changes
o Control cost changes and the impacts of those changes
o Analyze work performance data and variances
o Request changes
o Update the cost baseline, other parts of the project management plan,
and cost estimates
o Document lessons learned
o Manage the cost reserve
o Use earned value analysis to recalculate the estimate at completion
and other cost forecasts
o Obtain additional funding when needed
o Validate changes to make sure they do not over or under correct
problems.
• Use earned value analysis to assess whether the project is on track.
• You can also monitor the percent completion using the WBS for project
activities and deliverables as a way to show progress on deliverables within
the time and cost allocated to them in the plan.
• Reserve Analysis: Part of controlling costs also involves analyzing whether
the contingency reserves that got factored into the cost baseline are still
necessary or whether new reserves are required. If a risk threat is deemed
no longer a threat, the contingency reserve can be removed from the cost
baseline (and subsequently the cost budget). Or if a new risk is identified that
will require an increase to the contingency reserve would both require a
change request submitted through integrated change control.
• It might also be necessary to reassess the amount of management reserve
that was set aside to address unknown risks.
o Changes to management reserve will change the cost budget since
management reserves are not included in the cost baseline. If an
unknown risk occurs, management will pay for the workaround, but a
change request would be necessary to move management reserve
funds into the cost baseline.
• Trend Analysis: Used to alert you to problems before they occur.
• Earned Value Measurement
o Used in performance reviews to measure project performance against
the scope, schedule, and cost baselines (a/k/a “performance
measurement baseline”).
o Budget at Completion (BAC) is the same as the total Planned Value
(PV) of the project.
o It integrates cost, time, and the work done (scope).
o Please = Planned Value (PV): What SHOULD have been completed to
date: Planned % complete x BAC
o Eat = Earned Value: What you ACTUALLY completed to date: EV = %
complete x BAC. Can also be the sum of the Planned Value of the
completed work if more than one task.
o Carol’s = Cost Variance: CV = EV – AC
o Sweet = Schedule Variance: SV = EV – PV
o Cake & = Cost Performance Index: CPI = EV/AC
o S = Schedule Performance Index: SPI = EV/PV
o E = Estimate at Completion: EAC = BAC/CPI
o E = Estimate to Complete: ETC = EAC – AC
o The = To-Complete Performance Index (using BAC):
TCPI = (BAC – EV) / (BAC – AC)
o Terrific = To-Complete Performance Index (using EAC):
TCPI = (BAC – EV) / EAC – AC)
o Violinist: Variance at Completion: VAC = BAC – EAC
o For variances, negative is bad, positive is good
o For indices, less than one is bad, greater than one is good (opposite is
true of TCPI).
• On the exam, round to two decimal places.
• Types of cost
o Fixed
o Variable
o Direct: Billed directly to the project. Ex: materials used to construct a
building.
o Indirect: Costs that are shared and allocated among several or all
projects. Ex: manager’s salary since it’s overhead while the team
might be direct costs
o Sunk: Costs that have been invested into or expended upon the
project. Spilt milk. Treated as if they are irrelevant.
o Opportunity: Cost of the loss of potential benefit from the alternatives.
Most often associated with project selection.
Control Quality (Quality Management)

Monitoring the executed quality management activities to assess

performance and ensure the project outputs are complete, correct, and meet
customer expectations. Also, it involves recording the results of quality management
activities execution.

• Output
o Quality control measurements
o Verified deliverables
§ Work performance info
• This process is all about inspection.
• Hold periodic inspections
• If you are inspecting the product or looking at some kind of result, you are in
this process.
• Inputs
o Approved change requests: These flow into this process from Perform
Integrated Change Control.
o Deliverables: Compared against the quality management plan to see
how they line up.
• Involves both product and project deliverables.
• Ensure deliverables are meeting the standards
• Influence the factors that cause changes
• Request changes or improvements to work and processes
• Make decisions to accept or reject work
• Assess the effectiveness of project quality control systems
• Analyze work performance data and variances
• Update the quality management plan, as well as quality- and process-related
documentation
• Validate changes to make sure they do not over or under correct problems
• Document lessons learned.
• This is the sequence after each deliverable is produced:
o After each deliverable is produced, it is first evaluated for correctness
in the Control Quality process. Once deemed correct in terms of
quality, the deliverable is considered a verified deliverable
o It then passes to the Validate Scope process as an input
o The customer or sponsor inspects the verified deliverable, comparing
it against the acceptance criteria defined in the scope statement of the
scope baseline
o If the deliverable meets the criteria, it becomes an accepted
deliverable and formal documentation is sent to the Close Project or
Phase process.
o If the deliverable fails in Control Quality, a change request is
generated and the deliverable goes to Perform Integrated Change
Control.
• Closely related to Manage Quality with a different focus. Control addresses
the quality of product and focuses on getting a deliverable ready to move to
the Validate Scope process. Defects are detected and corrected. Manage
Quality addresses the effectiveness of quality management plans, processes,
and procedures, and whether the project is on track to meet quality
objectives. Quality defects are assumed to indicate issues with those plans,
processes, and procedures.
• Helps answer these questions
o Are the results of our work meeting the agreed-upon standards and
thereby meeting project requirements?
o What is the actual variance from the standards?
o Is the variance from standards or processes outside of acceptable
limits?
o Are people using the checklists to support meeting the metrics
established or the process?
o What changes in the project should be considered?
o Is it ready to move to the Validate Scope process?
• Process includes
o Inspect and measure the quality of deliverables to determine whether
they meet requirements
o Use the PMIS to track deviations from planned quality
o Identify the need for quality improvements (corrective or preventive
action, and defect repair)
o Complete checklists and check-sheets, perform tests, and evaluate
results
o Graphically document results of testing and evaluation using data
representation techniques
o Verify deliverables
o Validate approved changes
o Recommend improvements to testing processes.
o Use and update lessons learned
o Submit change requests
o Update the project management plan and project documents
• Important terms
o Mutual exclusivity: two events are mutually exclusive if they cannot
both occur in a single trial.
o Probability
o Normal distribution: The most common probability density
distribution chart. Bell curve. Used to measure variations
o Statistical independence: the probability of one event occurring does
not affect the probability of another event occurring. Ex: the probably
of rolling a size on a die is statistically independent from the
probability of getting a five on the next roll.
o Standard deviation (or Sigma): How far you are from the mean.
• Tools
o Quality Management System: The organizational framework whose
structure provides the policies, processes, procedures, and resources
required to implement the quality management plan. The system may
include, for example, guidelines on how and where the quality control
measurements captured during the Control Quality process should be
stored and processed.
o Control Charts: Used in this process to help determine if the results of
a process are within acceptable limits. During the Control Quality
process, samples are taken and plotted on the chart. The control chart
shows whether the samples are within acceptable limits. If the data
does not fall within acceptable range, the results are considered to be
“out of control” which indicates a problem that needs to be handled.
§ Upper and lower control limits. Often shown as two dashed
lines on a control chart, these limits are the acceptable range of
variation of a process or measurement’s results.
§ Mean (average): Indicated by a line in the middle of the control
chart.
§ Specification limits: The control limits indicate the performing
organization’s standards for quality, but while the specification
limits represent the customer’s expectations or the contractual
requirements for performance and quality.
§ Out of control
• A data point falls outside the upper or lower control
limit
• There are non-random data points; these may be within
the upper and lower control limits, such as the rule of
seven.
• Rule of Seven: A general rule (heuristic). A group or
series of non-random data points that total seven on
one side of the mean. This rule tells you that, although
none of these points are outside of the control limits,
they are not random and the process is out of control.
• Assignable Cause/Special Cause Variation: signifies that
a process is out of control.
o Cause and Effect (Fishbone, Ishikawa, Why-Why) Diagrams: You need
to both fix a defect and get to the root cause of the defect.
o Histograms: Shows data in the form of bars/columns. The results of
measurements taken during Control Quality.
o Pareto Charts: A type of histogram that arranges results from most
frequent to least frequent to help identify which root causes are
resulting in the most problems. 80/20 rule: states that 80% of
problems are due to 20% of the root causes.
o Scatter Diagrams: Used to determine the relationship between
variables and the quality of the results.
o Testing/Product Evaluations
 § Stress testing
§ Unit testing
§ Usability testing
§ Regression testing
§ Integration testing
• Outputs of Control Quality
o Measurements
o Validated changes
o Work performance information
o Updates to the project management plan
o Change requests, including the recommended corrective and
preventive actions and defect repair
o Verified deliverables
Control Resources (Resource Management)

Control Resources aims to ensure the availability of physical resources and

ensure they are allocated to the project as planned. At the same time comparing
planned resource use to actual resource use and take proper actions to fix
misalignment.

• Output
o Work performance info
o Physical resource assignments
o Resource Breakdown Structure
• Process includes
o Confirm the type and quantity of resources used are consistent with
what was planned
o Evaluate the effectiveness of the physical resources.
o Analyze work performance data and variances
o Request changes
o Validate change to make sure they do not over or under correct
problems
o Update the resource management plan as well as resource-related
documentation.
o Document lessons learned.
• The project manager also monitors the amount, costs, and quality of
resources being used and compares that to what was planned.
• Problem-solving method
o Define the real or root problem, not what is presented to you or what
appears to be the problem.
o Analyze the problem
o Identify solutions
o Pick a solution
o Implement a solution
o Review the solution and confirm that the solution solved the problem.
Monitor Communications (Communication Management)

Ensures meeting the project and stakeholders’ information needs.

• Output
o Work performance info
o Project communications document
• Process
o Ensure information is being communicated to the appropriate people
in the right way and at the right time
o Analyze work performance data and variances
o Request changes
o Analyze information about communications to make sure they are
meeting stakeholder needs
o Validate change to make sure they do not over or under correct
problems
o Document lessons learned.
• This process involves measuring to determine whether the communications
management plan is being followed and whether communications are
meeting the needs of the stakeholders.
• Determines if the planned communications artifacts and activities have had
the desired effect of increasing or maintaining stakeholders support for the
project’s deliverables and expected outcomes.
• Results in work performance information
Monitor Risks

Refers to the efforts of tracking risks, planned risk responses, reviewing the
actual state and evaluate the effectiveness of risk management as well as
identifying and assessing new risks.

• Output
o Work performance info
o Risk register
o Risk report
• Process
o Reassess risks, planned risk responses, and risk reserves
o Identify new risks
o Watch for the occurrence of risk triggers
o Create and implement workarounds
o Perform risk audits to evaluate the effectiveness of risk management
processes. Analyze work performance data, work performance
reports, and variances.
• Actions involved in monitoring risks
o Look for the occurrence of risk triggers
o Monitor residual risks
o Identify new risks and then analyze and plan for them.
o Evaluate the effectiveness of the risk management plan. Is it working?
Does it need adjustment?
o Develop new risk responses. If a plan no longer seems like it will
work, based on experience or new information, an alternate risk
response or responses may be more appropriate. These review and
analysis may lead to change requests.
o Collect and communicate risk status.
o Communicate with stakeholders about risks. Ex: “Remember that one
of the major risks on the project could occur next week”
o Determine if assumptions are still valid.
o Ensure proper risk management procedures are being followed.
o Revisit the watch list to see if additional risk responses need to be
determined.
o Recommend corrective actions to adjust to the severity of actual risk
events. Ex: “This risk did no have the impact we expected, so let’s
adjust the contingency plan…”
o Look for any unexpected effects or consequences of risk events. Ex:
“We did not expect this risk to damage the construction site”
o Reevaluate risk identification and qualitative and quantitative risk
analysis when the project deviates from the baseline. Ex: “This project
cost is over the cost baseline (or over the schedule baseline). This
implies we missed some major risks. Let’s hold another risk
identification session”.
 o Update risk management and response plans.
o Look at the changes, including recommended corrective actions, to
see if they lead to identifying more risks. Ex: “We keep having to take
corrective action related to this problem. Let’s look for the root cause
and identify any risks to the remainder of the project that relate to
this problem”.
o Submit change requests to integrated change control.
o Update the project management plan and project documents with
approved changes and any relevant information from the analysis of
work performance data.
o Create a database of risk data and lessons learned that may be used
throughout the organization on other projects.
o Perform variance and trend analysis on project performance data.
o Use contingency reserves and adjust for approved changes.
o Update the risk register and risk report with current risk exposure.
o Reevaluate assumptions and constraints, capture new issues, and
update existing ones.
o Close out risks.
• Workarounds: If the project has deviated from the baselines, the team may
take corrective action to bring it back in line. Such corrective action may
include workarounds. Whereas contingency responses are developed in
advance, workarounds are unplanned responses developed to deal with the
occurrences of unanticipated events or problems. If you spend a lot of your
time implementing workarounds, it probably means you didn’t perform
proper risk management.
• Risk Reassessments: The team needs to periodically review the risk
management plan and risk register and adjust the documentation as
required. It is important to determine whether any changes or adjustments
need to be made to what was planned based on information that become
apparent once work begins.
• Reserve Analysis: While the work is being done, reserve analysis is simply a
matter of checking to see how much reserve remains and how much might be
needed. Reserves must be protected throughout the project life cycle.
o A contingency reserve may only be used to handle the impact of the
specific risk it was set aside for. So, to change a project in response to
problems that have occurred, if the problem is not due to that specific
risk, the project manager must take preventive or corrective action,
fast track, crash, or otherwise adjust the project to accommodate or
make up for the impact of the problem and its resulting changes.
o Under certain circumstances, usually determined by the performing
organization, management reserves may be used for situations that
are within the scope of the project but were not previously identified.
o If identified risks do not occur, the associated time or cost reserves
should be returned to the company rather than used to address other
 issues on the project. Reserves are not a free amount of time or cost
that can be used at will by the project manager for any needs!
• Technical Performance Analysis: Uses project data to compare planned
versus actual completion of technical requirements to determine if there is
any variance from what was planned. Any variance could indicate a possible
risk.
• Meetings: Not status meetings. Instead “team meetings” where the project
manager can perform risk reviews and risk audits
o Risk reviews: Held regularly to discuss the effectiveness of planned
risk responses that have been implemented on the project, and may
result in the identification of new risks, secondary risks, and risks that
are no longer applicable. Closing of risks allows the team to focus on
managing the risks that are still open
o Risk audits: Can be performed during team meetings to assess the
overall process of risk management on the project.
• Inputs
o Work Performance Data: Used as an input here since monitoring and
controlling processes compare the plan to the results. Ex: the status of
a deliverable provides helpful information related to schedule risk,
cost risk, or other areas of concern.
o Work Performance Reports: These do not focus so much on what has
been done as they do on how it was done. Ex: Whereas the work
performance information provides info on the status of deliverables,
the work performance reports focus on cost, time, and quality
performance.
• Outputs
o Work performance information: Ex: results of risk reviews and audits
of how well risk processes are working for the project.
o Risk Register updates: The Monitor Risks process will add the
following to the risk register:
§ Outcomes of risk reassessments and risk audits
§ Results of implemented risk responses
§ Updates to previous parts of risk management, including the
identification of new risks
§ Closing of risks that are no longer applicable
§ Details of what happened when risks occurred
§ Lessons learned
o Change requests: This process will uncover needed project changes
including changes to the cost and schedule baselines due to overall
and individual project risks.
Control Procurements (Procurement Management)

Control Procurements process is concerned with managing procurement

relationships, monitoring contract performance as well as making changes and
corrections as appropriate, and closing out contracts.

• Output
o Closed procurements
o Work performance info
o Procurement documentation updates
• Involves managing the legal relationship between the buyer and seller
ensuring that both parties perform as required by the contract and that each
contract is closed when completed or terminated.
o Are the goods or services being delivered?
o Are the goods and services being delivered on time?
o Are the right amounts being invoiced or paid?
o Are additional conditions of the contract being met?
o Is the buyer/seller relationship being properly managed and
maintained?
• Throughout this process, the seller is focused on completing the work while
the buyer is focused on measuring the performance of the seller and
comparing actual performance to the contract, other procurement
documents, and management plans.
• Process
o Monitor performance to make sure both parties to the contract meet
contractual obligations
o Inspect and verify the contract deliverables
o Protect your legal rights
o Follow the defined procurement management procedures, including
the contract change control system.
o Analyze work performance data, seller work performance report, and
variances
o Request and manage changes
o Authorize contract-related work.
o Issue and review claims
o Maintain comprehensive records
o Report on seller performance compared to contract
o Review invoices and make payments
o Update the project management plan and procurement
documentation
o Validate contract changes, control contracts to updated versions, and
evaluate effectiveness of changes
o Document lessons learned
o Close out contracts as final deliverables are completed and accepted.
• Approved change requests from integrated change control are implemented
in this process.
• If variances are identified they are analyzed and may need to be managed
using the integrated change control system
• Contract changes are handled using the organization’s contract change
control system (an EEF)
• Tools and Techniques
o Performance reviews: Project manager analyzes all available data to
verify that the seller is performing as they should
o Inspection
o Audits: Includes reps from both buyer and seller
o Earned value analysis: identify scope, schedule, or cost variances from
the performance measurement baseline.
o Trend analysis
o Claims: An assertion by the seller that he was harmed by the buyer.
• Primary outputs
o Change requests
§ While work is underway, the buyer’s needs may change, and as
a result the buyer may issue a change order to the contract.
§ Handled through integrated change control along with other
project changes.
§ Constructive changes: happen through failure of buyer to
upload their end of the contract. Ex: failure to review
documents
o Procurement document updates: data on the contract and contract
performance by both the buyer and seller is gathered and analyzed.
o Closed Procurements. Consider closed when a contract is completed
or when a contract is terminated before the work is completed.
§ Verify all work and deliverables are accepted
§ Finalizing open claims
§ Paying retainers
§ All procurements must be closed as part of monitoring and
controlling before final project closure.
Monitor Stakeholder Engagement (Stakeholder Management)

Monitor Stakeholder Engagement process involves the efforts exerted to monitor

stakeholder relationships as well as customizing their engagement approaches to
ensure effective engagement.

• Output
o Work performance info
o Stakeholder register
• Process
o Linked to communications
o Actively engaging stakeholders
o Analyze work performance data and variances
o Evaluate stakeholder engagement and stakeholder relationships and
look for opportunities for improvement
o Assess whether stakeholders’ expectations are aligned with the
project
o Resolve conflicts
o Maintain an issue log
o Request changes
o Update the stakeholder management plan and the stakeholder
register
o Document lessons learned
o Validate success of changes to stakeholder engagement strategy.
• Inputs to this process
o Resource management plan: all team members are also stakeholders
o Communications management plan
o Stakeholder management plan
• This process requires you to collect and analyze data.
o Work Performance Data from the Direct and Manage Project Work
includes measurements of project performance and the engagement
levels of specific stakeholders. That data is then used to compare
actual engagement efforts against the project management plan to
look for variances. Any variances may indicate a potential problem
with stakeholder engagement.
o Results in work performance information: An analysis of the work
performance data gathered through your stakeholder engagement
efforts.
• Outputs
o Work Performance Information
o Change requests
Closing (Integration Management)

Close Project or Phase

Close Project or Phase process refers to the activities the project management
team do to complete all remaining phase or project activities. The project
manager performs this process each time he completes a phase or when he closes
the whole project. This process focuses on ensuring all planned work for the phase
or project is complete and all relevant information are stored in the right place. It
also helps in providing an official announcement of phase or project closure. The
key deliverable of the Close Project or Phase process is the final project or phase
product.

This process is within the Integration Management process group because all of the
final performance reporting involves reporting on all knowledge areas.

All of the activities within this process are known as “administrative closure”.

• Regression Analysis: For project closure, a technique that analyzes the

interrelationships between different project variables that contributed to the
project outcomes, which can be used to improve the performance on future
projects.

• Output
o Lessons learned register
o Final product, service, or result transition
o Final report
o OPAs (Lessons learned repository)