Ruankao Information System Project Manager (Senior) common mistakes
Ruankao Information System Project Manager (Senior) · Understand the traps and how to avoid them.
When answering earned value questions, candidates compute CV, SV, CPI and SPI but then state the schedule or cost status backwards, for example calling CPI = 0.85 'under budget' or SPI = 1.2 'behind schedule'. They also mix up whether EAC = BAC/CPI or EAC = AC + (BAC − EV) applies to the scenario given.
The formulas are memorised as symbols without a mental model of what the ratio compares. Candidates also rush because earned value questions appear in batches, and they do not anchor the interpretation to 'value earned per unit spent' or 'value earned per unit of planned time'.
What to do instead
CPI=EV/AC compares earned value with actual cost, while SPI=EV/PV compares earned value with planned value rather than elapsed duration. Interpret each under the stated baseline and choose EAC assumptions before calculating; neither index alone proves overall project health.
On critical path questions candidates identify the longest path but then answer the float question wrongly, treating total float and free float as interchangeable, or forgetting that a path's length must be recomputed after a duration change or a dependency-type change (for example FS to SS with a lag).
Candidates learn 'longest path = critical path' as a shortcut and skip drawing the network. When a question adds a lag or a start-to-start relationship, the shortcut silently fails, and total float versus free float is confused because both are described as 'slack'.
What to do instead
Always draw the activity-on-node network with early start, early finish, late start, late finish for every node, even when it feels slow. Then read total float = LS − ES and free float = min(ES of successors) − EF. When a question changes a dependency or adds a lag, redraw the affected portion and recompute path lengths explicitly rather than adjusting the old answer.
Candidates answer scope and requirements questions by choosing the tool they like (for example interviews or focus groups) rather than the tool the scenario demands, and they confuse the scope baseline (scope statement, WBS, WBS dictionary) with the requirements documentation or the project management plan as a whole.
Tool names are memorised as a list with thin definitions, so any option that sounds like 'gathering requirements' looks correct. The three components of the scope baseline are learned as a phrase without the function of each part, so questions that ask which document authorises work or defines acceptance criteria become guesswork.
What to do instead
Build a one-page comparison table for each requirements-gathering technique with columns: best when, output produced, limitation. Do the same for the scope baseline components, stating what each contains and which management process creates it. For every practice question, first name the process being tested, then the output, then choose the option that matches that output.
On organisational structure questions candidates answer by stereotype ('matrix is always better') rather than reading the scenario for the authority clues, and they misclassify weak, balanced and strong matrix projects, or confuse a project expeditor with a project coordinator.
The structures are learned as a ranking rather than as a set of authority arrangements. The distinguishing clues in the scenario (who controls the budget, who sets priorities, who performs performance reviews, where the project manager sits) are not actively looked for.
What to do instead
Make a table of functional, weak matrix, balanced matrix, strong matrix and projectised, with rows for budget control, resource control, project manager authority, and who reviews the project manager. Learn that an expeditor has no decision authority and a coordinator has some. On every question, underline the authority clue in the stem before reading the options.
Candidates confuse the project charter with the project management plan and with the contract, answering that the charter is created by the project manager, that it contains the detailed schedule, or that it can be changed by the project team. They also misstate who authorises the charter and who signs it.
The charter is introduced early and then rarely revisited, so its content and authorship blur into the general idea of 'the starting document'. Because the project manager is the central figure in most scenarios, candidates assume the project manager writes the charter.
What to do instead
Memorise three facts together: the charter is issued by the sponsor or initiating organisation, it formally authorises the project and names the project manager, and it contains high-level scope, objectives, milestones, budget summary and success criteria but no detailed plan. Note that the project manager may contribute to drafting but does not authorise it. Test yourself by asking, for each listed item, whether it belongs in the charter or the plan.
In quality management questions candidates pick 'inspect more' or 'increase testing' as the remedy for every quality problem, and they mix up quality assurance (process-oriented) with quality control (product-oriented), or confuse the cost of conformance with the cost of non-conformance.
Testing is the most familiar quality activity, so it becomes the default answer. The assurance/control distinction is abstract, and the cost categories are memorised as vocabulary without examples.
What to do instead
Learn the pairing: quality assurance audits processes and produces change requests and updates; quality control inspects deliverables and produces verified deliverables and quality control measurements. For cost of quality, sort examples into prevention, appraisal, internal failure and external failure, and note that prevention and appraisal are conformance costs while failures are non-conformance. When a question says the process is unstable, the answer involves process improvement, not more inspection.
Candidates treat risk management as a list of threats and forget that risk includes positive opportunities, that risk identification must involve the whole team and stakeholders, and that qualitative and quantitative analysis are distinct processes with different outputs. They also confuse the risk register with the risk report.
Everyday usage of the word 'risk' means danger, so opportunities are overlooked. The process names sound similar, and candidates memorise the register as the only risk document, missing that the risk report summarises overall exposure and analysis results.
What to do instead
Learn the risk processes in order with one sentence each on purpose and output, and explicitly note that opportunities are risks with positive effect and are handled by exploit, share, enhance and accept. Memorise the split: risk register holds individual risks and responses; risk report holds overall project risk exposure, analysis summaries and trends. In practice questions, check whether the scenario is about an individual risk or overall exposure before choosing.
Candidates answer procurement and contract questions by choosing the contract type that seems safest for the buyer in every case, ignore the risk-allocation principle, and confuse the procurement documents (RFI, RFQ, RFP) with the contract itself or mix up termination, breach and dispute resolution steps.
Procurement is often skimmed because it feels like legal detail, so the underlying rule that the party best able to manage a risk should bear it is never internalised. The document abbreviations are memorised without their purpose.
What to do instead
Learn one governing principle: contract type follows risk allocation. Fixed-price suits well-defined scope and puts cost risk on the seller; cost-reimbursable suits uncertain scope and puts cost risk on the buyer; time and materials sits in between. Then learn RFI (gather information), RFQ (price for defined items) and RFP (proposals for solution) by purpose. For disputes, memorise the escalation order from negotiation through ADR to litigation or arbitration as stated in the contract.
In case-analysis questions candidates write long narrative answers describing what the project manager should generally do, without naming the specific process, input, tool or output, and without tying the recommendation to the facts given in the case.
Case analysis is treated as an essay about good practice rather than as an application of the standard process framework. Candidates also run out of time on the multiple-choice section and write the case answers under pressure without structure.
What to do instead
Adopt a fixed answer template: identify the problem, name the management area and process, state the missing or incorrect input/tool/output, then give two or three concrete corrective actions with the artefact to be produced. Quote a fact from the case in each paragraph. Rehearse with timed past-style cases so the template becomes automatic.
Choosing a software architecture from a fashionable label without a measurable constraint.
The shortcut substitutes a label for the actual mapping, system state or measurable requirement, so it can select a technically inappropriate remedy.
What to do instead
State the actual quality scenario, failure assumptions, interfaces and evidence. Compare trade-offs rather than assuming microservices or an event bus automatically improve every quality attribute.
Candidates rely on generic project-management intuition for the information systems and technology fundamentals section, guessing at questions on network topologies, database normalisation, encryption and authentication, or system integration architectures, and they skip the laws, regulations and standards items assuming they are common sense.
The technology and legal domains feel peripheral to the 'management' identity of the exam, so study time is concentrated on the ten management knowledge areas. The technical vocabulary is broad and candidates cannot judge which terms they actually know.
What to do instead
Allocate a fixed weekly block to the technical fundamentals, covering networking basics, database and normalisation concepts, information security principles including symmetric versus asymmetric encryption and authentication factors, and common integration styles. For law and standards, learn the specific obligations and thresholds rather than slogans, and note which standard applies to which artefact. Use short recall quizzes rather than long reading so gaps surface quickly.
Answering an impacts-of-computing prompt with a slogan, such as 'automation causes job loss' or 'algorithms are biased', without naming the mechanism, the affected group, or a plausible mitigation, and confusing patents, copyrights, and trademarks in intellectual-property items.
These questions read as opinion rather than analysis, so candidates write the first socially acceptable claim instead of constructing a cause-and-effect chain, and the three IP regimes blur together as 'legal protection'.
What to do instead
Use a fixed three-part structure: mechanism (what the system does), affected party (who bears the cost or benefit), and mitigation (policy, design, or access remedy). For IP, key on the object protected (invention, expression, brand identifier) rather than on the duration.