ICAG Paper 1.2 BMIS common mistakes
ICAG Paper 1.2 BMIS · Understand the traps and how to avoid them.
Describing information systems purely in technical terms (hardware, software, networks) and omitting the business, organisational and management dimensions when asked what a business information system comprises.
Candidates revise the IT content in isolation and treat the exam as a computing paper, so they default to a technology-only definition and lose the marks attached to the people, process and management components.
What to do instead
Practise writing a one-sentence definition that explicitly names the five components (hardware, software, data, people, procedures) plus the business purpose, and force yourself to include at least one organisational and one managerial point in every 'what is a BMIS' answer.
Answering strategy, competitive-advantage or IS-planning questions by listing technologies (e.g. 'implement a CRM', 'move to the cloud') without linking each to a stated business objective, stakeholder or measurable outcome.
The scenario is skimmed for keywords and the candidate pattern-matches to a familiar technology, skipping the step of identifying the organisation's goals, so the answer describes tools rather than strategy alignment.
What to do instead
Before writing, extract the organisation's stated objective from the scenario and phrase every recommendation as 'to achieve X, the organisation should do Y, measured by Z'; reject any sentence that names a technology without a business rationale attached.
Confusing data, information and knowledge, or using the terms interchangeably within a single answer, and failing to apply the standard characteristics of good information (accuracy, relevance, timeliness, completeness, cost-effectiveness, etc.) to a given scenario.
The distinctions are learned as a list of definitions rather than as an analytical test, so under time pressure candidates revert to everyday usage and produce vague statements such as 'the system provides good information'.
What to do instead
Memorise a short hierarchy (data = raw facts, information = processed and meaningful, knowledge = interpreted and applied) and drill applying three named characteristics to a concrete example, stating for each whether the scenario's information meets it and why.
Writing essays that describe what a system does in general terms but never state the purpose, boundary, inputs, processes, outputs, environment and feedback of the specific system in the scenario.
Candidates memorise textbook system descriptions and reproduce them wholesale, missing that the marks come from mapping the general model onto the particular organisation described in the question.
What to do instead
Use a fixed checklist (purpose, boundary, inputs, processes, outputs, environment, feedback, control) and write one labelled sentence for each element using the scenario's own entities; if an element cannot be identified, say so explicitly and explain the implication.
Treating the systems development life cycle as a single undifferentiated block, so answers cannot distinguish requirements analysis from design, or testing from implementation, and cannot say what deliverable ends each stage.
Revision focuses on memorising stage names in order rather than the purpose, activities and outputs of each stage, so the stages blur together and the answer becomes a list of labels.
What to do instead
Build a table with one row per stage and columns for purpose, key activities, deliverable and who signs it off; practise describing a project's progress through the table so that each stage is defined by its output rather than its position in the sequence.
Recommending a development approach (waterfall, prototyping, agile, off-the-shelf package) without justifying it against the specific risk profile, requirement stability, timescale and organisational capability described in the scenario.
Candidates learn methodologies as descriptions and never as decision tools, so they pick the approach they know best and assert it is suitable instead of arguing from the scenario's constraints.
What to do instead
For each methodology, memorise two conditions where it fits and two where it fails, then answer in the form 'given [scenario condition], [approach] is appropriate because [mechanism], whereas [alternative] would fail because [reason]'.
Listing generic threats ('hackers', 'viruses', 'human error') without naming the asset at risk, the vulnerability being exploited, the likelihood and impact, or the specific control that addresses that vulnerability.
Security is revised as a vocabulary list of threat names, so candidates produce category labels instead of a risk analysis and the control they suggest is unrelated to the threat described.
What to do instead
Answer security questions with an explicit chain: asset, threat, vulnerability, likelihood, impact, control, residual risk. Check that each control you name actually closes the vulnerability you identified, and say what risk remains after the control.
Describing controls only in technical terms (firewalls, encryption, passwords) and omitting administrative and physical controls, or omitting the human and procedural side such as segregation of duties, access review and staff training.
Candidates equate information security with IT security and underestimate the proportion of marks awarded for managerial, legal and procedural controls in a business information systems paper.
What to do instead
For every control question, deliberately produce at least one control in each category (physical, technical, administrative/procedural) and state who in the organisation is responsible for operating each one.
Answering acquisition and implementation questions as if buying software ends the project, omitting data migration, configuration, user acceptance testing, training, change management and post-implementation review.
Attention is drawn to the visible procurement decision and the candidate has no mental model of the whole lifecycle, so the costly and risky later stages are forgotten even though they carry many marks.
What to do instead
Memorise a fixed implementation checklist (selection, contract, configuration, data migration and cleansing, testing, training, go-live and support, post-implementation review) and run every acquisition answer through it, naming the main risk at each stage.
Producing unstructured essay answers with no clear argument, no use of the scenario's facts and no conclusion, so valid points are buried and the marker cannot award application or evaluation marks.
Candidates write everything they know about the topic in the order it comes to mind, under time pressure, rather than planning a short structure that answers the verb in the question (explain, evaluate, recommend).
What to do instead
Spend the first two minutes writing a three-line plan (issue, analysis, recommendation), open each paragraph with a topic sentence that answers part of the question, cite a scenario fact in every paragraph, and close with an explicit recommendation that follows from the analysis.