23-Ind-B4 Design of Information Systems · December 2013
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams — December 2013 — 98-Ind-B4, Design of Information Systems. 3 hours; closed book, no calculator permitted. The exam comprises four parts: Part A (select 20 of 40 terms and explain each in a sentence or two, 2 marks each = 40 marks), Parts B and C (select 2 of 5 questions in each part, 11 marks each = 22 marks per part), and Part D (select 1 of 2 questions, 16 marks). Complete answers to every term and every question in all four parts follow below, not only the minimum selection a candidate would submit on exam day.
Reference texts: Laudon & Laudon, Management Information Systems: Managing the Digital Firm, 15th ed.; Schwalbe, Information Technology Project Management, 9th ed.
Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.
Large projects fail for reasons that compound rather than stand alone: requirements are often incompletely understood or specified at the outset, and the longer a project runs the more likely business needs genuinely change underneath it, turning the target the team is building toward into a moving one; complexity grows faster than project size, because the number of interdependencies and communication paths among team members and subsystems grows roughly with the square of team size, not linearly; unrealistic budgets and schedules are frequently set for political or competitive reasons (to win executive approval) rather than from a rigorous bottom-up estimate (Question 1, term 7), guaranteeing later overrun against a target that was never achievable; and inadequate project-management discipline — weak scope/change control (term 11), thin risk management — lets problems that could have been caught early instead surface only once they are expensive to fix.
Project size (budget, staff-time, duration, number of organizational units involved) is the single strongest predictor of risk: a larger project has more interdependencies, more stakeholders to coordinate, and a longer window in which requirements can drift. Scope that is broad or poorly bounded compounds this by making it harder to know when the project is actually "done," inviting continuous, uncontrolled addition of new requirements. Organizational issues — how much the new system requires established business processes, job roles, or reporting structures to change — add a distinct risk dimension of their own, tied directly to the sociotechnical-design point (term 39): a technically excellent system that demands large process change is riskier than a technically simpler system that fits the existing organization, because it depends on organizational change succeeding as well as the technology working. Politics arise because information systems redistribute information, and therefore power (Question 8): stakeholders whose authority, visibility, or job security the new system threatens have a rational incentive to resist, delay, or under-resource it, independent of the system's technical merit, and this resistance is frequently the true, unstated cause behind a project's "requirements kept changing" or "user adoption was poor" post-mortem.
The countermeasures map directly onto the risk sources above: formal, size-appropriate project management (a defined WBS, an experienced project leader, a cohesive and technically familiar team) to manage complexity; external integration tools — a steering committee spanning both business and IT, user liaison roles — to keep the project aligned with actual user needs and to give affected stakeholders a legitimate channel that reduces political resistance rather than letting it surface as covert sabotage; disciplined bottom-up estimating (term 7) and realistic, defensible budgets/schedules set from the estimate rather than backed into from a politically desired date; formal change control (term 11) so scope changes are evaluated and approved rather than silently absorbed; a phased or pilot conversion strategy (term 13) that limits the organizational and financial exposure of any single failure; and, throughout, executive sponsorship engaged enough to resolve the organizational and political conflicts a project team itself has no authority to settle.
Rather than applying one uniform level of project-management rigour to every IS project regardless of its actual risk, an organization should score each candidate project — typically on structure (how well-defined and stable requirements are), size (budget, duration, staff, organizational units touched), and technology familiarity (proven versus novel to the organization) — at the portfolio-selection stage (portfolio analysis, Question 1, term 33), and then match the level of formal control (documentation depth, review checkpoints, steering-committee involvement, external-integration-tool use) to the resulting risk profile. A well-structured, small, familiar-technology project genuinely needs little formal overhead; a poorly structured, large, unfamiliar-technology project needs the full governance structure described above. This risk-profile-matched approach, embedded in the organization's IT governance (term 24) and enterprise risk management (term 21) framework, is what turns "manage risk" from a slogan into a specific, repeatable decision at every project's outset.
