PMP PLANNING PHASE: WHAT TO DO, IN ORDER, STEP-BY-STEP

According to the Rita Mulcahy's popular PMP Exam prep, there is a specific order of
planning activities that you must learn:

1. Review the project charter

2. Determine development approach, lifecycle, and how you will plan for each
knowledge area (plan for a plan)
3. Define and prioritize requirements
4. Create project scope statement
5. Assess what to purchase and create procurement documents
6. Determine planning team
7. Create WBS and WBS dictionary
8. Create activity list
9. Create network diagram
10. Estimate resource requirements
11. Estimate activity durations and costs
12. Determine critical path
13. Develop schedule
14. Develop budget
15. Determine quality standards, processes, and metrics
16. Determine team charter and all roles and responsibilities
17. Plan communications and stakeholder engagement
18. Perform risk identification, qualitative and quantitative risk analysis, and risk
response planning
19. Go back - iterations
20. Finalize procurement strategy and documents
21. Create change and configuration management plans
22. Finalize all management plans
23. Develop realistic and sufficient project management plan and baselines
24. Gain formal approval of the plan
25. Hold kickoff meeting
26. Request changes

Read more: PMI-ACP Agile Certified Practitioner Cheat Sheet.

SCOPE MANAGEMENT

 After obtaining input from the customer and other stakeholders, the project
team is responsible for developing the scope baseline.
 The scope statement must be precise and can be quite detailed.
 Constraints may be listed in the scope statement, in the assumptions log, or in
a separate constraint log
 The Scope Statement includes 3 parts
o description of the project and product scope
o deliverables
o assumptions and constraints
 The Detailed Scope Statement includes
o product scope description
 o deliverables
o acceptance criteria
o exclusions
 The scope statement undergoes a preliminary review, and then later on a final
review.
 Customers approve the product scope (i.e. their requirements), but do not
generally approve the project scope (what you are going to do to complete
their requirements).
 Requirements are then used to measure the completion of the project. If you
don’t have complete requirements then you can’t measure whether the project
is complete.Whereas Perform Quality Control checks for correctness (in
software, this is like QA testing), Validate Scope checks
for acceptance (where the customer checks that the finished product fully
meets their requirements).
 If there is any change in the project or product scope at any time during the
project, it has to be explained to the customer, who can then make an
informed decision (or at least, provide input to the project team).
 A WBS is developed by the team but is used to communicate with all
stakeholders.
o The most valuable result of WBS is team buy-in.
o WBS also helps prevent work from falling through the cracks, and
conversely, it avoids gold-plating projects.
 A context diagram can be used during Collect Requirements. It's a visual
depiction of the product scope showing a business system (process,
equipment, computer system, etc.), and how people and other systems
(actors) interact with it. Presumably, BPMN diagrams and other "flow charts"
used by BAs are considered context diagrams.
 The Work Breakdown Structure (WBS) is a vital scoping tool for project
scope.
 Code of Accounts = unique IDs in the WBS
 Control Accounts are higher level than work packages and are figured out
in Schedule Management during Define Activities (post creation of the WBS)
 Have difficulty estimating cost? The most likely reason is LACK OF SCOPE
DEFINITION!
 “Validate scope” is done during monitoring&controlling and counts as part of
the overall “technical work”

SCHEDULE MANAGEMENT

 Estimates can be definitive (+/- 5-10%), budgetary (+/- 15-25%), or order of

magnitude (+/- 50%) depending on the stage of initiating or planning that you
are at.
 While early on defining the Project Charter, if the sponsor asks if you can do it
within time or budget, provide a big range +/-50% (even better than providing
an analogous estimate)
 Precedence Diagramming Method (PDM) includes start-to-
start relationships whereas AON does not. Watch out for tricky start-to-start
and start-to-finish questions!
  What-if analysis in project scheduling is often done using Monte Carlo
analysis. You enter a distribution of possible durations of each activity and it
spits out a distribution of possible durations of the overall project. Monte Carlo
only produces good results if the initial inputs you give it are valid.
 Rule of thumb: each activity of the WBS should take < 80 hours.
 In Estimate Activity Durations, WBS and RBS are used at a low and detailed
enough level to allow the work to be estimated
 Activity attributes include not only who and where the activity will be
performed, but also predecessor/successor linking info, duration/float,
leads/lags, etc. They do not include cost information however.
 Milestones are started in the project charter but are formally set when
defining all activities. Milestones are activities with duration of 0.
 Total Float = LS-ES
 Free Float = ES of next Activity – EF of current Activity
 Forward pass in the schedule checks the earliest start and finish of each
activity. Backward pass checks the latest start and finish
 Rolling wave planning means if a task can't be broken down yet, leave it
high level and break down further
 Discrete effort represents tasks, apportioned effort is when something
general and split across tasks (e.g. testing embedded in each task estimate)
 Standard deviation of a path is square root of variances of each node
 Brooks' law - adding more people late can make the project later rather than
accelerating it
 Dangle = unclear state/end date of an activity (e.g. it's based on a % of
another activity)
 A Fixed Formula Approach applies rules like 30/70 or 50/50 on start, so that
you don't micromanage the team asking them for a % complete every day.
 You can’t publish the schedule until resource availability (Resource
Management) is confirmed!
 A negative variance means that actuals are behind schedule / over budget.
Negative is bad, positive is good!
 If you are behind schedule, do the following in this order:
1. Check risks and re-estimate
2. Fast-track
3. Crash
4. Cut scope
5. Reduce quality
 Fast-tracking always adds risk. Crashing always adds cost and may add risk
(so only crash if you have extra budget).
 If you need to shorten one of the activities on the critical path, choose the
nearest-term activity.

Read more: CSM Certified Scrum Master Cheat Sheet.

COST MANAGEMENT

 When creating the Project Charter, provide a budget RANGE (which could be
informed by analogous or parametric estimation, among others)
  If a stakeholder asks for a precise project budget before planning is done, tell
them to wait until planning is done! (even though a budget range might have
been provided early on in the Project Charter)
 Analogous estimation is a form of TOP-DOWN estimation. It doesn't use
"detailed" historical task breakdowns, it’s a high-level comparison.
 Project setup costs are considered FIXED costs, not overhead costs
 The output of Determine Budget is a Cost Baseline. A Cost Baseline is
different from a Project Budget.
 Determine Budget makes use of the resource calendar (Resource
Management)
 S-curve is to show the cost baseline and remaining budget and time.
 CPI is calculated with ACTUAL costs, not estimated costs. A CPI of .5 means
only getting 50% of every dollar invested. It's not about progressing at a rate
(that's SPI)
 Value analysis (different from EVM) is about seeking ways to do the same
work at least cost, aka decrease cost while maintaining the same scope.
 COST RISK = risk that costs of project go higher than planned
 Identified risks are both an input and an output of Estimate Costs

QUALITY MANAGEMENT

 Quality Policy is the organization-wide quality intent. The Quality

Management Plan then documents how the Quality Policy is implemented on
the project.
 Modern quality management complements project management, as both
disciplines recognize the importance of customer satisfaction, prevention over
inspection, and continuous improvement.
 Quality is achieved when the product meets requirements (aka customer
expectations). In other words, "quality is the degree to which a project meets
the requirements".
 Quality can be about conforming to a standard (e.g. specs document) that
was previously decided.
 Emphasis is on prevention, as quality costs more later. The Cost of Quality
(COQ) is the cost of having to bring product that did not have acceptable
quality initially back up to standard. It is the sum of 2 types of costs
1. Cost of Conformance, which includes cost of Appraisal (i.e.
measuring quality periodically) and cost of Prevention
2. Cost of Nonconformance, also called failure costs, made up
of Internal (before shipping to the market) and External costs (after
shipping)
 An organization is said to have a Quality Culture when it is aware
and committed to quality in both its processes and the products it creates.
 Though everyone is responsible for quality, the Project Manager is ultimately
responsible for quality on the project.
 Quality Management must address quality of management, product, project
management, meeting customer requirements.
 For each project, must decide if cost, quality or schedule are more important
 The Quality Management Plan includes quality policy and quality control
charts
 Note that there is NO SUCH THING AS A QUALITY BASELINE (only scope,
schedule and cost baselines).
 In the Quality Management Plan, you develop a plan to make use of Tests
and Checklists. However the actual Tests and Checklists aren't developed
until Manage Quality.
 Checklist vs. Checksheet. Checklist is to verify compliance with steps of a
procedure. Checksheet is for tabulating test results.

o frequent errors scattered across the product without a discernible

pattern? Use checksheets to identify areas of error concentration and
then prioritize the response strategy
 Quality attributes = measurements for if the product is acceptable
 When planning and measuring quality:
o Specification limits are the allowable limits specified by the
customer, Control limits are the limits used by QA (which are most
likely narrower than the specification limits)
o Accuracy is about values being close to the true or target value,
whereas Precision is about values being clustered close to each other
and having little scatter.
 3 sigma = 99.7%, 2 sigma=95%, 1 sigma=68%
 Tools for planning quality:
o Design of experiments (DOE) is a statistical process for
identifying variables that can most impact quality
o Design for Excellence (DfX) in Manage Quality means you
purposefully design the product to optimize one or more specific
variables such as reliability, deployment, cost, service, safety, usability
 E.g. DfX to reduce costs while improving quality and
performance
 E.g. optimize for reliability, safety and cost
o Scatter Diagram shows the relationship between two variables. This
tool allows the quality team to study the possible relationship between
changes observed in two variables. Dependent variables vs
independent variables are plotted. The closer the points are to a
diagonal line, the more closely they are related.
o Scatter diagram is useful for 1-1 analysis. Affinity diagram is for
grouping.
 Diagrams for diagnosing quality issues:
o Ishikawa diagram = Fishbone diagram = Cause-and-effect
diagram = why-why diagram, showing the relationship between
causes and effects (e.g. show events that have a negative effect on
quality)
o Matrix diagram. Whereas cause-and-effect diagram helps you identify
multiple potential causes, Matrix helps you get to the root cause by
seeing relationships between causes.
 Inspections are sometimes called reviews, product reviews, audits, or
walkthroughs.
 Focus groups are not used in quality, they are for scope
 Inspections can include reviews, product reviews, audits, walkthroughs (but
not "stage gates")
  Remember definitions of TQM, Six Sigma, Deming's PDCA cycle, and Lean
 When it comes to selecting QA staff, experience is the most important factor,
though attitude and other factors are important too.
 Quality audits
o can be used to confirm that policies are being followed, to improve
processes, AND to confirm implementation of approved CRs.
o identifies process problems, gaps, non-conformity, etc. but does not
seek the root cause. Process analysis (subsequently) finds the root
cause.
 Quality reports
o summarize quality management issues that have been escalated by
the team and any corrective actions recommended or implemented
o info that can be used by other departments to take corrective actions in
order to achieve quality objectives
 Common causes are normal variations, special causes are due to
defects. A data point in a control chart that requires investigation is called
a special cause.

Read more: How To Build An Amazing Prototype On A Deadline.

RESOURCE MANAGEMENT

 The Resource Management Plan describes when resources will be brought

on and taken off, and how team members should communicate with the
Project Manager.
 The Resource Management Plan could be broken down into a Team
Management Plan (which can include policies such as when to be onsite) and
a Physical Resource Management Plan
 There are various documents that help you visualize people and physical
resources:
o RBS (Resource Breakdown Structure) is a hierarchical list of team
and physical resources related by category and resource type that is
used for planning, managing, and controlling project work. Each
descending level represents an increasingly detailed description of the
resource.
o Project Team Directory is a documented list of project team
members, their project roles, and communication info.
o Resource Calendar identifies the working days, shifts, business hours,
holidays, etc. of resources. When starting Acquire Resources you
consult this.
o Resource Histogram shows the resources used per time period. You
don’t just send the Functional Manager the resource histogram, you
have to talk it through with them and ask their opinions.
o WHO does each project activity in the schedule is managed with
the RAM (resource assignment matrix)
 In a matrix organization, the PM negotiates with the functional manager for
resources (PMO is not involved in staffing)
 Attitude is important but selection of resources is more than that, it's
education/skillset/experience/cost
  Control Resources is really about physical resources, whereas Manage
Team is for people, especially tracking performance and optimizing
performance
 Release Criteria is about releasing HR team members. It's both
the timing and method of releasing them.
 Conflict resolution:
o Source of conflicts in a project from highest to lowest respectively
are: Schedules, Priorities, Manpower, Technical, Procedures,
Personality, Costs
o Some commonly used techniques for conflict resolution are:
Withdrawal, Forcing and Compromising. However, the order of
preference for conflicts should be: 1. Confrontation 2. Compromise 3.
Smoothing 4. Forcing 5. Withdrawal
o If the team is fighting, start with ground rules then schedule team
building
 Tacit knowledge involves emotions, experience and abilities. Sharing this
requires trust. This is different from explicit knowledge such as facts and
lessons learned.
 Project performance appraisals = how an individual is performing,
whereas Team performance assessment = how the team is doing together
 Reward and expert power are the best types of power to use. Expert can
take some time to establish, so in the early days it’s either reward or formal. In
a weak matrix, you probably can’t use reward so expert is all you’ve got.

Read more: What Makes Top 1% Project Manager?

PROCUREMENT MANAGEMENT

 Plan Procurement Management process includes several things that you

might think happen at Conduct Procurements but don't:
o Make-or-buy analysis
o Source Selection Criteria
o Bid documents (also called Procurement Documents)
 Conduct Procurements is really the execution of the RFP process, which can
include contract types, independent estimates and advertising
 The purpose of a contract is to distribute reasonable amount of risk between 2
parties. The most important role that the Project Manager plays on the
contract is protecting the interests of the project.
 Many orgs treat contract administration separate from the project
organization
 Contracts go through intense approval process, even more than the Project
Management Plan.
 “Bid, tender, or quotation” terms used when the seller selection will be based
on price (commodities), while “proposal” is when technical capability or
technical approach are paramount.
 Bidder conferences save time!
 Records Management Systems (RMS) - Control Procurements includes
storing contract and other documents in the RMS
 Regarding certain types of contracts:
 o CPFF requires all costs on the invoice to be audited closely. The FF
(fixed fee) is paid continuously, not all at the end.
o A purchase order is a unilateral contract
o T&M is best used when project scope includes the progressive
elaboration of the scope of deliverables.
 Regarding breaches and disputes:
o When disputes arise, contract claims administration is used. File a
claim and then negotiate with the vendor on any
disagreement. Arbitration is next, then litigation (last resort).
o Constructive changes = situation when a contractor performs work
beyond the contract requirements, without a formal order under
the changes clause, either due to an informal order from, or through
the fault of, the buyer. This is also a change where the buyer and the
seller cannot reach an agreement.
o If during contract negotiations you also have a signed note (separate
from contract), if the contract ultimately doesn’t have what’s on that
note that the seller is only required to deliver what’s in the contract.
o If the contract requires certain things before commencement and the
seller does not issue, you can issue a default letter (notice of default)
o If the seller violates the T&Cs such as issuing an invoice for higher
amount, you can issue a breach of contract notice (then,
presumably, talk to them).
 Review the CPIF formula and the Point of total assumption (where seller
bears the risk and sharing ratio goes away)
 Control procurement is not just for monitoring contract but also for contract
closure.

RISK MANAGEMENT

 Risk should be an agenda item at every team meeting.

 Identify Risks techniques: document reviews, prompt lists, brainstorming,
and data analysis such as root cause analysis, checklist analysis, and
assumption and constraint analysis
o prompt lists in particular are when you prompt the team with pre-
defined lists of generic risks such as PESTLE (political, economic,
social, technological, legal, environmental), TECOP (technical,
environmental, commercial, operations, political), and VUCA (volatility,
uncertainty, complexity, ambiguity)
o Risk data quality assessment is the process of validating the
reliability of the inputs for data analysis
 Types of risk:
o Event risk, e.g. a key supplier may go out of business during project.
o Variability risk = uncertainty about characteristics of a planned event or
activity or decision (e.g. more bugs than expected, bad weather during
construction phase)
o Ambiguity risk = what might happen arising from lack of knowledge or
understanding, inherent systemic complexity in the project
 o Emergent risk = emerge from our blind spots, outside our
mind/cognizance, arising from limitations in our world view. Also known
as unknowable-unknowns.
 When planning risk responses:
o Risk responses aren't just for when risks occur (reactive), it can also
include proactive action to be taken over the course of project
o Risk Mitigation is where you reduce the probability or impact of an
event. Risk Acceptance is where you can't modify the event, so you
either let it happen without doing anything, or you plan around it (for
example shut down for the summer). Passive acceptance is best when
your best course of action is to simply deal with the problem if and
when it occurs.
o Another response to a risk can be Escalation. When you escalate a
risk, it’s now the responsibility of the person you escalated to (e.g.
Program Manager).
o If additional risks are identified during the response planning session,
those are secondary risks. Document them but keep going on
planning risk responses, don't stop and jump back to identify risks right
away.
o Output includes both Risk Triggers and Contingency Reserves
 When managing the project:
o Influencing risk owners is part of implementing risk responses
o Monitoring secondary risks is part of Monitor&Control Risks
o "Risk reassessment" is conducted in Monitor&Control Risks
o When baselines are far off, consider risk re-identification and analysis
o Only add risks to the risk register if they have not occurred. If a PMP
exam question says "a problem was identified" this implies that the
risk already has been triggered and you have to move to using
reserves.
o When an unplanned risk is identified but not triggered yet, qualify it.
However if it is triggered, then you need a workaround.
 Qualitative Risk Analysis outputs a prioritized list of risks and a watchlist of
low-priority risks that we don't analyze further.
o you can use a bubble chart to see a 3D visual of risks by detectability,
proximity, and impact, and prioritize accordingly
o you can use a tornado chart to compare and prioritize the relative
impact of different risks (a form of sensitivity analysis)
o risk propinquinty is the degree to which a risk is perceived to matter by
one or more stakeholders.
 Quantitative Risk Analysis outputs the probability of achieving time and cost
objectives (but NOT quality objectives). A numeric value is assigned to risks
impact and probability, but risks are NOT prioritized the way they are in
qualitative risk analysis.
 Risk audit is for anywhere in the risk management process
 Decision tree: a SQUARE represents a decision, a CIRCLE is a chance of an
event occurring

COMMUNICATIONS MANAGEMENT
  90% of PM's time is communicating
 Effective project INTEGRATION requires emphasis on communication at key
integration points
 When to use different types of communication:
o Informal verbal communication, such as F2F, is the best way to handle
issues of poor performance and resolve disputes among team
members
o Face-to-face is critical even for contract negotiations. However
contracts themselves are formal written (e.g. by procurement).
o Extensive use of written comms when solving complex problems, so
everyone involved receives the same info
o When differences in culture and remote employees, use written
formal comms to keep everyone in the loop
 Communications Logistics = # of people and locations
 Collection, creation, distribution, storage, and monitoring project information
are activities that fall under Communications Management, mostly under
Manage Communication
 5 C's of written communication: correct grammar, concise, clear purpose,
coherent, controlling flow of words and ideas
 If you talk in a meeting and people don't say much and just nod, then you
need ACTIVE LISTENING skills
 If the team is having a hard time understanding stakeholders concerns, train
them in cultural and active listening
 Review push and pull communications. A blog is a "push" method since
you publish regardless of recipient's interest
 Knowledge management tools are not just repositories but for actively
connecting people and getting them communicating.

Read more: The Complete Guide to Migrating Legacy Products to SaaS/Cloud.

STAKEHOLDER MANAGEMENT

 A communication styles assessment should be performed prior to

stakeholder engagement assessment, particularly for unsupportive
stakeholders.
 The role of the stakeholder is determined by the Project Manager and the
stakeholder collaboratively. The Project Manager does not order the
stakeholder!
 The Project Management plan has 4 key areas to help manage stakeholders
1. Communications management
2. Risk management
3. Change management
4. Stakeholder engagement
 Issue log and Change log are the 2 tools that you can use to build
communications and trust with stakeholders day-to-day
 Issue log is an important artefact to go through monitoring stakeholder
engagement (aka adjusting strategies for engaging stakeholders)
  If stakeholders outside the team are risk owners, INFLUENCING them to
ensure their engagement is most important. A risk system and regular calls is
good, but influence is needed most.
 Best way to involve stakeholders regularly, especially those who want to be
very involved, is to have them periodically review the requirements (moreso
than holding status meetings, sending them reports, etc.)
 Functional managers are very often forgotten stakeholders
 NETWORKING is very useful for problem solving, stakeholder influencing and
to obtain their support.

PROJECT CLOSING ("ADMINISTRATIVE CLOSURE")

 Things that are NOT part of closing:

o Performance measures, which are taken earlier during Monitor&Control
o Validate Scope, which happens in Control Scope
o Contract closure which happens in Control Procurements
 Close Project or Phase process is started once all the work has been verified,
delivered, and accepted by the customer. All open issues have been raised,
and finalized (come to a conclusion and closure).
 The sponsor is the one to sign off on the project closure.
 At closing, you need the Project Management Plan, Project Charter &
Business Documents. In particular the charter contains project success
criteria. Business docs include the benefits management plan to check
against. Business documents are the business case and the benefits
management plan .
 Know the Closure sequence!

1. Confirm the formal acceptance of the product (by all stakeholders, then
the customer)
2. Transfer the product/service/result to the next phase or to operations
3. Obtain financial, legal and administrative closure and ensure transfer of
liability
4. Obtain feedback from relevant stakeholders to evaluate their
satisfaction
5. Create the final project report
6. Update lessons learned
7. Archive project documents
8. Release resources
 Project closure documents are formal documents that indicate the closure
of the project and transfer to operations. Product support details are part of
the project closure documents. The customer may have written them and will
send them to you for archival
 Scope validation can be done at closure as a result of tailoring. (it seems
original PMP had "verify scope" as part of closing?)
 Scope validation doesn't require your team to verify deliverables if the
customer is responsible for verification themselves
 Old PMP: scope verification != product verification. Scope is at the end of
each phase (in closure?) Product is at the end of the project. Review the diff.
 Phase end:
 o At the end of each phase, closure ensures the phase met its objectives
o Exit criteria at the end of a phase are also called Phase end
criteria (not "phase closure or phase termination" criteria)
o At the end of phase, you might decide to extend the phase, continue to
next phase, close the project. But this is not where you initiate a new
project.
o Closing the project also involves documenting the degree to which
each phase was properly closed
 Lessons learned are best produce by the stakeholders, not just by the project
team

PMP ETHICS

 The Project Manager needs to consider the needs of the whole company, not
just their project. If they need a shared resource, start by negotiating with the
other project managers, don’t jump to getting the sponsor's help right away.
 When dealing with sending or receiving gifts, always contact senior
management about it.

Read more: What Makes a Top 1% Project Manager?

PMP LEADERSHIP

 To be an effective leader, first identify your strengths and weaknesses

 A manager should not delegate long-range planning, performance appraisals,
personal matters, or leadership activities to her subordinates. She can,
however, delegate routine project monitoring and controlling activities.
 For a brand new PM, most important thing to use is Lessons Learned, even
more important than project management training or consulting the previous
Project Manager.
 A company policy is not working well for the team. What should the PM do?
Discard it or ask to change? No, the PM should ensure that team members
adhere to the company policies at all times.
 If junior team members are underperforming, extra supervision is needed.
Colocation with senior team member is not a guarantee
 When solving a problem, you review, implement, and the CONFIRM it solved
the problem to avoid reoccurrence. This is more time upfront but a time
savings in the long run.

PROJECT SELECTION

 Opportunity cost is not considered in project selection

 NPV is same as net cash inflows
 NPV = FV/(1+r)
 BCR = Payback/Project Cost
 If EMV = 0, you can't decide whether to proceed with project or not
 Benefit Measurement Methods include IRR, Murder Board, Scoring Model,
Discounted cash flow
 IRR = discount rate, or investment yield rate over a period of time
  Do you know the answer to this question? "The calculated IRR of a project at
which NPV becomes 0 is 14%. What should be the target IRR?" If not, go
study this as it is a trick question you need to know!

PMP TERMINOLOGY

 Monochronic vs. polychronic (one thing at a time vs. multitasking)

 ISO is "International Organization of Standardization"

Read more: Identify Your "Must-Have" Customers.

EXECUTING VS. MONITORING AND CONTROLLING

 Project reports for stakeholders (in manage execution) include docs

like project status, lessons learned, issue logs, project closure reports, and
outputs from other knowledge areas. This is different from Performance
Reports. Report Performance is a process of collecting and distributing
performance information, including status report, progress measurements,
and forecasts.
o a variance report compares
o a status report is a snapshot in time
o a forecast looks at the future
o a trend report looks at the past
 EVM is a PERFORMANCE REPORTING TOOL. Allows for status and
forecasting
 Earned value analysis is different from earned value management
 Work performance data is the actual data that helps in measuring
performance.
 Work performance data (raw data) gets processed into work performance
information which then gets processed into work performance reports
 To quickly review where the project stands, look at the Progress Report, not
the Status Report
 Validate scope happens whenever a deliverable is ready, not just as you
near phase end or project end
 A burndown chart is for the iteration, not for the release

CHANGE CONTROL

 Change requests (CRs) are not necessary until project planning is complete
 Everything needs to go through change control- corrective action, preventive
action, and solving DEFECTS
 Even changing configuration requires a CR
 HOWEVER, IF THE PM CHECKS THAT NO IMPACTS ARE MADE TO THE
BASELINES, THEN NO NEED FOR CHANGE CONTROL!
 CORRECTIVE action is not just defect repair, it's a change to anything that
was done a different way before. PREVENTIVE is not changing anything.
 Management of the change is not complete when the Control Scope process
is completed. It is important to look at the impact of the change on other parts
 of the project, such as time and cost. Therefore, performing integrated change
control is the best thing to do next. This would probably be followed by making
sure the impact of the change is understood by the stakeholder, then
determining why this scope was not identified in planning, and asking the
stakeholder if there are more changes expected.
 The scope of the project has been completed. You receive a request for a
new module to be developed as part of this project. What should you do
next? As the scope is completed, the project is complete. Additional work
should be done as part of a new project.
 When a change is approved: update baselines AND NOTIFY RELEVANT
STAKEHOLDERS before implementing
 The Change management plan includes procedures, standards for reports,
and meetings, but not lessons learned.
 Corrective actions should be authorized and documented. If a team member
performs one roguely, record the corrective action in the change log then
discuss the value of documentation with the team to remind them
 If a team member implements a change without going to the CCB, but says
no impact on the baselines, the PM should still evaluate the impact by asking
the team member how he knows that there’s no impact. Eventually need to
put it through CCB anyway.
 Change log becomes part of the historical records database

AGILE VALUES

 Individuals and interactions over processes and tools

 Working software over comprehensive documentation (documentation should be barely
sufficient)
 Customer collaboration over contract negotiation
 Responding to change over following a plan.

12 AGILE PRINCIPLES

1. Customer Satisfaction - our highest priority

2. Welcome Changes
3. Frequent Delivery
4. Collocated Team
5. Motivated Individuals
6. Face-to-face Conversation
7. Working Software
8. Constant Pace
9. Continuous Attention
10. Simplicity
11. Self-Organization
12. Regular Reflection
SCRUM

 Values: Commitment, Courage, Focus, Openness, Respect

 3 Pillars
1. Transparency
2. Inspection
3. Adaptation
 Product Owner (PO) is responsible for maximizing the value of the product and the work of
the team

o 1 PO per team, but only 1 backlog for the whole product

o Responsible/accountable for backlog management
o The product owner represents the customer, users, and stakeholders. Take risk into
account when prioritizing backlog
 Development Team
o self-organizing, has all the skills needed, no titles, no sub-teams
o "share 2 pizzas" = team size between 3 and 9 (not counting PO and Scrum Master).
Other sources say the optimal team size is 8, others say 12.
 Scrum Master ensures the team understands and enacts Scrum
o humility, servant leader
o coaches the dev team and removes impediments
 Team practices Sashimi to ensure every slice of functionality delivered is complete

Read more: PMP Exam: Trick Questions Cheat Sheet.

EXTREME PROGRAMMING (XP)

 Values: Simplicity, Communication, Feedback, Courage, Respect

 12 Practices
1. Pair Programming - one person codes—the driver. The other person is the navigator,
whose job is to think
2. Planning Game
3. Test Driven Development (TDD)
4. Whole Team - everyone sits together, generalized specialists
5. Continuous Integration
6. Refactoring
7. Small Releases
8. Sustainable Pace
9. Collective Code Ownership - multiple people work on all the code, any pair of
developers can improve or amend any code.
10. Coding Standard
11. Simple Design
12. System Metaphor
 Roles: Coach (= Scrum Master), Customer (= Product Owner), Developers, Testers
 Pair programming is the most helpful technique in implementing collective code
ownership in a team
 Code goes through 4 levels of completion: Broken, Build, Ready for demo, Ready to release

LEAN
  Lean focuses on the Value Stream
 The 7 Lean principles:
1. Eliminate waste
2. Amplify learning (=early feedback loop)
3. Decide Late (=defer as long as responsibly possible)
4. Deliver Fast (=get value to the customer quickly)
5. Empower the team
6. Build integrity in (= test throughout, not just at the end)
7. See the whole (=see the system not just the parts)
 Nonvalue-added time in Lean is the time in the cycle where we find delays, waste and
constraints.
 Examples of Waste

o Partially done work (e.g. untested code)

o Extra processes (e.g. approval from manager who is not a true stakeholder)
o Extra features (gold plating)
o Task switching (e.g. if you're assigned to multiple projects)
o Waiting (e.g. waiting on sign-offs)
o Motion (e.g. poor communication between teams)
o Defects

KANBAN

 A key tool in lean manufacturing

 Focused sustainable pace and regular JIT delivery of individual items. Optimize the flow.
 Core Practices
o Define and visualize the workflow
o Limit Work-In-Progress (WIP)
o Measure and Manage Flow
o Make Process Policies Explicit
o Use Models to Suggest Improvement
 In practice, start by 1) visualizing the flow of work to identify bottlenecks, 2) speed up
or remove the bottlenecks that affect overall throughput 3) establish WIP limits, and then 4)
look for continuous improvement.
 Compared to Agile, Kanban focuses on continuous flow (vs. fixed iterations) and cycle
time (vs. velocity)
 Cycle time = # completed items/# days, the average time between the delivery of
completed work items. For example 10 completed items in 5 days means a cycle time of 0.5
days/item.
 Task Board serves the dual purpose of giving the team a convenient mechanism for
organizing their work and a way of seeing at a glance how much work is left. Can be a
whiteboard, cork board, cardboard, etc.
o Lets you visualize the workflow and identify constraints.
o On a task board you have 3 basic columns: to-do, in-progress, done.
o The WIP number on the board is the max number of work items in a swim lane.
o Kanban board uses a pull system
 Little's Law: # of items in the system = Rate items enter the system x Average time items
spend in the system. Demonstrates that the duration of work queue is dependent on its
size. Following Little's Law, to improve cycle time, reduce WIP (work in progress)
and increase ACR (average completion rate).
  Throughput is the number of features the team can develop in a particular amount of time.
 A testing team finds that it is often in the firing line as they often have more work than they
can handle. In the Kanban system the best way to handle this is to limit the WIP. This
will address the feeling of being overwhelmed with work and pave the way for more creative
solutions to the problem.
 David Anderson 5'S for Kanban agile development: Set in order, Sort, Shine, Standardize,
Sustain
 Scrumban is a hybrid of Scrum and Kanban

AGILE CHARTER AND PROGRAM

 Agile charters answer the W5H questions (who? what? where? when? how?)
o Charter doesn't specify costs or specific team members
o If the charter doesn't exist, create one with the sponsor
 5 Phases of Agile Project Management: Envision, Speculate (including release plan and
stories), Explore, Adapt, Close
 Planning Onion: Strategy, Portfolio, Product, Release, Iteration, Day. Team is mainly involved
starting at Release.
 4 types of revenue
o New revenue (from new markets, customers, features)
o Incremental revenue (existing features are enhanced, add-on's, encourage customer
to buy more)
o Retained revenue (what you will lose if you don't develop key features, could relate
to regulatory)
o Operational Efficiences (internal improvement)

Read more: 12 Shocking Facts about Scrum Methodology.

PLANNING TECHNIQUES

 In agile you will spend more time planning overall than in waterfall! However the planning is
spread out over the course of the project.
 Vision and requirements gathering:
o Design the Box - break into small groups and design the product name, graphic,
elevator pitch on the front, detailed features on the back, and operating instructions
o Prune the Tree - a requirements gathering technique
o Remember the Future
 Prioritization:
o MoSCoW
 Must Have – Critical to the current delivery timebox in order for it to be a
success
 Should Have – important but not necessary for delivery
 Could Have – Desirable, but not necessary; Could improve user experience
or customer satisfaction for very little cost
 Won’t Have – Have been agreed by stakeholders as the least-critical and not
to be delivered in the current timebox
 MustHave+ShouldHave = business case. Must+Should+Could = business case
+ contingency, 100% of total.
o Kano Analysis:
 Exciters/Delighters – features deliver unexpected benefits to the customer
 Performance/Satisfiers/Threshold/Must-Have – features deliver expected
benefits to the customer
  Basic/Dissatisfiers – If these features are missing, customers will be
unhappy
 Indifferent – Customers do not care if these features are in the product or
not
 Performance – Linear relationship between functionality/quality and
customer satisfaction
 Excitement – Customers will be willing to pay premium for these
features, lack of features will not decrease satisfaction
 Basic – Making these better, will not improve customer satisfaction,
best is neutral • Indifferent – Minimize these features inclusion
 Basic/Dissatisfiers are most important compared to Delighters or
Satisfiers. This will cause the customer to dislike a product if they
are not present. Indifferent features should be minimized or
eliminated.
o Relative Weighting - priority of a feature is determined by dividing the priority % by
the cost %
o Bang for the Buck, Buy a Feature, 100 Point Method
 Estimation
o Affinity estimating (e.g. T-Shirt sizing) is the practice of using common sizes to
rapidly place user stories into similarly sized groups - good for when you have at
least 20 stories, ideally 40 stories or even 100s of stories. Each story is placed on a
table and one by one a team member is given an opportunity to place a card in line
or adjusting a card in the line already.
o Wideband Delphi (e.g. Planning Poker) estimation includes plotting estimates on a
chart with no names, and then the range of points is discussed, and the team
attempts to reach a general consensus. Wideband Delphi is anonymous estimates
which minimizes the Bandwagon effect, HIPPO decision making and Groupthink
 Decision making: Fist to five, thumbs up, thumbs down or thumbs sideways, and decision
spectrum, Dot Voting (stickies), Forced Ranking (score criteria, then rank in order based on
score)
 Buy a story is a collaboration game to help stakeholders understand a complex issue
 Brainstorming: Round robin, Quiet Writing, Free for all.
 Collaboration: Listening Game, Collaborative Origami, 123 Go

BACKLOG, EPICS, USER STORIES

 User stories are not the same as "use cases" or "design scenarios". They are support tools for
analysis.
 User stories should be written following INVEST principles:
o I: Independent
o N: Negotiable
o V: Valuable
o E: Estimable
o S: Specific (or Small)
o T: Timely (or Testable)
 Each story has 3 elements, the 3 C's
o the Card (the story should fit on a 3" x 5" card)
o the Conversation (user stories are communicated by end-users to developers)
o the Confirmation (the acceptance criteria)
  A story map is like a product roadmap, using future stories to be implemented. Story
mapping is used to identify missing stories, categorize stories into functionality and prioritize
stories.
 Epic stories are large stories that have not been broken down, and these are typically found
at or near the bottom of the product backlog.
 Disaggregation refers to splitting a story or feature into smaller, easier-to-estimate pieces
(NOT decomposition)
 Small stories such as cosmetic UI changes and reading/writing bug reports can be combined
into larger stories
 Spikes: architectural spike (e.g. proof of concept), risk-based spike
 Research stories should last 1 day
 Acceptance criteria come from the customer, even if ultimately a team member might be
the one to write them down
 Theme is a set of related user stories that may be combined together and treated as a single
entity for either estimating or release planning.
 Quantity of function is scope measured in terms of user stories, use cases, requirements, or
features
 The risk-adjusted backlog is a primary way in which risk is managed. Stories in a risk-
adjusted backlog are prioritized based on EMV (expected monetary value).
 Grooming the backlog = refinement = adding detail, add/remove stories, prioritize

RELEASE PLANNING, ITERATION PLANNING and STAND-UPS

 When release planning:

o slice stores
o estimate velocity
o select stories
 Waves/milestones are intermediate 1-3 month timeframes with story-level capability and
commitment. When a milestone is achieved, someone can verbally announce it ("declaration
milestone")
 Definition of ready determines when an item is ready for development (ie. when it can go
into an iteration)
 Staging is the process of defining and prioritizing the nonfunctional requirements. Occurs
prior to the start of the first Sprint and takes just one day.
 Iteration planning includes the defining of tasks on an agile project. Break stories into tasks
during iteration planning
 Tasks are self-assigned by the team. If no one wants a task, the team collectively
decides. Task assignments are done by the team in a self-organized agile team
 Tasks are estimated at the time of Iteration Planning as well as during the iteration
 The PO shouldn't attend the standup which is a meeting of, for, and by the team
 End of iteration demo is called a product review meeting

AGILE PROJECT SCHEDULE

 The agile project schedule is created by estimating story points and applying velocity.
 Sprint 0 (or 'Iteration 0') does not deliver customer value. It can include initial training.
 Actual time is the amount of time an assignment would take to complete. Ideal time is the
amount of time an assignment would take if there were no interruptions or distractions. The
 conversion to elapsed time depends upon individuals involved but can usually be reasonably
estimated at an aggregate or team level.
 If project is release-timeboxed, a team can maintain a feature buffer and follow a MoSCoW
scheme to logically sequence the work.
 To avoid bottlenecks, it is recommended to get the team to be generalists so anyone can
pick up any task.
 Biggest advantage to delivering incrementally is that it reduces the amount of rework by
finding issues earlier.
 Velocity = number of story points a team can complete in a single iteration
 A team's velocity is not likely to be comparable to another one, so using industry standards
or using velocity to compare to teams is meaningless. Calculate velocity in the early sprints
by team consensus or using team capacity. Compare teams by ROI, not by velocity.
 The team should get to predictable velocity
 Lead time is the amount of time needed to get a feature from inception to live deployment
(not velocity)
 Feeding buffer is applied to stories that depend on other stories, in case the dependencies
are late

RETROSPECTIVES

 Format of meeting (15-60min):

1. Set the stage
2. Problem solving: gather data, generate insights, decide what to do
3. Closing
 Set the stage

o Everyone sits in circle or semi-circle

o Techniques: Check In, Focus On/Off, ESVP and Working Agreements.
 ESVP is a technique used to anonymously identify team members' attitudes
towards retrospectives as: Explorers, Shoppers, Vacationers, Prisoners.
 Generate insight techniques: Brainstorming, Pair Interviews
 Force field analysis = analyzing factors that drive change and restrict change
 Decide what to do techniques: Short Subjects, Triple Nickels, Voting with Dots
 Closing techniques: Plus/Delta or Speedboat to ask what team want more/less in next
iteration regarding process.
 ARCS, criteria for evaluating Instructional designs:
o Choose activities that help people stay engaged so they don’t drift off (Attention)
o That are relevant to the goal (Relevance).
o You want activities that people can accomplish successfully
(Confident/Competence).
o Finally, make sure activities fit into the overall design so people think the
retrospective is a good use of their time (Satisfaction).
 Return on Invested Time (ROTI) is used to determine the quality of the retrospective.
 You have Release Retrospectives, Project Retrospectives, Iteration Retrospectives and
Surprise Retrospectives. Surprise Retrospective is conducted when an unexpected event
changes your situation.

AGILE MODELING
  Agile modelling techniques are:
o use cases
o data diagram
o screen designs

DEVOPS

 DevOps helps speed up the deployment of products from development to operations

 Continuous integration (CI) is executed when code changes are checked in and tested daily.
CI components include source code control system, build tools, test tools, scheduler/trigger,
notifications BUT NOT UNIT TESTS

AGILE CONTRACTS

 If schedule variance is expected, use graduated fixed price contracts (when both parties
share some of the risk and reward associated with schedule variance)
 A DSDM Contract focuses on work being "fit for business purpose"
 "Money for nothing" in Agile contracting created by Jeff Sutherland means customer can
terminate early

INFORMATION RADIATORS, KPIs

 Information radiators include: burn charts, retrospective learnings, story maps (but not the
definition of done)
 Some stakeholders may want a vision statement. Next most detailed is the roadmap. Then
the detailed release plans and iteration plans.
 The burnup chart plots time on the X-axis and functionality on the Y-axis.
o Get a bird’s-eye view of the project.
o Shows progress and predicts a completion date.
o Burnup charts can show the impact of scope changes. Usually product when
you update the release plan.
 The burndown charts are used to track scope and schedule progress of the project. A
cumulative story point burndown chart is useful because it shows the total number of story
points completed through the end of each iteration.
o Example in practice: start at 200 points, the team completes 50, the PO adds 20
more. As 20 points get added, the bottom of the bar shifts down by 20 points and
reads "-20". The top of the bar moves down as the team completes the work. As 50
points are completed, the top will be at 150.
 4 KPIs used in Agile are
o remaining work
o rate of progress
o likely completion date
o likely costs remaining
 Best metric to compare agile teams: ROI, not velocity
 A S-curve is a graph that tracks a variable over time.
 EMV chart is a leading indicator which is why it is better than a GANTT chart.
 Trend analysis is a lead metric as it helps forecast issues based on trends.
QUALITY

 An escaped defect is a defect that wasn’t discovered by test teams. Instead, the defect was
found by customers.
 Component tests (as opposed to unit tests) verify that units and combinations of units work
together
 Error-feedback ratio is the number of new defects injected when fixing existing defects (e.g.,
20 new defects generated in fixing 100 defects would be an error-feedback ratio of 20%)
 Capers Jones concluded "a cumulative defect removal rate of 95% on a project appears to be
a nodal point where several other benefits accrue"

PMP FINANCIAL FUNDAMENTALS, APPLIED TO AGILE

 Net Present Value (NPV) • The present value of the cash flows, at the required rate of
return of your project, compared to your initial investment
o To compare projects, use NPV. The higher NPV the better.
o Time value of money
o A positive NPV means the project is profitable, a Negative NPV means the project is
not profitable
o Drawbacks – Need to make assumptions are inflation and interest rates
 Internal Rate of Return (IRR) • The discount rate that makes the NPV of all cash flows equal
to zero • Removes the assumptions of interest and inflation rates • Complicated to calculate,
expressed as a %. When comparing projects, chose the project with the higher IRR.
o Note that IRR is a superior measure to NPV, and should be used for making decisions
in benefit-cost analysis.
 ROI = Benefits/Investment. Higher is better. Example • Feature costs – $100,000, Net Profit
(i.e. benefits)- $25,000, therefore ROI = 25% • Drawback – Revenue generated after the
period of time, time value of money.
 The payback period is a calculation where a shorter payback period is preferred over a
larger period.

OTHER PMP FUNDAMENTALS

 Earned value management (EVM) in an agile project should be measured at the iteration
level, because this is the level where velocity is measured and resources are applied.
 Kaizen is the term for making small changes. The Plan-Do-Check-Act (PDCA) is the cycle
developed by Edward Deming for implementing small improvements.
 Common causes vs. special causes. Too often common causes are mistaken for special
causes. If it's a common cause, do nothing.

LEARNING

 When a team is trying to learn agile, First they need to "think", meaning individually learning
and internalizing agile principles (think first, then do).
 In Agile, you can change the plan when something new is learned or when it is known that a
mistake is to be avoided. You don't have to wait for the end of the iteration.
  The 3 Agile coaching styles are Training/Teaching, Coaching and Mentoring/Advising (not
supporting). When the team is storming, you should coach with a focus on conflict
resolution.
 Listening types: 1. internal 2. focused 3. global
 Shu Ha Ri. Shu: Follow the rule. Ha: Break the rule. Ri: Be the rule.
 For looking at how a team can improve, there are 3 levels
o The process level: How are we doing with agile?
o The quality and performance angle: How can the team produce better?
o The team dynamics dimension: How can the team become a better team?
 Lyssa Adkins guidelines for one-on-one coaching are guarantee safety, meet them a half-
step ahead, partner with managers and create positive regard

TEAM BUILDING AND COMMUNICATION

 Servant leadership: shield the team, remove impediments, carry food and water
 Caves and common area are essential for a team space so the team have caves where they
can work in quiet and a common area where knowledge sharing can happen
 Decision framing focuses on who gets involved in the decision process. Who makes the
decision is less important than getting the right people involved in the decision process.
 Health checks, often questionnaires, help determine how well the team is adhering to Agile
process.
 When facilitating meetings the facilitator is responsible for the goals, rules, timing, assisting,
including meeting minutes
 During problem solving, ask questions and listen, but avoid injecting your own ideas
 After understanding ones own feelings next is to manage them and then become more
aware of others and finally they will be able to influence others feelings.
 The 5 dysfunctions of a team are Absence of Trust, Fear of Conflict, Inattention to Results,
Avoidance of Accountability, Lack of Commitment
 Level-based conflict. It's best to empower the team members to solve conflict themselves
(e.g. Level 2 conflicts), unless the temperature is really high
 For announcing sprint priorities, two-way communication model ensures information is
bidirectional.

MISC

 FDD methodology is all about modelling

 Crystal methodology has more ceremony based on the size of the team and the criticality of
the project.
 Normative methodologies are based on solutions or sequences of steps known to work for
the discipline
 Workshops are meetings where work gets accomplished (different from status meeting or
knowledge transfer).
 Learn Cockburn's failure modes and 7 anti-patterns for a methodology
 Blanchard and Hersey's situational leadership stages in sequence are: Directing, Coaching,
Supporting, Delegating
 Be aware of the Dreyfus model of adult skill acquisition: Novice, Advanced Beginner,
Competent, Proficient and Expert
 Be aware of Tuchman team formation and development and Shu-Ha-Ri of skill mastery
 SMART goals are Specific, Measurable, Attainable, Relevant, Timely