Business Cases, Feasibility and Investment Decisions

Introduction

Information technology projects consume scarce capital, specialist skills, managerial attention and organisational capacity. A technically attractive idea is not automatically a sound investment. A business case connects a proposed intervention with a measurable organisational problem, evaluates whether it can be delivered, estimates its costs and benefits, and makes the assumptions and risks visible to decision-makers.

In project and product management, the business case is both an analytical instrument and a governance document. It supports portfolio selection, funding approval, prioritisation and later benefits realisation. It should not be treated as a document written only to obtain approval. A credible business case also identifies conditions under which the investment should be stopped, redesigned or deferred.

The central decision is not simply “Is this technology valuable?” It is “Does this alternative create sufficient risk-adjusted value, within the organisation’s constraints, compared with doing nothing or choosing another alternative?”

Learning Objectives

By the end of this chapter, readers should be able to:

1. Explain the purpose, structure and lifecycle of an IT business case.
2. Distinguish technical, operational, economic, legal and schedule feasibility.
3. Identify costs, benefits, assumptions, dependencies and uncertainties.
4. Calculate and interpret ROI, payback period, NPV and total cost of ownership.
5. Apply weighted scoring and sensitivity analysis to investment decisions.
6. Explain how real-options reasoning improves decisions under uncertainty.
7. Critically evaluate ethical, regulatory and governance issues in business cases.
8. Recommend an investment decision using evidence rather than unsupported optimism.

1. The Business Case as a Decision Model

A business case describes a decision situation, not merely a proposed solution. It normally contains:

• the strategic or operational problem;
• the current-state baseline;
• objectives and measurable outcomes;
• alternative courses of action;
• feasibility findings;
• costs, benefits and cash-flow timing;
• risks, assumptions and dependencies;
• implementation schedule;
• governance, ownership and benefits-realisation arrangements; and
• a recommendation and decision rights.

The “do nothing” or “continue as usual” option is essential. It provides the counterfactual against which alternatives are compared. Other alternatives may include incremental improvement, outsourcing, commercial software, internal development, platform adoption, or a staged pilot.

A business case should distinguish outputs, outcomes and benefits. An output is a delivered product, such as a data platform. An outcome is a change in behaviour or capability, such as faster reporting. A benefit is the resulting improvement, such as reduced inventory or better regulatory compliance. Installing software does not by itself establish that benefits will occur.

1.1 Strategic alignment and problem definition

A strong problem statement identifies who is affected, what is failing, how the failure is measured and why action is needed now. Statements such as “the organisation needs artificial intelligence” are solution-led and weak. A stronger statement might be: “Customer-service requests exceed capacity during peak periods, producing a three-day response delay and avoidable churn.”

Strategic alignment should be explicit. The proposal may support revenue growth, cost efficiency, resilience, customer experience, regulatory compliance, sustainability or innovation. Alignment, however, is not proof of value. A strategically aligned proposal may still fail economic, legal or delivery tests.

1.2 Assumptions, constraints and dependencies

Assumptions are propositions accepted temporarily for analysis, such as expected adoption or supplier pricing. Constraints are limits, such as a fixed regulatory deadline or an approved capital ceiling. Dependencies are conditions outside the proposal’s direct control, such as network upgrades, data quality, procurement or organisational restructuring.

Every material assumption should have an owner, evidence level and validation plan. A useful classification is:

2. Feasibility Analysis

Feasibility is multidimensional. Passing one dimension does not compensate automatically for failing another. A project can be technically feasible but legally unacceptable, economically attractive but operationally impossible, or strategically important but impossible to deliver by the required date.

2.1 Technical feasibility

Technical feasibility examines whether the proposed capability can be built, integrated, secured, operated and scaled with available technology and skills. Questions include:

• Can existing systems exchange the required data?
• Are data quality, latency, volume and interoperability adequate?
• Can performance, availability, recovery and security requirements be met?
• Is the architecture compatible with standards and organisational platforms?
• Are specialist skills, environments and vendor capabilities available?
• Can the solution be maintained after implementation?

A proof of concept should test the riskiest technical assumptions, not merely demonstrate a visually impressive prototype. For an AI system, this may include model performance across relevant groups, explainability, data provenance, drift monitoring and human oversight.

Technical feasibility should include non-functional requirements. A system that performs correctly but cannot meet a 99.9% availability target or a required response time is not feasible for its intended use.

2.2 Operational feasibility

Operational feasibility concerns adoption and sustained use. It asks whether processes, roles, skills, culture and support arrangements can absorb the change. Important factors include:

• executive sponsorship and stakeholder acceptance;
• process redesign and role clarity;
• training and support capacity;
• accessibility and usability;
• service management and incident response;
• data ownership and operating procedures; and
• readiness of customers, suppliers and employees.

Operational feasibility is often underestimated because business cases focus on procurement and implementation rather than behavioural change. Benefits are usually realised through changed work practices, not through the technical asset alone.

2.3 Economic and financial feasibility

Economic feasibility compares the value of expected consequences with resources consumed. Financial feasibility focuses on cash flows and funding impact; economic appraisal may also include non-cash or societal effects such as safety, service quality and compliance.

Costs should include more than purchase price. Typical categories are:

• discovery, design and implementation;
• licences, cloud consumption and infrastructure;
• data migration and integration;
• training, communications and change management;
• cybersecurity, privacy and assurance;
• support, maintenance and upgrades;
• retirement of legacy systems; and
• contingency for identified uncertainty.

Benefits may be financial, operational, strategic, regulatory or social. Avoid double counting. For example, a reduction in processing time should not also be counted as full labour savings unless the capacity is actually removed or redeployed to value-creating work.

2.4 Legal and regulatory feasibility

Legal feasibility addresses whether the proposal can operate lawfully and contractually. Depending on the context, review may include:

• privacy and data-protection obligations;
• intellectual-property ownership and licensing;
• cybersecurity and breach-notification duties;
• sector regulations and records retention;
• procurement and competition requirements;
• employment and workplace law;
• accessibility and discrimination law; and
• cross-border data transfer and supplier jurisdiction.

Legal feasibility is not a final “sign-off” added after the business case. Legal constraints can change architecture, supplier selection, data design and schedule. A proposal depending on unrestricted use of personal data may be economically attractive but infeasible if lawful consent, purpose limitation or retention requirements cannot be satisfied.

2.5 Schedule feasibility

Schedule feasibility asks whether the capability can be delivered by the date at which its value is needed. It should consider critical-path activities, procurement lead times, regulatory approvals, data migration, testing, training and organisational readiness.

A schedule compressed beyond realistic limits increases rework, defects and operational risk. Schedule feasibility is therefore not demonstrated merely by drawing activities in a project plan. Estimates should identify uncertainty, dependencies and resource constraints. A date imposed by management is a constraint, not evidence that delivery is feasible.

3. Financial Evaluation Methods

No single financial metric is sufficient. Metrics answer different questions and can produce different rankings. They should be accompanied by assumptions, scenario analysis and qualitative judgement.

3.1 Return on investment

A common simple ROI expression is:

Here, benefits and costs must use the same period, valuation basis and currency. Simple ROI does not normally account for the timing of cash flows, financing costs or risk. It is useful for communication but weak as the sole investment criterion.

For example, an initiative costing $400,000 and producing quantified benefits of $520,000 has:

ROI = (520,000 − 400,000) ÷ 400,000 × 100% = 30%

The result does not mean that the organisation earns 30% every year; it is a cumulative ratio for the defined appraisal period.

3.2 Payback period

The payback period is the time required for cumulative net cash flow to recover the initial investment. With equal annual net cash inflows:

If an investment is $600,000 and annual net cash inflow is $200,000, payback is three years. With unequal cash flows, cumulative cash flows must be calculated year by year. Payback ignores benefits after recovery and usually ignores the time value of money. A discounted payback period corrects the latter by using discounted cash flows but still ignores post-payback value.

3.3 Net present value

NPV expresses future net cash flows in present-value terms:

CF_t is net cash flow in period t, r is the discount rate per period, and n is the final period. CF₀ is commonly negative because it represents the initial investment. The discount rate should reflect the organisation’s opportunity cost of capital and, where appropriate, project risk. Cash flows and the discount rate must use compatible periods and nominal or real price assumptions.

If an initiative requires $500,000 immediately and returns $230,000 at the end of each of three years, with a 10% annual discount rate:

A positive NPV indicates value above the selected benchmark under the assumptions used. It does not prove that the project is risk-free or strategically preferable.

3.4 Total cost of ownership

TCO estimates the full cost of acquiring, operating, changing and retiring an asset or service:

TCO is a cost model, not a value model. It should include direct and indirect costs over a defined time horizon. Cloud services, for example, may reduce initial capital expenditure while increasing variable operating expenditure, monitoring needs, data-transfer charges and supplier-dependency costs.

3.5 Benefits realisation and benefit-cost ratio

A benefit-cost ratio can be expressed as:

A ratio above 1 indicates that discounted benefits exceed discounted costs, subject to consistent assumptions. Benefits should have owners, measures, baselines, target dates and mechanisms for attribution.

4. Risk, Uncertainty and Decision Quality

A forecast is not a fact. Demand, adoption, supplier performance, productivity improvement and technical performance are uncertain. A mature business case makes uncertainty visible rather than presenting a single precise number.

4.1 Sensitivity and scenario analysis

Sensitivity analysis changes one assumption at a time to identify influential variables. Scenario analysis changes several connected assumptions, such as demand, delivery delay and adoption rate. Typical scenarios are optimistic, central and pessimistic, but scenarios should be evidence-based rather than arbitrary.

A tornado analysis can rank assumptions by their effect on NPV. If a small change in adoption makes NPV negative, adoption is a critical risk and should receive early validation.

4.2 Weighted scoring

Financial value does not capture all decision criteria. A weighted scoring model can evaluate alternatives against strategic alignment, security, usability, delivery risk, sustainability and regulatory fit.

w_i is the weight of criterion i, with weights normally summing to 1, and s_ij is the score of alternative j on that criterion. Scores must use a defined scale, such as 0–5, and evaluators should document evidence. Weights should be tested because stakeholders may manipulate them to favour a preferred option.

Scoring does not create objectivity automatically. It makes judgement more explicit and auditable.

4.3 Real-options reasoning

Traditional appraisal often assumes that management commits to a project immediately and follows a fixed path. Real-options reasoning recognises the value of flexibility. An organisation may have the option to defer, expand, abandon, switch suppliers or stage investment after learning more.

Examples include:

• funding a pilot before full deployment;
• building a modular architecture that preserves supplier choice;
• purchasing capacity incrementally rather than committing to a large contract;
• retaining an exit clause if performance or regulation changes; and
• delaying an irreversible investment until uncertainty reduces.

The option has value when uncertainty is significant, future choices are available and investment can be staged. Staging also has costs: delay, duplicated work and possible loss of first-mover advantage. Real-options reasoning should therefore complement, not replace, NPV analysis.

5. Constructing and Governing the Business Case

A practical development sequence is:

1. Define the decision and problem.
2. Establish the baseline and counterfactual.
3. Identify feasible alternatives.
4. Test the highest-risk technical and operational assumptions.
5. Estimate costs, benefits and timing.
6. Evaluate legal, security, ethical and schedule constraints.
7. Model uncertainty and alternatives.
8. Recommend a decision with conditions and review points.
9. Assign benefit owners and establish post-implementation measurement.

The business case should be reviewed at stage gates. At each gate, decision-makers should ask whether evidence has improved, assumptions remain valid and the project should continue, pivot, pause or stop. This prevents escalation of commitment, in which prior expenditure is incorrectly used to justify further expenditure.

A benefits register may contain the benefit description, baseline, target, measure, owner, expected date, dependencies and evidence status. Benefits should be reviewed after implementation because delivery success and benefit success are different outcomes.

6. Illustrative Case: Regional Hospital Digital Scheduling

This is a fictional illustrative case designed for academic analysis.

Background and problem

A regional hospital operates outpatient clinics using separate scheduling systems. Appointment changes are handled manually, missed appointments are high and staff spend substantial time reconciling records. The hospital proposes an integrated scheduling and reminder platform.

The baseline is:

• implementation cost: $900,000 paid at the start;
• annual operating cost: $180,000;
• expected annual measurable benefit: $500,000 from reduced administrative effort and improved capacity;
• appraisal period: four years;
• discount rate: 8% per year;
• implementation duration: nine months.

The benefit estimate assumes that released staff capacity is redeployed to additional appointments rather than simply recorded as theoretical time savings.

Feasibility analysis

Technical feasibility. The platform has standard interfaces, but patient-identity matching and integration with the clinical-record system are high-risk areas. A pilot using representative, de-identified data is required.

Operational feasibility. Clinics must adopt common scheduling rules. Training and a transition period are needed because local workarounds are currently embedded in practice.

Legal feasibility. Patient information requires privacy controls, access logging, retention rules and a contract defining supplier responsibilities and breach notification.

Schedule feasibility. The nine-month target is plausible only if procurement and privacy review begin immediately. Migration during the peak winter period is not acceptable.

Economic feasibility. Annual net cash inflow is $320,000 before tax effects, calculated as $500,000 − $180,000.

Financial analysis

Simple payback is:

Payback = 900,000 ÷ 320,000 = 2.8125 years

For NPV, the cash flows are −$900,000 at time zero and $320,000 at the end of each of four years:

Under the central assumptions, the project has a positive NPV. However, a 20% reduction in realised benefits reduces annual net cash inflow to $220,000. The resulting NPV is approximately:

This sensitivity reveals that benefit realisation is decisive. The recommended decision should therefore be conditional: approve a controlled pilot, require evidence of appointment-capacity benefits, and release full funding only if identity matching, adoption and measurable capacity improvement meet agreed thresholds.

Outcome and learning points

In this illustrative case, a full immediate commitment is less defensible than a staged investment. The hospital should establish a pilot, validate the baseline, agree benefit ownership with clinic managers, and retain contractual exit and data-portability protections. The positive central NPV supports investigation, but the negative downside NPV demonstrates why feasibility evidence and real-options reasoning matter.

The case illustrates five principles:

1. A benefit must be tied to an operational mechanism.
2. Integration and adoption may dominate software functionality as risks.
3. Positive NPV is conditional on assumptions.
4. A pilot can purchase information before irreversible spending.
5. Governance must continue after approval.

7. Ethical, Governance and Contemporary Issues

Investment decisions distribute benefits, risks and burdens. A business case should therefore consider fairness, accessibility, worker impact, environmental effects and the possibility of harm. Automation may improve efficiency while reducing roles or increasing surveillance. AI systems may produce discriminatory outcomes if training data or evaluation methods are biased.

Governance should address accountability, auditability, security, privacy, model monitoring and human review. Claims about AI productivity should be separated from measured evidence. A responsible business case identifies data provenance, performance limits, failure modes and escalation procedures.

Sustainability is increasingly relevant. Evaluation may include energy consumption, hardware lifecycle, data-centre impacts, supplier practices and e-waste. These factors may be included as scored criteria, quantified costs, constraints or qualitative risks, but the method should be transparent.

Contemporary digital investments also face platform dependence, cybersecurity threats, rapid technology obsolescence and changing regulation. Modular architecture, open standards, data portability and staged contracts can preserve strategic flexibility.

8. Limitations and Best Practices

Business cases cannot eliminate uncertainty. Long-term forecasts may be unreliable, benefits may be difficult to attribute, and financial metrics may undervalue public or ethical outcomes. A high-scoring project may still fail because of weak leadership or poor adoption. Conversely, a project with modest direct returns may be necessary for resilience, compliance or strategic survival.

Best practices include:

• compare several realistic alternatives, including the counterfactual;
• use evidence and ranges rather than false precision;
• separate sunk costs from future decision costs;
• distinguish cash benefits from capacity benefits;
• include full lifecycle and transition costs;
• test technical and adoption assumptions early;
• use NPV alongside payback, TCO and qualitative criteria;
• document who owns each benefit;
• make legal, privacy, security and ethical review part of design;
• use stage gates and stop-or-pivot criteria; and
• update the business case when material assumptions change.

Chapter Summary

A business case is a structured decision model linking a problem, alternatives, feasibility evidence, costs, benefits, risks and governance. IT investment decisions require examination of technical, operational, economic, legal and schedule feasibility. ROI communicates a simple cumulative return, payback indicates recovery time, NPV accounts for the time value of money, and TCO exposes lifecycle expenditure. None is sufficient alone.

Reliable appraisal makes assumptions explicit, uses baselines and counterfactuals, tests sensitivity and assigns benefit ownership. Weighted scoring helps compare strategic and non-financial criteria, while real-options reasoning recognises the value of staged investment and flexibility under uncertainty. Ethical, legal, privacy, security and sustainability considerations are integral to feasibility. The best recommendation is not necessarily immediate approval: it may be a pilot, conditional funding, redesign, deferral or rejection.

Key Terms

Business case: Structured justification and decision model for an initiative.

Counterfactual: What is expected to happen if the proposal is not undertaken.

Feasibility: Assessment of whether an initiative can and should be delivered.

Technical feasibility: Capability to build, integrate, secure and operate the solution.

Operational feasibility: Capability of people and processes to adopt and sustain change.

Economic feasibility: Comparison of expected value with resources consumed.

Legal feasibility: Assessment of compliance with law, regulation and contracts.

Schedule feasibility: Assessment of deliverability within the required time.

ROI: Ratio of net benefits to costs, usually expressed as a percentage.

Payback period: Time required to recover the initial investment.

NPV: Present value of future net cash flows less the initial investment.

Discount rate: Rate used to convert future cash flows into present values.

TCO: Total lifecycle cost of acquiring, operating, changing and retiring an asset.

Benefit realisation: Process of achieving and measuring intended benefits.

Sensitivity analysis: Examination of the effect of changing one assumption.

Scenario analysis: Evaluation of outcomes under coherent alternative conditions.

Weighted scoring: Multi-criteria comparison using weighted evaluation criteria.

Real option: Value created by preserving the ability to defer, expand, abandon or switch.

Stage gate: Formal review point at which continuation, change or termination is decided.

Review Questions

5 Short Answer Questions

1. Why should the “do nothing” option be included in a business case?
2. Distinguish an output, an outcome and a benefit.
3. What does NPV add that simple ROI does not?
4. Identify four categories of IT project cost.
5. Why is operational feasibility important after technical feasibility has been demonstrated?

5 Long Answer Questions

1. Explain the five dimensions of feasibility and show how failure in one dimension can affect the others.
2. Compare ROI, payback period, NPV and TCO, including the strengths and limitations of each.
3. Describe how a business case should manage assumptions, risks, dependencies and benefits ownership.
4. Explain weighted scoring and discuss why it does not automatically eliminate subjectivity.
5. Discuss the ethical, legal and governance issues that should be considered in an AI-enabled IT investment.

3 Analytical / Application Questions

1. An initiative requires $750,000 initially and generates annual net cash inflows of $250,000 for four years. Calculate simple payback and NPV at an 8% annual discount rate. Interpret both results and identify at least two assumptions requiring validation.
2. A proposed platform has a positive central NPV but a negative NPV under low-adoption conditions. Recommend an investment approach using sensitivity analysis and real-options reasoning.
3. Construct a weighted scoring model for three alternatives: internal development, commercial software and outsourcing. Select at least five criteria, assign weights summing to 1, define a scoring scale and explain how you would test the robustness of the recommendation.

Multiple Choice Questions with Answers

Question 1

Which option is the appropriate counterfactual in a business case?

A. The most expensive competing solution

B. The expected situation if the proposal is not undertaken

C. The supplier’s preferred implementation plan

D. The project team’s optimistic forecast

Correct Answer: B. The expected situation if the proposal is not undertaken

Question 2

An investment costs $400,000 and produces total benefits of $520,000 over the appraisal period. What is its simple ROI?

A. 20%

B. 25%

C. 30%

D. 130%

Correct Answer: C. 30%

Question 3

Which metric explicitly discounts future cash flows?

A. Simple payback

B. Simple ROI

C. TCO

D. NPV

Correct Answer: D. NPV

Question 4

An initiative costs $600,000 and produces equal annual net cash inflows of $200,000. What is the simple payback period?

A. 2 years

B. 3 years

C. 4 years

D. 8 years

Correct Answer: B. 3 years

Question 5

Which issue is primarily an operational-feasibility concern?

A. Whether an API can support required throughput

B. Whether patient data may legally be transferred

C. Whether users can adopt new processes and receive support

D. Whether the discount rate is appropriate

Correct Answer: C. Whether users can adopt new processes and receive support

Question 6

In a weighted-scoring model, what should normally be true of the criterion weights?

A. They should all be identical

B. They should sum to 1 or 100%

C. They should be based only on project cost

D. They should be hidden from evaluators

Correct Answer: B. They should sum to 1 or 100%

Question 7

Which situation best illustrates real-options reasoning?

A. Ignoring future cash flows after payback

B. Approving every project with a positive ROI

C. Funding a pilot before making an irreversible full investment

D. Excluding legal review until after implementation

Correct Answer: C. Funding a pilot before making an irreversible full investment

Question 8

Which statement about TCO is most accurate?

A. It measures only the purchase price

B. It measures only expected benefits

C. It estimates lifecycle costs, including operation and retirement

D. It is another name for NPV

Correct Answer: C. It estimates lifecycle costs, including operation and retirement

Question 9

Why can a technically feasible project still be infeasible overall?

A. Technical feasibility guarantees financial success

B. It may fail operational, legal, economic or schedule requirements

C. Technical feasibility is unrelated to implementation

D. All technically feasible projects must be rejected

Correct Answer: B. It may fail operational, legal, economic or schedule requirements

Question 10

What is the primary purpose of sensitivity analysis?

A. To conceal uncertainty in the business case

B. To determine how changes in assumptions affect results

C. To replace all qualitative judgement

D. To calculate only the purchase price

Correct Answer: B. To determine how changes in assumptions affect results