PMP Study Notes 1 – Terms and Concepts ..............................................................................................................

6
Important PMP® Terms and Concepts ................................................................................................................ 6
Project .................................................................................................................................................................. 6
Project Management .......................................................................................................................................... 7
Role of the Project Manager .............................................................................................................................. 8
Organization System .......................................................................................................................................... 8
Project Life Cycle vs Project Management Life Cycle vs Product Life Cycle .............................................. 9
Other Important Project Management Terms .............................................................................................. 10
PMP Study Notes 2/3 – Project Management Processes and Knowledge Areas ................................................. 12
The Project Management Process Groups ......................................................................................................... 12
Initiating ............................................................................................................................................................ 12
Planning ............................................................................................................................................................. 13
Executing ........................................................................................................................................................... 13
Monitoring and Controlling............................................................................................................................. 13
Closing ............................................................................................................................................................... 13
PMBOK® Guide Knowledge Areas .................................................................................................................... 14
49 processes of Project Management .................................................................................................................. 15
Project Management Tools and Techniques (T&T) .......................................................................................... 15
PMP Study Notes 4 – Project Integration Management ....................................................................................... 16
Project Integration Management ........................................................................................................................ 16
Develop Project Charter .................................................................................................................................. 16
Develop Project Management Plan ................................................................................................................. 17
Direct and Manage Project Work ................................................................................................................... 18
Manage Project Knowledge (new to PMBOK® Guide 6th Edition)............................................................ 18
Monitor and Control Project Work ................................................................................................................ 19
Perform Integrated Change Control............................................................................................................... 19
Close Project or Phase ...................................................................................................................................... 20
PMP Study Notes 5 – Project Scope Management ................................................................................................ 22
Project Scope Management.................................................................................................................................. 22
Plan Scope Management .................................................................................................................................. 22
Collect Requirements ....................................................................................................................................... 23
Define Scope ...................................................................................................................................................... 23
Create WBS ....................................................................................................................................................... 24

1|Page
 Validate Scope ................................................................................................................................................... 25
Control Scope .................................................................................................................................................... 25
PMP Study Notes 6 – Project Schedule Management ........................................................................................... 27
Project Schedule Management ............................................................................................................................ 27
Plan Schedule Management ............................................................................................................................. 27
Define Activities ................................................................................................................................................ 27
Sequence Activities ........................................................................................................................................... 28
Estimate Activity Durations............................................................................................................................. 29
Develop Schedule .............................................................................................................................................. 30
Control Schedule............................................................................................................................................... 32
PMP Study Notes 7 – Project Cost Management ................................................................................................... 34
Project Cost Management .................................................................................................................................... 34
Plan Cost Management .................................................................................................................................... 34
Estimate Costs ................................................................................................................................................... 35
Determine Budget ............................................................................................................................................. 35
Control Costs..................................................................................................................................................... 36
PMP Study Notes 8 – Project Quality Management.............................................................................................. 38
Project Quality Management ............................................................................................................................... 38
Plan Quality Management ............................................................................................................................... 39
Manage Quality................................................................................................................................................. 41
Control Quality ................................................................................................................................................. 42
PMP Study Notes 9 – Project Resource Management ........................................................................................... 44
Project Resource Management ............................................................................................................................ 44
Plan Resource Management ............................................................................................................................ 44
Estimate Activity Resources ............................................................................................................................ 45
Acquire Resources ............................................................................................................................................ 46
Develop Team .................................................................................................................................................... 46
Manage Team .................................................................................................................................................... 48
Control Resources (New in PMBOK® Guide 6th Edition)........................................................................... 49
PMP Study Notes 10 – Project Communications Management ........................................................................... 51
Project Communications Management............................................................................................................... 51
Plan Communications Management ................................................................................................................... 51
Manage Communications ................................................................................................................................ 52

2|Page
 Monitor Communications ................................................................................................................................ 53
PMP Study Notes 11 – Project Risk Management ................................................................................................. 54
Plan Risk Management .................................................................................................................................... 54
Identify Risks .................................................................................................................................................... 55
Perform Qualitative Risk Analysis.................................................................................................................. 56
Perform Quantitative Risk Analysis ............................................................................................................... 56
Plan Risk Responses ......................................................................................................................................... 57
Implement Risk Responses (new in PMBOK® Guide 6th Edition) ............................................................. 58
Control Risks..................................................................................................................................................... 59
PMP Study Notes 12 – Project Procurement Management .................................................................................. 61
Project Procurement Management ..................................................................................................................... 61
Plan Procurement Management .......................................................................................................................... 61
Conduct Procurements..................................................................................................................................... 63
Control Procurements ...................................................................................................................................... 64
PMP Study Notes 13 – Project Stakeholder Management .................................................................................... 66
Project Stakeholder Management ....................................................................................................................... 66
Identify Stakeholders........................................................................................................................................ 66
Plan Stakeholder Engagement......................................................................................................................... 67
Manage Stakeholder Engagement................................................................................................................... 67
Monitor Stakeholder Engagement .................................................................................................................. 68
PMP Study Notes – Professional and Social Responsibility.................................................................................. 69
Responsibility ........................................................................................................................................................ 69
Respect ................................................................................................................................................................... 69
Fairness .................................................................................................................................................................. 69
Honesty .................................................................................................................................................................. 69
PMP Study Notes 14 – Agile Practice Guide .......................................................................................................... 70
Overview of the Agile Practice Guide ................................................................................................................. 70
47 Pairs of Easily Confused Terms ......................................................................................................................... 72
PMP Basics: Project vs Operation ...................................................................................................................... 72
PMP Basics: Enterprise Environmental Factors (EEF) vs Organization Process Assets (OPA) .................. 73
Estimate: ROM vs Definitive ............................................................................................................................... 74
Group Creativity Techniques: Nominal Group Technique vs Brainstorming ............................................... 75
Quality Control: Run Chart vs Control Chart .................................................................................................. 76

3|Page
Estimate: Analogous vs Parametric .................................................................................................................... 77
Project Risk Management: Avoid vs Mitigate ................................................................................................... 78
Project Risk Management: Contingency Plan vs Fallback Plan ...................................................................... 79
Project Risk Management: Enhance vs Exploit ................................................................................................. 80
Project Risk Management: Fallback vs Workaround ....................................................................................... 81
Project Risk Management: Qualitative vs Quantitative ................................................................................... 82
Project Communication Management: Push vs Pull ......................................................................................... 83
Project Resource Management: Develop Team vs Manage Team ................................................................... 84
Project Risk Management: Residual Risk vs Secondary Risk.......................................................................... 85
Change Control and Configuration Control ...................................................................................................... 86
Project Expeditor vs Project Coordinator .......................................................................................................... 87
Project Requirements vs Project Scope .............................................................................................................. 88
Project Statement of Work vs Project Charter .................................................................................................. 89
Project Statement of Work vs Business Case ..................................................................................................... 90
Create WBS vs Decomposition ............................................................................................................................ 91
RACI: Responsible vs Accountable..................................................................................................................... 92
RACI vs RAM ....................................................................................................................................................... 93
Scope: Project Scope vs Product Scope .............................................................................................................. 94
Cost of Quality: Cost of Conformance / Cost of Non-conformance ................................................................. 95
Work Package vs Activity .................................................................................................................................... 96
Critical Path Method (CPM) vs Critical Chain Method (CCM) ...................................................................... 97
Contingency Reserve vs Management Reserve .................................................................................................. 98
Quality Control vs Quality Assurance ................................................................................................................ 99
Assumptions vs Constraints vs Requirements ................................................................................................. 100
Corrective vs Preventive Actions....................................................................................................................... 101
Statement of Work (SOW) vs Project Scope Statement .................................................................................. 102
Quality vs Grade ................................................................................................................................................. 103
Accuracy vs Precision ......................................................................................................................................... 104
Accepted Deliverable vs Verified Deliverable .................................................................................................. 105
Project Calendar vs Resource Calendar ........................................................................................................... 106
Resource Leveling vs Resource Smoothing ...................................................................................................... 107
Functional vs Projectized vs Matrix Organizations ........................................................................................ 108
Project Life Cycle vs Product Life Cycle .......................................................................................................... 109

4|Page
Earned Value Measurement: Discrete Effort vs Apportioned Effort vs Level of Effort ............................. 110
Project Team vs Project Management Team ................................................................................................... 111
Project Procurement Management: Contract Types ...................................................................................... 112
Project Quality vs Product Quality ................................................................................................................... 113
Project Time Management: Free Float vs Total Float .................................................................................... 114
Project Cost Management: Cost Baseline vs Budget ....................................................................................... 115
Project Quality Management: Control Limit vs Specification Limit ............................................................. 116
Project Time Management: Crashing vs Fast Tracking ................................................................................. 117
Project Quality Management: Common Cause vs Special Cause .................................................................. 118

5|Page
PMP Study Notes 1 – Terms and Concepts
 1 Important PMP® Terms and Concepts (covering Section 1, 2 and 3 of the PMBOK® Guide 6th
Edition)
o 1.1 Project
o 1.2 Project Management
o 1.3 Role of the Project Manager
o 1.4 Organization System
o 1.5 Project Life Cycle vs Project Management Life Cycle vs Product Life Cycle
o 1.6 Other Important Project Management Terms
 2 Further PMP® Study Resources

Important PMP® Terms and Concepts

Project

 Project – a temporary endeavor to create a unique product, service or result (or enhancement of
existing services/products (e.g. v.2 development is a project) ) — may be collectively termed as
deliverable — (vs ongoing operations which manage processes in transforming resources into
output) sometimes may involve handing over the deliverable to the operation teams for continuous
operation
 Project drives changes in the organization and often is a means to create business values and to
achieve organizational goals — the net quantifiable benefit derived from a business
endeavor which can be tangible or intangible.
 Projects operate in an environment that may have favorable or unfavorable impacts on them. Two
major categories are:
o Organization Process Assets is a major input in all planning process, which may be kept
at PMO, directly related to project management, including Processes and Procedures
(including templates (e.g. WBS, schedule network diagrams, etc.), procedures for issuing
work authorizations, guidelines, performance measurements) and Organizational
Knowledge Repositories
o Enterprise Environment Factors (often are constraints) are influences not under control
of the project team that will affect the project, either intra-organization and extra-
organization, e.g. organizational culture, organization structure, existing human
resources, work authorization system, PMIS, market conditions, legal requirements,
technology
 EEF are inputs for all initiating, most planning process, not much in the
executing/controlling process, none in closing process
 Projects often involve more risks and uncertainties than operations and thus require more planning
 The following factors influence the operation of the organization which may lead to the need for
projects:
o Regulatory/legal/social requirements changes
o Stakeholders needs/requests
o Changes in technology/business
o Improvements, rectification and enhancements to processes/products/services
 A project can be subdivided into phases; each phase is a collection of logically related project
activities that result in the completion of deliverable(s). Towards the end of each phase is a “Phase
Gate” which determines whether the project will go on or not.
6|Page
  Process – a package of inputs, tools and outputs, there are 49 processes defined by
PMI. Processes are grouped in the PMBOK® Guide into 5 Process Groups (NOTE: Process
groups are not the same as project phases).
 Portfolio > Program > Project
o Program – a group of coordinated projects, taking operations into account, maybe with
common goals, achieving benefits not realized by running projects individually, if only
the client/technologies/resource are the same, then the projects should be managed
individually instead of a program
o Portfolio – a group of programs and/or projects to achieve organizational strategic goals
within the organization with a view to maximizing the value to the organization
o Actively coordinating and managing portfolios, programs and projects through
organizational project management (OPM) best position the organization to achieve
strategic business goals.
 Use of portfolio/program/project management to bridge the gap between organizational strategy
and business value realization

Project Management

 Project Management – the application of (all appropriate) knowledge, skills, tools & techniques
and whatsoever to manage project activities with a view to meet the project requirements and
achieve customer satisfaction
 The most important task is to align stakeholder expectations with the project requirements,
around 90% of the PM’s work is related to communication with stakeholders
 PMBOK® Guide is a framework/standard but not methodology (agile, scrum, PRINCE3, etc.)
— A framework allows flexibilities while a methodology would require the use of a predefined
system of practices, techniques, procedures and rules.
o Project management emphasizes tailoring — selecting the appropriate project management
processes, inputs, tools, techniques, outputs and life cycle phases according to the unique
nature of each individual project.
 Competing constraints: time, cost, scope, quality, risk, resources
 Project Management Business Documents
o Project Business Case — documents the economic feasibility vs benefits of the project and
is used for authorization of project management activities.
o Project Benefits Management Plan —describes how and when the benefits of the
deliverables of the project will bring and describes how to measure the benefits (also
including the alignment with organization strategies, assumptions and risks)
o Project Charter — authorizes the project and names the project manager
o Project Management Plan — how the project will be performed and managed –
documents assumptions & decisions, helps communication between stakeholders, goals,
costs & time scheduling (milestones), project management system and subsidiary
management plans and documents
o Project Success Measures — project success is now more inclined to be measured by
considering the achievement of project objectives as documented in this document

7|Page
Role of the Project Manager

 Project Manager: an individual assigned by the organization to lead the team and is responsible
for achieving project objectives
o is the leader of the project irrespective of the authority
o should consider every process to determine if they are needed for individual projects
(tailoring)
o the exact role of project manager is to be tailored to suit the needs of individual
organizations and projects
o may report to the functional manager, program manager, PMO manager, operation
manager, senior management, etc., maybe part-time or devoted
o identifies and documents conflicts of project objectives with organization strategy as early
as possible
 Skills required of project managers:
o Technical project management — process tailoring, planning, managing
schedule/cost/resources/risk
o Leadership — communication (within team and with stakeholders), team building,
motivation, influencing, coaching, trust building, conflict management, negotiation
o Strategic and business management — be aware of the high-level strategies of the
organization and effectively implement decisions/actions that align with strategic goals
(Organization Strategy may be expressed through mission and vision)
 Project Manager must balance the constraints and tradeoffs, effectively communicate the info
(including bad news) to the sponsor for informed decisions
 Project Manager needs to involve project team members in the planning process
 Project Manager needs to perform integration at process level, cognitive level and context level
 Project Team includes Project Manager, project management staff, project staff, PMO, SME
(subject matter experts can be outsourced), customer representative (with authority), sellers,
business partners, etc., maybe virtual or collocated
 Senior management must be consulted for changes to high-level constraints
 Leadership vs Management:
o Lead: guide through interactive discussion from one point to another
o Manage: direct a person to perform a set of expected behavior
 Leadership styles:
o Laissez-faire
o Transactional
o Servant leader
o Transformational
o Charismatic
o Interactional

Organization System

 The organizational system determines the power, influence, competence, leadership and political
capabilities of the people who can act within the system. e.g.
o Management Elements — general management principles/rules of the organization, e.g.
disciplinary action, division of skills, authorization model/practices, communication
channels
o Organizational Governance Frameworks — framework/processes describing how authority
within the organization is exercised
8|Page
 o Organizational Structure Types
 Organic or Simple
 Virtual
 Projectized (project manager has the ultimate authority over the project, team
members are often collocated)
 Matrix (Strong, Balanced, Week)
 Functional
 Composite/Hybrid – a combination of different types, depending on the actual
need
 PMO
 Tight Matrix = co-location, nothing to do with the organization type (not necessarily a matrix
org.)
 Functional organizations => the project manager has little authority, often called project expeditor
(no authority) or coordinator (little authority), project coordination among functional managers
 Matrix organization => multiple bosses and more complex
 Project Management Office (PMO) – standardizes governance, provides training, shares tools,
templates, resources, etc. across all projects/programs/portfolios
o 3 forms: supportive, controlling and directive (lead the project as PM)
o functions: training, resource coordination, methodology, document repository, project
management oversight, standards, career management of PMs
o may function as a stakeholder / key decision maker (e.g. to terminate the projects)
o control shared resources/interdependence across projects at the enterprise level
o play a decisive role in project governance

Project Life Cycle vs Project Management Life Cycle vs Product Life Cycle

 Project Life Cycle: includes: initiating, planning and organizing, carrying out/executing work,
closing the project. Project life cycles are independent of a product life cycle.
 Within a project life cycle, there can be one or more phases of the development of the product,
service, or result (a.k.a. development life cycles) with the following models:
o Predictive [plan driven/waterfall] – scope, time and cost determined early in the lifecycle,
may also employ rolling wave planning
o Iterative – repeat the phases as understanding of the project increases until the exit criteria
are met, similar to the rolling wave planning, high-level objectives, either
sequential/overlapping phase, scope/time/resources for each phase may be different
o Incremental – features/scope are added to each incremental cycle
o Adaptive [change driven/agile] – for projects with high levels of change, risk and/or
uncertainty, each iterative is very short (2-4 weeks), work is decomposed into product
backlog, each with a production-level product, scrum is one of the most effective agile
methods, stakeholders are involved throughout the process, time and resources are fixed,
allow low change cost/keep stakeholder influence high
o Hybrid
 The life cycle chosen must be suitable for the intended deliverable and flexible enough to deal
changes.
 each project phase within the product lifecycle may include all the five project management
process groups
 Product life cycle: development > production > adoption & growth > maturity > decline > end of
life

9|Page
Other Important Project Management Terms

 The Configuration Mgnt Knowledge Bases contain baselines of all organization standards
 Lessons Learned – focus on the deviances from plan (baseline) to actual results and how to solve
these discrepancies
 The work authorization system (WAS) is a system used during project integration management
to make sure that the right work gets done at the right time
 PMIS includes configuration system and change control system
 Never accept a change request to trim down one element of the triple constraint without changing
the rest.
 Sponsor – provides resources/support to project, lead the process through initiation (charter/scope
statement) through formally authorized, later involved in authorizing scope/budget change/review
 Customer – NOT necessarily provide the financial resources, may be external to the organization,
final acceptance of the product
 Business Partners – certification body, training, support, etc.
 Project Statement of Work (SOW): describes the business need, high-level scope
of deliverables and strategic plan of the organization, created by the sponsor/initiator/buyer
 Project Charter is not a contract
 Project Management Plan is NOT a project schedule
 Project Management System: includes a list of project mgnt processes, level of implementation
(what actions to take in the management processes), description of tools and techniques, resources,
procedures, change control system [forms with tracking systems, approval levels]
 Requirement Traceability Matrix (RTM) – a matrix connecting deliverables to requirements
and their sources (for managing scope)
 Work Breakdown Structure (WBS) – a hierarchal chart of decomposing deliverables into work
packages
 Activity List – a full list of all activities with indication of relationship to the work packages
 Activity Attributes – further information (duration, start date, end date, etc.) of all the activities in
the list (for scheduling)
 Roles and Responsibilities (RAR) – a document listing all the roles and description of their
responsibilities in the project (often by category)
 Responsibility Assignment Matrix (RAM) – a matrix connecting people to work
packages/activities, e.g. the RACI matrix (responsible, accountable, consult, inform), usually only
one person is accountable for each activity
 Resources Breakdown Structure (RBS) – a hierarchical chart listing all the resources by
categories, e.g. marketing, design, etc.
 Risk Breakdown Structure (RBS) – a hierarchical chart listing all risks by categories
 Project Management Data and Information
o Work Performance Data – raw data collected
o Work Performance Info – analyzed in context and integrated data, e.g. some forecasts
o Work Performance Reports – work performance information compiled in report format
 Sunk costs – money already spent, not to be considered whether to terminate a project, similar to
committed cost (often through contracts)
 Direct costs, indirect (shared) costs, Fixed costs, Variable costs
 Law of diminishing returns – beyond a point, the more input, the less return
 Working capital – assets minus liability, what the company has to invest in the projects
 Payback period – a time to earn back capital investment
 Benefit-cost ratio (BCR) – an indicator, used in the formal discipline of cost-benefit analysis, that
attempts to summarize the overall value for money of a project
10 | P a g e
 Depreciation – straight-line depreciation vs accelerated depreciation (the amount of depreciation
taken each year is higher during the earlier years of an asset’s life)
 Under double declining balance, the asset is depreciated twice as fast as under straight line.
Using the example above, 10% of the cost is depreciated each year using a straight line. Doubling
the rate would mean that 20% would be depreciated each year, so the asset would be fully
depreciated in 5 years, rather than 10.
 Under sum-of-the-years-digits, the asset is depreciated faster than the straight line but not as fast
as declining balance. As an example of how this method works, let’s say an asset’s useful life is 5
years. Adding up the digits would be 5+4+3+2+1 or a total of 15. The first year, 5/15 is expensed;
the next year 4/15 is expensed, and so on. So if the asset’s cost is $1000, 5/15, or $333.34 would
be expensed the first year, $266.67 the second year, and so on.
 Economic value added – the value of the project brought minus the cost of project (including
opportunity costs) e.g. for a project cost of $100, the estimated return for 1st year is $5, assuming
the same money can be invested to gain 8% per year, then the EVA is $5 – $100 * 8% = -$3
 Net present value (NPV) – the sum of the present values (PVs) of the individual cash flows of the
same entity
 Present value (PV) – or called present discounted value, is a future amount of money that has been
discounted to reflect its current value, as if it existed today (i.e. with inflation, etc.)
 Future value (FV) – is the value of an asset at a specific date
 Internal Rate of Return (IRR) – The inherent discount rate or investment yield rate produced by
the project’s deliverables over a pre-defined period of time.
 Forecast (future) vs Status Report (current status) vs Progress Report (what have been
done/delivered)
 Journey to Abilene (Abilene’s Paradox) – committee decisions can have a paradox outcome, the
joint decision is not welcome by either party (because of fear of raising objections)
 when something unusual happens, always refer to the PM Plan/Charter for instruction on how to
proceed; if not found, ask for direction from the management
 unresolved issues will lead to conflicts

11 | P a g e
PMP Study Notes 2/3 – Project Management Processes
and Knowledge Areas
 1 The Project Management Process Groups
o 1.1 Initiating
o 1.2 Planning
o 1.3 Executing
o 1.4 Monitoring and Controlling
o 1.5 Closing
 2 PMBOK® Guide Knowledge Areas
 3 49 processes of Project Management
 4 Project Management Tools and Techniques (T&T)

The Project Management Process Groups

 Initiating
 Planning
 Executing
 Monitoring and Controlling
 Closing

 Planning and Executing are iterative. Monitoring and Controlling is exercised over Planning and
Executing.
 A phase is not a process group. The 5 process groups will usually be included in any single
phase.
 The process groups are not to be carried out in sequence as some are iterative and some are
overlapping.
 The PM should identify and choose the most appropriate processes in each process group to fit in
each individual project (tailoring)
 The deliverables from each phase/project are often incremental in nature meaning the deliverables
will be continually refined/enhanced by each phase/project.

Initiating

 align project purposes with stakeholders’ expectations

 assign a project manager
 identify stakeholders and develop the project charter
 document business case (created by an initiator, maybe well before the initiating process group)
and cost-benefit analysis, identify high-level risks, identify project selection criteria
 early in the process, the staffing, costs and chance of success are low, risk and stakeholder
influence is high
 may be performed at portfolio/program level (i.e. outside the project’s level of control)

12 | P a g e
Planning
 create Project Management Plan [why the project? what to deliver? who does what? when be
accepted? How to execute?], subsidiary documents (schedule baseline, cost baseline, scope
baseline (scope statement, WBS, WBS dictionary), performance management baseline, and
subsidiary management plans (scope, schedule, budget, quality, human resources [roles &
responsibility, organization chart and staffing management plan include the staff need, rewards,
safety and training need], stakeholder, requirements, process improvement, communication,
change, risk and procurement) – all are not finalized until a thorough risk management has been
performed, need to be approved before work begins
 all plan and documents can be formal or informal, generalized or detailed, depending on needs
(tailoring)
 Project Management Plan may be continually updated during the project with rolling wave
planning / progressive elaboration
 obtain approval of the plan from designated stakeholders, changes to the project mgnt plan and
subsidiary documents/plans need formal procedures described in the change control system
 hold the kick-off meeting
 planning process group is MOST important for project management, with around 1/2 of all the
49 process in this group
 may need re-planning when significant changes to the baseline is observed in the
executing/monitoring processes

Executing
 coordinating human/infrastructure resources in accordance with the project management plan
 updates and re-baselining the project mgnt plan and subsidiary management plans when needed
 normal execution, manage contracts, acquire, develop & manager project team, perform quality
assurance and manage stakeholder expectation/communication
 direct and manage project work
 continuous improvement process (quality assurance)
 use up the largest share of resources here in the Executing process group

Monitoring and Controlling

 measure performance, address change requests, recommend corrective/preventive measures and
rectify defects
 usually performed at regular intervals
 control the quality, inspection and reporting, problem-solving, identify new risks
 reassess control process
 should there be any internal deviance from the stated plan, the PM should make corrections (use
contingency reserve if necessary)
 monitor and control project work and integrate change control
 make sure only approved changes (through integrated change control) are incorporated

Closing
 either project finished or cancelled
 final product verification, contract closure, produce the final report (closeout documentation),
obtain formal acceptance, archive, release resources, close project
 feedback, review and lessons learned (about the process), transition of deliverables to operation
13 | P a g e
PMBOK® Guide Knowledge Areas
1. Project Integration Management – assemble and combine all the various parts of the project into
a coherent whole
2. Project Scope Management – plan, execute and control the project scope
3. Project Schedule Management – plan, execute and control the project schedule
4. Project Cost Management – plan, execute and control the project cost
5. Project Quality Management – plan, execute and control the project quality
6. Project Resource Management – plan, execute and control the project resources including human,
equipment and other physical resources
7. Project Communications Management – plan, execute and control the project communication
(channels, methods, etc.)
8. Project Risk Management – plan, execute and control the project risk control measures
9. Project Procurement Management – plan, execute and control the project procurement
10. Project Stakeholder Mgnt – plan, execute and control how to best dealing with project
stakeholders

14 | P a g e
49 processes of Project Management
The 49 processes of project management are grouped under one of the 5 process groups/10 knowledge
areas listed above. 3 new processes are added while 1 deleted in PMBOK® Guide 6th edition, resulting in
a total of 49 processes from 47 processes in PMBOK® Guide 5th edition:

 Added processes
o Manage Project Knowledge – in Executing Process Group / Project Integration
Management knowledge area
o Implement Risk Responses – in Executing Process Group / Project Risk Management
knowledge area
o Control Resources – in Monitoring and Controlling Process Group / Project Resource
Management knowledge area
 Deleted process
o Close Procurement – activities now are included in Control Procurements and Close
Project or Phase process
 Naming Changed processes
o Perform Quality Assurance → Manage Quality
o Plan Human Resource Management → Plan Resource Management
o Acquire project Team → Acquire Resources
o Develop Project Team → Develop Team
o Manage Project Team → Manage Team
o Control Communications → Monitor Communications
o Control Risks → Monitor Risks
o Plan Stakeholder Management → Plan Stakeholder Engagement
o Control Stakeholder Engagement → Monitor Stakeholder Engagement

Each project management process is now categorized into:

 used once or at predefined points in the project

 done periodically as needed
 done continuously throughout the project

It is important to understand the differences between PMBOK® Guide 6th and 5th edition (what new
things have been added) as PMI usually emphasizes on these “new” things in the new PMP® Exam 2018.

Project Management Tools and Techniques (T&T)

In the PMBOK® Guide 6th edition, many tools and techniques have been grouped according to their
purpose with a view to better supporting tailoring:

 Data gathering
 Data analysis
 Decision making
 Communication
 Interpersonal and team skills
 Communication skills

15 | P a g e
PMP Study Notes 4 – Project Integration Management
 1 Project Integration Management
o 1.1 Develop Project Charter
o 1.2 Develop Project Management Plan
o 1.3 Direct and Manage Project Work
o 1.4 Manage Project Knowledge (new to PMBOK® Guide 6th Edition)
o 1.5 Monitor and Control Project Work
o 1.6 Perform Integrated Change Control
o 1.7 Close Project or Phase

Project Integration Management

Project Integration Mgnt encompasses all the process and activities to identify, define, combine, unify and
coordinate all the various project management processes and activities and manage the interdependencies.

 integration management is required when different project management processes interact

 tailoring of processes is a very important topic in the PMBOK® Guide 6th edition with a view to
meeting project objectives
 of all the project management activities, communication is the most important one according to
many project managers
 a PM Plan not meeting requirements is a defect

Develop Project Charter

 Inputs: Business Documents (including business case), Agreements, EEF, OPA

 Tools & Techniques: Expert Judgement, Data gathering (including brainstorming, focus groups,
interviews), Interpersonal and team skills (including conflict management, facilitation, meeting
management), Meetings
 Outputs: Project Charter, Assumption log (records all assumptions and constraints of the project)

 to formally authorize the project and allow the PM to apply organizational resources
 well-defined project start and project boundaries
 the project charter is a several page document including high-level information of the project:
project background, business case, goals (S.M.A.R.T. specific, measurable, achievable, relevant,
time-bound), who is and the authority of the project manager, budget, risk, stakeholders,
deliverables, approval criteria, etc.
o the business case contains info to determine whether the project is justified
o agreements are a group of project documents (either a contract (for external parties), letter
of intent, service level agreement, etc. (can be legally binding or NOT)) that define initial
intentions of the project
o a charter is NOT a contract because there is no consideration
 signed off by the sponsor (the one who supply the money/resources)
 PMO may provide the expert judgement
16 | P a g e
Develop Project Management Plan

 Inputs: Project Charter, Outputs from other processes, EEF, OPA

 Tools & Techniques: Expert Judgement, Data gathering, Interpersonal and team skills, Meetings
 Outputs: Project Management Plan

 the project management plan is a formal written document on how the project is executed,
monitored and closed, including all subsidiary management plans (scope, requirements, change,
configuration, schedule, cost, quality, process improvement, human resource, communication, risk,
procurement) and documents (cost baseline, schedule baseline, scope baseline, performance
measurement baseline, cost estimate, schedule, responsibility for each deliverable, staff
requirements) and some additional documents/plans (selected PM processes and level of
implementation)
o the contents to be tailored by the PM (tailoring) to suit each project
o the PM plan may be progressively elaborated in iterative phases (as outputs from other
processes), this must be the final process/iteration to consolidate the PM Plan
o created by PM, signed off by destined KEY stakeholders (e.g. can be the project sponsor,
project team, project manager)
o when the project management plan is baselined (i.e. validated and then signed off by key
stakeholders), it is subject to formal change control and is used as a basis for comparison to
the actual plan
o after baselining, the senior management must be consulted if these high level constraints
are to be altered (whether to use the management reserves)
 the PM Plan can be re-baselined if significant changes are seen (scope change, internal
changes/variances (for the project execution), external factors)
o needed to be approved by sponsors/stakeholders/senior management, must understand the
underlying reasons first (built-in costs is not usually a legitimate reason)
 cost baseline (specific time-phased budget), schedule baseline (-> knows when to spend
money), scope baseline (includes scope statement, WBS, WBS dictionary): whether
preventive/corrective/defect repair actions are needed
 the performance measurement baseline (PMB) is an approved scope-schedule-cost plan for the
project work (to be used in earned value management), this includes contingency reserve but
excludes management reserves
 configuration management (works with change control management plan), document all
change versions of project deliverables and completed project components, PMIS includes:
Configuration Management System (contains the updated deliverable/project specifications and
processes) and Change Control System (contains formal documents for tracking changes)
o configuration management system contains the most updated version of project
documents
 Kick-off Meeting: at beginning of the project/phase, participants including project team +
stakeholders, element including project review, responsibility assignment matrix, participation of
stakeholders, escalation path, frequency of meetings

17 | P a g e
Direct and Manage Project Work

 Inputs: Project Mgnt Plan, Project documents (including change log, Lessons learned register, risk
register, project schedule, project communications, etc.), Approved change requests, EEF, OPA
 Tools & Techniques: Expert Judgement, Project management information system, Meetings
 Outputs: Deliverables, Work performance data, Issue log, Change requests, Project management
plan updates, Project documents updates, OPA updates

 The Direct and Manage Project Work process creates project deliverables, acquire/assign/train
staff, manage vendors, collect data for reports, document lessons learned
o most of the project time to be spent here
 the PM implements approved process improvement plans and changes, change requests
include corrective actions, preventive actions, defect repair and updates (all considered to be
change requests)
 if the PM discovers a defect, he/she should instruct the team to make defect repair during this
process (need change request but may be approved by the PM only (if stipulated in PM Plan for
minor changes))
 approved change requests – approved in the perform integrated change control, may include
preventive, corrective and defect repair actions
o change requests may arise as a result of implementing approved change requests
 a work authorization system (part of EEF) defines approval levels needed to issue work
authorization (to allocate the work) and is used to prevent scope creep as formal approval must
be sought before work begins
 Stakeholder risk tolerance is part of EEF
 Face-to-face meeting is considered to be most effective
 The PM Plan itself can be considered as a deliverable

Manage Project Knowledge (new to PMBOK® Guide 6th Edition)

 Inputs: Project Management Plan, Project documents, Deliverables, EEF, OPA

 Tools & Techniques: Expert Judgement, Knowledge Management, Information Management,
Interpersonal and team skills
 Outputs: Lessons learned register, Project management plan updates, OPA updates

 This newly added Manage Project Knowledge process is involved in documenting and using
knowledge learnt from the project to achieve the project objectives and the whole organization to
learn from the experiences.
 Documenting lessons learned from the project is a recurring process during the life cycle of the
project.
 The lessons learned register is a new output (first mentioned the PMBOK® Guide) which records
challenges, problems and successes throughout the project
18 | P a g e
Monitor and Control Project Work

 Inputs: Project Management Plan, Project documents, Work performance information,

Agreements, EEF, OPA
 Tools & Techniques: Expert Judgement, Data Analysis, Decision Making, Meetings
 Outputs: Work performance reports, Change requests, Project management plan updates, Project
documents updates

 corrective and preventive actions usually don’t affect the baseline, only affect the performance
against the baseline
 defect repair: considered as rework, deliverable not accepted, either rework or scrap, strongly
advise defect prevention to defect repair
 the work performance info is fed from all other control processes (e.g. control schedule, control
stakeholder engagement, control communications, control costs, control quality, etc.)
 Data Analysis Techniques include:
o Alternatives analysis
o Cost-benefit analysis
o Earned value analysis
o Root cause analysis
o Trend analysis – forecasts future performance based on past performance
o Variance analysis – analyzes the differences (or variances) between planned and actual
performance
 Decision Making is a technique to achieve a decision e.g. by voting.

Perform Integrated Change Control

 Inputs: Project Management Plan, Project documents, Work performance reports, Change requests,
EEF, OPA
 Tools & Techniques: Expert Judgement, Change control tools, Data Analysis, Decision Making,
Meetings
 Outputs: Approved change requests, Project mgnt plan updates, Project documents updates

 changes in the project arise as a result of missed requirements, views of stakeholders, poorly
designed WBS, misunderstanding, inadequate risk assessment
o the PM should influence the factors that cause project change
 life cycle of a change request:
1. identify needs
2. assess the impact, response and alternatives
3. create the change request
4. meet with stakeholders

19 | P a g e
 5. obtain approval from CCB (change control board) or PM as defined in roles and
responsibility document/PM Plan
 customers/sponsors may need to approve certain decisions by CCB (if they are not
part of CCB)
6. request more funding if needed
 the whole process must be documented in the change log (which is a project document)
 changes need to be tracked using a change management system, also affect configuration
management system
o configuration control: changes to deliverables and processes
o change control: identify/document/approve changes
 configuration mgnt activities: configuration identification, configuration status accounting,
configuration verification/audit to ensure the latest configuration is adopted and delivered
 communicate the resolutions (approve or reject) to change requests to stakeholders

Close Project or Phase

 Inputs: Project charter, Project Management Plan, Project documents, Accepted deliverables,
Business documents, Agreements, Procurement documents, OPA
 Tools & Techniques: Expert Judgement, Data Analysis, Meetings
 Outputs: Project documents updates, Final product, service or results transition, Final report,
OPA updates

 must ensure all procurements are closed before formal closure of the project/phase, all
procurement documentation must be collected, indexed and filed
 obtain formal approval to close out the project/phase (administrative closure)
o obtain approval and deliver the deliverables (maybe with training)
o formal sign off by designated stakeholders/customer
 finish and archive documentation, lessons learnt and update to organizational process asset
 if the contract comes with a warranty, make sure that changes during the project are evaluated
against the origin clauses, ensure alignment of the warranty and changes
 to close a project as neatly and permanently possible
 for multi-phase projects, this process will be performed once for every phase end and once for the
whole project (5 times for project with 4 phases)
 The final report is a summary of the project performance, including:
o Summary level description of the project or phase
o Scope objectives
o Quality objectives
o Cost objectives
o Summary of the validation information for the final product, service or result
o Schedule objectives
o Summary of how the final product, service, or result achieved the business needs
o Summary of any risks or issues encountered on the project and how they were addressed
 litigation can be further pursued after the closure

20 | P a g e
21 | P a g e
PMP Study Notes 5 – Project Scope Management
 1 Project Scope Management
o 1.1 Plan Scope Management
o 1.2 Collect Requirements
o 1.3 Define Scope
o 1.4 Create WBS
o 1.5 Validate Scope
o 1.6 Control Scope

Project Scope Management

 The project manager would need to ensure the inclusion of all and only the work required to
complete the project successfully (to achieve project objectives to deliver business values).
 The primary aim of scope management to define the exact scope of work and to prevent scope
creep (additional requirements added without any proper control) or gold-plating (added by the
project team with a view to impressing stakeholders).
 Product Scope – requirements needed to be fulfilled to create the product, assessed against the
product requirements and WBS
 Scope Baseline: scope statement + WBS + WBS dictionary
o WBS includes only the deliverables/outcomes/results (not actions)
 Project Scope – activities and processes needed to be performed to deliver the product scope,
assessed against the scope baseline (scope statement, WBS and WBS dictionary), e.g. including
testing & quality assurance, assessed against the Project Management Plan
o The completion of project scope is measured against the project management plan whereas
the completion of product scope is measured against the product requirements/WBS

Plan Scope Management

 Inputs: Project Charter, Project Management Plan, EEF, OPA

 Tools & Techniques: Expert Judgement, Data Analysis, Meetings
 Outputs: Scope Management Plan, Requirements Management Plan

 Scope Management Plan (will form part of the Project Management Plan): how the scope will be
defined, validated and controlled
o includes how to prevent scope creep, how to handle change requests, escalation path for
disagreement on scope elements between stakeholders, processes for creating scope
statement, WBS, processing CR, how the deliverables will be accepted
 Requirements Mgnt Plan: how the requirements will be managed, documented and analyzed
o includes how to process requirements, address missed requirements, configuration
management, prioritize requirements, metrics for defining the product, define the
traceability structure (in RTM), authorization level for approving new requirements
o [important] the requirement management plan is the primary means to understand and
manage stakeholder expectations
22 | P a g e
Collect Requirements

 Inputs: Project Charter, PM Plan, Project Documents, Biz Documents, Agreements, EEF, OPA
 Tools & Techniques: Expert Judgement, Data Gathering, Data Analysis, Decision Making, Data
Representation, Interpersonal and Team Skills, Content Diagram, Prototypes
 Outputs: Requirements Documentation, Requirements Traceability Matrix

 Requirement: a condition/capability that must be met /possessed by a deliverable to satisfy a

contract/standard/etc., including quantified/documented needs, wants, expectation of the
sponsor/stakeholder/customer
o Business requirements – support business objectives of the company
o Stakeholder requirements
o Solution requirements – functional (product behavior) and nonfunctional requirements
(reliability, security, performance, safety, etc.)
o Transitional requirements: temporary capability including data conversion/training
o Project requirements : actions/processes/conditions the project needs to met
o Quality requirements : quality criteria defined by stakeholders
 Requirements Collection Tools
o Data Gathering
 Brainstorming
 Interviews
 Focus groups
 Questionnaires and surveys
 Benchmarking
o Data Analysis
 Document analysis
o Data Representation
 Affinity Diagram: for identifying a large number of ideas by grouping similar
ideas together
 Mind Mapping: to generate ideas with the process of backtracking
 Requirements Traceability Matrix tracks requirements from origins to deliverables,
including source of requirements and completion status, effective to prevent gold plating (also
work with work authorization system)
 Requirement documentation needs to be unambiguous, traceable, compete, consistent and
acceptable to key stakeholders and is approved by the customer and other stakeholders

Define Scope

 Inputs: Project Charter, Project Management Plan, Project Documents, EEF, OPA
 Tools & Techniques: Expert Judgement, Data Analysis, Decision Making, Interpersonal and Team
Skills, Product Analysis
 Outputs: Project Scope Statement, Project Documents Updates

23 | P a g e
  to define both the project & product scope in details, outlines what WILL and what WILL NOT
be included in the deliverables, including details of constraints and assumptions
o vs project charter which includes only high-level descriptions
 may provide alternatives if the budget and schedule could not meet management’s expectations
 Product analysis includes techniques such as:
o product breakdown
o systems analysis
o requirements analysis
o systems engineering
o value engineering – a part of product analysis technique (Value Engineering (value
analysis, value management, value methodology) with a view to finding alternatives to
constraints to improve product/reduce cost without sacrificing the scope)
o value analysis
 Project Scope Statement includes objectives, (project and product) scope, requirements,
boundaries, deliverables, acceptance criteria, constraints, assumptions, milestones, cost
estimation, specifications, configuration management requirements, approval requirements, etc.
o the scope statement is usually progressively elaborated throughout the project

Create WBS

 Inputs: Project Management Plan, Project Documents, EEF, OPA

 Tools & Techniques: Expert Judgement, Decomposition
 Outputs: Scope Baseline, Project Documents Updates

 the WBS must be created for every project (if you take on a running project without WBS, you
must stop the project immediately and prepare the WBS first)
o WBS is a structured hierarchy created by the organization/stakeholders, can be in an
organization chart or table form, based on the project deliverables (not tasks needed)
o WBS is a decomposition tool to break down work into lowest level manageable (time and
cost can be estimated, work package can be assigned to a team member) work packages,
e.g. by phase or major deliverables
o the work packages are broken down enough to delegate to a staff, usu. 8 – 80 hours work
and different work packages can be at different levels of decompositions
o WBS does not show dependencies between work packages, but a WBS dictionary does
(WBS dictionary clarifies WBS by adding additional information)
o WBS includes 100% of scope (100% rule)
o can be a template in OPA
 a higher level above a work package is ‘control account‘ (control point where scope, cost and
schedule are compared to earn value for performance measurement)
o a work package can have only ONE control account
 code of accounts: a numbering system to identify WBS components
 chart of accounts: a list of all account names and numbers
o 1.1 for the 2nd level, 1.1.1 for the 3rd level
 the major deliverables should always be defined in terms of how the project will actually be
organized, for a project with phases, the decomposition should begin with the phase first
24 | P a g e
  Scope Baseline, an output from Create WBS, includes:
o WBS (Work Breakdown Structure)
o WBS Dictionary
o Scope Statement
o Scope Management Plan
 Scope Baseline is to be created by the project team

Validate Scope

 Inputs: Project Management Plan, Project Documents, Verified Deliverables, Work Performance
Data
 Tools & Techniques: Inspection, Decision Making
 Outputs: Accepted Deliverables, Work Performance Information, Change Requests, Project
Documents Updates

 the purpose of this process is to gain formal acceptance of deliverables from

customer/stakeholders (e.g. obtain customer sign off, requirements validations, etc.) near the end
of project/phase/each deliverable, e.g. user acceptance test
o change requests may be an output as stakeholders may request changes to the deliverables
o if no formal sign off is received as stipulated, the Project Manager needs to follow the pre-
defined process in PM plan, e.g. escalation to management
 work performance data tells how the deliverables were created, work performance data includes
non-conformance and compliance data
 Validate Scope is often preceded by Control Quality Process to give the verified deliverable as
input to this process, verified deliverables is fed from the control quality process
o vs Control Quality: the process of monitoring/recording results of executing quality
activities to assess performance and recommend necessary changes, e.g. UT  high vs low
 need to perform even in case of early termination/cancellation of the project to save any usable
deliverables for other projects

Control Scope

 Inputs: Project Management Plan, Project Documents, Work Performance Data, OPA
 Tools & Techniques: Data Analysis
 Outputs: Work Performance Information, Change Requests, Project Management Plan Updates,
Project Documents Updates

 Control Scope is performed when assessing additional requirements by the customer or the project
manager proactively overlooking the project scope
o to prevent unnecessary changes (either internally or externally requested) to project
 a well-documented and enforced change control process is required
25 | P a g e
 measure the work product against the scope baseline to ensure the project stays on track
proactively, may need preventive, corrective actions or defect repair
 the customer has the ultimate authority to change scope while the senior management can make
use of management reserves
o i.e. in general, disagreement should be resolved in favor of the customer
 Data Analysis includes:
o variance analysis – method to compare planned (baseline) and actual work and determine
the causes/actions e.g. update baseline (keep the variance) or preventive/corrective actions,
both need CR
o trend analysis
 work performance info – scope variance, causes, recommended action
 may end up updating some of the inputs – requirements documentation & requirement traceability
matrix & lessons learnt in OPA

26 | P a g e
PMP Study Notes 6 – Project Schedule Management
 1 Project Schedule Management
o 1.1 Plan Schedule Management
o 1.2 Define Activities
o 1.3 Sequence Activities
o 1.4 Estimate Activity Durations
o 1.5 Develop Schedule
o 1.6 Control Schedule

Project Schedule Management

 The PM is required to create a detailed schedule plan to describe how and when the project/team
will deliver the products, services and results as defined in the project scope in the PM plan
 The project schedule will later be used as a tool for communication (for managing stakeholder
expectations) and performance assessment/reporting

Plan Schedule Management

 Inputs: Project Charter, Project Management Plan, EEF, OPA

 Tools & Techniques: Expert Judgement, Data Analysis, Meetings
 Outputs: Schedule Management Plan

 defines policies, procedures and documentation for managing and controlling project schedule
o including scheduling methodology, tools, level of accuracy, control thresholds (limit
beyond which preventive/corrective actions needed), rules of performance measurement
(e.g. earned value)
 lead and lags are NOT considered as schedule constraints
 Data analysis would include:
o choosing the scheduling methodology (or a combination of various methods)
o determining the detail level of the schedule and how often the schedule needs to be
reviewed and updated
o the duration of waves for rolling wave planning, etc.

Define Activities

 Inputs: Project Management Plan, EEF, OPA

 Tools & Techniques: Expert Judgement, Decomposition, Rolling Wave Planning, Meetings
 Outputs: Activity List, Activity Attributes, Milestone List, Change Requests, Project
Management Plan Updates

27 | P a g e
  the scope baseline (as part of the PM Plan) is used here as it represents the approved (stable) scope
 further decompose work packages into activities for more detailed and accurate estimations
o ‘activities’ is the PMI terminology for ‘tasks’ and ‘work efforts’
o activity is more related to the actual work/process to produce the deliverables
o activity types: level of efforts (support, measured in time period), discrete efforts or
apportioned effort (in direct proportion to another discrete effort)
 activities have durations while milestones do not (zero duration)
 changes requests are listed as a possible output because progressive elaboration of deliverables
into activities (using rolling wave planning) may allow us to discover work that was not initially
included as part of the project baselines — need to update the project baselines

Sequence Activities

 Inputs: Project Management Plan, Project Documents, EEF, OPA

 Tools & Techniques: Precedence Diagramming Method, Dependency Determination and
Integration, Leads and Lags, Project Management Information System
 Outputs: Project Schedule Network Diagrams, Project Documents Updates

 Precedence Diagramming Method (PDM) to diagram dependencies

o Network Diagramming Tools are software that graphically represent activity sequences
o network diagrams: shows dependencies, duration, workflow, help identifying critical paths
 precedence relationships (also known as ‘activity on node (AON)‘ approach):
o finish-to-start (the majority, accounts for about 95% of all precedence relationships)
o start-to-start
o finish-to-finish
o start-to-finish (least)
 Activity on Arrow (AOA) or Arrow Diagramming Method (ADM) activities are represented as
arrows, dashed arrows represent dummy activities (duration: 0) that shows dependencies

 Graphical Evaluation and Review Technique (GERT) allows for conditional branching and loops
 Network Dependency Types (to be determined during Sequence Activities Process):
o Mandatory Dependency (hard logic): A must be completed before B begins/ technical
dependencies may not be hard
o Discretionary Dependency (preferred, soft logic): sequence preferred by the organization,
may be removed should fast-tracking is required
o External Dependency: dependency required by external organization
o Internal Dependency: precedence relationship usually within the project team’s control
 Milestones: the completion of a key deliverable/a phase of the project, as checkpoints/summary
for progress, often used in funding vendor activities
o Milestone list is part of i) project plan, ii) project scope statement, iii) WBS dictionary

28 | P a g e
  Leads (negative lags): begin successor activity before end of predecessor, for schedule
compression (fast-tracking)
 Lags: imposed delay to successor activity, e.g. wait 2 weeks for concrete to cure (FS +14 days)
 Network Diagram Setup: 7-box method, usually using software tools or 5-box method
 if the ES and LS are identical, the activity is on the critical path
 The Project Management Information System provides the scheduling software to allow planning
the activities with logical relationships, leads, lags, etc.

Estimate Activity Durations

 Inputs: Project Management Plan, Project Documents, EEF, OPA

 Tools & Techniques: Expert Judgement, Analogous Estimating, Parametric Estimating, Three-
point Estimating, Bottom-up Estimating, Data Analysis, Decision Making, Meetings
 Outputs: Duration Estimates, Basis of Estimates, Project Documents Updates

 consults SME (subject matter experts, i.e. the one carrying out the actual work) to come with the
estimation, not on the PM’s own
 Different Estimating Tools and Techniques:
o Analogous Estimating: based on previous activity of similar nature (a form of expert
judgement), used when little is known or very similar scope, works well when project is
small, NOT ACCURATE
o Parametric Estimating: based on some parameters, e.g. the time for producing 1000
component based on that for 1 component * 1000, use an algorithm based on historical
data, accuracy depends on the parameters selected, can be used on project.
o One-Point Estimating: based on expert judgement, but highly unreliable.
o Three-Point Estimating: best (optimistic), most likely (realistic), worst (pessimistic),
Triangular Distribution (non-weighted average of three data points, (P+M+O)/3)
vs PERT (Project Evaluation and Review Techniques, Beta Distribution, (P+4M+O)/6,
weighted average using statistical methods.
o In real-world applications, the PERT estimate is processed using Monte Carlo analysis, tie
specific confidence factors to the PERT estimate
o Bottom-Up Estimating: a detailed estimate by decomposing the tasks (lower-level
components of the WBS) and aggregating the estimates based on reliable historical values,
most accurate but time-consuming
o Heuristics: use rule of thumb for estimating
 standard deviation (sigma value, deviation from mean, to specify the precision of measurement):
1 sigma: 68%, 2 sigma 95%, 3 sigma 99.7%, 6 sigma 99.99%
𝟐 𝟐
 standard deviation (𝜎) = (P – O)/6; 𝝈𝒎 𝒎 𝒎 𝒎
𝟏 = √∑𝟏 𝑺𝑫𝒊 ; 𝒏 𝝈𝟏 = n * √∑𝟏 𝑺𝑫𝒊
 accuracy is the conformance to the target value
 contingency reserve: for known unknowns, owned by PM, may be updated, part of schedule
baseline
 management reserve: for unknown unknowns, owned by management, included in overall
schedule requirements
 update to documents: the basis of estimates, assumptions and contingencies
29 | P a g e
  activity duration estimate may be in a range, don’t include lags
 Data Analysis tools and technique may include:
o Alternatives analysis
o Reserve analysis
 Duration Estimates are the quantitative assessments of the likely durations that are required to
complete the activities, phases or a project (maybe in the form of a range).
 Basis of Estimates provide the detail to support duration estimate process (e.g. the basis of the
estimate, assumptions, constraints, ranges of possible estimates, confidence levels of the final
estimate, individual project risks influencing this estimate, etc.)

Develop Schedule

 Inputs: Project Management Plan, Project Documents, Agreements, EEF, OPA

 Tools & Techniques: Schedule Network Analysis, Critical Path Method, Resource
Optimization, Data Analysis, Lead and Lags, Schedule Compression, Project Management
Information System, Agile Release Planning
 Outputs: Schedule Baseline, Project Schedule, Schedule Data, Project Calendars, Change
Requests, Project Management Plan Updates, Project Documents Updates

 the schedule baseline is the approved and signed version of project schedule that is incorporated
into the PM plan
 the project schedule is calendar-based taking into accounts holidays/resource
availability/vacations
o vs the time estimate (work effort/level of effort) just describes the man hours/man days
 the Schedule Data includes schedule milestones, schedule activities, activities attributes, and
documentation of all assumptions and constraints, alternative schedules and scheduling of
contingency reserves
 Slack/Float
o Slack/Float: activities that can be delayed without impacting the schedule
o Free slack/float: time an activity can be delayed without delaying the Early Start of the
successor
o Total slack/float: time an activity can be delayed from early start without delaying the
project end date (scheduling flexibility), can be negative, 0 (on the critical path) or
positive
o Project Float: without affecting another project
o Negative float: problem with schedule, need schedule rework
o Project slack/float: time the project can be delayed without delaying another project
 Early Start (ES) – earliest time to start the activity
 Late Start (LS) – latest time to start without impacting the late finish
 Early Finish (EF) – earliest time to end the activity
 Late Finish (LF) – latest time to finish without impacting successor activity
 Slack/Float = LS – ES or LF – EF
 The float is the highest single value along the critical path, NOT the sum of them

30 | P a g e
 Critical Path: the longest path that amount to shortest possible completion time (usually zero
floats, activities with mandatory dependency with finish-to-start relationship), can have more
than 1 critical paths (more risks), critical paths may change (keep an eye on near-critical paths)
o activities on the critical path are called critical activities
o Path with negative float = behind schedule, need compression to eliminate negative float
 Forward Pass: compute the early start
 Backward Pass: compute the late start
 Fast Tracking: allow overlapping of activities or activities in parallel, included risks/resource
overloading
 Crashing: shorten the activities by adding resources, may result in team burnout
 Agreements are added as an input (in PMBOK® Guide 6th Edition) as these contain details of
how the sellers/vendors will perform the project work to meet contractual commitments. Works
from external parties will have a direct impact on the project schedule.
 Agile Release Planning, also added as an input, provides a high-level summary timeline of the
release schedule (typically within 3-6 months) based on the product roadmap and the product
vision for the product releases (based on business goals, dependencies, etc.)
o determines the number of iterations or sprints required in a release
o allows the product owner and team to decide how much time needed
 Scheduling Techniques
o Critical Path Method (CPM) – compute the forward and backward pass to determine the
critical path and float
o Critical Chain Method (CCM) – deal with scarce resources and uncertainties, keep the
resources levelly loaded by chaining all activities and grouping the contingency and put at
the end as project buffer, for activities running in parallel, the contingency is called
feeding buffer (expect 50% of activities to overrun)
o The buffer is determined by assessing the number of uncertainties, human factors, etc.
 Parkinson’s Law: Work expands so as to fill the time available for its completion.
 Resource Optimization Techniques
o Resource leveling is used to adjust the variation in resource loading to stabilize the
number of resources working each time and to avoid burnout, may need to extend the
schedule in CPM
o Resource smoothing is to adjust resource requirements so as not to exceed predetermined
resource limits, but only optimized within the float boundaries
 Data Analysis Tools
o What if analysis: to address feasibility/possibility of meeting project schedule, useful in
creating contingency plan
o Monte Carlo: run thousands of times to obtain the distribution using a set of random
variables (stochastic variables), use a combination of PERT estimate and triangular
distributions as endpoint estimates to create the model to eliminate schedule risks, the
graph is an ‘S’ curve
 Network Diagram: bar charts with logical connections
 Hammock activities: higher-level summary activities between milestones
 Milestone Charts: show only major deliverables/events on the timeline
 data date (status date, as-of date): the date on which the data is recorded
 the Project Calendars identify working days

31 | P a g e
Control Schedule

 Inputs: Project Management Plan, Project Documents, Work Performance Data, OPA
 Tools & Techniques: Data Analysis, Critical Path Method, Project Management Information
System, Resource Optimization, Lead and Lags, Schedule Compression
 Outputs: Work Performance Information, Schedule Forecasts, Change Requests, Project
Management Plan Updates, Project Documents Updates

 measure result, make adjustments to the project work plan (if needed) through resource
optimization, lead and lags or schedule compression, and adjust metrics
 Data analysis includes:
o Earned value analysis
o Iteration burndown chart
o Performance reviews
o Trend analysis
o Variance analysis
o What-if scenario analysis
 Change requests generated are to be assessed in the Perform Integrated Control Process

32 | P a g e
33 | P a g e
PMP Study Notes 7 – Project Cost Management
 1 Project Cost Management
o 1.1 Plan Cost Management
o 1.2 Estimate Costs
o 1.3 Determine Budget
o 1.4 Control Costs

Project Cost Management

 important cost management/calculation terms:
o sunk cost – cost already incurred in the past and cannot be recovered, do not consider any
more
o opportunity cost – difference in value between one path vs alternative (= 100% of the
value of next best alternative)
o value analysis/ engineering – cost reduction without affecting the scope
o Benefit-Cost Analysis (BCA) / Cost-Benefit Analysis (CBA) – determine feasibility,
bigger benefit/cost ratio (BCR)
o Payback Period – the length of time to recover the investment
o Return on Investment (ROI) – the efficiency of investment = (Gain-Cost)/Cost
o Time Value of Money – Present Value (PV) = value / (1+interest rate)*year, Future Value
(FV) = value * (1+interest rate)*year
o Net Present Value (NPV) = PV of cash inflows – PV of cash outflows (cost)
o funding for the project: self-fund, funding with equity, funding with debts
o discount rate – rate used to calculate the present value of expected yearly benefits and costs

Plan Cost Management

 Inputs: Project Charter, Project Management Plan, EEF, OPA

 Tools & Techniques: Expert Judgement, Data Analysis, Meetings
 Outputs: Cost Management Plan

 The Cost Management Plan establishes

o level of accuracy and level of precision
o unit of measurement
o WBS procedure links (to control account (CA))
o control threshold
o earned value rules of performance, reporting, funding and processes
 Life cycle costing = total cost of ownership: production cost, running and maintenance cost, etc.
 Data analysis techniques include:
o alternatives analysis — strategic funding options, ways to acquire project resources

34 | P a g e
Estimate Costs

 Inputs: Project Management Plan, Project Documents, EEF, OPA

 Tools & Techniques: Expert Judgement, Analogous Estimating, Parametric Estimating, Bottom-up
Estimating, Three-point Estimating, Data Analysis, Project Management Information System,
Decision Making
 Outputs: Cost Estimates, Basis of Estimates, Project Document Updates

 look for ways to reduce cost

 ensure the subject matter experts (SME) to deliver the estimates (which is much more accurate)
 cost estimate to be based on WBS
 Cost Types
o Variable costs – costs change with the amount of work, e.g. hourly consultants
o Fixed costs – costs that are constant, e.g. equipment leases
o Direct costs – directly attributed to the project
o Indirect costs – shared costs like AC, lighting, etc.
 Data Analysis Techniques
o Alternatives analysis
o Reserve analysis
o Cost of quality – cost of conformance and non-conformance
 Cost Estimate Tools
o Analogous Estimating (Top Down Estimate) — compare to a similar project in the past
(an estimating heuristic/rule of thumb)
o Parametric Estimating — use a parameter and repetitive units of identical work
o Bottom-up Estimating — detailed estimates of each individual activity from historical
data, more accurate and time-consuming
o Three-point Estimating — taking into accounts of the pessimistic, optimistic and most
likely estimates
 Activity Cost Estimates may include indirect cost and contingency reserves
 usually to be expressed in a range of values
 Basis of Estimates – detailed analysis on how the cost estimate was derived (assumptions,
constraints, possible range (+/-15%), confidence level of final estimate)

Determine Budget

 Inputs: Project Management Plan, Project Documents, Business Documents (business case,
benefits management plan), Agreements, EEF, OPA
 Tools & Techniques: Expert Judgement, Cost Aggregation, Data Analysis, Historical
Relationships, Funding Limit Reconciliation, Financing
 Outputs: Cost Baseline, Project Funding Requirements, Project Document Updates

35 | P a g e
  Budget is more about when to spend money
 Historical Relationships – analogous/parametric estimation
 Data Analysis => Reserve Analysis – addresses Management Reserve (unknown unknowns) and
Contingency Reserve (known risks) [not included in calculation of earned value management]
 Funding Limit Reconciliation – addresses variance between funding limit (e.g. monthly or
yearly limit) and planned expenditure, may require rescheduling of work to level of the rate of
expenditure
 Value Engineering – to improve quality/shorten schedule without affecting the scope
 Project Budget = Cost baseline (the approved time-phased budget) + Management Reserve
 when mgnt reserve is used during project execution, the amount is added to the cost baseline
 S-curve: total project expenditure over project lifecycle
 Financing: acquiring funding for projects, may source from internal and/or external sources

Control Costs

 Inputs: Project Management Plan, Project Documents, Project Funding Requirements, Work
Performance Data, OPA
 Tools & Techniques: Expert Judgement, Data Analysis, To-complete Performance Index, Project
Management Information System
 Outputs: Work Performance Information, Cost Forecasts, Change Requests, Project Management
Plan Updates, Project Document Updates

 Check against the Project Funding Requirements

o controlling costs including informing stakeholders of all approved changes and their costs
o perform Control Cost more often during execution where money is spent fastest
 Data analysis techniques:
o Earned value analysis
o Variance analysis — including schedule variance (SV), cost variance (CV), schedule
performance index (SPI), and cost performance index (CPI) to check against the baseline
for any variance
o Trend analysis
o Reserve analysis
 Earned Value Calculation
o Estimate at Complete:
 new estimate required (original flawed)
 no BAC variance
 CPI will continue
 sub-standard cost/schedule will continue
o TCPI (To-complete Performance Index):
 >1 not enough funding remain (over budget)
 <1 more fund available than needed (under budget)
 Earned Value Accrual
o Discrete Efforts – describes activities that can be planned/measured for output, including
Fixed Formula (activity given a % of budget of work package at start and earn the
remaining when completed, e.g. 50/50, 20/80 or 0/100), Weighted Milestone (earn value
36 | P a g e
 for milestones of deliverables of the work package), Percentage Complete, Physical
Measurement
o Apportioned Efforts – describes work that has a direct/supporting relationship to discrete
work, e.g. testing, pm activities, calculated as % of the discrete work
o Level of Efforts (LOE) – describes activities without deliverables, e.g. troubleshooting,
assigned the EV as scheduled, without schedule variance but may have cost variance
 SPI at end of project must be 1
 SPI is NOT telling much information about whether the project is on schedule as the Critical
Path must also be investigated to get a meaningful picture

37 | P a g e
PMP Study Notes 8 – Project Quality Management
 1 Project Quality Management
o 1.1 Plan Quality Management
o 1.2 Manage Quality
o 1.3 Control Quality

Project Quality Management

 Quality: the degree to which a set of inherent characteristics fulfills requirements, decrease
rework/costs, increase productivity/stakeholder satisfaction
 everyone in the organization is responsible for the quality (project team for destined parts while
PM for project quality), the project manager is ultimately responsible for the project quality
 The project manager is required to perform continuous improvement activities (quality assurance),
verify quality before completion of deliverables (control quality)
 prevention over inspection
 continuous improvement to ensure quality (quality assurance) — Quality Management processes
are so focused on reviewing EVERY deliverable – not just the final product, but all of the
components, designs and specifications too.
 some costs of quality will be borne by the organization (organization quality policy, e.g. quality
audit, ISO accreditation)
 Quality Management Concepts
o Crosby Zero Defects: identify processes to remove defects, quality is built in to the
processes
o Juran Fitness for Use: does the product/service meet customer’s need? i) Grade, ii)
Quality conformance, iii) Reliability/maintainability, iv) Safety, v) Actual Use
o W. Edwards Deming: 85% of quality problem is managers’ responsibility, develop
“System of Profound Knowledge” [system = components working together to achieve an
aim] i) Appreciation for system, ii) Knowledge about variation (special cause vs common
cause) , iii) Theory of Knowledge (built up by prediction/observation/adjustment) , iv)
Psychology
o Six Sigma: achieve 3.4/1 mil defect level (99.999%) using DMAIC (Define, Measure,
Analyze, Implement, Control) or [Design for Six Sigma] DMADV (Define, Measure,
Analyze, Design, Validate) approach, refine the process to get rid of human error and
outside influences with precise measurements, variations are random in nature
o Just In Time: eliminate buildup of inventory
o Total Quality Management (TQM): ISO 8402 all members to center on quality to drive
customer satisfaction , refine the process of producing the product
o Kaizen 改善: implement consistent and incremental improvement, to reduce costs, cycle
time, drive customer satisfaction using PDCA (Plan Do Check Act)
o The Plan-Do-Check-Act cycle is a way of making small improvements and testing their
impact before you make a change to the process as a whole. It comes from W. Edwards
Deming’s work in process improvement, which popularized the cycle that was originally
invented by Walter Shewhart in the 1930s.
o Capability Maturity Model Integration (CMMI): improve overall software quality
(design, development and deployment)
o ISO9000: ensures the defined processes are performed in accordance to the plan

38 | P a g e
  Important Terms:
o outliers are singular measurements outside the control limits
o Grade (fit for use or not) vs Quality (conformance to stated requirements)
o Accuracy (correctness) vs Precision (consistence, how closely conforms to target,
standard deviation is a measure of precision, smaller standard deviation higher precision)
o under control: the process is predictable and repeatable

Plan Quality Management

 Inputs: Project Charter, Project Management Plan, Project Documents (assumption log,
requirements traceability matrix, risk register, stakeholder register), EEF, OPA
 Tools & Techniques: Expert Judgement, Data Gathering, Data Analysis, Decision Making, Data
Representation, Test and Inspection Planning, Meetings
 Outputs: Quality Management Plan, Quality Metrics, Project Management Plan Updates, Project
Documents Updates

 quality policy (either organizational or just for the project), methods and procedures to meet the
objectives and satisfy customer’s needs
o including identifying the quality requirements and document how to achieve
o The goal is to refine the process so that human errors and outside influences no longer
exist, and any remaining variations are completely random
 Quality Metrics: function points, MTBF (mean time between failure), MTTR (mean time to
repair)
 Data Gathering Tools:
o Benchmarking: compare to past activities/standard/competition
o Brainstorming
o Interviews
 Data Analysis tools:
o Cost-benefit Analysis: cost of implementing quality requirements against benefits
o Cost of Quality:
 Cost of Quality is the total cost of quality efforts throughout the product’s lifecycle
 cost of conformance + cost of non-conformance: cost of conformance (prevention
cost, appraisal cost) vs cost of non-conformance (failure cost [internal/external])
 lowest quality cost is prevention, highest quality cost (poor quality) is rework and
defect repair (as high as 5000 times the cost for carrying out unit testing), lost
reputation and sales, failure cost may be internal/external (found by customer)
 Warranty claims are external cost of quality — internal/external is reference to
the project (not the organization)
o Cause-and-effect / Ishikawa / Fishbone Diagram: for identifying the cause
o Flowchart: (e.g. SIPOC diagram) for identifying failing process steps and process
improvement opportunities
o Check Sheets (tally sheets): collecting data/documenting steps for defeat analysis
o Histograms: does not consider the influence of time on the variation that exits within a
distribution

39 | P a g e
 o Pareto Chart: based on 80/20 principle, a prioritization tool to identify critical issues in
descending order of frequency, sort of a histogram
o Statistical Process Control (SPC) Chart: determine if a process is stable/predictable
using statistical sampling (assessed by accuracy[conformance] and precision[standard
deviation]), identity the internally computed control limits (UCL/LCL) and specification
limits (USL/LSL) by the customer/PM
o run chart is similar to control chart, but without the control
 usually +-3sigma i.e. a range of 6 sigma
 a form of time series
 if a process is within control limit but beyond specification limit, the process is
experiencing common cause variation (random) that cannot be corrected by the
system, management help is needed (special cause can be tackled but NOT
common cause)
o Stability Analysis / Zone Test:
 rule of seven (7 consecutive on either side of the mean = out of control)
 rule of six (six consecutive with a trend = out of control)
 rule of ten (10 as a saw-tooth pattern around the mean)
 rule of one (1 point beyond control limit) [signal in the noise]
o Scatter Diagram: for trending, a form of regression analysis
 Data Representation tools:
o Flowcharts
o Logical data model
o Matrix Diagrams: House of Quality (HOQ) used in Quality Function Deployment (QFD)
(method to transform user demands [VOC] into design quality)
o Mind mapping
 Test and Inspection Planning
o used to determine how to test or inspect the product, deliverable, or service to meet the
stakeholders’ needs and expectations
 alpha/beta releases
 inspections
 field tests
 Other quality tools:
o Design of Experiments (DOE): change several factors at a time for each experiment, to
determine testing approaches and their impact on cost of quality
o Loss Function: a financial measure of the user’s dissatisfaction with product performance
o Kano Model: differentiate features as satisfy, delight or dissatisfy
o Marginal Analysis: cost-benefit analysis
o Force Field Analysis (FFA): reviews any proposed action with proactive and opposing
forces
o Process Improvement Plan: process boundaries, configuration, process metrics/efficiencies,
targets for improved performance
o Quality Checklists: checklist to verify a series of steps have been performed
o Marginal Analysis: ROI of quality measures

40 | P a g e
Manage Quality

 Inputs: Project Management Plan, Project Documents, OPA

 Tools & Techniques: Data Gathering, Data Analysis, Decision Making, Data Representation,
Audits, Design for X (DfX), Problem Solving, Quality Improvement Methods
 Outputs: Quality Report, Test and Evaluation Documents, Change Requests, Project
Management Plan Updates, Project Documents Updates

 Manage Quality is in the Executing Process Group

o ensures the quality standards are being followed, to ensure unfinished works would meet
the quality requirements
o by quality assurance department or sponsor/customer not actively involved in the project
o primarily concerned with overall process improvement for activities and processes
(rather than the deliverable)
o utilize the data collected in Control Quality Process
 Data Analysis tools:
o Alternatives analysis
o Document analysis
o Process analysis — to identify opportunities for process improvements
o Root cause analysis
 Data Representation tools:
o Affinity Diagrams: like a mind-mapping diagram, organize thoughts on how to solve
problems
o Cause and Effect Diagrams
o Flowcharts
o Histograms
o Matrix Diagrams: e.g. ‘house of quality’ in QFD
o Scatter Diagrams
 Design for X (Design for Excellence, DfX)
o a set of technical guidelines that may be applied during the design phase of a product to
optimize specific aspects of the design
o may be able to improve the final characteristics of the product (in aspects like cost
reduction, quality improvement, better performance and customer satisfaction)
 Quality Audit:
o to verify quality of processes
o to seek improvement
o identify best practices
o reduce overall cost of quality
o confirm implementation of approved changes
o need quality documentation
 Quality Review: to review the quality management plan
 change requests are mostly procedural changes
 Quality Improvement Methods are used to analyze and evaluate opportunities for improvements:
o Plan-Do-Check-Act
o Six Sigma

41 | P a g e
  Quality Reports
o can be graphical, numerical or qualitative
o to provide information to help take corrective actions to fulfil project quality expectations
o includes quality management issues escalated by the team; recommendations for process,
project and product improvements; corrective action recommendations (can be rework,
defect, bug repair, inspection, etc.), summary findings
 Test and Evaluation Documents
o used to evaluate the achievement of quality objectives
o may include checklists and detailed requirements traceability matrices

Control Quality

 Inputs: Project Management Plan, Project Documents, Approved Change Requests,

Deliverables, Work Performance Data, EEF, OPA
 Tools & Techniques: Data Gathering, Data Analysis, Inspection, Testing/product Evaluations,
Data Representation, Meetings
 Outputs: Quality Control Measurements, Verified Deliverables, Work Performance Information,
Change Requests, Project Management Plan Updates, Project Documents Updates

 verify the deliverables against customer’s specifications to ensure customer satisfaction

 validate the changes against the original approved change requests
 conditional probability (events somewhat related) vs statistical independence (events not
interrelated) vs mutual exclusivity
 statistical sampling for control quality
 variable (continuous) data: measurements, can do math on e.g. average
 attribute (discrete) data: yes/no, no.123, just an identifier, can’t do math on
 QC includes the PM process (lesson learnt, budget, scope)
 tolerance (spec limits, deliverables acceptable) vs control limits (process acceptable)
 if within control limit but outside tolerance: rework the process to give better precision
 all control and execution processes may generate lesson learned
 Data Analysis Techniques:
o Performance reviews
o Root cause analysis
 Testing/Product Evaluations
o an organized investigation to provide objective information about the quality of the
product/service in accordance with project requirements

42 | P a g e
43 | P a g e
PMP Study Notes 9 – Project Resource Management
 1 Project Resource Management
o 1.1 Plan Resource Management
 1.1.1 What is a RACI chart / RACI matrix or RACI graph?
o 1.2 Estimate Activity Resources
o 1.3 Acquire Resources
o 1.4 Develop Team
o 1.5 Manage Team
o 1.6 Control Resources (New in PMBOK® Guide 6th Edition)

Project Resource Management

Plan Resource Management

 Inputs: Project Charter, Project Management Plan, Project Documents, EEF, OPA
 Tools & Techniques: Expert Judgement, Data Representation, Organization Theory, Meetings
 Outputs: Resource Management Plan, Team Charter, Project Documents Update

 The Resource Management Plan is to organize and lead the project team as well as other resources
o include roles and responsibilities (identify resources that can take up the responsibilities) as
documented (ownership of deliverables) in RAM in the form of RACI chart (matrix) or in a
chart/text form, org charts – an organizational breakdown structure (OBS) and staffing
management plan – staff acquisition, release, resource calendar, resource histogram, training,
rewards, compliance & safety requirements
 networking is useful in understanding skills of individuals and the political and interpersonal factors within
the organization
 Data Representation techniques:
o Hierarchical-type charts
 Work breakdown structures (WBS)
 Organizational breakdown structure (OBS) — the OBS displays organizational
relationships and then uses them for assigning work to resources in a project (WBS); the
org chart also indicates the reporting structure of the project
 Resource breakdown structure (RBS)
 RACI chart
o Assignment matrix
o Text-oriented formats
 The Team Charter is the document documenting team values, agreements and operating guidelines to
create a favorable culture for the project team members.

44 | P a g e
What is a RACI chart / RACI matrix or RACI graph?

 The four letters of RACI stands for:

o Responsible – Which project member is responsible for carrying out the execution of the task?
o Accountable – The member who is held accountable for the tasks and is given the authority to
make decisions? In general, there should only be 1 member accountable for the project task.
o Consulted – The stakeholders that should be consulted for the work or be included in the decision
making (to be engaged in two-way communication).
o Informed – Who should be informed of the decisions or progress of the work by means of email
updates, progress reports, etc. (one-way communication)?
 The RACI chart is a tool for tracking the tools for tracking the roles and responsibilities of project members
for specific project tasks during project execution.
 While there can be an unlimited number of members responsible for the execution of a project task,
there should only be one member accountable for the same task. Fixing the accountability to a single
person will allow the project team members to know which person to go to should they need to know the
progress or details of the task. This can also avoid the false assumption that the other person (if there are
more than one accountable) accountable for the task has taken care of the task but in the end, no one has
looked after the task.
 The member responsible and accountable can be the same for small tasks.
 Below is an example of the RACI chart for a website project:
Project Manager Graphic Designer Copywriter Coder

Logo Design A R C

Web Copy C AR

Web Coding A C R

Estimate Activity Resources

 Inputs: Project Management Plan, Project Documents, EEF, OPA

 Tools & Techniques: Expert Judgement, Bottom-up Estimating, Analogous Estimating, Parametric
Estimating, Data Analysis, Project Management Information System, Meetings
 Outputs: Resource Requirements, Basics of Estimates, Resource Breakdown Structure (RBS), Project
Documents Update

 as a planning process
 closely related to Estimate Cost Process (in Project Cost Management knowledge area)
 Data Analysis includes:
o Various levels of resource capability or skills
o Different sizes or types of machines
o Different tools (manual versus automated)
o Make-rent-or-buy decisions
 resource calendar spells out the availability of resources (internal/external) during the project period
45 | P a g e
  matches human resources to activities (as human resources will affect duration).
 effort (man day, work week…) vs duration vs time lapsed (total time needed, including holidays, time off).
 “alternative analysis” includes make-or-buy decisions, different tools, different skills, etc.
 Resource Requirements details the types and amounts of resources required for each activity in a work
package.
 The basis of estimates includes methods, assumptions, constraints, the range of estimates, confidence
levels, risks, etc.
 Resource Breakdown Structure (RBS) is a graphical representation of the hierarchical structure of
resources by category and resource type where each level is broken down until it is small enough to be
used in conjunction with the work breakdown structure (WBS). The goal is to have all resources on a
project, NOT ONLY human resources, linked to specific activities in the WBS in order to plan, monitor, and
control the project work. Being able to link resources back to the WBS is essential in ensuring that each
activity will be successfully performed.

Acquire Resources

 Inputs: Project Management Plan, Project Documents, EEF, OPA

 Tools & Techniques: Decision Making, Interpersonal and Team Skills, Pre-assignment, Virtual Teams
 Outputs: Physical Resource Assignments, Project Team Assignments, Resource Calendars, Change
Requests, Project Management Plan Updates, Project Documents Updates, EEF Updates, OPA Updates

 to acquire team members/facilities/equipment/materials and other resources necessary to complete the

project work
 pre-assignment is the selection of certain team members/resources in advance
 halo effect: a cognitive bias (if he is good at one thing, he will be good at everything)
 Physical Resource Assignments
o documents the physical resource assignments including material, equipment, supplies, locations,
and other physical resources that will be used during the project
 Project Team Assignments
o documents team assignments including who the team members are and their roles and
responsibilities
 Resource Calendars
o identifies the working days/shifts/holidays for each resource included in the assignment

Develop Team

 Inputs: Project Management Plan, Project Documents, EEF, OPA

 Tools & Techniques: Colocation, Virtual Teams, Communication Technology, Interpersonal and Team Skills,
Recognition and Rewards, Training, Individual and Team Assessments, Meetings
 Outputs: Team Performance Assessments, Change Requests, Project Management Plan Updates, Project
Documents Updates, EEF Updates, OPA Updates

46 | P a g e
 enhancing and improving overall team performance
 offer feedback, support, engage team members, manage conflicts, facilitate cooperation
 Colocation is considered the most effective and productive, should be arranged if allowed
 training cost can be set within the project budget or supported by the organization
 Communication Technology includes:
o Shared portal
o Video conferencing
o Audio conferencing
o Email/chat
 Individual and Team Assessment includes:
o Attitudinal surveys
o Specific assessments
o Structured interviews
o Ability tests
o Focus groups
 PM Authority: legitimate (assigned in project charter), reward, penalty, expert (need to be earned),
referent (charisma and likeable, with people with higher power), representative (elected as
representative)
o Expert > Reward are best forms of power. Penalty is worst.
 Tuckman Model: Forming – Storming – Norming – Performing – Adjourning
 the cultural difference should be considered when determining award and recognition
 recognition should focus on the win-win reward for the team (NOT competitive-based)
 team building is important throughout the whole project period
 Motivational Theories
o Maslow’s Hierarchy of Needs – personal needs (Physiological > Security > Social > Esteem > Self
Actualization)
o Herzberg’s Hygiene Theory – satisfaction (motivators) vs dissatisfaction (hygiene factors to avoid
dissatisfaction but do not provide satisfaction, also called KITA factors e.g.
incentives/punishments), hygiene factors include good working conditions, a satisfying personal
life, and good relations with the boss and coworkers
o Expectancy Theory – Expectancy (extra work will be rewarded) Instrumentality (good results will
be rewarded) Valence (the individual’s expected reward), for a person to be motivated,
efforts/performance/outcome must be matched – will only work hard for achievable goals
o Achievement Theory – three motivation needs: achievement (nAch), power (nPow), affiliation
(nAff), best is a balanced style for the PM
o Contingency Theory – task-oriented/relationship-oriented with stress level (high stress -> task-
oriented better)
 Leadership Theory
o including analytical (with expertise), autocratic (with power), bureaucratic, charismatic,
consultative, driver (micromanagement), influencing, laissez-faire (stay out)
o Theory X – assumes employees are lazy and avoid work, need incentive/threats/close supervising
o Theory Y – assumes employees may be ambitious and self-motivated, will perform given the right
conditions
o Theory Z – (Japanese) increasing loyalty by providing job for life with focus on well-being of
employee (on and off job), produces high productivity and morale
o Situational Continuum Leadership – directing/telling > coaching/selling (manager define the
work) > supporting/participating (subordinate define the work) > delegating according to
maturity/capability of the subordinate
 Team Performance Assessments: assess team performance as a whole vs project performance appraisals:
individual performance

47 | P a g e
Manage Team

 Inputs: Project Management Plan, Project Documents, Work Performance Reports, Team Performance
Assessments, EEF, OPA
 Tools & Techniques: Interpersonal and Team Skills, Project Management Information System
 Outputs: Change Requests, Project Management Plan Updates, Project Documents Updates, EEF Updates

 in the executing process group

 track team member performance, provide feedback, resolve issues and manage team changes
 when managed properly, differences of opinion can lead to increased creativity and better decision
making
 Project Documents Input
o issue log is fed from Manage Stakeholder Engagement – used to understand who is responsible
for resolving specific issues
o Lessons learned register
o Project team assignments
o Team charter
 conflicts: schedule, project priority, resources, technical opinions, administrative overhead (too much
administration work), cost, personality
 Interpersonal and Team Skills
o conflict management: conflicts force a search for alternatives, need openness, not personal,
focus on present and future
o conflict resolution
 collaborate/problem solve[confrontation of problem] (best)
 compromise/reconcile (give-and-take, temporary/partially resolve)
 force/direct (worst/short-lived)
 smooth/accommodate (emphasis common grounds and avoid/touch lightly the
disagreements for harmony/relationship)
 withdraw/avoid (other leads to lose-lose)
o compromise is lose-lose
o Forcing would only provide a temporary solution
o Award decisions are made during the process of project performance appraisals
o Decision making
o Emotional intelligence
o Influencing
o Leadership
 monitoring and controlling of the performance of the staff assigned is typically performed by functional
managers/HR for functional org

48 | P a g e
Control Resources (New in PMBOK® Guide 6th Edition)

 Inputs: Project Management Plan, Project Documents, Work Performance Reports, Agreements, EEF
 Tools & Techniques: Data Analysis, Problem Solving, Interpersonal and Team Skills, Project Management
Information System
 Outputs: Work Performance Information, Change Requests, Project Management Plan Updates, Project
Documents Updates

 in the monitoring and controlling process group

 ensure that the physical resources assigned to the project are available as planned
 monitor the planned versus actual utilization of resources and take corrective action with changes
requests (if needed)
 Data Analysis
o Alternatives analysis
o Cost-benefit analysis
o Performance reviews
o Trend analysis
 Problem-solving steps:
1. Identify the problem
2. Define the problem
3. Investigate
4. Analyze
5. Solve
6. Check the solution

49 | P a g e
50 | P a g e
PMP Study Notes 10 – Project Communications
Management
 1 Project Communications Management
 2 Plan Communications Management
o 2.1 Manage Communications
o 2.2 Monitor Communications

Project Communications Management

 assure the timely collection, generation, distribution, storage, retrieval and ultimate disposition of
project information
 this Knowledge Area is very important to the ultimate success of the project
 message transmission: 7% in word, 38% in vocal pitch, 55% in body language (according to
Albert Mehrabian)
 must not delay in communicating good and even bad news
 the sender has the responsibility to ensure the receiver correctly understand the message
 if part of the project is procured, more formal written communication will be expected

Plan Communications Management

 Inputs: Project Charter, Project Management Plan, Project Documents, EEF, OPA
 Tools & Techniques: Expert Judgement, Communication Requirements Analysis, Communication
Technology, Communication Models, Interpersonal and Team Skills, Data Representation,
Meetings
 Outputs: Communications Management Plan, Project Management Plan Update, Project
Documents Update

 identify the needs for communication with stakeholders of the project

o including the who, what, when (frequency), why, where and how of communications needs
and the persons responsible
o may need to limit who can communicate with whom and who will receive what
information
o time and budget for the resources, escalation path, flow charts, constraints, guideline and
templates
 efficient communication: only the required messages
 effective communication: right timing, right format, right medium
 Communication Methods
o interactive (multidirectional communication, most effective)
o push (active, messages sent without validation of receipt)
o pull (passive, access directly by stakeholders)
 low context vs high context (Japanese — more polite)

51 | P a g e
  (Shannon-Weaver model) Sender-Receiver Model:
o encoded the idea
o message and feedback
o medium
o noise level
o decoded idea.
The sender to ensure info is clear, complete and the recipient correct understands. The
recipient to ensure the complete message is received (to acknowledge) and provide
feedback/response.
 Effective Listening:
o feedback
o active listening
o paralingual (voice expression, nonverbal elements)
 Communication channels: N (N -1) / 2 // N is the number of team members
 meetings should facilitate problem-solving
 As a norm, PM spends 90% of their time on COMMUNICATION activities, 50% of the time is
spent on communicating with the team

Manage Communications

 Inputs: Project Management Plan, Project Documents, Work Performance Reports, EEF, OPA
 Tools & Techniques: Communication Technology, Communication Models, Communication
Skills, Project Management Information System, Project Reporting, Interpersonal and Team Skills,
Data Representation, Meetings
 Outputs: Project Communications, Project Management Plan Update, Project Documents Update,
OPA Update

 create, collect, distribute, store, retrieve and dispose of project information according to the
Communications Management Plan
o ensures good communication, noises managed, stakeholders may feedback on how to
improve
 Communication Barriers vs Communication Enhancers
 55% message thru body language, 38% thru paralingual, 7% thru words used
 Types of Communications: Formal Written, Formal Verbal, Information Written, Informal Verbal
 Interpersonal and Team Skills include:
o Active listening
o Conflict management
o Cultural awareness
o Meeting management
o Networking
o Political awareness
 Project Reporting: status, progress, variance, trend, earned value reports and forecasts, summary
of changes, risks and issues
 PM Plan Update to show the latest performance (against Performance Measurement Baseline)
 Feedback from stakeholders are to be stored in OPA
52 | P a g e
Monitor Communications

 Inputs: Project Management Plan, Project Documents, Work Performance Data, EEF, OPA
 Tools & Techniques: Expert Judgement, Project Management Information System, Data Analysis,
Interpersonal and Team Skills, Meetings
 Outputs: Work Performance Information, Change Requests, Project Management Plan Update,
Project Documents Update

 to ensure optimal information flow for effective stakeholder expectation management

 issue log is to document the issues and monitor its resolutions (by the person responsible)
 Data Analysis tool includes stakeholder engagement assessment matrix — to assess the current
situation of communication effectiveness through the review of changes between the desired and
current engagement and adjusting communications (alternative ways/frequency/methods) as
necessary

53 | P a g e
PMP Study Notes 11 – Project Risk Management
 1 Project Risk Management
o 1.1 Plan Risk Management
o 1.2 Identify Risks
o 1.3 Perform Qualitative Risk Analysis
o 1.4 Perform Quantitative Risk Analysis
o 1.5 Plan Risk Responses
o 1.6 Implement Risk Responses (new in PMBOK® Guide 6th Edition)
o 1.7 Control Risks

Project Risk Management

 Project Risk Management is involved in risk identification, management and response strategy
impacts every area of the project management lifecycle
o risk = uncertainty
o risk management= increase the probability of project success by minimizing/eliminating
negative risks (threats) and increasing positive events (opportunities)
o everyone is responsible for identifying risks for the project
 risk has one or more causes and has one or more impacts
 risk attitudes (EEF): risk appetite (willingness to take risks for rewards), tolerance for risk (risk
tolerant or risk-averse), risk threshold (level beyond which the organization refuses to tolerate
risks and may change its response)
 pure (insurable) risk vs business risk (can be +ve or -ve)
 known risks that cannot be dealt with proactively (active acceptance) should be assigned a
contingency reserve or if the known risks cannot be analyzed, just wait for its happening and
implement the workaround (which is considered passive acceptance)

Plan Risk Management

 Inputs: Project Charter, Project Management Plan, Project Documents, EEF, OPA
 Tools & Techniques: Expert Judgement, Data Analysis, Meetings
 Outputs: Risk Management Plan

 The Plan Risk Management process is involved in defining and providing resources and time to
perform risk management.
o including methodology, roles and responsibilities, budget, timing (when and how often),
risk categories (e.g. risk breakdown structure RBS), definitions, stakeholder tolerances (an
EEF), reporting and tracking
 performed at project initiation and early in the Planning process
 failure to address risks early on can ultimately be more costly later on in the project
 Data Analysis techniques include stakeholder risk profile analysis (using the stakeholder register),
strategic risk scoring sheets, etc.

54 | P a g e
  a risk breakdown structure (RBS) (included in the PM Plan) – risks grouped by categories and
occurring areas
 key risk categories:
o scope creep
o inherent schedule flaws
o employee turnover
o specification breakdown (conflicts in deliverable specifications)
o poor productivity

Identify Risks

 Inputs: Project Management Plan, Project Documents, Agreements, Procurement Documentation,

EEF, OPA
 Tools & Techniques: Expert Judgement, Data Gathering, Data Analysis, Interpersonal and Team
Skills, Prompt Lists, Meetings
 Outputs: Risk Register, Risk Report, Project Document Updates

 to find out and document all risks affecting the project from all aspects of the project, including:
o agreements/contracts within/outside of the organization
o procurements
o requirements, schedule, cost, resource, quality, scope, etc. from the project management
plan
 Data Gathering Techniques: brainstorming, checklists, interviews, Delphi technique [a panel of
independent experts, maintain anonymity, use questionnaire, encourage open critique],
 Data Analysis Techniques:
o root cause analysis [performed after an event to gain understanding to prevent similar
events from occurring], SWOT analysis, assumption and constraint analysis
 root cause analysis: safety-based (prevent accidents), production-based, process-
based (include business process), failure-based, systems-based (all above)
 root cause analysis tools: FMEA, Pareto Analysis, Bayesian Inference (conditional
probability), Ishikawa Diagrams, Kepner-Tregoe
o Monte Carlo analysis can identify points of schedule risks
 Prompt List
o The prompt list (newly added in PMBOK® Guide 6th Edition) is a predetermined list of
risk categories that are at the lowest level of the risk breakdown structure which is used to
assist in identifying risks of the projects
o examples of prompt lists:
 PESTLE (political, economic, social, technological, legal, environmental)
 TECOP (technical, environmental, commercial, operations, political)
 VUCA (volatility, uncertainty, complexity, ambiguity)
 Risk Register (typically not including the risk reserve)
o The Risk Register may include a risk statement
o any risk with a probability of >70% is an issue (to be dealt with proactively and recorded
in the issue log)

55 | P a g e
  The Risk Report (new in PMBOK® Guide 6th Edition) is a document used to present
information (e.g. no. of identified threats and opportunities, distribution of risks across risk
categories, metrics and trends) on overall project risk. It also includes summary information on
individual project risks.

Perform Qualitative Risk Analysis

 Inputs: Project Management Plan, Project Documents, Agreements, Procurement Documentation,

EEF, OPA
 Tools & Techniques: Expert Judgement, Data Gathering, Data Analysis, Interpersonal and Team
Skills, Risk Categorization, Data Representation, Meetings
 Outputs: Project Document Updates (e.g. Risk Register)

 prioritizing risks for further analysis/action and identify high priority risks
o risks requiring near-term responses are more urgent to address
o need to identify bias and correct it (e.g. risk attitude of the stakeholders)
 Data Analysis Techniques include:
o Risk data quality assessment
o Risk probability and impact assessment
o Assessment of other risk parameters (e.g. urgency, proximity, dormancy, manageability,
controllability, detectability, connectivity, strategic impact, propinquity)
 Data Representation Tools:
o qualitative risk assessment matrix (format described in the Risk Management Plan)
o hierarchical-type charts
 the risk register is updated along the following processes: Perform Qualitative Risk Analysis,
Perform Quantitative Analysis, Plan Risk Responses and Monitor & Control Risks

Perform Quantitative Risk Analysis

 Inputs: Project Management Plan, Project Documents, Agreements, Procurement Documentation,

EEF, OPA
 Tools & Techniques: Expert Judgement, Data Gathering, Interpersonal and Team Skills,
Representation of Uncertainty, Data Analysis
 Outputs: Project Document Updates

 the cost, schedule and risk mgnt plan contains guidelines on how to quantitatively analyze risks
o involves mathematical modelling for forecasts and trend analysis
 Representation of Uncertainty (probability distribution) reflects the risks as a probability
distribution, which can be in the following distribution types:
o Triangular
o Normal (bell-shaped curve)
56 | P a g e
 o Lognormal
o Beta
o Uniform
o Discrete
 Data Analysis Techniques:
o sensitivity analysis (using the tornado diagram as presentation) for determining the risks
that have the most impact on the project
o Failure Modes Effects Analysis (FMEA)
o FMEA for manufactured product or where risk may be undetectable, Risk Priority Number
(RPN) = severity (1-10) x occurrence ([0.07%] 1-10 [20%]) X detectability (1-10
[undetectable]), also a non-proprietary approach for risk management
o Expected Value / Expected Monetary Value (EMV), probability x impact (cost/effort
lost), opportunities (+ve values), threats (-ve values)
o Simulations/Monte Carlo Analysis – by running simulations many times over in order
to calculate those same probabilities heuristically just like actually playing and recording
your results in a real casino situation, ‘S’ curve (cumulative distribution) will result, may
use PERT/triangular distribution to model data, may use thousands of data points (a
random variable), for budget/schedule analysis
o Decision Tree Analysis – another form of EMV, branching: decision squares (decision
branch – options), circles (uncertainty branch – possible outcomes)
o Influence Diagram – graphical representations of situations showing causal influences,
time ordering of events, and other relationships among variables and outcomes

Plan Risk Responses

 Inputs: Project Management Plan, Project Documents, Agreements, Procurement Documentation,

EEF, OPA
 Tools & Techniques: Expert Judgement, Data Gathering, Interpersonal and Team Skills, Strategies
for Threats, Strategies for Opportunities, Contingent Response Strategies, Strategies for
Overall Project Risks, Data Analysis, Decision Making
 Outputs: Change Requests, Project Management Plan Updates, Project Document Updates

 plan response to enhance opportunities and reduce threats

 each risk is owned by a responsible person
 the watch list is the list of low priority risks items in the risk register
 a fallback plan will be used if 1) risk response not effective, 2) accepted risk occurs
 Contingency Plan (contingent response strategies) (plan A) are developed for specific risk
(when you have accepted a risk) with certain triggers vs Fallback Plan (plan B)
 Negative Risk Strategies:
o eliminate/avoid (not to use, extend the schedule)
o transfer (outsource, warranty, insurance)
o mitigate (reduce the risk of more testing/precautionary actions/redundancy)
o accept (passive – do nothing or active – contingency)
o escalate (escalates a risk to the appropriate party — can be deleted from the risk register or
retain in the risk register with a remark)
57 | P a g e
  Positive Risk Strategies:
o exploit (ensure opportunity by using internal resources e.g. reduce cost/use of top
talents/new tech)
o share (contractor with specialized skills, joint venture)
o enhance (increase likelihood / impact e.g. fast-tracking, add resources etc.)
o accept
 passive risk acceptance to be dealt with when the risk occurs
 Strategies for Overall Project Risk
o the PM needs to address the overall project risks with one of the following strategies:
 Avoid/Exploit
 Transfer/Share
 Mitigate/Enhance
 Accept
 Residual Risks – risks remain after the risk response strategy was implemented, may be identified
in the planning process (may subject to contingency/fallback planning) They don’t need any
further analysis because you have already planned the complete response strategy you know in
dealing with the risk that came before them.
 Secondary Risks – risk arises when the risk response strategy was implemented
 Reserve Types
o Contingency Reserve: known unknowns (determined risk), part of cost baseline
o Management Reserve: unknown unknowns (discovery risk), part of project budget
 The Risk Register is now completed with: risks and descriptions, triggers, response strategy,
persons responsible, results from qualitative and quantitative analysis, residual and secondary risks,
contingency and fallback, risk budget/time

Implement Risk Responses (new in PMBOK® Guide 6th Edition)

 Inputs: Project Management Plan, Project Documents, OPA

 Tools & Techniques: Expert Judgement, Interpersonal and Team Skills, Project Management
Information System
 Outputs: Change Requests, Project Document Updates

 in the Executing process group

 implementing risk responses is the responsibilities of the risk owners
 to ensure that agreed upon risk responses (as from the Plan Risk Response process) are executed
as planned to
o address overall project risk exposure
o minimize individual project threats
o maximize individual project opportunities
 the Project Management Information System provides the information to allow agreed-upon risk
response plans and associated activities to be executed alongside other project activities

58 | P a g e
Control Risks

 Inputs: Project Management Plan, Project Documents, Agreements, Work Performance Data,
Work Performance Reports
 Tools & Techniques: Data Analysis, Audits, Meetings
 Outputs: Work Performance Information, Change Requests, Project Management Plan Updates,
Project Document Updates, OPA Updates

 when all the above risk planning processes have been performed with due diligence, the project is
said to have a low-risk profile
 responsibilities include:
o to check if assumptions are still valid, procedures are being followed and any deviance
o to identify new risks and evaluate effectiveness of risk response plan
o any need to adjust contingency and management reserves
o to re-assess the individual risk response strategies to see if they are effective
 risk audits deal with the effectiveness of risk response and the risk management process
o risk audits are usually performed by experts outside project team for the whole risk
management process
 Data Analysis Techniques:
o reserve analysis – apply only to the specific risks of the project for which they were set
aside
o technical performance analysis
 workaround: when no contingency plan exists, executed on-the-fly to address unplanned events
– still need to pass through normal change control if change requests are needed
o determine the workaround is performed in control risks

59 | P a g e
60 | P a g e
PMP Study Notes 12 – Project Procurement
Management
 1 Project Procurement Management
 2 Plan Procurement Management
o 2.1 Conduct Procurements
o 2.2 Control Procurements

Project Procurement Management

 sellers are external to the project team
 need to go through all 4 processes for each and every procurement
 Contract Elements:
o offer (seller offer buyer)
o acceptance (buyer criteria)
o capacity (physical/financial capabilities)
o consideration (seller receive)
o legal purpose (must be legal under law)
 PM needs to understand terms and conditions, identify risks, include procurement schedule and
involve in negotiations
 Centralized contracting vs Decentralized contracting
 Procurement Categories:
o major complexity (high risk)
o minor complexity (low risk, expensive)
o routine purchase (Commercial Off the Shelf Products COTS)
o goods and services (to perform part of our product)
 Suppliers can be:
o sole source
o single source (preferred, for building a long-term relationship)
o oligopoly (very few sellers)
 a contract is not required to be written, it can be verbal or handshake, for internal projects, a
formal contract is best

Plan Procurement Management

 Inputs: Project Charter, Business Documents, Project Mgnt Plan, Project Documents, EEF, OPA
 Tools & Techniques: Expert Judgement, Data Gathering (e.g. Market Research), Data Analysis,
Source Selection Analysis, Meetings
 Outputs: Procurement Management Plan, Procurement Strategy, Bid Documents, Procurement
Statement of Work, Source Selection Criteria, Make-or-buy Decisions, Independent Cost
Estimates (inside or outside the organization), Change Requests, Project Documents Update,
OPA Updates

61 | P a g e
 identify explicitly what is needed
 identify possible sellers and pre-meeting with them
 make-or-buy analysis (determine whether to obtain products/services outside of the
organization) is a compulsory process, needs to take risks into considerations
o carefully written terms and conditions can transfer/share risks
o teaming agreements or joint ventures
 Procurement Documents:
o request for proposal (RFP)
o invitation for bid (IFB)
o request for quote (RFQ)
o request for information (RFI)
o tender notice
o invitation for negotiation
o seller initial response
 The procurement management plan specifies how a project will acquire goods/services from
outside, includes contract type, risk management, constraints and assumptions, insurance
requirements, form and format, pre-qualified sellers, metrics used, etc.
 Data Analysis Techniques:
o Return on investment (ROI)
o Internal rate of return (IRR)
o Discounted cash flow
o Net present value (NPV)
o Benefit/cost analysis (BCA)
 target cost = total cost = estimated cost, total price = total cost + total profit
 Point of Total Assumption – (in fixed-price (incentive fee) contracts) in budget overrun, the
point at which the seller assumes all additional costs for delivering the product/service
o PTA = (Ceiling Price – Total Price) / Buyer’s Share Ratio + Target Cost
o PTA = Target Cost + (Ceiling Price – Target Price) / % Share of Cost Overrun
 Procurement Statement of Work (SOW) is a legal document subject to legal reviews, legal advice
should be sought throughout the whole procurement process, can be developed by the seller or
buyer and must be detailed enough to allow the potential sellers to decide whether they want/are
qualified (at a minimum) to pursue the work
o performance (describe what can be accomplished)
o functional (convey the end purpose or result)
o design (convey precisely what are to be done),
 Evaluation Criteria: risk, understanding of need, life-cycle cost, technical capability,
management approach, technical approach
 Procurement Strategy (new in PMBOK® Guide 6th Edition)
o the procurement strategy determines the project delivery method:
 with/without subtracting, joint venture, representative, etc.
 turnkey, design and build (DB), build own operate transfer (BOOT), etc.
o contract payment types:
 Firm Fixed Price (FFP) – the price is fixed, specifications are well known, risk on
the seller
 Fixed Price Incentive Fee (FPIF) – incentives for faster/better than contracted
 Fixed Price with Economic Adjustment / Economic Price Adjustment (FPEA / FP-
EPA) – inflation are taken into account
 Purchase Order (PO) – for off-the-shelf goods/services with published rates

62 | P a g e
  Cost Reimbursable (CR) / Cost Plus – buying the expertise (not the products),
outcome is not clear, risk on the buyer, little incentive to control costs on buyer,
need invoice audits
 Cost Plus Fixed Fee (CPFF)
 Cost Plus Incentive Fee (CPIF) – incentive for performance, sharing of
unused money if under/over contracted amount
 Cost Plus Award Fee (CPAF) – award to be given based on agreed criteria,
solely decided by the customer on the degree of satisfaction
 Cost Plus Percentage of Costs (CPPC) – illegal for contracts with US
Government
 Cost Contract – no profit, for NGO
 Best Efforts – obligates the seller to utilize best attempts, high uncertainty in
meeting the goal
 Time and Materials (T&M) – (hybrid type) when scope is not known, need
constant monitoring to control schedule and cost, simple, for short duration, good
for proof-of-concept type projects
o procurement types
 Bid Documents
o Request for Proposal (RFP) – cost reimbursable contract, functional/performance SOW
o Invitation for Bid (IFB) / Request for Bid (RFB) – fixed-price contract, design SOW
o Request for Quote (RFP) – time and material, any type of SOW
 Contractual Terms
o Cancellation for Convenience – buyer can cancel and pay up to the point
o Cancellation for Cause – default by either party, may result in legal actions
o Escrow – survivability of seller in doubt, put the product in escrow (esp. if seller does not
give up intellectual properties)
o Force Majeure – standard disclaimer refers to ‘Acts of God’
o Indemnification / Liability – responsible party
o LOI Letter of Intent – not legally binding
o Privity – the contractor may use sub-contractor, no direct contractual relationship with
buyer
o Retainage – amount to be withheld to ensure delivery
o Risk of Loss – how the risk is shoulder by the parties
o Time is of the Essence – delay in delivery will cause cardinal breach of contract
o Work Made for Hire – all work owned by the buyer

Conduct Procurements

 Inputs: Project Management Plan, Project Documents, Agreements, Procurement Documentation,

Seller Proposals, EEF, OPA
 Tools & Techniques: Expert Judgement, Advertising, Bidder Conferences, Data Analysis,
Interpersonal and Team Skills
 Outputs: Selected Sellers, Agreements, Change Requests, Project Management Plan Updates,
Project Documents Update, OPA Updates

63 | P a g e
  identify the sellers and award the contracts
 PM may not be the lead negotiator on procurement but may be present to assist
o may need senior management approval before awarding the contracts
 bidder’s conference is a Q&A session with bidders, all bidders receive the same information
(bidder are careful not to expose their technical approach during the session => may not have
many questions)
 remember NOT to have secret meetings or communications with individual vendors
 review seller proposals: weighting systems, independent estimates, screening systems (screen out
non-qualified vendors), seller rating systems (for past performance), expert judgement
 Data Analysis includes ensuring that proposal is full and complete
 Contract Negotiations and Tactics
o Fait Accompli – not negotiable terms
o Deadline – deadline for deliverables
o Good Guy/ Bad Guy – one friendly, one aggressive
o Missing Man – decision maker is missing
o Limited Authority – not given authority
o Fair and Reasonable – what is fair?
o Unreasonable – making unreasonable demands
o Delay – esp in critical moments
o Attack – force compliance
 The agreement is legally binding and should include (PM should NOT attempt to write the
agreement):
o statement of work, schedule baseline, performance reporting, the period of performance,
roles and responsibilities, warranty, payment terms, fees and retainers, incentives, liability,
penalties, etc.

Control Procurements

 Inputs: Project Management Plan, Project Documents, Agreements, Procurement Documentation,

Approved Change Requests, Work Performance Data, EEF, OPA
 Tools & Techniques: Expert Judgement, Claims Administration, Data Analysis, Inspection,
Audits
 Outputs: Closed Procurements, Work Performance Information, Procurement Documentation
Updates, Change Requests, Project Mgnt Plan Updates, Project Documents Update, OPA Updates

 would be performed by both seller and buyer

 manage procurement relationships, monitor contract performance, make change and corrections
 Data Analysis Techniques:
o Performance reviews
o Earned value analysis (EVA)
o Trend analysis
 the procurement administrator may be external to the project team
o to close a procurement, the project management team should check and approve all
deliverables and a written notice be sent to the seller (closed procurement)
o may identify early signs and capture details for pre-mature termination of a contract

64 | P a g e
 For Fixed Price contracts, look out for Bait and Switch (replace with cheaper materials), look out
for excessive change requests
 For Cost Reimbursable contracts, audit all invoices, look out for additional charges, tie payment
to milestones, make sure people with the required skill sets are doing the job
 For Time and Materials contracts, ensure hours are not padded, follow the milestone dates
 the claims administration process deals with changes/disputes, disputes is best to be settled
through negotiation > ADR
 may need Alternative Dispute Resolution (ADR) by 3rd parties in case disputes cannot be settled
 OPA may include the seller’s performance

65 | P a g e
PMP Study Notes 13 – Project Stakeholder Management
 1 Project Stakeholder Management
o 1.1 Identify Stakeholders
o 1.2 Plan Stakeholder Engagement
o 1.3 Manage Stakeholder Engagement
o 1.4 Monitor Stakeholder Engagement

Project Stakeholder Management

 stakeholders are groups/individuals who may affect/be affected by the project
 identify stakeholders is a continual process throughout the project lifecycle as some stakeholders
may become irrelevant while new stakeholders may be identified as the project evolves
 the Project Manager is responsible for the engaging and managing the various project stakeholders
in a project.
o identify stakeholders, communicate and engage them, manage expectations and focus on
satisfaction
o stakeholder satisfaction is a key project objective

Identify Stakeholders

 Inputs: Project Charter, Business Documents, Project Management Plan, Project Documents,
Agreements, EEF, OPA
 Tools & Techniques: Expert Judgement, Data Gathering, Data Analysis, Data Representation,
Meetings
 Outputs: Stakeholder Register, Change Requests, Project Management Plan Update, Project
Documents Update

 identify stakeholders and document the importance/influence (=active involvement)

/impact/interest/involvement of stakeholders/groups of stakeholders
 stakeholders from procurement process and operation process needed to be included
o agreements are used for determining external stakeholders such as the seller
 Data Gathering Tools:
o Questionnaires and surveys
o Brainstorming
 Data Analysis Techniques:
o stakeholder analysis techniques
 Interest, rights (legal or moral rights), power/interest, power/influence or
impact/influence grid, salience model, prioritization, etc.
 Data Representation Tools:
o Power/interest grid, power influence grid or impact/influence grid (3 ‘I’s: importance,
interest, influence)
 determine the stakeholders’ hot buttons (what response in specific situations) and develop support
strategies
66 | P a g e
  stakeholders have the greatest influence in the initial stage of the project
 stakeholder analysis matrix is part of the stakeholder management strategy (output of Identify
Stakeholders Process)
 Salience Model: describing stakeholders based on the power (influence), urgency and
legitimacy
 document only influential stakeholders if there is a large number of stakeholders
 document the impact using a power/influence grid, power/interest grid, influence/impact grid,
salience model

Plan Stakeholder Engagement

 Inputs: Project Charter, Project Management Plan, Project Documents, Agreements, EEF, OPA
 Tools & Techniques: Expert Judgement, Data Gathering, Data Analysis, Decision Making, Data
Representation, Meetings
 Outputs: Stakeholder Engagement Plan

 strategies to engage stakeholders throughout the project lifecycle

 Stakeholder Engagement Plan contains: current/desired engagement levels, scope and impact to
stakeholders, interrelationships, communication requirements and forms, how to update the plan
o The distribution of this plan requires precautions as the engagement level of stakeholders is
a very sensitive information
 Data Analysis Tools:
o Assumptions and constraint analysis
o Mind mapping
o Root cause analysis
o Stakeholder Engagement Assessment Matrix: (C-current level, D-desired level)
o SWOT analysis
 Engagement Level
o Unaware
o Resistant: resistant to change
o Neutral
o Supportive: supportive of change
o Leading: actively engaged in project success

Manage Stakeholder Engagement

 Inputs: Project Management Plan, Project Documents, Agreements, EEF, OPA

 Tools & Techniques: Expert Judgement, Communication Skills, Interpersonal and Team Skills,
Ground Rules, Meetings
 Outputs: Change Requests, Project Management Plan Update, Project Documents Update

67 | P a g e
  ultimate aim is to increase support and minimize resistance from stakeholders by addressing
issues with a view to increasing the success of the project
o communicate & work with stakeholders to meet their needs/expectations & address issues
o build trust and resolve conflicts, negotiation skills, communication skills
o need to communicate bad news/issues in a timely manner (not to hide, not to delay)
 the communication requirements of individual stakeholder are recorded in the Project
Communication Plan
 PM may call upon the sponsor for assistance
 Ground rules are created to set the expected behavior of project team members and other
stakeholders (for stakeholder engagement)
 the Issue Log (Action Item Log): to identify issues/define impacts, owner (most important
element) and priority/with the due date

Monitor Stakeholder Engagement

 Inputs: Project Management Plan, Project Documents, Work Performance Data, EEF, OPA
 Tools & Techniques: Data Analysis, Decision Making, Data Representation, Communication
Skills, Interpersonal and Team Skills, Meetings
 Outputs: Work Performance Information, Change Requests, Project Management Plan Update,
Project Documents Update

 monitor overall stakeholder relationships and adjusting strategies to achieve the desired level of
stakeholder engagement
 Decision-Making Tools:
o Multi-criteria decision analysis
o Voting

68 | P a g e
PMP Study Notes – Professional and Social
Responsibility
 1 Responsibility
 2 Respect
 3 Fairness
 4 Honesty

Responsibility
 in the best interest of the society, public and environment
 accept assignments consistent with skills and fulfill commitments
 accept stretch assignment when the assigner is fully aware of the skill gaps
 own error and make corrections
 uphold laws and regulations
 report illegal/unethical activities substantiated with facts
 ask for direction should the decision is beyond assigned authority

Respect
 show respect to others
 listen and understand others
 conduct in a professional manner, even if not reciprocated
 resolve conflicts directly
 negotiate in good faith
 do not influence others for personal benefits
 respect others rights

Fairness
 transparency in decision making
 be objective
 provide equal access to information, equal opportunities
 disclose any conflict of interests and refrain from making decisions in case of conflict of interest
 do not deny opportunities base on personal considerations
 do not discriminate
 apply rules without favoritism or prejudice

Honesty
 understand the truth and be truthful
 honor commitments
 not to deceive others
 not engage in dishonest behavior for personal gain / at the expense of others

69 | P a g e
PMP Study Notes 14 – Agile Practice Guide
 1 Overview of the Agile Practice Guide
 2 PMP® Study Resources

Overview of the Agile Practice Guide

 Section 1: Introduction
o Why the Agile Practice Guide is published is because projects nowadays are often
disrupted by the rapidly changing environments (technologies/demands/etc.), one of the
drawbacks of traditional waterfall project management approach (predictive) is that
changes are not easy to be implemented mid-way through the project. Agile project
management (adaptive) is the now regarded an answer to embracing changes.
 Section 2: An Introduction to Agile
o the Agile Manifesto mindset, values, and principles — 4 Values, 12 Principles, many
practices
 individual and interactions over processes and tools
 working software over comprehensive documentation
 customer collaboration over contract negotiation
 responding to changes over following a plan
o definable and high-uncertainty work
 definable work: with clear and proven procedures (from similar projects in the past)
 high-uncertainty work: complex, high-risk and prone to changes
o the correlation between Lean, the Kanban Method and Agile approaches
 Lean thinking: focus on value, small batch sizes, elimination of waste
 Agile and Kanban are subsets of Lean
 Kanban is based on lean thinking but used specifically for knowledge work
 Scrum, Crystal, XP, FDD, DSDM, etc. are subsets of Agile
 Section 3: Life Cycle Selection
o various life cycles
 predictive life cycle: traditional approach with lots of planning
 iterative life cycle: allows feedback for improving the unfinished work as the
project evolves
 incremental life cycle: provides deliverables (additional features) that customers
can use immediately after each cycle
 Agile life cycle: both interactive and incremental in name, to refine the work and
deliver usable products frequently
 Hybrid life cycle: making use of more than 1 types of development life cycles, to
fit for the purpose of the project / as a transition strategy from predictive to Agile
o suitability filters — help to determine whether Agile approaches are suitable
o tailoring guidelines
 factors to consider: demand patterns, the rate of process improvement, the flow of
work, 1 team or more, quality of product increments, the experience of Agile
among team members
o common combinations of approaches
 combined Agile and predictive approaches
 predictive approach with Agile components
 Agile approach with predictive components
70 | P a g e
 Section 4: Implementing Agile: Creating an Agile Environment
o critical factors to consider in an agile environment
 servant leadership to empower the team and remove organization impediments
 team composition
 agile roles: cross-functional team members, product owner, team facilitator
 members may be dedicated or multi-tasking/specialists or cross-functional
 Section 5: Implementing Agile: Delivering in an Agile Environment
o organizing Agile teams
o common practices for teams to deliver value
 retrospectives — to review the lessons learned
 backlog preparation and refinement — a prioritized list of tasks (in the form of
stories) yet to be completed
 daily standups — what has been done, what will be done, any
impediments/risks/problems
 demonstrations/reviews
 execution practices: continuous integration, test at all levels, Acceptance Test-
Driven Development (ATDD), Test-Driven Development (TDD), spikes (time-
limited experiments)
 Agile measurements — story points (points are assigned to the stories of the
backlog)
 Section 6: Organizational Considerations for Project Agility
o key organizational factors impacting Agile approaches
 culture (whether it is safe to fail for new initiatives), organization change
management, readiness for change
 enhance business practices to support Agile
 the role of a PMO — Agile PMO is value-driven, invitation-oriented and
multidisciplinary
 Section 7: A Call to Action
o asks project professional to help to continue refining this Agile Practice Guide
 Extras
o Annexes — (mandatory) additional information
o Appendixes — (non-mandatory) additional information
o References — a list of references cited/listed in the Agile Practice Guide
o Bibliography — a list of additional readings
o Glossary — a list of terms used in the Guide with definition

71 | P a g e
47 Pairs of Easily Confused Terms

PMP Basics: Project vs Operation

In the PMBOK® Guide, “Project” and “Operation” are defined differently:

 Project: A project is a temporary endeavor that is taken to create a unique deliverable (namely: product,
service or result).
o A project must be unique and non-recurring, i.e. every project is different.
o Every project has a definite begin and end date.
o The ultimate aim of projects is to achieve/align with the strategic objectives of the organization,
e.g. improve efficiency, introduce new products, enhance current products, etc.
o The end products for a project can be a new product, improved products, enhanced operation
procedures, etc.
o Examples: develop a new PMP® Exam reference book, create a new PMP® online training course,
prepare for the PMP® Exam
 Operation: Operations are routine ongoing activities/tasks for the organization.
o Operations must adhere to pre-defined steps/procedures.
o Operations carry on indefinitely until a change is introduced.
o All normal business functions of the organization are considered operations.
o Operations are necessary to sustain the business.
o Examples: printing of PMP® Exam books, delivering online PMP® Exam training to Aspirants,
accounting/staffing/sales management

On the other hand, “Project” and “Operation” do carry some similarities:

 They both have to take limited resources into accounts.

 Both projects and operations are performed by people/human resources.
 Both involve execution and control (e.g. quality control).

Summary: Project vs Operation

 Project: temporary, unique, aligned with strategic objectives, with a defined outcome (product, service or
result)
 Operation: ongoing, repetitive, vital to sustaining the business

72 | P a g e
PMP Basics: Enterprise Environmental Factors (EEF) vs
Organization Process Assets (OPA)
Both Enterprise Environmental Factors (EEF) and Organization Process Assets (OPA) are
support/constraints provided by the outside to the project mgnt team to effectively deliver the projects.

 Enterprise Environmental Factors (EEF): EEF are conditions that will influence / affect the project that are
not under the immediate control of the project team.
o “Environment” is the key term here.
o The project team need to understand and work with the EEF in order to successfully carry out the
project as these cannot be controlled by the team.
o The project team has little or no influence on the EEF.
o EEF are often seen as constraints or opportunities — i.e. may or may not benefit the project
o EEF examples:
 technology advancements / breakthroughs — mobile adoption, internet of things,
wearable technologies
 Government policies — pollution limitation, reduction of carbon emission, increase in the
use of renewable energy
 Community involvements
 Project Management Information System (PMIS) — the project templates and
configuration control stored in PMIS are OPA
 Skills of human resources
 Industry standards
 Work Authorization System (WAS)
 Organization culture / structure
 External and internal political conditions
 Resources (including money and human) available
 Organization Process Assets (OPA): OPA are any specific knowledge and documents (including processes
and plans) that are created / adopted to be used in the performing organization.
o OPA is a collection of all historic information (e.g. lessons learned / process improvements /
requirements / best practices) from the performing organization that is available for use by the
project manager to help achieving project / organization objectives.
o The organization may define which OPA are mandatory and which are recommended.
o When used properly, the OPA help the project manager in the management of the project.
o The OPA may be updated during the project execution as new knowledge is gained.
o OPA examples:
 Lessons learned knowledgebase
 Guidelines
 Project templates
 Recommended workflow/process
 Historic records
 Accounting practices
 Risk / stakeholder register

Summary: EEF vs OPA

 Enterprise Environmental Factors (EEF): factors related to the environment not under the (immediate)
control of the project team
 Organization Process Assets (OPA): knowledge specific to the performing organization
73 | P a g e
Estimate: ROM vs Definitive
 Rough Order of Magnitude (ROM) Estimate: the differences between estimates and actual
figures may be as large as 75% more or 25% less
o used in early stage of the project when things are not very solid/clear and/or for projects
that span a lengthy period
 Definitive Estimate: the differences between estimates and actual figures may be within the range
of -5% to + 10% (more or less)
o used in latter stage of the project and/or the project is simple to estimate

In addition to the ROM Estimate and Definitive Estimate, there are some more estimation ranges:

 Preliminary estimate: within the range of -15% to +50%

 Budget estimate: within the range of -10% to +25%
 Final estimate: 100% accurate

The degree of accuracy of the estimations will become more accurate as the project proceed as many
unknowns at the beginning of the project will become known later on.

ROM Estimate vs Definitive Estimate Illustrated

At the very beginning of the exam preparation, the Aspirants may have little or no previous knowledge
about the exam syllabus and the PMBOK® Guide. The actual period of time required for the studies may
not be known accurately. The only way to estimate the study period is through the lessons learned of other
exam takers.

And as a rule of thumb, the estimated preparation period for the exam is roughly 3 months of part-time
study, which is considered a Rough Order of Magnitude (ROM) Estimate.

But after going through the exam prep course, the PMP® Aspirant will then be able to understand the
topics for the exam and their knowledge gaps. Hence a more accurate estimate can be made (e.g. 100 days
— more like a Definitive Estimate). And at that time, it is often advisable to book the exact date of the
exam, which can also act as a driving force for the PMP® study.

Conclusion: ROM Estimate vs Definitive Estimate

The various degree of accuracy of estimations mentioned in the PMBOK® Guide and other PMP® Exam
Prep books are listed below:

 Rough Order of Magnitude (ROM) Estimate: within the range of -25% to +75%
 Preliminary estimate: within the range of -15% to +50%
 Budget estimate: within the range of -10% to +25%
 Definitive Estimate: within the range of -5% to +10%
 Final estimate: 100% accurate

74 | P a g e
Group Creativity Techniques: Nominal Group Technique vs
Brainstorming
Nominal Group Technique and Brainstorming are two Group Creativity Techniques named as PMBOK® Guide
ITTOs. These two are indeed quite similar as they both include the generation of ideas / requirements e.g. in
identifying project requirements. Yet, there are some major differences between Nominal Group Technique and
Brainstorming that Aspirants should understand in order to identify the correct ITTOs for the processes.

 Nominal Group Technique: The Nominal Group Technique is a technique for small group discussion in
which ideas / requirements are ranked / prioritized by all the members of the group after generation of all
the ideas / requirements.
o The Nominal Group Technique was originally developed by Delbecq and VandeVen as an
alternative to brainstorming.
o The Nominal Group Technique prevents domination of a single person over the discussion by
allowing the voices of all members to be represented.
o Steps:
 All the participants are divided into small groups of 5 or 6
 Each group member are allowed several minutes to brainstorm their requirements / ideas
separately
 All the requirements / ideas are presented and recorded, no criticism is allowed
 After clarifications, all the requirements / ideas are ranked / prioritized by all group
members (e.g. by giving points based on their merits)
 Brainstorming: Brainstorming is a group creativity technique in which member(s) are allowed to generate
as many ideas / requirements as possible without criticism.
o Ground rules: no “NO”s and criticisms are allowed.
o Participants are safe to present their own creative ideas even though some ideas are unrealistic /
absurd.
o All generated ideas / requirements are recorded without any assessments.

Both Nominal Group Technique and Brainstorming are useful Group Creativity Techniques to help the
project team to generate requirements and solutions to problems. These two allow equal opportunities for
participants of all members of the group by avoiding domination.

Summary: Nominal Group Technique vs Brainstorming

According to the above definition, it can be said that the Nominal Group Technique is brainstorming with
prioritization:

 Nominal Group Technique: brainstorming + group ranking / prioritization

 Brainstorming: generating as many ideas as possible in a safe environment without any
judgement from others

Note: other PMP® Group Creativity Techniques mentioned in the PMBOK® Guide include:

 Delphi technique
 Mind mapping
 Affinity diagram
 Multi-criteria Decision Analysis
75 | P a g e
Quality Control: Run Chart vs Control Chart
 Run Chart: A Run Chart simply plots the data of a variable over time.
o Through analysis of a run chart, the following can be derived:
 changes / trends of the process over time
 any pattern / cycle of the process
o Examples of a run chart:
 progress of the project / processes / tasks (percentage completion over time)
 expenditure of the project
o Plus: A run chart is easy to draw and interpret. It is useful for analysis of simple processes.
o Minus: Cannot show if the process is in control or stable. Not quite useful for quality control.
 Control Chart: A Control Chart also plots the data of a variable over time (same as the run chart), but also
includes specification limits (Upper Specification Limit USL and Lower Specification Limit LSL) and control
limits (Upper Control Limit UCL and Lower Control Limit LCL).
o Specification Limits: provided in the project plan/contract as a project requirement of the process;
o Control Limits: specified by the quality requirements of the process (e.g. 3-sigma); if a data go
beyond the control limits or a pattern/trend has been formed, corrective actions must be taken to
correction the deviation.
o Tells whether the process is under control
 Telltales of “Out of Control”:
 Any data point outside the control limits
 Rule of 7: 7 consecutive data points within the control limits but on either side of
the mean
 A trend has been formed (e.g. 6 consecutive points forming an increasing or
decreasing trend)

To put it another way, a Control Chart is a Run Chart with 4 line indicating the limits added (upper/lower
specification limits and upper/lower control limits) (plus optional a line indicating the mean of all data).

76 | P a g e
Estimate: Analogous vs Parametric
 Analogous Estimating: the estimation is made by simply taking the values from past projects/activities
with similar scope to the current projects/activities (somewhat like making an analogy)
o the fastest and easiest estimation method to give a rough estimation
o requires a combination of historical information and expert judgment (the information from past
projects can be adjusted with consideration of the special circumstances of the current project,
e.g. including inflation, etc.)
o however, the estimation is least reliable as no two projects are identical
o used in cases where there are only limited amounts of available information early in the project
o also known as “Top-Down Estimating“
 Parametric Estimating: the estimation is based on historical information of very similar projects with
consideration of the scale differences
o by first identifying the unit cost/duration from the past projects/activities and scale the
estimation to the required number of units for the current project/activity
o the estimation is more reliable
o used only when a statistical relationship between historical data and current work can be
established; often have limited use as the nature/details of the current project/activity may differ
significantly from previous ones and thus makes parametric estimating not feasible

Though both Analogous Estimating vs Parametric Estimating is based on the historical information from
the organization/industry to estimate cost/duration of the project/activity, there are some very noted
differences between them:

 Analogous Estimating is considered a top-down approach which is much less accurate than parametric
estimating in which Analogous Estimating is based on simple “analogy”;
 Parametric Estimating is more accurate for projects/activities with components which are similar and
“scalable”, it is based on a unit cost/duration of historical data which is scaled to give the estimation;
 Analogous Estimating is used early in the project where there are only limited amounts of information
available while Parametric Estimating is used if the project/activity is “scalable”.

In addition to the two types of estimation methods detailed above, the PMBOK® Guide has also
mentioned two other estimation methods:

 Bottom-up Estimating — (also known as the “definitive technique”) the most accurate and time-
consuming of all estimation methods in which every single activity is broken down into details at the
bottom level and aggregate the estimations of each individual components to give an overall estimation.
o (updated for new PMP® Exam 2018) note that the PMBOK® Guide 6th Edition has included
Bottom-up Estimating as one of the tools and techniques for “Estimate Activity Durations” process
in addition to “Analogous Estimating”, “Parametric Estimating” and “Three-point Estimating”.
 Three points Estimating — this more accurate estimation is developed from three estimates using
the PERT (Program Evaluation And Review Technique) formula:
o (Eo + 4Em + Ep)/6
 Most Likely Estimate (Em): The estimate when everything goes as normal
 Pessimistic Estimate (Ep): The estimate when everything goes (almost) wrong
 Optimistic Estimate (Eo): The estimate when everything goes (almost) smoother than
expected
o risks and uncertainty are taken into accounts
o more accurate than Analogous Estimating and Parametric Estimating

77 | P a g e
Project Risk Management: Avoid vs Mitigate
In project risk management, there are several risk management strategies for positive or negative risks:

 For negative risks:  For positive risks (i.e. opportunities):

o Mitigate o Enhance
o Avoid o Exploit
o Transfer o Share
o Accept o Accept
o Escalate

 Avoid: taking any possible measures/actions (e.g. changing the project plan or approach) to
completely prevent the risks from occurring/eliminate the adverse effects once they occur
o not many risks may be avoided (not realistic for most cases)
o avoid usually involves a lot of costs
 Mitigate: taking measures/actions (e.g. changing the project plan or approach) to reduce the likelihood
of the risks from occurring/minimize the impact once they occur
o some residual risks may remain

 Transfer: the negative impacts related to the occurrence of the risk are shifted to a 3rd party
o the 3rd party will absorb all the losses
o may be arranged in the form of insurance policy or penalty clause
o usually involve contractual arrangements and considerations
 Accept: the negative risks are to be accepted passively
o no active actions / measures are carried out to reduce the likelihood of occurrence / degree of
negative impact which might be caused by the occurrence of the risk
o workarounds may be carried out as a response once the risks occur
 Escalate: escalate the project risk to the appropriate party to handle it
o no longer a responsibility of the project manager
o can be deleted from the risk register or leave it there with a remark

Avoid vs Mitigate for PMP® Exam Illustrated

One of the most common problem any PMP® Aspirant may face is to be late for the PMP® Exam owing
to traffic jam (which you may just be denied the exam or have the exam time cut). There are a number of
suggestions for this risk as proposed by other Aspirants. We will look into the risk response strategies for
the “Avoid” and “Mitigate” categories:

 Avoid Risk Management Strategy

o Do not take the PMP® Exam at all (avoid the Exam)
o Walk to the PMP® Exam Centre instead of riding a car/bus/train (avoid any traffic)
o Sleep at the door of the PMP® Exam centre the night before
 Mitigate Risk Management Strategy
o Go to the Exam centre at least 1 hours earlier than the Exam time in preparation of any traffic jam
o Live in a hotel adjacent to the Exam centre to minimize the traffic time
o Book an Exam centre in an area with little traffic jams
o Book the PMP® Exam in the afternoon away from the morning peak hours

78 | P a g e
Project Risk Management: Contingency Plan vs Fallback Plan
In project risk management, actions are required to be planned should identified risks actually occur.
There are two major types of planning: Contingency Plan and Fallback Plan — both the Contingency Plan
and the Fallback Plan are developed in advance during Plan Risk Responses process.

Contingency Plan and Fallback Plan

 Contingency Plan: a contingency plan is developed to be taken only when risk event occurs
o only for risks that have been accepted (i.e. no proactive actions to be taken to minimize their
occurrence)
o for identified risks (known unknowns)
o developed during Plan Risk Responses process
 Fallback Plan: a fallback plan is developed to deal with risks if the primary planned risk response is not
effective
o to be taken after the Contingency Plan
o for identified risks (known unknowns)
o developed during Plan Risk Responses process

In short, Contingency Plan (also known as Contingent Response Strategies) are developed for specific
accepted risk with certain triggers while Fallback Plan is used when the planned primary risk response
(e.g. Contingency Plan) is not effective (similar to the meaning of “Plan B”).

In addition, for all unidentified risks (unknown unknowns), workaround would be carried out:

 Workaround: the immediate risk response strategies for unidentified or passively accepted risks occur in
order to contain the damages against the project plan (the costs dealing with identified risks can be
obtained from the management reserve upon management approval)

Note: the costs dealing with identified risks are included in the contingency reserve. The costs
dealing with unidentified risks are included in the management reserve

Contingency Plan and Fallback Plan Illustrated

Let’s take the project of PMP® Exam study and preparation as an example to illustrate the concept of
Contingency Plan and Fallback Plan.

Falling ill during exam preparation is one of the top risks that may adversely affect the exam preparation
and taking. Though in theory there are a number of measures that can be taken to minimize the risk of
falling sick; in reality, there are not many Aspirants can do to avoid the risk. Hence, many Aspirants will
just accept falling ill as an accepted risk.

For every accepted risk, there are two plans that need to be developed:

 Contingency Plan — accelerate the exam preparation by taking annual leave from work so as to catch up
with the original PMP® Exam schedule
 Fallback Plan — postpone the exam date (even if an administration fee is required — a US $70 fee will be
charged if you reschedule or cancel your exam within 30 calendar days of the appointment)
79 | P a g e
Project Risk Management: Enhance vs Exploit
In project risk management, there are several risk management strategies for positive or negative risks:

 For negative risks:  For positive risks (i.e. opportunities):

o Mitigate o Enhance
o Avoid o Exploit
o Transfer o Share
o Accept o Accept
o Escalate

Enhance vs Exploit
 Enhance: taking measures/actions (e.g. changing the project plan or approach) to increase the probability
of the occurrence of opportunities / increase the benefits from the opportunities
o note that the opportunities may not realize in the end
o may be considered as the opposite of “mitigation” in negative risk response strategy
 Exploit: taking any possible actions to make sure the opportunities will realize
o do everything to realize the opportunities, including adding budgets or carrying out dramatic
actions
o may be considered as the opposite of “avoid” in negative risk response strategy

Illustrated Example
Let’s take the project of exam study and preparation again for the illustration of the meanings of Enhance
vs Exploit risk management strategies.

An Aspirant, Dave, aims to sit for the exam before the change of the exam syllabus as his employer has
set up a scholarship for the study materials for the current version (the costs of exam prep books as well as
mock exam question banks would be paid by his employer). In order to take advantage of the offer, Dave
has formulated the following actions in the “Enhance” and “Exploit” categories:

 Enhance Risk Management Strategy

o Submit application as early as possible
o Spare an extra hour of study time every day
o Make use of an online exam prep course (instead of a classroom course/bootcamp) to allow him
to study anywhere with his mobile phone
o Attempt mock exams early in his preparation to understand his knowledge gap
 Exploit Risk Management Strategy
o Subscribe to an exam coach service to tailor a study plan with an experience tutor
o Take leave from work till he has finished all the study and preparation
o Use same day courier service to submit the audit document (if required for an audit)
o Schedule and take the exam before the change of exam version (even if he has not finished his
preparation)
o Book a hotel room in the vicinity of the exam center for the night before the exam day

80 | P a g e
Project Risk Management: Fallback vs Workaround
 Fallback: a fallback plan is a plan developed to deal with risks that have been identified during project
planning
o for identified risks
o known unknowns
 Workaround: a workaround is the unplanned response the Project Manager need to take to deal with
emerging risks and risks that are passively accepted as the risk response during project execution (i.e.
there are no pre-determined risk response plan in place)
o for unidentified risks or risks that are passively accepted (note: risks that are accepted actively
will be dealt with a Fallback)
o unknown unknowns

Note: Risks can be either accepted actively or passively:

 active acceptance means the identified risk is accepted without any response to reduce or eliminate the
chance of occurrence but measures are planned (i.e. fallback) to deal with it once it occurs
 passive acceptance means the identified risk is accepted without any response altogether (maybe the
chance of occurrence is too low or the effect too minimal), just wait and see if workaround is needed once
it occurs.

Illustrated Example
Tim has formulated a study plan for his exam:
 Week 1-4: finish the online course by watching the course videos on the computer at home and get the
35 Contact Hours for the exam
 Week 5-6: complete the exam application and take free mock exams to bridge any knowledge gap
 Week 7: take a week off for relaxation
 Week 8: last minute revisions and take the exam at the end of Week 8

Tim has also identified two most common risks and their fallback plans:
 not able to finish online course on time: download the PMP® courses onto his mobile phone and watch
the exam prep courses during transit and running
 not able to get the recommended results (70%-80%) for the free mock exams: purchase a paid exam
simulator for more practices (at extra costs)

Now when it is at the end of Week 5, Tim is caught in an accident that keeps him hospitalized for 1 week.
Tim has to immediately develop a workaround plan this time by moving the relaxation week (Week 7)
up to Week 5 and work on the mock exams in Week 6 – 7 to make up the loss time.

Conclusion
Though both Fallback and Workaround are used to deal with risks when they occur, Aspirants would need
to remember that:
 Fallback is pre-developed risk response strategies for identified risks in order to protect the original
project plan (the costs deal with identified risks are included in the contingency reserve)
 Workaround is immediate risk response strategies for unidentified risks (or identified risks that have been
accepted passively) in order to contain the damages to the project plan (the costs deal with unidentified
risks can be obtained from the management reserve upon management approval)
81 | P a g e
Project Risk Management: Qualitative vs Quantitative
After project risks are identified in the “Identify Risks” process and registered into the Risk Register,
these risks must be undergone Qualitative Risk Analysis and Quantitative Risk Analysis in order to assess
their implications for risk response planning.

 Qualitative Risk Analysis: Qualitative Risk Analysis aims to assess all identified risks for their probability or
likelihood of occurrence and their implications/impact to the project objectives should they materialize.
o The Risk Score for individual identified risk is calculated by multiplying the probability of
occurrence (P) by impact (I): i.e. Risk Score = P x I
o The Risks will usually be assigned an value according to the Impact Scale
 e.g. an Impact Scale of 1 to 5 with 1 is the lowest impact and 5 is the highest impact
o The Risk Score / Impact Scale will facilitate the project manager in prioritizing the risks (i.e. highly
risk score risks must be dealt with first as they will have large impact on the project success and
they are more likely to occur).
 Quantitative Risk Analysis: Quantitative Risk Analysis aims to estimate the effects of risks on the project
objectives in monetary terms/time cost.
o Quantitative Risk Analysis will usually be performed on the risks with highest priority as they are
most important risks to the success or failure of the project.
o Quantitative Risk Analysis is very time consuming as the impact of the individual risks must be
evaluated.

Illustrated Example
You are PM of the “Getting PMP® Certified in First Try” project. Below are a number of identified risks:
 Trapped in a car accident and begin late for the exam.
 A sudden work assignment requires you to work OT every day during your exam preparation.
 Your son falls ill during your exam preparation.
 The World War 3 breaks out during your preparation.
 A new version of the exam is administrated while you study for the old version.
 ……

In Project Qualitative Risk Analysis, every risk is assigned an Impact Scale value:
 Trapped in a car accident and begin late for the exam. (5)
 A sudden work assignment requires you to work OT every day during your exam preparation. (3)
 Your son falls ill during your exam preparation. (0 – as you don’t have a son)
 The World War 3 breaks out during your preparation. (1)
 A new version of the exam is administrated while you study for the old version. (3)

In Project Quantitative Risk Analysis, only high impact risks are assessed:
 Trapped in a car accident and begin late for the exam — costs involved:
o the exam invigilator will possibly deny entry to the exam and you will need to re-schedule the
PMP® Exam with a fee (A)
o an extra day off from work is required for taking the exam (B)
o the travelling costs to and from the exam centre (C)
o the risk may cost A + B + C

82 | P a g e
Project Communication Management: Push vs Pull
 Push Communication: Uni-directional communication sent from sender to receiver.
o Push Communication is recommended if the project manager just want to disseminate
information without any needs to obtain immediate feedback from recipient.
o The message/information conveyed through push communication is usually in written form and
should not be urgent or sensitive/classified.
o Advantages:
 Easy to disseminate message/information to a large pool of recipients in a short while
o Disadvantages:
 Not face-to-face
 Not easy to verify that the messages have been conveyed successfully and the recipients
understand them correctly
 Not suitable for urgent matters
o Examples of Push Communication : Letters, Memos, Emails, Reports, Voice mails
 Pull Communication: Uni-directional communication by providing all related stakeholders access to
certain information.
o All related stakeholders can gain access to (pull) the information provided anytime they
need/want.
o Pull Communication is only suitable for information dissemination that is not urgent or critical —
if the intended recipients do not read the information, little or no effect on the project would be
resulted.
o Advantages:
 Easy to disseminate message/information to even a much larger pool of recipients in a
short while
 Information can be retrieved whenever needed
o Disadvantages:
 Not face-to-face
 Not suitable for urgent / sensitive matters
 Not easy to track if all the recipients have accessed the information
o Examples of Pull Communication: websites, wiki / knowledge repositories, bulletin board (e-
bulletin board), dashboard

In addition, there exists a more efficient communication method — Interactive Communication.

 Interactive Communication: Bi-directional communication by communicating in real time.
o The most efficient method of communication as interactive communication can ensure all
stakeholders understand the message / information correctly.
o Advantages:
 Can check if the recipients understand the message/information delivered.
 Allow the recipients to have their queries/doubts answered immediately.
 The project manager can collect direct feedback from the recipients to understand their
reception/thoughts.
 Suitable for sensitive / classified information.
o Disadvantages:
 Time-consuming
 In order to remain effective, interactive communication is more suitable for a smaller
group of participants
o Examples of Interactive Communication: Meetings, Phone Calls / Conference, Video Calls /
Conference, Workshops

83 | P a g e
Project Resource Management: Develop Team vs Manage Team
In Project Human Resource Management, there are four processes, namely, Plan Human Resource
Management, Acquire Project Team, Develop Project Team and Manage Project Team. The latter two are
somewhat confusing as they both are related to the management of the project team in our everyday
language.

 Develop Project Team: Develop Project Team is a process under Project Human Resource Management in
which the project manager tries to improve the competencies, environment and interaction of team
member interaction with a view to enhance project performance.
o The core aim of this process is to provide the suitable training and environment for the team
member to flourish.
o Major tools and techniques to be employed include:
 training
 colocation
 reward scheme
 team building (note: forming, storming, norming, performing and adjourning)
 ground rules
o A performing team can be expected when the project manager is doing a good job in Develop
Project Team.
 Manage Project Team: Manage Project Team is a process under Project Human Resource Management in
which the project manager tries to track the team member performance, provide feedback and resolve
issues with a view to optimize project performance.
o The core aim of manage project team is to track performance, resolve issues and conflicts (e.g.
performance issues and interpersonal conflicts).
o Major tools and techniques to be employed include:
 performance tracking
 appraisals
 conflict management
 conversation and dialogue
o If soft skills are not useful, disciplinary actions (including termination of employment) may need to
be taken to control the damage to the overall performance of the team.
o Manage Project Team is more difficult than Develop Project Team as the project manager is
required to deal with the most difficult factor of project success — i.e. human. The interpersonal
soft skill of the project manager is put to test when dealing with conflicts and issues.

Summary
After acquiring the project team, the project manager is responsible for both develop and manage the
project team:

 Develop is to bring out the best of the project team (as a team and individually) through training and
better environment;
 Manage is to resolve issues and conflicts that impede the performance of the team through interpersonal
skills and appraisals.

84 | P a g e
Project Risk Management: Residual Risk vs Secondary Risk
 Residual Risk: the risk(s) that remains after carrying out the risks response or those risks that are
accepted without any risk responses (maybe the cost for the risk response is more than the cost of dealing
with it)
o residual risks must be identified and documented during the risk management process
o a contingency reserve should be set up to tackle these risks should these kinds of risks arise
 Secondary Risk: the risk(s) that are created directly owing to the implementation of a risk response for
primary risks
o since every activity involves risks — the risk responses themselves are no exception,
implementation of a risk response will result in new risks for the project
o a risk response plan would need to be planned and implemented to tackle this kind of risks
o secondary risks may be accepted without further actions if their impact are small on the overall
project objectives

Illustrated Example
When planning the study schedule for exam, the primary risks that may affect your study schedule are:

 suddenly be fully engaged with a new project during exam prep that leaves no time for studying
 fall ill during exam prep
 change of the exam syllabus
 ……

One risk response activity for not finding enough study time owing to professional engagement would be
to begin the exam prep in a low season (i.e. avoid the peak seasons) by taking reference to the work
pattern for the previous years.

 The residual risk for this risk response would be: an unexpected large-scale project comes up during your
exam prep. In that case, you may need to set aside budget (a “known unknown” — from contingency
reserve) to postpone your PMP® Exam in order to find enough time for studying.

The risk response activity for avoiding falling ill during exam prep would be taking vaccination for five of
the most common contagious disease at the time of exam prep.

 The secondary risk for this risk response would be the vaccines themselves may cause side effects
(including prolonged fatigue or headache) or even cause infection. A risk response plan may need to be
created for this secondary risk.
 As there are countless variety of germs/toxins that can cause illnesses, the 5 vaccines taken may just be
able to protect you against a portion of the most common diseases. You can still be exposed to some less
common diseases — this is the residual risk.

Summary
Risks are inevitable. In addition to the primary risks, there are also residual and secondary risks:

 Residual Risks are risks that are left over after implementing a risk response
 Secondary Risks are risks that are created directly by implementing a risk response
85 | P a g e
Change Control and Configuration Control
One of the vital elements for project management success is to control changes as in the Perform
Integrated Change Control process; otherwise scope creep and missed requirements may result.
Change management in projects involves Change Control and Configuration Control. These two terms are
often used interchangeably in daily work; however, PMBOK® Guide has put specific meaning to each of
them that Aspirants should not get confused.

 Change Control: In project management, change control is the process to identify, document,
approve/reject and communicate changes to the baselines of the project (project baselines include scope,
schedule, cost and other relevant baselines as required by the project management plan).
o The exact steps of change control are specified in the Change Management Plan by using
the Change Control System.
o Changes need to be proposed in written form as Change Requests which will be studied, analyzed
and approved/rejected by the relevant authorities.
o Change Control ensures all changes to the project are authorized which prevents scope creep and
gold plating.
 Configuration Control: In project management, configuration control is about managing the specifications
of the deliverables and processes with appropriate documentation throughout the lifecycle of the project
from the very beginning to the closure of the project.
o The project configuration provides the information of the latest version of the entire approved
product and related documents/components and an archive of all previous versions.
o All the items under Configuration Control are known as Configuration Items (CI).
o Configuration Control is facilitated by the Configuration Control System.
o The exact details of Configuration Management are documented in the Configuration
Management Plan, which is a subsidiary of the Project Management Plan.
o Configuration Management activities usually include:
 configuration identification
 configuration status accounting
 configuration verification / audit to ensure the latest configuration is adopted and
delivered

The PMIS (Project Management Information System) is a tool that facilitates both the Configuration
Control System as well as the Change Control System.

Summary:
Both the Change Control and Configuration Control processes aim to protect the project from:

 Change Control is about protecting the project from undocumented changes to the project baselines by
addition/changing requirements, etc.
 Configuration Control is about managing the specifications/versions of the deliverables, processes and
related documents throughout the lifecycle of the project.

86 | P a g e
Project Expeditor vs Project Coordinator
In Weak Matrix organizations, there are usually no “real” project managers; even if there is a post of
“Project Manager”, they usually perform the role more of a Project Coordinator or Project Expeditor. For
strong matrix and projectized organizations, Project Expeditor and Project Coordinator may exist
alongside with the Project Manager.

 Project Expeditor: A Project Expeditor usually carries the responsibility of staff assistant / communication
coordinator.
o A Project Expeditor is not given the authority (or very low authority) to make or enforce decisions.
o The Project Expeditor will communicate with various parties of the project to ensure timely action.
o For larger projects, the Project Manager may have some Project Expeditors assisting them for
communication and logistics.
 Project Coordinator: A Project Coordinator carries the responsibility of partially managing the project
under the supervision of other managers.
o A Project Coordinator is usually given some sort of limited authority to make decision.
o For larger projects, the Project Manager may have some Project Coordinators reporting to them.

The power or authority of the roles of Project Manager, Project Expeditor and Project Coordinator is
listed in descending order: Project Manager >> Project Coordinator >> Project Expeditor

Illustrated Example
Let’s again take the project of PMP® Exam preparation as an example. Though there is just one project
manager (i.e. that’s you), just imagine there are one project expeditor and one project coordinator working
for you. Then their responsibility may be:

 Project Expeditor
o Purchase the exam study guide and ensure delivery of the book (chase the seller in case the book
is not delivered)
o Purchase the online course for the 35 Contact Hour of Project Management education
o Purchase the online mock exam
o Book the exam date according to instruction of the Project Manager
 Project Coordinator
o Compare different online courses for the 35 Contact Hour of Project Management education and
recommend the best online course
o Compare different online mock exams (or called exam simulator) and make recommendations
o Select which working experiences are to be included in the Application Form
o Help to fill in the PMP® Application Form

Summary
Project Expeditor and Project Coordinator are roles that facilitate the running of the projects depending on
the type of organization (functional, weak matrix, balanced matrix, strong matrix). The main distinction
between Project Expeditor and Project Coordinator is their level of authority given by senior management:

 Project Expeditors are NOT given the authority (or very low authority) to make or enforce decisions.
 Project Coordinators are given some sort of limited authority to make decision.
87 | P a g e
Project Requirements vs Project Scope
 Project Requirements: Requirements are what are expected to be fulfilled by the project from the users’
point of view.
o Requirements is a collection of items that are the needs of the users — capabilities that are
supposed to be present in the deliverables.
o The Requirements are collected through the Collect Requirements process with the use of
questionnaires, workshops and interviews, etc. with defined stakeholders.
 Each requirement must be documented in details with acceptance criteria.
 Requirements documentation, requirements management plan and requirements
traceability matrix are produced.
 Project Scope: Project Scope defines the boundary of the project and it is the sum of products, service
and/or results of the project.
o Project Scope is derived from the project requirements that are more thoroughly studied and
documented.
o Project Scope indicates the list of activities/tasks that need to be done in order to fulfil the
requirements.
o In particular, project scope outlines in details what are and are NOT included in the project.
o The project scope statement is produced in the Define Scope process to give a baseline for
understanding and agreement among all stakeholders.

Illustrated Example
The project requirements of the end user (i.e. you) may include the following:

 Fulfil the PMI requirements and requisites for applying for the exam.
 Be well prepared for the exam.
 Pass the exam and be certified.

And the scope of the project would include:

 Getting the requirement number of working experience hours in project management.

 Getting 35 Contact Hours of project management education by going through an online course
 Applying for the exam and paying the exam fee.
 Purchasing and going through a reference prep book.
 Going through several mock exams and compare the results to understand the exam readiness.
 Schedule and take the exam.

Summary
Project Requirements and Project Scope may be considered as opposite sides of the same coin:

 Project Requirements are the expectations from the stakeholders that the project need to address. The
requirements are usually written in the form of capabilities (what things can be done).
 Project Scope lists out all the work that needs to be done in order to deliver products, services and/or
results that provide the capabilities to fulfil the user requirements. The scope is usually written as the
detailed activity list.

88 | P a g e
Project Statement of Work vs Project Charter
 Project Statement of Work (SOW): The Project Statement of Work is a document providing the business
need and the overview of the qualities/characteristics of intended deliverables/products the project
would deliver. It will also include what are included / NOT included in the project.
o The Project SOW is provided:
 (for external projects) customer as the basis for writing the bid document;
 (for internal projects) project sponsor
 Project Charter: The Project Charter is a formal document to authorize the project and give the project
manager the authority to spend the project budget.
o The Project Charter includes:
 Project purpose / justification
 High-level project objectives and product characteristics
 Project success criteria
 High-level requirements
 High-level schedule and budget
 Name the Project manager
 List out the project approval requirements and approval authority
o The Project Charter is created in the Develop Project Charter process with the following inputs:
 Project statement of work (SOW)
 Business case
 Agreement
 Enterprise environmental factors (EEFs)
 Organizational process assets

Illustrated Example
The Project Statement of Work would likely to include:
 Be qualified for the exam (e.g. 35 Contact Hours of project mgnt education; working experience; etc.);
 Be well prepared for the exam through studying and mock exam taking;
 Sit and pass the exam in first try to get the credential.

The Project Charter would contain similar items:

 Project purpose: Be able to pass the exam and get PMP® certified as this would add competitive
advantages to the project management career
 Project success criteria: pass the exam in first try
 High-level schedule and budget: study and take the exam within 3 months (the norms for practicing
project managers), the minimal certification cost for the exam prep and exam is around US$1000
 Project manager: you

Summary
Project Statement of Work is provided by the organization/management to the project manager for
creation of Project Charter:
 Project Statement of Work (SOW) includes the business need and the overview of the qualities/
characteristics of deliverables;
 Project Charter is the document created based on the Project Statement of Work to authorize the Project
Manager to kick off the project and spend the budget.
89 | P a g e
Project Statement of Work vs Business Case
 Project Statement of Work (SOW): The Project Statement of Work is a document providing the business
need and the overview of the qualities/characteristics of intended deliverables/products the project
would deliver. It will also include what are included / NOT included in the project.
o The Project SOW is provided:
 (for external projects) customer as the basis for writing the bid document;
 (for internal projects) project sponsor
 Business Case: The Business Case includes the business needs of the project with respect to high-level
strategic goals of the performing organization, reasons and grounds (including information on cost benefit
analysis) for identifying and selecting the project.
o Cost benefit analysis information is often presented as:
 net present value (NPV)
 internal rate of return (IRR)
 return on investment (ROI)
o The PMP® Exam does not test on how to create a business case or how to calculate IRR, NPV or
ROI but would assume each project is backed up with a comprehensive business case.

Illustrated Example
Let’s again take the project of PMP® Exam preparation as an example. Imagine you are the senior
management of your exam prep project and you are to write the Project Statement of Work and Business
Case for your project manager (who, incidentally, is also you).

The Project Statement of Work would likely to include:

 Be qualified for the exam (e.g. 35 Contact Hours of project management education; working experience…);
 Be well prepared for the exam through studying and mock exam taking;
 Sit and pass the exam in first try to get certified.

The Business Case would likely to include:

 A comparison of the exam and other professional qualifications (e.g. CAPM®, PMI-ACP®, ITIL®, etc.) ;
 How PMP® will benefit your professional growth in the long run?
 What are the expected inputs (in terms of money and time) and what is the ROI from getting certified?
 Why is it justifiable to get certified?

Summary
Project Statement of Work and Business Case are two different documents provided by the
organization/management to the project manager for creation of Project Charter:

 Project Statement of Work (SOW) includes the business need and the overview of the
qualities/characteristics of deliverables;
 Business Case includes the justifications (usually in financial feasibility) for the existence of the project
and how the project is aligned to strategic goals of the organization.

90 | P a g e
Create WBS vs Decomposition
 Create WBS (Work Breakdown Structure): Create WBS is a process for Project Scope Management.
o The primary aim of Create WBS process is to provide a hierarchical / organization chart for better
depiction of project scope for activities, costs, quality, risks, etc. identification, estimation and
control.
o WBS (Work Breakdown Structure) is the primary output of the Create WBS process.
o The WBS Dictionary is also created to supplement the WBS with additional information/attributes
for each work packages.
o The WBS consists of many layers:
 Deliverables
 Planning Packages
 Control Accounts — when all the work packages under a control account have
been completed, this will trigger some monitoring and controlling activities to be
performed
 Work Packages — the lowest level component of WBS, by common practice, a work
package is the amount of work assigned to a single resource that can produces a
verifiable outcome
o The creation of WBS follows the 100% rule — the WBS must include 100% of the work defined by
the project scope and captures all deliverables and there is no overlap between different work
packages
o WBS is NOT a project plan or schedule not it is an exhaustive list of all works to be performed in
the project (e.g. project management products/processes are not included).
o Each WBS component must have a unique code (code of account).
 Decomposition: Decomposition is the primary tool for the process of Create WBS in Project Scope
Management.
o Decomposition will break down deliverables into small enough components to be considered as a
Work Package.
o The Work Packages are then used for work effort, cost, and time estimation.
o The Work Packages will need to be further decomposed into Activities and then Tasks later on for
more accurate time estimation with activity sequencing.

Note: In the PMBOK® Guide there is no recommended or fixed way of how detailed the “Work Package”
or the “Activity” needs to be, and that would depend on the project/organization needs.

Summary
Remember this: Creating WBS requires the tool of “Decomposition” and yet “Decomposition” will also
break down the lowest level of WBS (i.e. Work Packages) into Activities and Tasks.

Creating the WBS is a process for project scope management while the tool “Decomposition” is used in
both project scope and time management.

91 | P a g e
RACI: Responsible vs Accountable
In the RACI Chart, project individuals / stakeholders are defined as responsible, accountable, consult
and inform statuses for different project activities in order to show their involvement and responsibility
clearly. Among these four statuses, “responsible” and “accountable” are often not correctly understood as
these two statuses sometimes assigned to the same individual for smaller activities.

 Responsible: Responsible means the person(s) assigned is/are the ones to carry out and finish the task
o There can be more than one people responsible for an activity/task
o Responsible individuals can be thought of as the workers for an activity/task
 Accountable: Accountable means the person assigned is
o Accountability CANNOT be shared, meaning that there is only ONE individual accountable for an
activity/task
o The accountable person is tasked with the management responsibility (i.e. manager) of the
activity, including progress tracking, issue escalation (if needed) and deliverable assessment and
signing off, they are ultimately answerable for the results and actions taken
o An individual can both be responsible and accountable for an activity/task

Illustrated Example
For each tasks included in the PMP® exam preparation, the Aspirant is always accountable and
responsible:

 “Responsible” means that the Aspirant is the one to do all the studies, attempt mock exams and the
real exam
 “Accountable” means that the Aspirant is the one held answerable for their choice of online exam prep
course, exam simulator, whether or not to read the PMBOK® Guide in full, decide when to take the exam,
etc.

This Responsible/Accountable burden makes the exam prep a stressed and difficult task (as I have
undergone the whole process myself without much assistance from others). That’s why I set up this exam
prep website to help fellow Aspirants to get the much needed information on how to choose online
training courses, how to pass the audit, how to find quality (and sometimes free) exam prep resources, etc.
with a view to allow them to make informed choices as the accountable person. And I have uploaded my
own study notes to ease the life of those who are responsible for doing the exam prep.

Summary
It is actually not difficult to distinguish between Responsible and Accountable:

 There is only ONE accountable

 Accountable is ultimately answerable for the decision and deliverable (often after finishing the task)

92 | P a g e
RACI vs RAM
 RACI: RACI is a popular type of RAM (Responsibility Assignment Matrix) that defines project individuals /
stakeholders as responsible, accountable, consult and inform statuses for different project activities.
o Explanation on responsible, accountable, consult and inform statuses:
 Responsible — those who actually carry out the work to achieve the task objectives.
 Accountable — the one individual who is ultimately accountable for the success (or failure)
of a task and will approve the work created by those Responsible. There is ONE and ONLY
ONE Accountable for a specific task / deliverable.
 Consulted — those who would have opinions that need to be sought / weighted in for the
task / deliverable and be kept updated of the progress (two-way communication).
 Informed — those who would need to be updated on the task progress (one-way
communication).
o In the project, a role may be performed by many individuals while a person can perform many
roles. However, for each task / activity, it is advisable to have a person assigned to one role only
(though if there is none accountable, the one responsible will also be the de facto responsible
person for the task).
 RAM: RAM stands for Responsibility Assignment Matrix; it is a grid-like responsibility assignment chart
that shows assignment of project resources to individual work package.
o RAM clarifies the roles and responsibilities of project resources in projects and processes.
o RAMs can have different levels (in particular for larger and more complex projects), the higher
levels for programs / project phases while the lower levels for project activities.
o RACI Matrix and Linear Responsibility Chart (LRC) are two popular examples. The PMBOK® Guide
describes RACI in more details as a type of RAM.
o Project managers are advised to involve team members when creating the RAM / RACI Chart.

Illustrated Example
Below is the high-level RACI (R – responsible, A – accountable, C – consult and I – inform):

Author Editor Marketer Designer and Printer Distributor

Writing and editing R A I I

Designing and typesetting C A C R

Printing and delivering I I C R I

Marketing and sales C C A R

Updating and revising R A C R I

Within each project phases, there can be lower-level, more detailed RACI Matrices for the various work
packages and tasks defined by decomposition to better illustrate the roles and responsibilities of different
project resources.

93 | P a g e
Scope: Project Scope vs Product Scope
 Project Scope: includes all the work required to deliver the required project product, service or results
(collectively known as “deliverables”)
o Project Scope is the about the project (including all the processes described in the PMBOK® Guide)
to deliver the product
o Project Scope involves the requirements of the product as well as the methods/processes
involved to deliver the product
o Project Scope is documented in the Project Scope Statement / Statement of Work — detailing the
results of the project as well as the constraints and assumptions
 Product Scope: includes the features and functions of the required product, service or result from the
project
o Product Scope is about the product itself and no more
o Product Scope would describe how the product will look like, how it will work and the results it
will deliver (technical specifications)

Illustrated Example
The Product Scope is simply “getting a pass in the real PMP® exam” as what we Aspirants want is
getting the “Congratulations” screen at the end of the 4-hour exam (of course, the knowledge gained from
studying the PMBOK® Guide is also very valuable to everyday project management work — but I would
say that’s a “by-product”, the PMP® title is the most important part).

For the Project Scope of the exam, it would involves lots of things (which is why getting certified is not
that simple):

 Understand the requirements — i.e. getting a pass in the exam

 Estimate the project budget (including the cost of exam fee, cost of 35 contact hours course, exam Prep
books, PMBOK® Guide, exam simulators, etc) , develop the study and exam plan and create the study and
exam schedule
 Carry out the study and continually monitor the progress (including whether to defer the exam if needed)
 Check your study quality by trying mock exams
 Write the exam once ready
 Review the results — retake the exam if necessary

Summary
The product is what the project need to deliver and the Product Scope is all about it specifications
(i.e. what it looks like, its features and functions and how it works). The Project Scope is developed
based on the Product Scope that includes all the work (planning, executing, monitoring & controlling and
closing processes) in order to deliver the product with intended results. Many management products
(including project plans, registers, lessons learned, change requests, etc.) are created within the project
scope in order to allow the creation of the product according to the product scope.

As you would have seen, the PMBOK® Guide is mainly about the Project Scope as it provides guidance
on how to carry out the planning, executing, monitoring & controlling and closing processes.

94 | P a g e
Cost of Quality: Cost of Conformance / Cost of Non-conformance
 Cost of Conformance: the costs incurred by carrying out activities to ensure the project and deliverables
conform to the quality requirements and avoid failure (i.e. building quality into the project processes).
o Cost of Conformance can be broadly divided into two categories:
 Prevention Costs — money spent on activities/equipment to prevent defects from arising
in the first place, e.g. :
 Equipment update and maintenance
 Training provided to staff
 Documentation
 Following quality standards
 Time and human resources involved
 Quality Assurance activities
 Appraisal Costs — money spent on those activities to inspect and dig out defects to
prevent these defects from getting into the hands of the customers, e.g.:
 Testing and inspection
 Destructive testing loss
 Quality Control activities
 Cost of Non-Conformance: money that needs to be spent for not conforming to the quality requirements.
o Cost of Non-Conformance can also be broadly divided into two categories:
 Internal Failure Costs — the costs incurred when defects in the deliverables are detected
internally (i.e. not yet presented to the customers)
 Defect Repair
 Rework
 External Failure Costs — the costs incurred when defects are found the deliverables have
been delivered to customers and in actual use (this is the worst kind of quality costs)
 Warranty work
 Liabilities
 Loss of business goodwill

Both the Cost of Conformance and the Cost of Non-Conformance can be collectively referred to as
the Cost of Quality. Cost of Conformance is considered much lower than the Cost of Non-Conformance.

Illustrated Example
During the writing of the Book, a lot of time, efforts and money are involved in the editing and
proofreading of the book to ensure all the content of the book is accurate and error-free. These Cost of
Conformance activities include reviews (in multiple times) by the author, editors and subject matter
experts. Oftentimes, current credential holders and students are also invited to read through the book to
provide valuable feedback. Extensive testing on printing and production will also be carried out to ensure
the final product is in the perfect shape. All these would involve considerable time and costs.

However, if the publisher would like to accelerate the delivery of the Book to market after a change of the
exam syllabus by leaving out these Cost of Conformance activities (i.e. once the author has finished the
writing, it will go directly into printing). Aspirants would initially be pleased to be able to receive the
book so early to facilitate their exam preparation. But, they will later find that the content contains a lot of
errors (in definitions, concepts and even the mock PMP® exams) that hinder their studies or even cost
their exam failure. A lot of bad comments and low ratings would be given to the book so other students
will consider this book to be of low quality — that’s a loss of a lot of reputation and business.
95 | P a g e
Work Package vs Activity
 Work Package: a work package is the lowest level element of the WBS (Work Breakdown Structure)
through decomposition of the project scope in the “Create WBS” process.
o The Work Package is the lowest level in the sense that meaningful estimation of cost and duration
for the scope of work included can be achieved.
o One Work Package can contain many activities which are to be performed by one or more project
team members.
o For Project Scope Management
 Activity: an activity is a small enough unit of work that needs to be carried out to fulfil the project scope.
o The Work Package is further decomposed into activities (which are entered into the “Activity List”)
o The activity list is to be used to develop the project schedule.
o Every activity has a start and end day (duration), there may be some sort of logical relationship
between the activities.
o For Project Time Management

There is no recommended or fixed way of how detailed the “Work Package” or the “Activity” need to be.
The detail level should be suitable for the project in question to give meaning estimation and planning.

Illustrated Example
The following are my “work packages” to be included in my PMP® Exam prep:
 Fulfil the Exam Registration Requirements
 Revise the Exam Syllabus
 Assess My Readiness
 Take the Exam (and pass in first try)

And the following are the activities under each work package of exam study:
 Fulfil the Exam Registration Requirements
1. Get 35 Contact Hours of Project Management Education with PM PrepCast™
2. Get enough project management experience
3. Fill in the online registration form
4. Pay the fee
5. Respond to audit request (if required)
 Revise the Exam Syllabus
1. Read the PMBOK® Guide once
2. Read Andy Crowe’s How to Pass the PMP® Exam in First Try once
 Assess My Readiness
1. Try out online mock exam question banks
2. Get over 70% for at least 2 full-length mock exams
 Take the exam (and pass in first try)
1. Schedule the timeslot online through Prometric
2. Get up early on the day
3. Get to the Exam Centre 30 minutes early
4. Take and pass the exam

As you can see, for each work package there are many activities. The work packages can give us an
overview of what need to be done (for scope estimation) while the activities can give us a detailed account
of what are actually involved (for time estimation).
96 | P a g e
Critical Path Method (CPM) vs Critical Chain Method (CCM)
 Critical Path Method (CPM): the CPM is the most popular scheduling method which involves the
calculation of early start (ES), early finish (EF), late start (LS) and late finish (LF) through forward and
backward passes in the project schedule network diagram. This will facilitate the project manager to
estimate the buffers (floats) or the lack of for individual activities on the schedule network path.
o The Critical Path Method focuses on the sequence of activities/tasks to allow the project team to
visualize the overall flow of the tasks.
 Critical Chain Method (CCM): the Critical Chain Method actually builds on the Critical Path Method by
considering the resource availabilities and their dependencies along all the task chain and adding buffers
to the end of the chain to account for scarcity of resources in order to protect the project schedule from
slipping. This may result in a new Critical Path to be identified instead of the one found in CPM.
o The Critical Chain Method is derived from the “Theory of Constraints”, it focuses on resource
availability and dealing with uncertainties/changes.
o Instead of micro-managing the schedule of individual activities of the network path with task-
based buffers, Critical Chain Method focuses on managing the overall buffer of all the activities on
the chain. This will allow the project schedule to be in better control.
o If used properly, the Critical Chain Method will achieve higher efficiency by removing implicit
buffers of individual tasks and lower schedule risks.
o There are 3 types of buffers:
 Project Buffer: placed at the end of the project, the project buffer provides contingency
for the critical chain activities
 Feeding Buffer: placed at the end of non-critical chains in order to match the duration of
critical chain
 Resource Buffer: placed on the critical chain to allow rooms for the designated resources
to work on the critical chain tasks

Illustrated Example
 The Critical Path Method allows the project team to easily visualize the sequence of tasks and the
estimated duration of individual tasks in a straight-forward manner. However, since there are no overall
buffers to be added to the critical path, project team members may, while estimating for the duration of
individual tasks, try to add “implicit buffers” conservatively to each task with a view to protect the overall
schedule. This may result in “too much” buffers added to the critical path and make the estimation not
efficient. The project manager need to monitor closely the progress of individual tasks as one task
progresses at a slower than expected pace will adversely affect the whole project schedule.
 The Critical Chain Method, just put the tasks together in a chain by considering the minimal time needed
for individual tasks. An overall “project buffer” is added to the end of the chain which provides some
protection against the project schedule. This may result in higher efficiency of the buffer estimation by
combining the individual implicit buffer for an explicit buffer. Team members would be able to provide a
more aggressive schedule for each task as there is an overall buffer to protect the project schedule. The
PM will focus on managing the overall buffer during the executing and monitoring processes.

Summary
 Terms used in Critical Path Method: Forward Pass, Backward Pass, Early Start, Late Start, Early Finish, Late
Finish, Slack / Float, Total Slack / Float, Calculate the Duration, Critical Path

97 | P a g e
  Terms used in Critical Chain Method: Project Buffer, Feeding Buffer, Resources Buffer, Critical Chain,
resource constraints

Contingency Reserve vs Management Reserve

 Contingency Reserve: contingency reserves are money added to the project cost estimates by the project
manager for uncertain events / risks that might happen (also known as “known unknowns”).
o to manage identified risks
o the amount is calculated based on risk management techniques defined in the risk management
plan (e.g. Expected Monetary Value (EMV) or Decision Tree Method)
o the project manager has the full authority to make use of the contingency reserve once the risk(s)
has/have materialized
o contingency reserve is included in the cost baseline (Cost Baseline = Project Cost Estimate +
Contingency Reserve)
o once a risk is not realized, the contingency reserve set aside for that risk would be released
 Management Reserve: management reserves are money added to the project overall budget by the
senior management for uncertain events that are not even thought of (also known as “unknown
unknowns”, i.e. risks not shown in the risk register).
o to manage unidentified risks (i.e. risks that cannot be identified through the risk management
processes)
o the amount is based on the organization policies and/or complexity of the project (usually
“guessed”(not scientifically) at 5 – 15% of the total budget)
o the management reserve is controlled by a representative from senior management (NOT the
project manager), prior approval must be sought before utilizing the reserve on the project
o management reserve is NOT included in the cost baseline but in the project overall budget
(Project Budget = Cost Baseline + Management Reserve)
o the management reserve would be kept until the end of the project
o NOTE: in reality, management reserve is seldom set aside in real world projects as many consider
the organization would provide extra funding upon project managers’ requests should
circumstances require anyway; however, this is NOT PMP® Exam’s way of doing project
management

Illustrated Example
To illustrate the difference between Contingency Reserve vs Management Reserve, we will look at the
events that require the use of each:

 You are a project manager for a critical building project in an earthquake prone zone. A minor earthquake
happened yesterday that had destroyed some of the machinery. You, as the project manager, would
immediately make use of the Contingency Reserve to repair / replace the broken machinery in order to
move the project forward. — Since earthquakes are considered a risk (threat) to the project (know
unknown), funding has already set aside as contingency reserve in preparation for such risks.
 Later in the project, the site the project was working on was struck by a tiny asteroid at night that resulted
in the destruction of the building foundation. You, as the project manager, immediately reported the
event to the senior management which authorized the use of Management Reserve immediately to clear
the area and rebuild the foundation. — Since asteroid strike is NOT considered a risk that is possible
enough to enter into the risk register.

98 | P a g e
Quality Control vs Quality Assurance
 Quality Control: quality control is in the “monitoring and controlling process group” and is concerned
with the activities and measures taken to achieve quality requirements (as in the Control Quality process).
o In simpler words, Quality Control is concerned about the quality of the “products/deliverables“.
Its major aim is to ensure the correctness of and check for defects in the products/deliverables.
o Quality Control is a “reactive” process to inspect the products/deliverables to detect any non-
conformance in them.
o Quality Control is used to verify the quality of the product.
 Quality Assurance: quality assurance is in the “executing process group” and is a process based approach
to ensure the processes and methodology associated with the production of the final
deliverables/products are defect free such that the deliverables/products can fulfil the quality objectives
(as in the Perform Quality Assurance process).
o In simpler words, Quality Assurance is concerned about the “processes“. Its major aim is to avoid
defects in products/deliverable at all by assessing the effectiveness of current quality control
processes and issue change requests as necessary to correct any defects in the processes.
o Quality Assurance is a “pro-active” process involving understanding the requirements and
formulating measures (e.g. quality audit, training, etc.) to achieve the requirement objectives.
o Quality Assurance is used to manage the quality of the processes.

As seen from the above, Quality Control and Quality Assurance processes are closely related and interact
with each other. The quality assurance process defines the procedures to carry out quality control, and
feedback from quality control will influence the quality assurance process. Should defects are found from
quality control processes; the information would be used by quality assurance processes to determine any
corrective/preventive measures that are needed. That’s why “Quality Control Measurements” are an
input to the Perform Quality Assurance process in the Quality Management process group.

Illustrated Example
To illustrate the difference between Quality Control and Quality Assurance, we will look at what each one
would look at in the project:

 Quality Control would examine the final product against the quality requirements set out in the Quality
Management Plan and report as Quality Control Measurements.
 Quality Assurance would make use of the Quality Control Measurements and other information to re-
assess whether the correct methodology and processes are used in the project and the Quality Control
process is looking at the correct/most effective metrics, etc.

99 | P a g e
Assumptions vs Constraints vs Requirements
 Assumptions: these are factors that are used in the planning process to allow plans to be created with
reasonable details (since without those assumptions, forecasts and budgets cannot be made).
Assumptions are reasonably believed to be true based on experience (e.g. lessons learned), knowledge or
information at hand.
o Assumptions are needed for estimating the scope, schedule, costs, etc. during the project
planning and are well documented in project management plans.
o The risks of false assumptions are dealt with during risk management planning. If the assumptions
would adversely affect the project if found to be false, the assumptions would be documented as
risks for risk management.
o After completion of the project, the project management will need to assess the accuracy of
assumptions and document any findings in lessons learned.
 Constraints: these are factors that need to be taken into accounts when planning the project. Constraints
are mostly restrictions imposed on the project. However, with good planning, constraints can be a real
benefit to boost effectiveness and efficiency.
o Project managers and the team need to work within the constraints of the project in order to
achieve project success. Managing the constraints is one core responsibility of the PM.
o In the PMBOK® Guide, constraints include a total of 6 competing project constraints:
 Scope – what are required / expected of the project?
 Time – when will the project need to be finished?
 Cost – how much money is provided?
 Quality – what is the expectation of the outcome? high or just okay?
 Resources – who are the working team members? what materials are provided?
 Risk – what can go wrong with the project and how to deal with them?
o These constraints on the project are interrelated, change in one constrain will affect some/all the
others. For example, if one skilled team member has just resigned, more time would be needed to
finish the project. Likewise, the quality, cost, risk, etc. would also be affected.
 Requirements: these are features/capabilities/products/deliverables that expected to be delivered from
the project as interim or end results.
o Requirements focus on the capability of the deliverable rather than the project itself.

Illustrated Example
Suppose you are just named the project manager of a new hybrid car. The sponsor requests, among others:
1. a demo unit to be created by the next car show in 1.5 years’ time,
2. the car to have a 0-60 mph time of 8 seconds; and
3. it meets the statutory emission requirements for clean car rebate.

Which of these is assumption, constraint and requirement?

 Requirements are the easiest to spot as these are features directly related to the deliverable. So “having a
0-60 mph time of 8 seconds” is a requirement.
 How about “a demo unit to be created by the next car show in 1.5 years’ time”? In plain English, this is a
requirement by the sponsor. However, in PM terms, the 1.5 year is a limiting time factor which is
considered a “constraint” for the project (but not the deliverable). So, it is a constraint.
 The third one: is a requirement in itself as it is concerned about the cleanliness of the exhaust gas from
the car. However, there is an underlying assumption which is the statutory emission requirement would
NOT be changed during this 1.5 year as the goals are aligned to the current statutory emission
requirements which is an assumption believed to be true at the beginning of the project.
100 | P a g e
Corrective vs Preventive Actions
 Corrective Actions: actions taken when the project deviates from the scope, schedule, cost or quality plan
in order to bring the project performance back to the baselines. Corrective actions are reactive actions.
o These are actions taken when non-conformances have already been detected to rectify the cause
of the issue.
 Preventive Actions: these are actions taken when the project is likely to trend away from the scope,
schedule, cost or quality plan to ensure the project performance is aligned to the baselines. Preventive
actions are proactive actions.
o These are actions taken to prevent issues/problems from occurring in future.

Illustrated Example
Mid-way in the production plant building project, you have noticed that the time taken to build the
building may be longer than expected owing to the possible frequent occurrence adverse weather this year.
You try to squeeze more time by asking the machinery to be installed before all the floors have been built.
By it, you have ensured the project to be finished within the original schedule. It is Preventive Action.

During the installation and testing of the production machinery, you found that the products created from
the machine do not meet the requirements documented in the project plan. The team takes a considerable
time solving the problem which results in the late delivery of the machine and may cause the whole
project to deliver late. You try to compress the schedule by asking another team to work concurrently on
site for the rest two machines in order to the installation schedule on time. The actions
taken are Corrective Actions.

Which is Preferred?
Given PMI always prefers the project managers to be proactive in their roles, preventive actions are
always preferred. Project Managers should work hard to anticipate and identify any likely occurrence of
issues through proactive measures and respond promptly to prevent it from ever occurring.

Preventive actions will ensure the project to proceed smoothly and follow the baselines closely.

Corrective Actions, Preventive Actions and Defect Repairs

Defect repairs are actions taken when the deliverable does not meet the agreed quality requirements if
the deliverable can still be rectified. Otherwise, a complete rework is needed to create the deliverables
from scratches. Both defect repairs and rework impose a high cost of quality to the project and are least
preferred. Prevention has the lowest cost of quality.

Take the production plant project again, you have delivered the plant to the client but was found that one
production machine fail to produce the products as required in the contract. It was found out that the
wrong kind of components has been used. You need to repair the defects by dismantling part of the plant
and install the machine again (defect repairs). Worse, a floor of the plant suddenly collapsed while you
carried out the defect repair and it was found that the concrete used in building the plant was sub-standard.
Your company is responsible for dismantling the whole plant and builds it up again (rework).

101 | P a g e
Statement of Work (SOW) vs Project Scope Statement
 Statement of Work (SOW): is also known as Project SOW (to distinguish with Procurement Statement of
Work) is a document including the high level description of the intended deliverables of the project.
 Project Scope Statement: a document including more details than Project Statement of Work on the
scope and deliverables of the project, major assumptions and constraints are also added if appropriate.

It seems that Statement of Work and Project Scope Statement are very similar as they both contain the
descriptions of the project deliverables. However, when researched in more depths, it can be found that:
 Statement of Work (SOW) contains high level information of the project deliverables
 Project Scope Statement contains more details of the deliverables plus assumptions and constraints

Illustrated Example
Statement of Work (SOW) contains at least the following three elements:
1. Organization strategic plan
2. Business needs
3. High level product scope

These are meant to provide an overarching direction for the project only, NOT the full implementation
details. The high level product scope contained in the statement of work must be further developed in
order for all stakeholders and project team members to really understand what are expected from the
project. This is where the Project Scope Statement comes into play.
Project Scope Statement on the other hands includes lots of details for the project (not necessarily
include all of the following): objectives, project scope, product scope, requirements, boundaries,
deliverables, acceptance criteria, constraints, assumptions, milestones, cost estimation, specifications,
configuration management requirements, approval requirements, etc.

The Project Scope Statement may be elaborated progressively over time when more details on
requirements and constraints are known during the requirements collection and scope defining processes.

Project Scope Statement together with WBS and WBS Dictionary form the Scope Baseline.

Which Comes First?

These two terms are often confused in real-world practice as project managers may use the two terms
interchangeably to refer to documentation containing all the work to be done for the
project. But according to the PMBOK® Guide, the Statement of Work (SOW) would only contain very
high level scope while the Project Scope Statement contains the full details.

Since the Statement of Work (SOW) contains a high level description of the project scope while the
Project Scope Statement contains the lower level (more detailed) description of the project scope, it can
be easily inferred that the Project Scope Statement is developed from the contents of the Statement of
Work (SOW). So the following documents need to be developed in sequence:
1. Project Statement of Work (SOW) – documenting the very first ideas for the project
2. Project Charter – formally authorizing the project and project manager (= SOW + Business Case + Contract)
3. Project Scope Statement – when the project manager is collecting requirements and defining scope
102 | P a g e
Quality vs Grade
In real life, we have been using the terms “Quality” and “Grade” mostly interchangeably. Low grade
products would be described as low quality and vice versa. In the PMP® Exam, “Quality” and “Grade”
are totally different concepts which aspirants should not get confused. Let’s go to the definitions of them.
 Quality: a measure of how the product conforms to the requirement / fit for the expected use level.
o If the product has high quality, it should meet the quality requirements set out in the production
specification and is fit for the uses as described. However, if it does not, it is said to have low
quality.
 Grade: a measure of which level the product is expected to perform.
o If the product is low grade, it is intended / designed to be used on an everyday condition than in
extreme cases.

Illustrated Example
In order to help PMP® Aspirant understand the differences between Quality vs Grade, let’s consider the
following case.

Suppose you are buying a mobile phone, what would you look for?

 If you just want a mobile phone with basic calling functions, the “low grade” option is a mobile phone
allowing you to make and receive phone calls only (probably with a number pad for you to input the
telephone number). A “higher grade” phone would have a small screen to show the telephone number as
well as functions to store and retrieve same frequently used phone numbers.
 If you want the “high grade” or “premium grade” options, you would select the “flagship” phones which
boosts a large touch screen, a camera with high pixel count and aperture, the latest iOS or Android OS,
some killer features (e.g. sexy metal frame design, infra-red control, zoom lens, curved screen, etc.). You
get the idea.
 Usually, the ones with higher price tag attached are the higher grade models.

But besides the features, what you would probably also consider whether the phone is reliable and durable.
This concept is known as the quality. A “high quality” product will do what it is intended to do reliably
while a “low quality” phone may break down after several hours of use (this is quality issue but NOT
grade issue as a phone will never designed to work for several hours only). Like grade, low quality phones
are usually cheaper.

So, the most sensible advice for purchasing a mobile phone is: always look for a good quality one with a
grade that meets your requirements.

Quality & Grade: Which is more important?

Judging from the above examples, we can further infer that:

 A product with low grade is acceptable since it fulfils its intended functions and expectations (e.g. less
features) probably at a lower cost.
 A product with low quality is a problem, since it does not meet the requirements and expectations (e.g.
breaks down easily).
 A high quality product will always meet your expectations while a low quality product won’t.
103 | P a g e
Accuracy vs Precision
Accuracy and Precision are descriptions of repeated measurements taken from a process. Let’s go to the
definitions of them.
 Accuracy: a measure of how the measured values close to the target value
o If the measured values are accurate, they may not be precise as they can be larger or smaller than
the target value on a wide range.
 Precision: a measure of how the measured values close to each other (but not necessarily close to the
target value)
o If we say the measurements are very precise, we do not give out any hint on whether the
measurements are accurate (i.e. close to the target value).

Illustrated Example
Suppose you are a supplier for metal wire and a client ordered five wire of 100 meters. The wire cutting
machine cuts the wires according to your instruction and you measured them manually to get the
following data:
 First wire: 100.6 m
 Second wire: 100.5 m
 Third wire: 100.7 m
 Fourth wire: 100.7 m
 Fifth wire: 100.5 m

How would you describe the measured values? Accurate or Precise?

Answer: The measured values are precise but NOT accurate. While they are close to each other (within
~0.2%), they are not close to the desired value of 100 meters.

What about if the following data are recorded:

 First wire: 100.2 m
 Second wire: 100.1 m
 Third wire: 99.8 m
 Fourth wire: 99.8 m
 Fifth wire: 100.0 m

Answer: The measured values are accurate but NOT quite precise. While they are close to the
target (within ~0.2%), they are not as close to each other as in the first case.

Accuracy & Precision: Which is more important?

The question now is which attribute is more important in quality management? I am sure judging from the
example above, you will see that accuracy is MUCH MUCH MORE important than precision. The
client required wires of 100 meters in length, your job is to give wires with length as close to 100 meters
as possible in order to satisfy the requirement (of course, some client would welcome if you give more
than they request, that would not be considered in this case). A precision wrong length is still wrong, no
matter how precise the measurements are. Only when the output is accurate then it is meaningful to
strike for precision.

104 | P a g e
Accepted Deliverable vs Verified Deliverable
 Verified Deliverable: Output from project tasks that meets by quality control measures as specified in
Quality Management Plan; an output of the Control Quality (Project Quality Management)
 Accepted Deliverable: The verified deliverables from perform quality control that have been approved by
the customer/stakeholders to fulfil the acceptance criteria; an output of Validate Scope (Project Scope
Mgnt)

Where is “Validated Deliverable”?

 Validated Deliverable: this term was originally mentioned a lot in PMBOK® Guide 5th Edition but later
amended as “Verified Deliverable” in the errata. Now there is only 1 mention of “Validated Deliverable”
on page 251, however, the term there should also be updated as “Verified Deliverable”.

So, remember, there are only “Verified Deliverable” and “Accepted Deliverable” but NO “Validated
Deliverable”. However, the question remains: why “Validated Deliverable” is not amended as “Verified
Deliverable”? It all has to do with the clarification of the definitions of “Validation” and “Verification” in
PMBOK® Guide 5th Edition.

Verification vs Validation
 Verification: a quality control process to ensure the deliverables meet the regulation, requirements,
specifications, etc.
o According to the PMBOK® Guide 5th Edition: Verification is “the evaluation of whether or not a
product, service, or system compiles with a regulation, requirement, specification, or imposed
condition. It is often an internal process”.
 Validation: the acceptance process by customers / stakeholders to formally acknowledge the deliverables
meet their requirements.
o According to the PMBOK® Guide 5th Edition: Validation is “the assurance that a product, service,
or system meets the needs of the customer and other identified stakeholders. It often involves
acceptance and suitability with external customers”.

Illustrated Example
Suppose you had purchased a new flat and awarded the renovation contract to Contractor A. Contractor A
had previously collected and discussed all your requirements and you had agreed to the quotation.

Contractor A then asked several painters to paint the walls of all bedrooms in beige and the common
rooms in white according to your requirements. After painting, Contractor A would read the contract
again and inspect every room to ensure that the rooms were painted in the correct color [Verification –
that’s the “verified deliverable”].

Afterwards, Contractor A asked you to come and check the work. You and Contractor A walked from
room to room to look closely at the painted walls and you were mostly satisfied with the
work [Validation – that’s the “accepted deliverable”]. However, you suddenly realized that you wanted
the baby room to paint in pink and asked Contractor A to make the amendment [Change Request] ……

105 | P a g e
Project Calendar vs Resource Calendar
 Project Calendar: Project Calendar indicates the days, dates and time the project team is/planned to be
working.
o It shows which days/time of day the project team will be working and which days/time of day the
project will NOT be working (e.g. holidays, etc.).
o The project calendar is concerned about the project environment and constraints (e.g. noisy work
will be restrained during the day).
o Project calendars can be part of OPA (which is input to many processes).
o e.g. non-urgent road enhancement projects can only be carried out during weekends when the
traffic is low
 Resource Calendar: Resource Calendar indicates the days, dates and time a particular resource (human
resources/machines/etc.) will work.
o In the PMP® Exam, Resource Calendar is mainly about Human Resources as it is mentioned in the
Project Human Resource Management Knowledge Group.
o This is because a particular resource may be required to work concurrently for several projects
and its share of availability for a particular project is limited, or there is planned vacation for
resources, etc.
o Resource Calendar is included in the Staffing Management Plan (which is part of the Human
Resource Management Plan)
o Output of Acquire Project Team process — by updating the original Resource Calendar (which was
created in Plan Human resource management) with the details of the team members which were
acquired during Acquire Project Team process

The Project Calendar and Resources Calendars are continually updated during the planning and executing
processes to reflect the changes in project environment and project team availability. These two types of
calendars together help the Project Manager to develop the Project schedule.

Illustrated Example
Let’s take the PMP® Exam prep as an example, for an Aspirant named David having a full-time project
manager job:

 To balance study, family obligations and relaxation, David has decided to set the project calendar
including only weekdays as the weekends are reserved for the family.
 David has also promised his kids for a short trip during Christmas vacation and therefore the second half
of December is excluded from the Resource Calendar.

While developing David’s project schedule, he has to take into accounts the resource calendar and the
project calendar in order to give a realistic and achievable schedule for his project.

Summary
As their name suggests:

 the Project Calendar is concerned about the Project

 the Resource Calendar is concerned about human resource (team members)

106 | P a g e
Resource Leveling vs Resource Smoothing
During “Develop Project Schedule”, activities are usually first sequenced and assigned resources based on
the dependencies between different activities (either mandatory/discretionary dependencies) without
consideration of the loading of different activities. Thus, some resources may be over-loaded. In order to
solve this issue, Resource Optimization Techniques are employed.
 Resource Leveling: Resource Leveling is a resource optimization technique in which the Project Manager
adjusts the start dates and finish dates of different activities in order to balance the demand for resources
vs available supply.
o Resource Leveling is always carried out first
o e.g. Under normal situation, it is generally considered the man hour for each team member is 45
hours per week, if more than 45 hours’ work is assigned to a member in a particular week (which
is not recommended), the activities must be adjusted by resource leveling and trimmed down to
45 hours — i.e. it takes more days to complete the activities than originally planned
 Resource Smoothing: Resource Smoothing is a resource optimization technique in which the Project
Manager adjusts the timing of different activities so that the requirement for resources does not exceed a
certain pre-defined limit.
o The pre-defined limit may be statutory or a company policy, e.g. no more than 38 hours in a week
o After Resource Leveling, Resource Smoothing is used to ensure the demand for a particular
resource is more balanced over time — i.e. if the original plan requires the resources to work 45
hours during the first 3 weeks but only 20 hours for the next 2 weeks, resource smoothing will try
to “smooth” the hours per week to around 35 for the 5 weeks of the project duration
o While carrying out resource smoothing, care has to be taken to balance between the desire pre-
defined limit and the overall duration of the project/activities. In this regards, the desired pre-
defined limits may not always be possible.

Illustrated Example
David is having a full-time job; the maximum number of hours that can be devoted to exam prep is 20
hours per week. However, he prefers to work 10 hours per week in order to spare some time for his family.

He hopes to finish online course and get the 35 Contact Hours Certificate within two week. However,
since it is estimated to take around 50 hours to be able to complete the online course, the original plan is
NOT feasible. David has to employ Resource Leveling to extend the schedule to 2.5 weeks.

He also uses Resource Smoothing to decrease the workload to around 15 hours per week in order to
leave some breathing space. The final duration of is estimated to be around 3.33 weeks.

Summary
The end goal for the Resource Optimization Techniques:
 If it is for meeting resource constraints (e.g. statutory requirements, resource availability), Resource
Leveling is employed. Resource Leveling is a necessary as the original plan is not practical and feasible.
 If it is for better utilization of resources or achieving the desired level of efforts (e.g. 38 hours per week to
allow for some buffers of resources), Resource Smoothing is employed. Resource Smoothing is preferred
but not absolutely necessary.

Resource leveling is always applied first before applying resource smoothing.

107 | P a g e
Functional vs Projectized vs Matrix Organizations
 Functional Organization: are organized around the functions the organization needs to be performed.
o Functions include: Human Resources, Information Technology, Sales, Marketing, Administration…
o This is the traditional structure of organizations
o The “Project Management” role will be performed by a team member of a functional area under
the management of a functional manager
 Resources are controlled and authorized by functional managers
 The “Project Management” role would act more like a “Project Coordinator” or “Project
Expediter” who do not usually carry the title of “Project Manager”
 Project Management is considered a part-time responsibility
 Authority of the “Project Manager” is very limited
 Projectized Organization: are organized around projects for maximal project management effectiveness.
o The Project Manager is given more authority and resources control
o The Project Manager is responsible to the Sponsor and/or Senior Management
o The Project Manager is usually a full-time role
o Team members are usually co-located within the same office / virtually co-located to maximize
communication effectiveness
o There can be some functional units within organization, however, those units are having a
supportive function only without authority over the project manager
 Matrix Organization: Matrix Organizations are organizations with structures that carry a blend of the
characteristics of functional and projectized organizations.
o Matrix organizations can be classified as weak, balanced or strong based on the relative authority
of the Functional Manager and Project Manager
o If the “Project Manager” is given a role of more like “Project Coordinator” or “Project Expediter”,
then the organization is considered “Weak Matrix”
o If the “Project Manager” is given much more authority on resources and budget spending, the
organization is considered “Strong Matrix”

Functional Weak Matrix Balanced Matrix Strong Matrix Projectized

Project Manager Role

Part-time/Full-time Part-Time Part-Time Full-Time Full-Time Full-Time

Supportive Staff Nil Nil or Part-Time Part-Time Full-Time Full-Time

Authority Nil Low Low to Moderate Moderate - High High to Total

Project Resource Control

Resource Moderate -
Very Low Low Low to Moderate High to Total
Availability High

Functional Functional Mixed Project Project

Project Budget I/C
Manager Manager (FM with PM) Manager Manager

108 | P a g e
Project Life Cycle vs Product Life Cycle
 Project Life Cycle: The Project Life Cycle is a collection of sequential/overlapping project phases which are
determined by the project control needs of the organization.
o Projects are usually divided into phases for enhanced overall control of the project by the
organization. Project Life Cycle may include, but not limited to:
 Analysis
 Design
 Development
 Testing
 Launch
 Closure
o The project phases may be sequential or overlapping.
o Project life cycles will be dependent on the industry, the organization or the type of project.
o Projects within an organization may adopt the same Project Life Cycle definition according to the
Organization Process Assets.
 Product Life Cycle: The Product Life Cycle is a collection of sequential and non-overlapping product which
are determined by the control needs of the organization.
o Product Life Cycle focuses primarily on the product (i.e. the deliverables of the project).
o Product Life Cycle consists of sequential and non-overlapping phases including:
 Ideation
 Creation
 Introduction
 Growth
 Maturity
 Decline
 Retirement
o During a product life cycle, a number of Project Life Cycle may be involved to create, improve,
upgrade, etc. the product to match market needs — projects are about bringing changes.

How About Project Management Life Cycle?

In the PMBOK® Guide, the Project Management Life Cycle is defined as:

 Initiation
 Planning
 Executing
 Monitoring & Control
 Closing (phase or project)

Each project phase/project must involve all these project management process groups as defined by PMI
in order to successfully carry out the project.

109 | P a g e
Earned Value Measurement: Discrete Effort vs Apportioned
Effort vs Level of Effort
 Discrete Effort: Discrete Effort is work that can be planned and measured with specific output.
o also known as “Measurable Effort”
o the work can be directly associated with a Work Breakdown Structure (WBS) component and can
be measured with percentage of progress
o e.g. the coder has already finished 500 lines of code for the component with an estimated length
of 1000 lines — 50% completion
 Non-discrete Effort: Opposite of Discrete Effort, further divided into two types:
o Apportioned Effort: Apportioned Effort is work which cannot be divided into discrete efforts and
is allotted proportionately to other discrete effort(s).
 the work is directly associated with a Work Breakdown Structure (WBS)
component/deliverable, usually cannot be separated from the discrete efforts
 Apportioned Effort supports Discrete Efforts and therefore its earned value is directly
proportional to the discrete effort
 e.g. inspection, quality assurance, verification, validation activities
o Level of Effort (LoE): Level of Effort is supportive work that does not produce definitive
output but is measured with (passage of) time.
 the work is not associated with a Work Breakdown Structure (WBS)
component/deliverable
 Level of Effort activities support an activity or the whole project
 usually consists of short duration of work repeated periodically throughout the project
 Level of Effort activities cannot be put in the critical path as they do not add time to the
project duration
 Level of Effort activities are included to reflect the resource requirements of activities
without deliverables, such as:
 project management, meetings, administrative work, accounting, maintenance

Illustrated Example
For the exam prep project for the PMP® Exam, one would usually have the following activities/effort
involved (to name but a few). Since all these efforts would involve project resources, planned value (PV)
should be allocated for each of these activities. Many of these are actually Discrete Effort with
measurable progress/results; however, some of these are Apportioned Effort and Level of Effort (LoE) as
indicated in the list below:

 Exam Prep Project Management — Level of Effort (LoE): to overlook the whole project, measured with
the passage of time, will end only after attempting the exam (the target exam date)
 Getting 35 Contact Hours of Project Management Education — Discrete Effort
 Applying for the exam — Discrete Effort
 Responding to the Audit (if needed) — Discrete Effort
 Finish reading the PMBOK® Guide — Discrete Effort
 Finish reading a exam prep Book — Discrete Effort
 Taking mock exams — Discrete Effort
 Quality assurance of the process / knowledge — Apportioned Effort: relative the the percentage of
completion of the whole exam prep
 Attempt and pass the exam — Discrete Effort

110 | P a g e
Project Team vs Project Management Team
 Project Team: The Project Team is a collective term describing all the people that are involved to work on
the project, from planning, executing to closing.
o The Project Team includes the Project Management Team.
o Other sub-sets in the project team may include: design team, specialty teams.
o In small projects, the whole team may be responsible for project management and there is NOT a
single Project Management Team defined.
 Project Management Team: The Project Management Team is responsible for the project management
and leadership activities such as: initiating, planning, executing, monitoring, controlling and closing of the
project/project phases.
o The Project Management Team is a subset of the Project Team, including the Project Manager.
o The Project Management Team is NOT responsible for executing out the project.
o The Project Management Team is also known as the core, executive or leadership team.

Illustrated Example
Let’s take the project of publishing a book as an example. In the book project, many people, in addition to
the author(s), are involved to get the book into the hands of Aspirants:

 Project Management Team — responsible for coordinating and managing the project to ensure the target
publication date and budget are met and the processes are followed through (i.e. overall successful
delivery of the project deliverable)
 Editorial Team — including the author(s), editor(s) and proof-reader(s), etc., responsible for the quality of
the contents of the book
 Logistics Team — to coordinate with the typesetter, printer, delivery services, etc. to get the Exam Prep
book to the vendors (both online and offline)
 Sales and Marketing Team — to publicize the release of the book, to get reviews from users and to
response to orders, etc.

As you can see, the Project Management Team is a small yet crucial team within the Project Team, but
the success of the project is largely dependent on the works of the Project Management Team. Aspirants
are privileged to be able to work in such an important team!

Summary:
Aspirants would need to remember the key differences between Project Team and Project Management
Team:

 Project Team: all the human resources involved in the project (Project Manager is one of them)
 Project Management Team: includes only the human resources responsible for managing and controlling
the project (Project Manager is one of them)

111 | P a g e
Project Procurement Management: Contract Types
A contract is required if the organization needs to purchase resources/services from outside the company.
The type of contract needed depends on a number of factors: can the scope of the resources/services be
well defined, complexity of the resources/services, frequency of changes needed, risks involved...

Generally speaking, there are three major types of contracts to be used in procurement management:
1. Cost Reimbursable (a.k.a. Cost Plus)
2. Fixed Price
3. Time and Material (a.k.a. Unit Price)

Cost Reimbursable (Cost Plus): in which the buyer agrees to pay for the actual cost of the
materials/services plus an additional fee (maybe) for meeting/exceeding expectations. The risk is higher
on the buyer as the buyer needs to bear the risk of over budget.
 Cost Plus Fixed Fee (CPFF) — the buyer would need to pay the actual cost of the work plus a fixed fee
calculated based on the initial estimation
 Cost Plus Incentive Fee (CPIF) – buyer would need to pay the actual cost of the work plus an incentive fee
if the performance of seller meets mutually agreed pre-defined performance targets (objective evaluation)
 Cost Plus Award Fee (CPAF) – the buyer would need to pay the actual cost of the work plus an
award based on subjective evaluation on the seller’s performance by the buyer
 Cost Plus Percentage of Costs (CPPC) – the buyer would need to pay the actual cost of the work plus a fee
calculated based on a percentage of actual cost
Cost Reimbursable is suitable where the project is complex and the scope is not very well defined and
changes are expected. If the scope increases the cost would increase and the buyer needs to bear all. PM
would use Cost Reimbursable contracts when completing the tasks on schedule is top priority.

Fixed Price contracts: in which the buyer agrees to pay for the fixed agreed total price. The risk is
higher on the seller. Incentives may be offered according to mutual agreement. The risk is higher on
the seller as the seller needs to absorb any omissions, reworks, inflation and other external risks.
 Firm Fixed Price (FFP) – a fixed price is set for the seller to complete the contract scope unless there is a
change in the scope where amendments to the contract is needed
 Fixed Price Incentive Fee (FPIF) – the buyer would need to pay a fixed price for the completion of the
project plus awarding an incentive if the buyer meets or exceeds the agreed metrics (e.g. cost saving from
the cost ceiling, schedule, performance, scope, etc.)
 Fixed Price with Economic Adjustment / Economic Price Adjustment (FPEA / FP-EPA) – a fixed price
contract in which inflation is taken into account, usually for contracts that span several years. This
contract type offers more protection for cost increase on the seller side.
Fixed Price is suitable where the project is simple and the scope is very well defined and changes are not
expected. Project Manager would make use of Fixed Price contracts when controlling costs is top priority.

Time and Material (Unit Price) contracts: somewhere between Cost Reimbursable and Fixed Price. It is
a contractual agreement that specifies the price based on a per-hour or per-item basis only without fixing
the total amount. A ceiling price may be put in the contract. The risk is similar on both seller and buyer.

Time and Material contracts are suitable where the project is small or the scope is expected to be highly
variable at the time of signing the contract. Project Manager would make use of Time and
Material contracts when the project is not well defined at the beginning of the project in order to keep the
cost to be under control (e.g. by limiting the project scope based on funding availability).

112 | P a g e
Project Quality vs Product Quality
 Product Quality: product quality is the adherence/conformance of the product/deliverable of the project
to the pre-defined requirements/standards.
o Product Quality can be improved and guaranteed by quality control and quality assurance
 Quality control: concerned with the activities and measures taken to achieve quality
requirements
 Quality assurance: a process based approach to ensure the processes and methodology
associated with the production of the final deliverables/products are defect free
 Project Quality: project quality is concerned about the management and implementation of the project
processes to turn the project requirements into project deliverables
o Project Quality is assessed by carrying audit on the project management practices (which is
outside the scope of the PMBOK® Guide, somewhat performed by the role of Project Assurance in
PRINCE2®)

Illustrated Example
Let’s take the project of exam study and preparation as an example to illustrate the concept of Project
Quality and Product Quality. The Product of the exam preparation is of course getting the PMP®
Certificate.

By following closely the recommendations (e.g. exam prep courses, reference book, mock exams, study
plans and advices from exam takers), an Aspirant is able to pass the exam in first try — both the Project
Quality and Product Quality are considered high.

However, an Aspirant can get a quality product (i.e. passing the exam with flying colors) from the project
of exam prep without having a good Project Quality (e.g. constantly delaying the plan, not following all
the pre-defined processes and milestones, skipping some parts of the exam syllabus, etc.) — low Project
Quality and high Product Quality.

Summary:
To distinguish between Project Quality vs Product Quality, always remember the following definitions of
these:

 Product Quality is concerned about the conformance of the deliverables to pre-defined requirements
and standards.
 Project Quality is about the conformance of the management/execution of the project to pre-approved
processes. Project Quality is not to be tested in the PMP® Exam.

113 | P a g e
Project Time Management: Free Float vs Total Float
 Free Float: the amount of time (float) an activity on the schedule network diagram can be freely delayed
without affecting the early start of the of following/successor activity
o for activities NOT on the critical path
o Free Float can only be non-zero when two or more activities have a common successor activity
o Free Float = ES of successor activity – EF
where ES = Early Start, EF = Early Finish
 Total Float: the total amount of time (float) an activity on the schedule network diagram can be delayed
without affecting the project finish date
o for activities NOT on the critical path
o Total Float = LF – EF (or LS – ES)
where ES = Early Start, EF = Early Finish, LS = Late Start, LF = Late Finish

Note the following:

 Activities on the Critical Path have ZERO free float or total float.
 Total Float and Free Float for an activity may be the same or different depending on the other activities in
the schedule diagram.
 When you are asked to calculate the “Float” for an activity in the PMP® Exam, you are asked to calculate
the “Total Float“.

Illustrated Example
 Activity A — Get 35 Contact Hours (duration: 4 weeks)
 Activity B — Apply for the exam and pass the audit (duration: 6 weeks)
 Activity C — Write mock exams (duration: 3 weeks)

 Total Float of Activity C = LF – EF = 10 – 3 = 7 weeks

 Free Float of Activity C = ES of successor activity – EF = 7 weeks
 Though the Total Float and Free Float is the same in this case, that can be different!

Summary
To distinguish between Free Float and Total Float, always remember the following definitions of these:
 Free Float is the amount of time an activity can be freely delayed without affecting the early start of the
of successor activity
 Total Float is the total amount of time an activity can be delayed without affecting the overall project
finish date

Note: Float can be negative which indicates the activity must start before the predecessor activities have
finished to catch up with a target finish date, which probably caused by a delay in predecessor activities.
114 | P a g e
Project Cost Management: Cost Baseline vs Budget
 Cost Baseline: is the authorized time-phased spending plan for the project on which the project cost
performance is to be measured against. As the Cost Baseline is baselined and managed under
configuration mgnt, changes to the Cost Baseline must undergo proper change management processes.
o Cost Baseline includes all project activities/resources costs and the money set aside to respond to
risks identified (i.e. known unknowns) over time and it is usually represented as an S-curve
o Cost Baseline = Project Cost Estimates + Contingency Reserves
 Cost Budget: the allowable deviations requested based on customer expectations
o The Cost Budget is the estimate of total amount of money required for carrying out the Project,
including money set aside for identified and unidentified risks (i.e. unknown unknowns)
o The Cost Budget can be thought of as the Cost Baseline over time plus the Management Reserves
o Cost Budget = Project Cost Estimates + Contingency Reserves + Management Reserves

Cost Baseline vs Budget

Paul has determined to get certified through self-study, budget for getting PMP® Certification is as follow:
 PMI Membership Fee: US$139
 Project Management Training through self-study: US$199
 PMP® Exam Fee (for PMI Member): US$405
 You may also need to set aside budget for miscellaneous items (e.g. transportation, exam Prep book,
PMBOK® Guide, mock exams etc.): US$300
 PMP® Certification Cost: US$1043 which is the cost estimate for the PMP® Project

Paul will also need to set aside budget for any identified risks (e.g. unable to finish preparation on time —
postpone the exam, need extra learning aids…) which is expected to be US$500 (Contingency Reserve).

Paul is also advised to set aside money for any unknown unknowns which is set at around 10% of the
Cost Estimate at this time (according to his own decision), i.e. US$100 (Management Reserve).

 Total Cost Baseline = Cost Estimate + Contingency Reserve = US$1043 + US$500 = US$1543
 Total Cost Budget = Cost Baseline + Management Reserve = US$1043 + US$500 + US$100 = US$1643

Summary
The simplified formulas in order to understand the differences between Cost Baseline and Budget:
 Cost Budget = Cost Baseline + Management Reserve
 Cost Baseline = Cost Estimate + Contingency Reserve
 Cost Estimate = sum of costs for work packages/activities

In fact, for Project Cost Management, there are a number of terms that Aspirants need to understand:
 Cost Estimate: the aggregated costs for the work packages or activities of the project without making
allowances for risks
 Management Reserves: management reserves are money added to the project overall budget by the
senior management for uncertain events that are not even thought of (also known as “unknown
unknowns”, i.e. risks not shown in the risk register)
 Contingency Reserves: contingency reserves are money added to the project cost estimates by the
project manager for uncertain events / risks that might happen (also known as “known unknowns”)
115 | P a g e
Project Quality Management: Control Limit vs Specification
Limit
 Control Limit: the limit established for the control chart based on statistical analysis or from historical
records
o There are 2 Control Limits: Upper Control Limit (ucl) and Lower Control Limit (lcl) indicating the
maximum and mininium allowable values respectively
o By convention, the Control Limits would usually be±2 or ±3 standard deviations (σ) from the
target value, though this will vary from process to process
o If there are results falling outside the Control Limits, the process is said to be unstable (i.e. out of
control) ; root analysis is needed to investigate the special cause and rework/scrap would be
needed
o In addition, there are still some other pattern that will indicate the process is out of control, e.g. 7
consecutive data points on either side of mean (Rule of Seven)
 Specification Limit: the allowable deviations requested based on customer expectations
o There are 2 Specification Limits: Upper Specification Limit (usl) and Lower Specification Limit (lsl)
indicating the maximum and mininium allowable values respectively
o If there are results falling outside the Specification Limits (but within Control Limits),
improvement works would be needed to adjust the process to give greater precision;
nevertheless the process is still considered stable
o The Specification Limits would be documented in agreements and penalties would be imposed if
the results fall outside these Specification Limits
o Specification Limits may be within or beyond the Control Limits — that would depend on the
precision that is required for the process

Summary
Aspirants would need to remember Control Limits are there to indicate whether the process/system is
under control or not. Results falling outside the Control Limits would mean the process is unstable and
root cause analysis is needed. Specification Limits are imposed by agreement with customers on strictly
quality requirements, i.e. Specification Limits must be within the Control Limits.

116 | P a g e
Project Time Management: Crashing vs Fast Tracking
 Crashing: crashing is a schedule compression technique to shorten the activity duration by adding extra
resources (money and/or human resources)
o involves additional costs as extra resources are needed for
 overtime
 extra manpower
 outsourcing
o normally to be explored after Fast Tracking
o Project Manager needs to judge which activities can be “crashed” with the lowest cost for the
maximum effectiveness
o may create risks for rework/defects
 Fast Tracking: is a schedule compression technique to perform activities in parallel (partial or in whole) in
order to save time
o the activities to be performed in parallel should be analyzed for logical relationship and that the
two activities in question can really be carried our in parallel (i.e. overlapping of part or the whole
activities)
o normally no extra resources are needed
o additional risks may be created
o Fast Tracking is the preferred method for schedule compression

Both Fast Tracking and Crashing must be applied to activities on the Critical Path in order to really
shorten the project duration. When applied on activities not on the critical path, it would only increase
Floats which will not shorten the project duration (note: the Critical Path may be different when there are
delays to activities of the project).

Summary
Crashing and Fast Tracking are the two most common schedule compression technique to shorten the
project duration in case of delays while preserving the project scope. Fast Tracking is to carry out
activities originally in sequence to be in parallel (partial or whole) while Crashing is to add extra
resources to shorten the normal duration of the activities.

Fast Tracking is preferred over Crashing as the former does not involve extra resources and costs
which would affect the project budget performance. However, it is important to note that both Fast
Tracking and Crashing creates risks for rework (otherwise this would have actually been incorporated
into the Project Plan at the very beginning) which needs to be carefully balanced with the benefits of
schedule compression.

For information, another effective schedule compression technique is to trim down the project scope, but
this would likely affect the project objectives and thus is not the preferred way to go.

117 | P a g e
Project Quality Management: Common Cause vs Special Cause
 Common Cause: the normal variances for every process which in random in nature — inherit in the
process (life is not perfect)
o Common cause is normal and cannot be eliminated
o On a control chart, common cause variations would have the pattern of:
 all points within the control limits
 points distributed randomly on both sides of the average value
o Common cause variance is also known as random cause — i.e. there is not a special reason for the
variation
o The process in question is considered as stable
 Special Cause: causes that are NOT inherent in the process
o Special cause indicates that there may be some sort of defects in the process and the cause of the
variance needs to be dug out
o Special cause can usually be resolved with adjustments to the processes, components or methods
o On a control chart, special cause variations would have the pattern of either:
 a point or more beyond the control limits
 some trends of the points (e.g. > 5 consecutive points on one side of the average value
o Special cause is also known as assignable cause — that can be attributed to some special reasons

Illustrated Example
When working on some mock exam papers, your score for 5 different mock question sets were: 72%,
70%, 68%, 69%, 73%

All these scores were within the control limits of 3 standard deviations with the mean of 70.4%. The
variations in the mock exam results were due to common causes.

However, after attempting the 6th mock exam question, you got 29%. The deviation must be due to
special causes and you needed to dig out the underlying reasons. Below are some possible causes:
 this mock exam paper is extremely difficult
 the questions ask you about knowledge that is outside the exam syllabus
 the quality of the mock exam paper is questionable (maybe many of answers to the questions were wrong
or even the questions were wrong)
 you are not familiar with the knowledge areas covered specially in this mock exam
 ……

There might be lots of different explanations the unexpectedly low marks you got from this exam. You
would need to try finding out which one (or more) cause from the above list is the “special causes” so that
you could take actions to make things right — and to move closer to your goal of passing the real exam.

Summary
Aspirants would just need to remember that common cause is “common” and that is not considered a
defect while special cause is caused by a “special” reason (defect) which must be resolved in order for the
process to run probably. The use of control charts can bring the matters into light and help the project
manager to differentiate between Common Cause and Special Cause variance.

118 | P a g e
119 | P a g e
120 | P a g e
121 | P a g e
122 | P a g e
123 | P a g e
124 | P a g e
125 | P a g e
126 | P a g e
127 | P a g e
128 | P a g e