🎯 If You Already Have Real PM Experience, Read This Group First
Trap: inventing complexity the question never stated. Years of real projects going sideways trains you to imagine every complication that could be lurking behind a scenario. The exam wants the opposite: take the stem at face value. If it doesn't mention a budget constraint, a difficult stakeholder, or a hidden political angle, don't assume one. Answer the scenario that's actually written, not the messier one your experience expects.
Trap: assuming you can skip process taxonomy because you "just do the work." After years on the job, you stop consciously labeling what you're doing as "Plan Quality Management" versus "Manage Quality", you just do quality work. The exam still tests the taxonomy: which named process a scenario belongs to, and roughly when in the project it happens. Knowing the outcome isn't the same as knowing the label, and the exam asks for the label.
Translation exercise: take three recent real decisions you made on a project and, for each, ask: which PMI process or knowledge area does this map to, and what sequence would PMI say comes first? Running a kickoff meeting maps to chartering and early stakeholder identification. Sending a status update maps to monitoring and controlling. Handling a scope dispute maps to integrated change control. Wherever your actual steps differ from PMI's preferred sequence, you've found a real gap worth studying, not a knowledge gap but a sequence gap.
Self-diagnostic for Gauntlet misses: for every practice question you get wrong, write down two things: what you instinctively would have picked based on real experience, and what the PMI-preferred answer actually was. After 30-50 questions, look for a pattern. Most experienced PMs find that two or three recurring real-world habits, like skipping a written change request because "everyone already agreed verbally," or routing around a slow procurement process, account for the majority of their misses. Once you can name the habit, it's much easier to catch yourself overriding it on exam day.
🔍 Problem-Solving & Investigation (Traditional)
1. Investigate before acting. Never implement or escalate immediately. Perform root-cause analysis, talk to team members privately, or review the relevant management plan first.
2. Review existing baselines first. Before proposing a fix, check the PM Plan, risk register, or issue log, the scenario may already be anticipated.
3. Risk vs. Issue. Might happen = Risk → update Risk Register. Already happened = Issue → update Issue Log and review the Risk Response Plan.
4. Proactive over reactive. Choose answers where the PM identifies risks and engages stakeholders early rather than reacting to a crisis.
5. Don't delegate your core job. Exhaust all options to resolve issues at your level first. Do not ask the sponsor, HR, or executives to handle conflicts for you.
6. Only escalate to sponsor when necessary. Go to the sponsor only for formal budget approvals, scope baseline modifications, or issues that truly exceed your authority, and always bring analyzed data and solutions.
7. Identify the methodology first. Before selecting an answer, determine if the question is Predictive, Agile, or Hybrid, each has different rules.
8. Never act without a plan. Do not take any significant action before creating or reviewing a plan. Every response should be grounded in what the PM Plan or relevant subsidiary plan says.
9. Your main job is integration. Do not concentrate time and effort on one area while ignoring others. The PM is an integrator of scope, schedule, cost, quality, resources, communications, risk, procurement, and stakeholders, all at once.
10. Final decisions must benefit project objectives. When there are conflicting methods or approaches, always choose the one that delivers the most value to the project outcome, not the easiest or fastest option.
11. Use inclusive tools. Favor tools that involve the whole team, like a whiteboard and markers, over complex software that creates barriers to participation.
👥 People Management & Servant Leadership (Traditional)
12. Lead as a servant. Remove blockers, facilitate communication, protect the team from external distractions. Don't command or dictate.
13. Enforce psychological safety. Prioritize answers that build a safe environment for open disagreement and collaboration over top-down decisions.
14. Resolve conflicts privately first. Before resolving a conflict, understand the SOURCE of it. Encourage team members to resolve it themselves. If you step in, address them privately, always aim for a win-win (Collaborate/Problem Solve). Resolve for the benefit of project objectives, not to satisfy one person over another.
15. Address performance privately. Never fire, publicly embarrass, or complain about a team member to their manager. Coach and mentor privately first.
16. Empower the team. The team estimates the work and determines the technical approach. The best people to break down work AND to determine when activities should happen is the project team. The PM facilitates, does not dictate.
17. No overtime or corner-cutting. Reject answers that suggest forcing late hours, weekend work, or bypassing quality checks to meet a deadline.
18. Share recognition jointly. Recognize team achievements frequently and include the entire team in celebrations.
19. Use emotional intelligence. Analyze your own feelings and those around you to respond to stakeholder and team needs more effectively. Emotional intelligence allows you to solve problems quicker and build trust.
20. Consult the team before deciding. The project team will have a more practical approach. Include them in decisions that affect their work.
📐 Scope, Change & Quality (Traditional)
21. Strict formal change control. Any change to a baseline must go through a formal Change Request. Never implement a change just because a stakeholder asks. All change requests must be reviewed and assessed.
22. Assess scope changes holistically. All scope changes should be evaluated for impact on ALL other areas: schedule, cost, quality, resources, communications, risk, procurement, and stakeholder engagement.
23. Follow the exact CR sequence. Document → Assess impact → Present to CCB → Await approval → Update PM Plan → Implement.
24. Verify schedule logic. Every dependency, logic tie, and critical path calculation must be deliberately verified, not guessed.
25. Spend money to save time. On the critical path, it's generally preferred to crash or fast-track (spend more) rather than delay the delivery date.
26. Define quality early and check often. Quality requirements should be defined at the start of the project and verified regularly, not just at the end.
27. Customers verify scope and quality. The customer is the best person to check a deliverable for scope conformance and quality requirements being met, they are the ones who will actually use the product. This is Validate Scope.
28. Use bottom-up estimating. When estimating, use bottom-up (detail first, then roll up) rather than top-down. It takes more time but produces more accurate estimates.
⚠️ Risk, Procurement & Stakeholders (Traditional)
29. Identify risk early and often. Identify as much risk as possible as early as possible. All identified risks, both threats and opportunities, should be documented in the Risk Register with corresponding responses.
30. Negative risk = threat. Positive risk = opportunity. Risk management covers both. Ensure responses are planned for opportunities just as much as threats.
31. Choose mutually beneficial contracts. When selecting a contract type, always choose one that is mutually beneficial to both seller and buyer, in service of the overall project objectives.
32. Engage stakeholders often and regularly. Use meetings, one-on-one conversations, phone calls, and presentations. Don't wait for stakeholders to come to you.
33. Tailor communications to each stakeholder. Before sending communications, analyze stakeholder needs: what do they need, how often, in what format, and who delivers it. Ensure they understand what they receive.
34. Keep stakeholders engaged. If a stakeholder is resistant or disengaged, review the Stakeholder Engagement Plan, meet with them, understand their concerns, and update your communication strategy.
35. Never hide bad news. Report variances, delays, and risks transparently, always with an impact analysis and a remediation plan.
🔒 Closing & Lessons Learned (Traditional)
36. Update lessons learned throughout the project. Don't wait until the end. Update the Lessons Learned Register continuously so knowledge can be transferred to future projects in the organization.
37. Close every phase formally. Always obtain formal sign-off, release resources, ensure all bills are paid, archive lessons learned, and transfer deliverables, even if the project was terminated prematurely.
38. Terminated projects still need formal closure. Projects that end early must still go through the Close Project or Phase process. Skipping closure is never acceptable.
39. Business value over compliance. Always evaluate choices based on delivering the highest business value to the customer, not just checking boxes in a document.
🏃 Agile: Servant Leadership & Team
A1. Be a servant leader at all times. Empower the team and remove impediments. Give them the tools they need to succeed while staying out of their way. Be a central figure, not a dictator.
A2. Product Owner owns the backlog, always. Only the PO can prioritize features in the product backlog. If the PO refuses to prioritize (feeling all items are equally valuable), train them on the benefits of doing so. Do NOT prioritize yourself.
A3. Never disrupt a sprint. Once a sprint starts, scope is locked. New requests go to the product backlog for the next sprint, unless the PO cancels the sprint entirely because the goal is no longer valid.
A4. Let the team solve problems. Any problem that occurs should be resolved by the project team. Let them choose the solution while you coach and support. Do not impose solutions.
A5. Provide psychological safety. Create a safe environment for disagreements. Do not punish anyone for a difference of opinion. Understand that conflict in agile is a positive, healthy step and an opportunity to learn.
A6. Understand what motivates each team member. People are motivated differently. Learn what drives each person and use that knowledge to support their performance and wellbeing.
A7. Have good ethical values. Transparency, honesty, and integrity are core to the agile mindset. Do not cut corners or hide problems.
A8. Make success and failure criteria clear. Ensure the team understands the Definition of Done, what success looks like, and what failure looks like, before the sprint starts.
📊 Agile: Communication & Visibility
A9. Face-to-face is best. Face-to-face communication with a whiteboard and markers is the most effective form of communication in agile. Use co-location wherever possible.
A10. Radiate information visually. Use large charts, graphs, burnup/burndown charts, and Kanban boards to make project status visible to everyone on the team at all times. Prefer physical boards (whiteboard) over digital monitors where possible.
A11. Limit work in progress (WIP). Use Kanban to limit WIP. When a column hits its limit, the team must finish something before starting something new. Prevents overloading and bottlenecks.
A12. Deliver value early via demos. Deliver working software or prototypes at the end of every iteration. Use MVPs to validate assumptions, reveal risks, and gather rapid feedback.
A12b. Use a spike to resolve uncertainty. A spike is a short, time-boxed investigation the team runs when a story is too unclear or too technically risky to estimate. Instead of guessing, the team does a quick research or prototyping task to learn enough to move forward. Its purpose is reducing uncertainty and technical risk, not producing shippable work. Exam trap: when a story cannot be estimated because the team does not yet understand it, the answer is often "run a spike," not "guess an estimate" or "start building." Two types: a technical spike (investigate an approach) and a functional spike (explore how users would interact). On charts, a "spike" can also mean a sudden jump in the data, for example on a run chart or cumulative flow diagram, so read which sense the question intends.
A12c. Prioritize with MoSCoW or Kano. MoSCoW sorts backlog items into Must have, Should have, Could have, and Won't have (this time), a fast way to force ranking when everything feels critical. Kano classifies features by customer reaction: basic expectations (their absence angers, their presence goes unnoticed), performance features (more is better), and delighters (unexpected joy). Exam cue: "the product owner cannot decide what goes in the release" points at a prioritization technique, not at the PM deciding for them.
A12d. Estimate as a group, improve as a cycle. Wideband Delphi is group estimating through anonymous rounds that converge on consensus, killing anchoring and boss-bias. Planning poker is its familiar cousin, and affinity estimation does the same job faster by grouping stories into relative size buckets. Kaizen is the culture of small continuous improvement, and PDCA (Plan, Do, Check, Act) is its engine: plan the change, try it small, verify it worked, then standardize it. Exam cue: "the team wants to improve its process" rarely means a big-bang overhaul; it means the retrospective feeding small PDCA cycles.
A13. Lightweight documentation. Working software over comprehensive documentation (Agile Manifesto). Avoid heavy formal plan updates. Prefer sprint backlog, user stories, and information radiators.
A14. Consistently re-communicate the project vision. Regularly remind the team WHY they are doing the work. A shared vision keeps the team aligned and motivated.
🔄 Agile: Continuous Improvement
A15. Run retrospectives. After every sprint, review how the work was completed, not what was delivered. What went well? What should change? Create actionable improvement items for the next sprint.
A16. Use feedback loops. After completing a task, take what you learned and apply it to the next task or sprint. Feedback loops are the engine of continuous improvement in agile.
A17. Identify methodology first. Before answering any agile exam question, confirm it's an agile context. Agile rules override traditional rules in an agile scenario, different answers apply.
