HSC Enterprise Computing common mistakes
HSC Enterprise Computing · Understand the traps and how to avoid them.
When asked to describe an enterprise computing system, the candidate lists hardware and software components (e.g., servers, databases, ERP modules) but does not explain how they are integrated or how data flows between them to support business processes.
Candidates confuse the components of an enterprise system with the system itself, often because they memorise definitions without understanding the concept of integration and interdependence.
What to do instead
Practise writing explanations that explicitly link components: for each example, state how the components communicate (e.g., via APIs, shared databases) and how that integration enables a specific business function such as order processing or financial reporting.
In questions about enterprise architecture, the candidate describes only the technical layer (infrastructure, applications) and omits the business, information, and technology layers, or fails to explain how the layers align with organisational goals.
Candidates focus on the tangible technology they can see, and may not have studied frameworks like TOGAF or Zachman in enough depth to recall all layers and their relationships.
What to do instead
Create a summary table of common enterprise architecture layers (business, data/information, application, technology) and for each layer write a one-sentence purpose and an example. Then practise explaining how a change in one layer affects the others.
When evaluating the impact of an enterprise system on an organisation, the candidate lists only benefits (e.g., efficiency, data consistency) and ignores costs, risks, and change management challenges.
Candidates may assume that enterprise systems are inherently positive and overlook the need for balanced evaluation, or they may not have learned about implementation risks such as cost overruns and user resistance.
What to do instead
Use a structured evaluation framework: for each impact, identify at least one benefit and one cost or risk, and classify them as economic, operational, or social. Practise with past exam questions that ask for 'discuss' or 'evaluate' to ensure balanced responses.
When describing the role of data in enterprise systems, the candidate treats data as static records and does not discuss data quality, data governance, or the importance of master data management for decision-making.
Candidates often focus on data storage and retrieval rather than on the strategic value of data and the processes needed to ensure its accuracy and consistency across systems.
What to do instead
Study the concepts of data governance, data stewardship, and master data management. For each, write a definition and an example of how poor practice leads to business problems (e.g., duplicate customer records causing billing errors).
In questions about enterprise system security, the candidate lists technical controls (firewalls, encryption) but does not address policy, user training, or physical security, and fails to link controls to specific threats.
Candidates may rely on general cybersecurity knowledge from other courses and not adapt it to the enterprise context, where security is as much about governance and people as about technology.
What to do instead
Create a table of threat types (internal, external, physical, logical) and for each list at least one technical and one non-technical control. Practise explaining how each control mitigates the threat and who is responsible.
When asked to outline the phases of an enterprise computing project, the candidate lists phases in a rigid sequential order (e.g., initiation, planning, execution, closure) without acknowledging that phases may overlap or iterate, and without explaining the purpose of each phase.
Candidates memorise a linear model and do not understand that real projects often use iterative or agile approaches, leading to answers that lack depth and flexibility.
What to do instead
Learn both predictive (waterfall) and adaptive (agile) lifecycles. For each phase, write its key deliverable and one reason why iteration or overlap might occur. Practise describing a project scenario using both models.
When developing a project plan, the candidate includes tasks and timelines but omits resource allocation, risk management, and quality assurance activities.
Candidates focus on scheduling and may not have practised integrating all knowledge areas of project management, or they underestimate the importance of non-scheduling components.
What to do instead
Use a template that includes scope, schedule, resources, risks, and quality. For a given scenario, fill in each section with at least two specific items and explain how they interrelate (e.g., a resource shortage may increase risk).
In stakeholder analysis, the candidate identifies only direct users and ignores other stakeholders such as sponsors, suppliers, regulators, and IT support, and does not assess their influence and interest.
Candidates may think of stakeholders as only the people who will use the system, missing the broader organisational and external context that affects project success.
What to do instead
Practise creating a stakeholder matrix (influence vs. interest) and for each quadrant list example stakeholders and an engagement strategy. Use a case study to identify at least six stakeholder groups and their concerns.
When explaining project risk management, the candidate lists risks but does not describe a process for identifying, assessing, and mitigating them, and does not distinguish between risks and issues.
Candidates may treat risk management as a one-off list rather than an ongoing process, and may confuse a risk (potential future problem) with an issue (current problem).
What to do instead
Learn the risk management cycle: identify, analyse (probability and impact), plan responses (avoid, mitigate, transfer, accept), and monitor. For a project scenario, create a risk register with at least three risks, their ratings, and response strategies.
When evaluating project success, the candidate considers only whether the project was completed on time and within budget, ignoring quality, stakeholder satisfaction, and achievement of business benefits.
Candidates may rely on the traditional triple constraint (time, cost, scope) and not realise that success in enterprise projects is also measured by outcomes and value delivered.
What to do instead
Study balanced success criteria: time, cost, quality, scope, stakeholder satisfaction, and benefits realisation. For a given project, write at least three success measures beyond time and cost, and explain how each would be assessed.