PMP Exam: Trick Questions Cheat Sheet

Yes the PMP exam does have many "trick questions"! ​Here is my cheat sheet of tricks, gotchas and pitfalls collected about these questions. You have to be very careful about the wording and cut through the noise in the question to find what the really important answer is. This is meant to simulate project management in the real-world, where day-to-day you have to cut through the noise and make decisions based on what's truly important. There is also lots of terminology, acronyms and references to names of theories and principles that you need to know, and sometimes these terms are not even in the PMBOK itself. 

GENERAL PROJECT MANAGEMENT

• ​​Projects are temporary, create unique outputs, and drive change.
• The Project Charter not only gives the Project Manager authority, but also it sets stakeholder expectations and prevents constant change. 
• The Sponsor signs the Project Charter, or it could be someone else in senior management, or a committee. The key is that it is a person with access to funding.
• The Project Management Plan includes both PLANS AND BASELINES.
• As part of Project Management planning, you plan 2 lifecycles - the Project Lifecycle (phases, etc.) and Development Lifecycle (waterfall, agile, etc.)
• Having multiple sponsors on the Project Charter means more time communicating and more time in Configuration Management due to competing needs
• For each Phase, you still have to start with the Initiating process including reviewing and updating the Project Charter
• An Assumption Log is started from the time of initiation. Assumptions can later be used to identify risks. Constraints can also be stored in the assumptions log.
• The Project Manager must be constantly re-evaluating whether the project is inline with objectives and fit (e.g. if the organization changes, if new projects start, etc. the Project Manager should question whether their project still makes sense)
• If the previous PM said he had to “constantly push the team to get anything done”, chances are there’s no management strategy
• Multi-criteria decision analysis considers factors with weights to decide on resources or other things. This is different from source selection criteria which are just for procurement.
• Know the differences when you have a controlling PMO, supportive PMO, etc.
• Know who the PM reports to in all scenarios (matrix, functional, etc.). For example, in a balanced matrix organization, the Project Manager reports to a Functional Manager.
• Always be aware of whether you are in Initiating, Planning, Executing, Controlling or Closing. Sometimes PMP exam questions will mention that you are in "Executing", then give you a lot of useless information, and the correct answer is simply the only tool that can be used within "Executing".

Online PMP Practice Exams:​
​PMP PrepCast 120 Questions
Simplilearn 200 Questions

PMP SYSTEMS

• ​Project Management System = aggregation of the processes, tools, techniques and methodologies to manage a project
• Project Management Information System (PMIS) = coherent organization of information used to manage a project, typically implemented with software
• Project Control System is set up during planning and used for monitoring and controlling.
• A Work Authorization System is used to manage WHEN and in WHAT sequence work is done, but WHO does each activity is managed with the RAM (resource assignment matrix)
• Records Management Systems (RMS) - specific to Control Procurements includes storing contract and other documents in the RMS
• Knowledge Management System - requires understanding lessons learned on what worked before, current project team's assignments, and the resource breakdown structure. 
• Configuration Management System - Configuration Management is about as confusing as it gets in the PMBOK, but cutting through all the jargon, it is really just talking about a Sharepoint or Confluence-like system where you store and version plans like the Scope Management Plan, Schedule Management Plan, etc. So for example, the Configuration Management System will tell you that the current Project Management Plan comprises Scope Management Plan v2.1 from August, Schedule Management Plan v3.5 from June, and so forth.

Read more: 12 Surprising Facts about Scrum Methodology. 

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
  • ​description of the project and product scope
  • deliverables
  • assumptions and constraints
• The Detailed Scope Statement includes​
  • product scope description
  • deliverables
  • acceptance criteria
  • 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.
  • The most valuable result of WBS is team buy-in.
  • 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.
  • ​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:
  • 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)
  • 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:
  • Design of experiments (DOE) is a statistical process for identifying variables that can most impact quality
  • 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​
  • 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.
  • Scatter diagram is useful for 1-1 analysis. Affinity diagram is for grouping.
• ​Diagrams for diagnosing quality issues:
  • 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)
  • 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
  • can be used to confirm that policies are being followed, to improve processes, AND to confirm implementation of approved CRs.
  • identifies process problems, gaps, non-conformity, etc. but does not seek the root cause. Process analysis (subsequently) finds the root cause.
• Quality reports
  • ​summarize quality management issues that have been escalated by the team and any corrective actions recommended or implemented
  • 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:
  • 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.
  • Project Team Directory is a documented list of project team members, their project roles, and communication info. 
  • Resource Calendar identifies the working days, shifts, business hours, holidays, etc. of resources. When starting Acquire Resources you consult this.
  • 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.
  • 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:
  • Source of conflicts in a project from highest to lowest respectively are:  Schedules, Priorities, Manpower, Technical, Procedures, Personality, Costs 
  • 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 
  • 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:
  • Make-or-buy analysis
  • Source Selection Criteria
  • 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:
  • CPFF requires all costs on the invoice to be audited closely. The FF (fixed fee) is paid continuously, not all at the end.
  • A purchase order is a unilateral contract 
  • T&M is best used when project scope includes the progressive elaboration of the scope of deliverables.
• Regarding breaches and disputes:
  • 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).
  • 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. 
  • 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.
  • If the contract requires certain things before commencement and the seller does not issue, you can issue a default letter (notice of default)
  • 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
  • ​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)
  • Risk data quality assessment is the process of validating the reliability of the inputs for data analysis
• Types of risk:
  • Event risk, e.g. a key supplier may go out of business during project.
  • Variability risk = uncertainty about characteristics of a planned event or activity or decision (e.g. more bugs than expected, bad weather during construction phase)
  • Ambiguity risk = what might happen arising from lack of knowledge or understanding, inherent systemic complexity in the project
  • 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:
  • Risk responses aren't just for when risks occur (reactive), it can also include proactive action to be taken over the course of project
  • 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.
  • 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).
  • 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.
  • Output includes both Risk Triggers and Contingency Reserves 
• When managing the project:
  • Influencing risk owners is part of implementing risk responses
  • Monitoring secondary risks is part of Monitor&Control Risks
  • "Risk reassessment" is conducted in Monitor&Control Risks
  • When baselines are far off, consider risk re-identification and analysis
  • 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.
  • 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. 
  • you can use a bubble chart to see a 3D visual of risks by detectability, proximity, and impact, and prioritize accordingly
  • you can use a tornado chart to compare and prioritize the relative impact of different risks (a form of sensitivity analysis)
  • 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:
  • Informal verbal communication, such as F2F, is the best way to handle issues of poor performance and resolve disputes among team members 
  • Face-to-face is critical even for contract negotiations. However contracts themselves are formal written (e.g. by procurement).
  • Extensive use of written comms when solving complex problems, so everyone involved receives the same info
  • 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:
  • Performance measures, which are taken earlier during Monitor&Control
  • Validate Scope, which happens in Control Scope
  • 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:
  • At the end of each phase, closure ensures the phase met its objectives
  • Exit criteria at the end of a phase are also called Phase end criteria (not "phase closure or phase termination" criteria)
  • 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.
  • 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.
  • a variance report compares
  • a status report is a snapshot in time
  • a forecast looks at the future
  • 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