Key PMP Mindset / Notes:
General:
1. Always discuss, investigate, determine root cause, review, analyze, assess,
ask/consult before deciding or taking action — especially if it says ‘what should PM do first
or next’.
2. Collaborate with the team when making decisions or developing plans.
3. Act as a servant leader — support, coach, and mentor your team.
4. Focus on prevention over inspection — deal with risks and issues proactively.
5. Base actions on data, trends, or impact assessments, not assumptions or gut
feelings.
6. Refer to the project vision or objectives if the team is confused or misaligned.
7. Respect organizational processes and governance — don’t bypass them.
8. Avoid escalating or involving third parties like HR, sponsor, or steering committee —
unless the situation explicitly calls for it.
9. Don’t delay, pause, or stop the project unnecessarily — keep progress moving.
10. Don’t overreact — avoid firing, rejecting, or making extreme decisions unless
ethically required. If all the options sound bad, try to pick the better one. If all the options
sound good, try to pick the one that must happen first.
Stakeholders & Communication:
11. If a stakeholder is unresponsive → revisit the Stakeholder Engagement Plan.
12. If a stakeholder missed updates → check the Communication Management Plan.
13. Meet 1-on-1 with stakeholders to resolve conflicts or understand preferences.
14. Tailor communication style and frequency to stakeholder needs, not fixed cycles
(e.g., not “monthly” or “daily” by default).
15. Consider cultural and individual preferences, especially with global teams.
16. Don’t act immediately on requests — analyze feasibility and impact first.
17. Keep stakeholders engaged and informed throughout the project lifecycle.
Agile / Hybrid:
18. Product Owner owns the backlog and prioritizes based on value and stakeholder
input.
19. Team owns sprint backlog, story points, and velocity estimation — empower them.
Ideally, velocity should be consistent.
20. Once a sprint begins, no changes.
21. Use demos for progress, retrospectives for improvement, and refinement for clarity.
22. Backlog Grooming / Refinement can happen before sprint planning. Ensure safety /
health / security regulations are included in Definition of Done.
23. If the org is transitioning to Agile → provide training and coaching.
24. Agile is feedback-driven — use MVPs and early releases to validate and adapt.
25. Use video calls for distributed teams to maintain face-to-face communication.
26. Avoid command-and-control behaviors — support sustainable pace and shared
ownership. Burn down chart shows work remaining. Burn up chart shows work completed.
Spike is the horizontal part of the graph. Bottleneck in Kanban is when the number of items
= WIP limit
27. Hybrid = when part of the project is predictive (e.g., regulatory) and part is adaptive
(e.g., user interface).
Predictive (Waterfall):
28. Can’t update baselines (scope, schedule, cost) without a formal change request.
29. Initiating a change control processes involves assessing the impact.
30. Work authorization and governance systems must be followed.
31. Project charter = high level; scope baseline = scope statement, WBS, WBS
dictionary.
32. Cost baseline = estimates + contingency; project budget = cost baseline +
management reserves. CPI, SPI > 1; CV, SV > 0 means good (under budget, ahead of
schedule).
33. Risk, quality, and stakeholder management are ongoing efforts, not one-time tasks.
For schedule delays, prefer Fast Tracking over Crashing (unless the question says
additional funds are available). For resource optimization, prefer Smoothing over Levelling
(to avoid changing the critical path).
34. If a project is terminated early, a formal project closure must still happen.
Risk & Issue Management:
35. “Something may/might happen” = risk, “has/will happen” = issue.
36. Add new risks to the risk register, and active issues to the issue log.
37. Don’t ignore or delay risk response — act early and appropriately. If a known risk
materializes → it becomes an issue; execute the planned risk response.
38. Use Monte Carlo simulation for scenario-based risk analysis. Like when there’re
multiple scenarios that need to be analyzed.
39. New regulations? → Assess impact first, then update risk register if applicable.
40. Escalate only if the issue exceeds your authority — not just because it’s difficult.
Contingency reserves are for known risks and management reserves are for the unknowns.
Generally, approval is not required for using contingency reserves, but it is necessary for
using management reserves.
Quality, Procurement & Resource Management:
41. Quality Control = product-level; Quality Assurance / Plan Quality = process-level.
42. If a deliverable is rejected → review the acceptance criteria.
43. For vendor/supplier issues → refer to the contract and procurement agreements.
44. If a team member lacks knowledge → arrange training or mentoring. Refer to OPAs,
historical info, or lessons learned — especially if a similar project was done before. Consult
SMEs if absolutely no idea.
45. For resource constraints → work with the Functional Manager to resolve.
46. Establish and follow a Team Charter / Social Agreement with team norms and ground
rules.
47. Use the team charter or conflict resolution techniques for team issues or misbehavior.
Collaboration (win/win) is usually best for conflict resolution. Compromise is the second best.
48. Recognition should be timely, relevant, and based on team member preferences.
Team evaluation should be fair and transparent.
Red Flags:
49. Be cautious of options with harsh tone: instruct, demand, force, command.
50. Avoid answers with:
• Rigid phrases: always, never, only, immediately, do nothing, pause project.
• Specific timelines: weekly, monthly, daily (unless the question says so).
• Third-party escalation: HR, sponsor, steering committee — unless the scenario
involves them.
• Single-constraint focus: answers that mention just cost, schedule, scope or quality,
without considering the others.
