TEST ARCHED common mistakes
TEST ARCHED · Understand the traps and how to avoid them.
Treating the project charter and the business case as interchangeable, so the candidate answers that a charter is written to justify the investment, or says the business case authorises the project manager to start work.
Both documents appear early and both mention benefits and cost, so candidates pattern-match on 'document that starts the project' without checking whether the question asks about authorisation or justification.
What to do instead
Memorise the split: the business case justifies why the work should be funded and is owned by the sponsor; the charter formally authorises the project, names the project manager, and records high-level scope, budget, and success criteria. Practise sorting sample statements into 'justification' versus 'authorisation' columns.
Answering benefit-realisation questions by naming the project manager as the owner of benefits after handover.
Candidates conflate accountability for delivery with accountability for outcomes, and the project manager is the most familiar role in the scenario.
What to do instead
Attribute benefit realisation to the sponsoring organisation or business owner; the project manager's role ends with successful transition and measurement baselines. When a question asks 'who owns the benefit', reject options that place it with the PMO or the project manager unless the scenario explicitly assigns that accountability.
Confusing a work breakdown structure with a scope statement or a task list, and then choosing 'decompose the WBS into activities' as the next step after scope baseline approval.
WBS, scope statement, and activity list are all 'lists of work', and exam wording often omits the artifact name and describes only its purpose.
What to do instead
Anchor each artifact by its level: scope statement defines boundaries and acceptance criteria; WBS decomposes deliverables (noun-based) into work packages; the activity list decomposes work packages into schedulable activities (verb-based). If an option describes verbs at WBS level, it is wrong.
Selecting 'gold plating' behaviours as good practice when a stakeholder asks for a small extra feature that is cheap and clearly useful.
Candidates reason from customer satisfaction rather than from scope control, and small additions feel harmless in a narrative scenario.
What to do instead
Apply the test: is the change inside the approved scope baseline? If not, it goes through integrated change control regardless of cost. Choose options that log the request, assess impact, and route it to the change authority; reject options that 'quietly include it to keep the stakeholder happy'.
Choosing a design pattern or architectural style by name recognition rather than by the quality attributes the scenario states, e.g. picking microservices for a small team with a single deployment target.
Candidates memorise pattern definitions but not the trade-off table, so they map 'scalable' or 'modern' to the most fashionable pattern.
What to do instead
For every architecture question, extract the stated drivers first (team size, latency, consistency, deployment frequency, budget) and eliminate options that violate a stated constraint. Write a one-line trade-off note for each common style covering coupling, operational cost, and data consistency.
Treating non-functional requirements as optional quality notes rather than as testable architectural constraints, and then answering that they are validated at user acceptance.
NFRs are often phrased qualitatively ('the system should be responsive'), so candidates classify them as soft expectations instead of measurable criteria.
What to do instead
Rewrite every NFR into a measurable form with a metric and threshold (e.g. p95 response under 300 ms at 500 concurrent users) and place its verification at the appropriate test level (performance test, security review), not at UAT. If an option has no measurable criterion, it cannot be the verification answer.
Answering critical-path questions by picking the longest-duration task, or by assuming float can be consumed freely without affecting the project finish date.
Critical path is often taught as 'the longest path', which candidates collapse into 'the longest activity', and float is intuitively treated as slack that is always safe to spend.
What to do instead
Recompute the path: sum durations along each path from start to finish and identify the path with zero total float. Remember that consuming float on a non-critical path can make it critical; only float on the critical path is zero by definition. Practise two-pass forward/backward calculations on small networks.
Choosing 'increase testing' or 'add resources' as the response to a quality problem without first identifying whether the defect source is process or product.
Candidates reach for the most visible lever, and 'more testing' sounds rigorous, but testing detects defects rather than removing their cause.
What to do instead
Use root-cause ordering: first locate the phase where the defect was introduced (cost of change rises with detection delay), then select the corrective action at that phase. Options that add inspection without changing the introducing process should be eliminated unless the question explicitly asks for containment.
Confusing risk response strategies: answering 'mitigate' when the scenario transfers liability, or 'avoid' when the team merely reduces probability.
The four negative-risk strategies differ by mechanism, not by outcome, and scenario wording ('insurance', 'fixed-price contract', 'drop the feature') is the only reliable cue.
What to do instead
Map cues to strategies: avoid = change the plan to eliminate the threat; transfer = shift financial consequence to a third party (insurance, warranty, fixed-price); mitigate = reduce probability or impact; accept = no action beyond contingency. For opportunities, use exploit, share, enhance, accept. Classify each option by mechanism before judging fit.
Answering governance questions by having the project manager approve scope changes or accept deliverables on behalf of the business.
The project manager is the central actor in most scenarios, so candidates default to PM authority whenever a decision is needed.
What to do instead
Separate delivery authority from decision authority: the PM prepares impact assessments and recommendations, while the change control board, sponsor, or customer approves changes and accepts deliverables. If an option has the PM self-approving a baseline change, it is a distractor.