Introduction to System Analysis

The Business Case for a New System

18 min Lesson 6 of 10

The Business Case for a New System

Every systems project begins with a question: why does this system need to exist? Before a single requirement is written, a database is sketched, or a developer is assigned, someone must be able to answer that question convincingly — in business terms, not technical ones. That answer is the business case.

The business case is the foundational document that justifies a new system (or a major change to an existing one). It frames the need, quantifies the problem, proposes a solution direction, and ties everything back to organisational goals. A strong business case is the difference between a project that gets funded and championed, and one that dies in committee.

Key idea: The systems analyst is often the person who builds or validates the business case. Understanding what triggers a project — and how to frame that trigger as a compelling argument — is one of the most important skills in the profession.

The Three Triggers: Problems, Opportunities, and Directives

Projects do not appear from nowhere. Every system project is set in motion by one of three types of triggers:

Problems — something is broken, slow, costly, or error-prone in the current situation. The organisation must act to stop harm.
Opportunities — something new is possible: a market opening, a new technology, a competitor's weakness. The organisation can gain advantage by acting.
Directives — an external or internal mandate requires action regardless of perceived benefit. A new regulation, a merger, a board decision.

Most real projects are driven by more than one trigger. Recognising which type dominates shapes how you frame the business case and who you need to convince.

The three project triggers — Problems, Opportunities, and Directives — feed into analysis, which produces the business case.

Problems: When the Current System Is Failing

A problem trigger exists when the current way of doing things is causing measurable harm — wasted time, lost revenue, compliance violations, or customer defection. The analyst's job is to characterise the problem clearly and quantify its cost.

Consider a private clinic in Dubai. Patients book appointments by phone, a receptionist writes them in a paper diary, and the doctor often sees duplicate bookings or no-shows with no advance warning. The measurable harm is real:

30% of appointment slots wasted on no-shows (each slot worth AED 200 = ~AED 12,000 lost per week).
3–4 double-bookings per week causing patient complaints and rescheduling costs.
Receptionists spend 2 hours daily on reminder calls that could be automated.

This is the problem statement. Notice how each item is concrete and numbered. Vague problems — "the booking system is inefficient" — are much harder to justify funding for than costed ones.

Best practice: Always attach a number to a problem. "We lose approximately AED 12,000 per week" is far more persuasive than "we have wasted appointment slots." If exact figures are unavailable, use conservative estimates and state your assumptions.

Opportunities: When Conditions Allow You to Gain Ground

An opportunity trigger is not about what is broken — it is about what is newly possible. Market conditions shift, new technology matures, or a competitor stumbles. Acting on an opportunity builds advantage; failing to act erodes it.

Suppose a mid-size logistics firm in Amman has been running manual route planning. A logistics startup competitor just launched real-time AI-assisted routing in the same market, cutting fuel costs by 18%. The firm is not technically "broken" — but the competitive gap is widening.

The opportunity: by adopting a route-optimisation system now, the firm can close the gap before the competitor's advantage becomes irreversible. Projected benefit: AED 80,000 per month in fuel savings plus a 12% increase in delivery capacity. That is the business case framing for an opportunity.

Directives: When You Have No Choice

A directive trigger comes from outside the organisation's control — or from a level of authority that has already decided. Examples:

A new data-protection regulation (like GDPR or the UAE PDPL) requires audit logs of every customer-data access — the existing system has none.
A parent company acquires a smaller firm and mandates integration with the group's ERP within 12 months.
The board decides to move all operations to cloud-based systems by year end.

When a directive drives a project, the "why invest" argument is already made. The business case focuses instead on which solution meets the mandate at acceptable cost and risk, and by what date.

Common pitfall: Treating a directive project as if it needs the same justification as a problem or opportunity project wastes time and misframes the stakeholder conversation. For directives, compliance and risk mitigation are the primary value arguments — not ROI.

Framing the Business Need: Four Essential Questions

Regardless of trigger type, a well-formed business case answers four questions:

What is the current situation and what is wrong (or possible) about it? Describe and quantify the current state. Use data from interviews, process observation, and system logs.
What is the desired future state? Describe the target outcome in measurable terms: "appointment no-show rate below 10%", "route planning completed in under 5 minutes", "full audit log of all PII accesses retained for 7 years."
What are the broad solution options and their trade-offs? A business case is not a technical specification, but it should sketch the main options (buy off-the-shelf, build custom, hybrid, process change without IT) and give a rough cost/benefit comparison.
What is the recommended course of action and why? The analyst makes a recommendation — not just a list of options. Decision-makers need a clear steer.

The four-question structure of a business case — from current pain to recommended action.

Putting It Together: A Worked Example

An online grocery retailer in Riyadh currently processes all customer orders through a single legacy system. During Ramadan peak demand, the system crashes for an average of 4 hours per day, costing an estimated SAR 35,000 per hour in lost sales. Outside peak periods, the system is adequate. What type of trigger is this?

Primary trigger: Problem — the current system causes quantifiable revenue loss during a predictable, recurring event.
Secondary trigger: Opportunity — a scalable cloud platform would also enable features (personalised recommendations, loyalty programme integration) not currently possible.

A good business case frames both. The problem gives urgency and justifies the timeline; the opportunity justifies a larger investment than pure cost-avoidance would warrant.

The recommended course of action might be: migrate the order-management core to a cloud-native platform by Q3 (before the next Ramadan) at an estimated cost of SAR 800,000, projected to eliminate the SAR 35,000/hour downtime loss and unlock SAR 200,000 annually in upsell revenue from the new personalisation engine. Net positive ROI within 14 months.

Remember: The business case is a living document. It should be revisited at key project milestones — if the underlying problem changes, or if a solution option proves more or less costly than estimated, the business case must be updated and re-approved. Analysts who let a business case go stale find that projects lose sponsorship when the numbers no longer hold.

Summary

Projects are initiated by three types of triggers: problems that cause harm, opportunities that offer advantage, and directives that impose requirements. The business case translates these triggers into a structured argument: current situation, desired future state, solution options, and a clear recommendation. Quantifying the need — in revenue lost, time wasted, compliance risk, or competitive gap — is the analyst's most persuasive tool. A compelling business case earns buy-in from the people who control budget and priorities, and sets the scope for everything that follows in the project lifecycle.