PMGT-BC common mistakes
PMGT-BC · Understand the traps and how to avoid them.
When a question contrasts a predictive and an agile approach, the candidate picks the answer that sounds most modern or 'best practice' rather than the one that matches the project context described in the stem.
Candidates carry a personal preference for agile (or for waterfall) and read the question as 'what is the best way to manage projects' instead of 'what does this situation call for'. The stem's clues (fixed regulatory scope, co-located team, frequent change, contractual constraints) get ignored.
What to do instead
Before looking at the options, underline the context words in the stem (fixed vs. evolving scope, stakeholder availability, regulatory constraints, delivery cadence) and commit to a lifecycle orientation. Then eliminate any option that contradicts that orientation, even if it is generally a good practice.
The candidate answers with the ideal textbook response (e.g., 'escalate to the sponsor', 'rebaseline the plan') when the scenario implies a lower-effort or earlier action is appropriate.
Exam items often test the escalation ladder and the order of operations. Candidates jump to the most decisive-sounding action because it feels responsible, missing that the correct answer is usually the next step the project manager should personally take first.
What to do instead
Memorize and apply a simple decision ladder: understand/analyze the situation, attempt to resolve within the team, use the project manager's authority, then escalate. Choose the earliest rung that the stem has not already exhausted.
The candidate treats 'project', 'program', 'portfolio', and 'operations' as interchangeable and selects answers that describe ongoing operational work as a project (or vice versa).
The words sound similar and the distinctions are learned early, so candidates skim the stem and miss a keyword that signals a program-level benefit or a portfolio prioritization decision.
What to do instead
Build a one-line test for each: a project is temporary and produces a unique product/service/result; a program is a group of related projects managed for synergistic benefit; a portfolio is a collection managed to meet strategic objectives; operations is ongoing and repetitive. Apply the test to the entity named in the stem before evaluating options.
The candidate selects the network diagram or schedule answer that reflects the longest path by summing durations, without verifying path continuity or accounting for the critical path definition.
Under time pressure, candidates add durations along the visually longest chain and skip checking that each path is a valid end-to-end sequence. They also confuse 'longest path' with 'path with the most activities'.
What to do instead
For any schedule item, enumerate every complete path from start to finish, sum each path's durations, and identify the maximum. Then confirm the critical path has zero total float; if the stem gives float or early/late dates, compute forward and backward passes rather than eyeballing.
When asked what a given earned value figure means, the candidate reports the formula result but mislabels the interpretation (e.g., calls a negative cost variance 'under budget' or a CPI below 1.0 'efficient').
Candidates memorize formulas (CV = EV - AC, SV = EV - PV, CPI = EV/AC, SPI = EV/PV) but not the sign/threshold conventions, and they reverse EV and AC under pressure.
What to do instead
Anchor on plain-language rules: CV negative or CPI below 1.0 means spending more than planned for the work accomplished; SV negative or SPI below 1.0 means behind the planned schedule. Write EV first in every formula and sanity-check with a tiny numeric example before choosing.
The candidate answers change-control questions by approving the change, rejecting the change, or updating the baseline directly, rather than describing the process step the project manager should perform next.
The instinct is to resolve the scenario, and the option that 'fixes' the problem reads as more satisfying than 'submit a change request' or 'assess the impact'. Candidates also forget that approved changes flow into the baseline only through formal updates.
What to do instead
Treat every scope/schedule/cost change as a process question: the correct option is almost always to document the request, assess impact across constraints, route it to the change control body, and only then update baselines and communicate. Reject any option that modifies a baseline before approval.
The candidate maps a described practice to the wrong agile framework (e.g., attributes sprint reviews to Kanban, or assigns Scrum Master accountability for the product backlog's value to the wrong role).
Frameworks share vocabulary (iterations, boards, retrospectives), and candidates blur roles and events across Scrum, Kanban, XP, and SAFe rather than recalling each framework's distinct structure.
What to do instead
Build a comparison grid: for Scrum, list the three accountabilities, five events, and three artifacts with their purposes; for Kanban, the core practices (visualize, limit WIP, manage flow, explicit policies, feedback loops); for XP, engineering practices. When a stem names a framework, eliminate options that use another framework's event or role names.
The candidate picks a command-and-control answer (assign the task, direct the team, decide for the team) in a scenario that describes a self-organizing team or a servant-leadership situation.
Candidates with traditional management experience default to directive behavior, and the 'take charge' option feels like strong leadership. They miss cues such as 'the team is blocked', 'the team disagrees', or 'the team is new to agile'.
What to do instead
For agile scenarios, prefer options where the project manager/Scrum Master removes impediments, coaches, facilitates, and lets the team decide. Reserve directive options for genuine safety, compliance, or team-immaturity escalations explicitly signaled in the stem.
The candidate confuses business analysis elicitation with requirements documentation and selects an answer that jumps to writing or approving requirements before stakeholders have been analyzed and information gathered.
Requirements work feels like the 'real' deliverable, so candidates skip the preceding steps (stakeholder identification, elicitation planning, elicitation itself, analysis, validation) that the question is actually testing.
What to do instead
Memorize the sequence: plan the BA approach, identify and analyze stakeholders, elicit, analyze and model, document, validate, and manage requirements for change. For any 'what should the BA do next' item, locate the stem's current step and choose the immediately following step, not a later one.
The candidate accepts a stated solution or requirement at face value and selects the option that implements it, rather than recognizing that the underlying business need has not been validated.
Stems often present a stakeholder's proposed solution as if it were the requirement. Candidates conflate the requested feature with the actual problem, so they choose 'build it' over 'investigate the need'.
What to do instead
Whenever a stem quotes a stakeholder request, ask whether the problem statement, root cause, and success criteria are established. If not, the correct answer is to analyze the need (problem definition, root-cause analysis, gap analysis) before committing to a solution.