WACE Applied IT common mistakes
WACE Applied IT · Understand the traps and how to avoid them.
In the project-management section, students describe each phase of the design process in generic terms ("we planned, then we made it, then we tested it") without naming the actual deliverable produced at the end of each phase, such as a requirements list, a Gantt chart, a prototype, or a test report.
Students memorise the phase names and treat the process as a vocabulary list rather than a sequence of outputs, so they never link each phase to the document or artefact that proves it was completed. Under exam pressure they write the first generic sentence that comes to mind.
What to do instead
Practise writing one sentence per phase in the form "At the end of [phase] the team produces [artefact], which is used by [next phase] to...". Build a table of phases against deliverables for a project you have actually done, and rehearse it until the artefacts are automatic.
When asked to evaluate a design or project outcome, students list only strengths, or only weaknesses, and finish without a recommendation or judgement about whether the solution met the original requirements.
Evaluation is confused with description. Students describe what the product does instead of judging it against criteria, and they run out of time before writing the concluding judgement that carries the marks.
What to do instead
Use a fixed evaluation scaffold: restate the requirement, state evidence of how well it was met, state a limitation, then give an explicit overall judgement ("it meets the brief for X but not Y because..."). Always write the judgement sentence, even if it is short.
Students confuse primary storage with secondary storage, or RAM with ROM, describing RAM as permanent storage or claiming that a hard drive holds the data currently being processed by the CPU.
Everyday language blurs the terms ("saving to memory", "phone memory"), and students rely on that casual usage instead of the technical definitions of volatility, access by the CPU, and capacity.
What to do instead
Learn a three-column comparison table (volatility, typical capacity, role in the fetch-execute cycle) for RAM, ROM, cache, SSD and HDD, and answer hardware questions by naming the role in the cycle first, then the properties.
In data-management questions, students choose a field type for a database table by guessing from the field name (for example storing a phone number as a number, or a date as text) without considering sorting, calculation, or validation needs.
Students pick the type that looks natural rather than the type that supports the operations the question describes, and they do not think about leading zeros, date arithmetic, or range checks.
What to do instead
Before naming a data type, ask three questions: will this field be calculated on, sorted, or validated? Then justify the choice in one clause ("stored as text because leading zeros must be preserved"). Practise with phone numbers, postcodes, and dates.
Students describe a security measure such as encryption, a firewall, or two-factor authentication without stating what specific threat it mitigates and what it does not protect against.
Security terms are learned as definitions to recite, so students never pair the control with the attack it addresses, and they cannot distinguish, for example, encryption at rest from encryption in transit.
What to do instead
For each control, write a two-part card: "protects against X; does not protect against Y". Answer security questions using the pattern threat, control, residual risk, so the mitigation is always explicit.
In networking questions, students describe the internet as a single computer or confuse the roles of router, switch, and modem, or claim that a LAN and the internet use the same addressing scheme without mentioning IP addresses, DNS, or DHCP.
The devices sit in one box at home, so students never see them as separate functions. They also learn the acronyms without the purpose each device serves in moving a packet from source to destination.
What to do instead
Trace a single request (typing a web address and receiving a page) step by step, naming the device or protocol at each hop: DNS lookup, router forwarding, server response. Practise the trace until each device's job is distinct.
When asked to select and justify a software tool or feature for a task, students name a product ("use Word" or "use Excel") instead of the capability required ("use a spreadsheet with a lookup function to match records"), and give no justification tied to the task requirements.
Students answer from brand familiarity rather than from an analysis of the task, and they omit the justification sentence because they think naming the tool is the answer.
What to do instead
Answer in three moves: state the task requirement, name the capability or feature that satisfies it, then give one reason why it is preferable to an alternative. Rehearse this with tasks such as mail merge, absolute referencing, and conditional formatting.
In impacts-of-IT questions, students list only benefits (or only drawbacks) and write sweeping claims such as "technology makes life easier" or "it causes isolation" with no affected group, mechanism, or example.
These questions invite opinion, and students answer with opinion alone. They do not identify who is affected or how the effect occurs, so the response stays at the level of a slogan.
What to do instead
Structure every impact answer as: group affected, mechanism, example, counterpoint. For instance, name remote workers, explain the mechanism (always-on messaging), give a concrete example, then note the opposing effect for another group.
On emerging-technology questions, students describe a technology (AI, blockchain, IoT) in promotional terms from marketing material without stating a limitation, a dependency, or a condition under which it fails.
Students absorb advertising language and news headlines rather than technical descriptions, and they treat the novelty of the technology as sufficient for full marks.
What to do instead
For each emerging technology, prepare a balanced note: what it does, what it requires to work (data, connectivity, power, skills), and one credible limitation. Always include the limitation in the answer, even when the question only asks for a description.
Students answer extended-response questions in dot points of single words, or write a long narrative with no structure, so the reasoning linking cause to effect is never stated and marks for explanation are lost.
Time pressure encourages brevity, and students do not distinguish a list question (dot points fine) from an explain or discuss question (connected prose required). They also skip planning, so the argument has no shape.
What to do instead
Spend thirty seconds planning two or three topic sentences before writing. Use the command word to choose the format: list for identify, connected sentences with "because" or "therefore" for explain, and a balanced two-sided structure with a conclusion for discuss.