IT Investment: Build a Business Case Before Buying

What the investment includes

Information technology (IT) covers systems used to process, store, protect and exchange digital information. An investment may involve applications, infrastructure, integration, security and support. It also requires people to configure systems, maintain data and change the way work is done.

Digitizing a form is a specific change. Digital transformation is broader organizational change in how technology enables operations and value. Calling every software purchase a transformation obscures the decisions and responsibilities involved.

Describe the problem before the product

Record the current process, its owner and the observed failure. “We need AI” does not explain a business problem. “Customer orders are retyped between systems and require repeated correction” identifies work that can be investigated.

For that example, establish transaction volumes, time spent, correction frequency and downstream effects. Check whether the real cause is missing information or inconsistent rules. Automating an unclear process may reproduce its errors more quickly.

Compare credible alternatives

• Improve the current process without buying a new system.
• Configure unused functions in an existing product.
• Connect systems where duplicate entry creates the problem.
• Replace a system when its limitations justify the disruption.
• Run a limited experiment when benefits remain uncertain.

Include a do-minimum option to show what happens if the business delays. Compare alternatives on the same scope and planning period. A supplier demonstration is useful for understanding features, but evidence from your own representative tasks is stronger evidence of fit.

Separate cash savings, capacity and service benefits

Time saved can create capacity without reducing payroll expenditure. Do not record the full value of saved staff time as a cash saving unless the spending will actually change. Improved reliability or customer response can also matter, but state how these benefits will be observed.

Include implementation, data preparation, integration, subscriptions, training, support, security and exit costs. Record assumptions about adoption and transaction growth. Use a cautious scenario alongside the expected one. Avoid counting the same benefit under several headings.

Make security and continuity part of the case

The NIST Cybersecurity Framework 2.0 provides a useful reference for organizing cybersecurity risk discussions. For the proposed system, identify critical information, access roles, supplier dependencies, monitoring and recovery responsibilities. A cloud service does not automatically provide continuity for your business process.

Ask what happens during a service outage, incorrect update or compromised account. Determine how data is backed up, how restoration is tested and how the organization can leave the supplier. Relevant privacy and contractual requirements must be reviewed for the actual use case.

A financial example that tests the case

Simplified fictional example: Implementation and training cost AED 30,000, with annual operating costs of AED 12,000. If the system removes AED 24,000 of actual external expenditure each year, net annual savings are AED 12,000 and simple payback is 2.5 years. The 2.5-year estimate assumes net savings accrue evenly from the outset and costs remain stable. If cash flows occur only at each year-end, recovery first occurs at the end of year 3. The example excludes discounting, taxes and exit costs.

In a cautious scenario, gross savings fall to AED 15,000. Net savings become AED 3,000 and payback becomes 10 years. If planned useful life is shorter, this return alone does not justify the investment. Staff hours released by improvement remain additional capacity unless expenditure actually falls.

Now use an illustrative 3-year planning horizon. In the expected case, total net operating savings are AED 36,000; after the initial AED 30,000, the undiscounted balance is AED 6,000. In the cautious case, AED 9,000 of net savings leaves a negative AED 21,000 balance. These figures use the same exclusions as the example and assume no residual value. They are not accounting profit or net present value (NPV).

Payback shows how long cash recovery takes; it ignores cash flows after recovery and, in its simple form, the time value of money. For a material decision, finance should assess the full cash-flow schedule and an appropriate discount rate. If adoption delays benefits, place savings in the periods when they are expected rather than assuming a full year immediately. Test renewal increases, transition costs and end-of-life costs as well as lower benefits.

Define the cost boundary before comparing offers

Separate one-off payments, recurring costs and usage-dependent items. Ask what each offer includes and excludes. A low subscription price may leave substantial work for data preparation, migration or integration outside the estimate. Identify who would do that work and when they would have time.

Compare the same user numbers, transaction volumes and planning period. Show assumptions about contract renewal, capacity increases and support. An offer including training and migration is not equivalent to a licence-only quote. List unpriced items as gaps requiring investigation rather than entering a zero that implies no cost.

Keep an assumptions table with someone responsible for checking each item. If expected volume or the start date changes, update the calculation before deciding. This organises the comparison; it does not guarantee the project’s cost or return.

Assign an owner for benefits after implementation

Connect each benefit to a business owner, a dated baseline, a measurement method and a review date. The system owner can demonstrate that a function operates. The process owner needs to show what changed in the work. Also agree who records correction and support effort, so additional costs do not disappear outside the project report.

In a fictional example, a team aims to reduce retyping customer orders. It compares similar transactions before implementation and after usage has stabilised. The review records transaction numbers, errors and time, alongside changes in demand or staff experience. If manual work has moved to another team, include that effort rather than claiming a net saving.

Review results at a scheduled point suited to the operating cycle. If the benefit is missing, investigate adoption, data quality and the original assumption before buying extra features. The decision may be to revise the process, narrow the scope or stop expansion. Document the decision, evidence and next action owner. Launching a system should not end the review of its business case.

Define an acceptance gate before the pilot

Set the decision rules before testing: mandatory controls, acceptable performance, pilot spending limit and evidence needed for expansion. Keep technical acceptance separate from the later benefits review. Some benefits need a full operating cycle to measure; record that remaining uncertainty, its owner and review date instead of declaring the business case proven at installation.

Assign an owner to each test and resolve material defects before wider rollout. Review results against the original baseline, including additional work created elsewhere. Decide to expand, revise or stop; a completed installation is not the same as a successful investment.

Start with one costly or unreliable process and a short business case. ATMACSS’s business and operation modelling can help frame the operating requirement, while the technology solution needs appropriately qualified implementation support.