The art of writing a clear business case for ICT procurement

An ICT procurement decision can shape an organisation’s operating model for years. It may affect customer service, employee productivity, data protection, reporting, compliance, and the cost of future change. Yet many proposals still focus on product features before explaining the business problem that justifies the investment.

A strong business case creates a logical bridge between a current weakness and a practical procurement decision. It shows what is happening now, what improvement is required, which options were considered, and how the organisation will control cost and risk.

The best documents are written for decision-makers who may not share the project team’s technical background. They use plain language, credible evidence, transparent assumptions, and a clear recommendation. Technical detail remains important, but it supports the decision instead of obscuring it.

Why ICT procurement cases often fail

A business case becomes difficult to approve when it reads like a vendor brochure. Long lists of specifications, certifications, and platform capabilities do not explain why the organisation should spend money now. Decision-makers need to see the connection between technology and measurable business outcomes.

Another common weakness is an incomplete view of cost. Teams may include licences and implementation fees while overlooking migration, integration, training, support, security testing, data cleansing, internal staff time, and contract management. These omissions create unrealistic budgets and weaken confidence in the proposal.

Unclear ownership can cause similar problems. An ICT project may involve finance, procurement, legal, cybersecurity, operations, records management, and senior leadership. If the case does not identify who owns the problem, who approves the funding, and who will manage benefits after implementation, approval may lead to an unfocused project.

A clear case should answer five basic questions early:

• What problem requires action?
• Why is action needed now?
• What options were assessed?
• What will the preferred option cost and deliver?
• How will the organisation measure success?

Begin with the service problem

The starting point should be a business or public-service problem, rather than a desired technology. “The department needs a new cloud platform” is a solution statement. “Case officers spend three days reconciling records across disconnected systems” describes a problem that can be investigated and measured.

Describe the current state with evidence. Useful material may include processing times, error rates, service complaints, audit findings, security incidents, system downtime, staff surveys, transaction volumes, or the cost of manual work. A short baseline gives readers something against which to judge the proposed improvement.

It is also helpful to define the affected users. They may include citizens, internal teams, suppliers, managers, regulators, or partner institutions. Explain how the current arrangement affects each group and distinguish symptoms from root causes. Slow service may result from poor workflow design, duplicate data entry, weak integration, insufficient training, or outdated infrastructure.

Urgency should be specific rather than dramatic. A contract may be expiring, a system may be approaching end of support, a regulatory deadline may be approaching, or transaction volumes may be exceeding capacity. If there is no immediate deadline, explain the cost of delay and the consequences of maintaining the current state.

Establish scope, outcomes, and governance

A procurement case should define what the investment will cover and what it will leave outside the project. Scope may include software, hardware, hosting, implementation services, data migration, integration, user support, training, and ongoing operations. It should also state whether the project involves redesigning processes or simply replacing an existing tool.

Outcomes describe the change that matters. Examples include reducing application processing time from ten days to five, improving system availability to a defined service level, eliminating duplicate data entry, or giving managers reliable performance information. Outputs such as “configure a portal” are necessary, but they do not prove that the organisation has achieved value.

Strong outcomes have owners and timeframes. A service director may own processing efficiency, the chief information security officer may own risk reduction, and a finance leader may own savings validation. Benefits should be tracked after deployment because a system can be delivered on schedule without producing the expected operational improvement.

Governance should be visible in the case. Identify the sponsoring executive, project board, procurement route, technical authority, information owner, security reviewer, and operational owner. Where public-sector transformation is involved, align the proposal with enterprise architecture, digital-service standards, records obligations, accessibility expectations, and relevant cybersecurity controls.

For practical questions about the website or its reference material, readers can use the contact information provided by E-Pragati. The site is an independent information resource, not an official government department, so formal procurement decisions must still rely on authorised organisational policies and regulations.

Compare realistic procurement options

A credible options appraisal should include more than a preferred supplier. At minimum, assess the current state, a minimum-change option, a managed service or commercial solution, and a custom-build or broader transformation option where appropriate. The right set depends on the problem, market conditions, internal capability, and strategic direction.

The current-state option is important because it establishes the cost and risk of doing nothing. “Do nothing” rarely means zero cost. It may involve recurring workarounds, support for obsolete systems, growing cyber exposure, declining service quality, or missed opportunities for automation.

Each option should be assessed against consistent criteria. These may include strategic fit, functional suitability, total cost of ownership, implementation time, scalability, interoperability, information security, privacy, accessibility, supplier viability, internal capability, and exit complexity. Weighting the criteria makes the evaluation more transparent, although the rationale for each weight should be recorded.

Assessment area	Questions to address	Evidence to include
Business fit	Does the option solve the defined problem?	Process maps, user needs, outcome measures
Financial value	What will it cost over the full lifecycle?	Five-year cost model, assumptions, sensitivity analysis
Technical fit	Can it integrate and scale safely?	Architecture review, interface requirements, capacity estimates
Delivery feasibility	Can the organisation implement and operate it?	Resource plan, dependencies, delivery schedule
Risk and compliance	Can legal, security, privacy, and continuity needs be met?	Risk assessment, control requirements, assurance plan
Supplier position	Is the provider reliable and commercially sustainable?	Market research, references, financial checks
Exit and resilience	Can the organisation change supplier or recover from failure?	Exit plan, data portability terms, continuity arrangements

Market engagement can improve the business case before a formal tender. A request for information, supplier briefing, or early market consultation may reveal available commercial models, integration constraints, implementation lead times, and likely pricing. It should be conducted fairly and documented so that the eventual procurement remains transparent.

Make the financial case testable

A financial model should separate one-time costs from recurring costs. One-time items may include discovery, configuration, custom development, migration, testing, training, and transition. Recurring expenses may include subscriptions, hosting, support, security monitoring, upgrades, connectivity, licences, and internal administration.

Calculate total cost of ownership across a period that matches the investment. Three to five years is common, though a longer period may be appropriate for major infrastructure. Include assumptions about inflation, user growth, currency exposure, contract escalation, asset replacement, and the likely cost of extending the existing arrangement.

Benefits also require discipline. Cashable savings, avoided costs, productivity gains, revenue improvements, service-quality gains, and risk reduction should be presented separately. A reduction in staff effort does not automatically create a budget saving if employees will be reassigned to higher-value work. State who will receive each benefit and how it will be measured.

Use sensitivity analysis for uncertain assumptions. Show what happens if implementation takes longer, adoption is lower, transaction volumes increase, or supplier charges rise. A range is often more credible than a single precise figure. For example, the case could present a base estimate alongside cautious and optimistic scenarios.

Budget planning is relevant beyond formal procurement. Even a personal planning guide, such as a budget weekend trip, depends on separating essential costs, optional spending, assumptions, and contingencies. ICT cases require the same habit at a much larger scale, with documented evidence and financial controls.

Treat risk as a management plan

A risk register should explain what could happen, why it matters, how likely it is, and what action will reduce the exposure. Generic statements such as “there may be implementation risks” are weak. Specific risks might include incomplete data migration, insecure interfaces, vendor lock-in, resistance to new processes, inadequate accessibility, or an unstable supply chain.

Assign an owner to each material risk and identify a trigger that shows when escalation is required. A risk without an owner is an observation rather than a management instrument. Residual risk should be stated after proposed controls, along with the level of risk the organisation is prepared to accept.

ICT procurement also needs commercial risk analysis. Consider service credits, liability limits, intellectual property, data location, subcontracting, audit rights, termination assistance, business continuity, change control, and price increases. Contract terms should reflect the service’s criticality. A minor administrative tool does not need the same resilience obligations as a platform supporting essential public services.

Security and privacy should be built into requirements before supplier selection. Define identity and access controls, encryption, logging, vulnerability management, incident notification, retention, backup, recovery objectives, and independent assurance. Procurement teams should involve security specialists early instead of treating assurance as a final approval gate.

Write for a decision, not a filing cabinet

A decision-ready business case has a concise executive summary that can stand alone. It should state the problem, recommended option, required funding, expected outcomes, major risks, procurement approach, and decision requested. Senior readers should not have to search through technical annexes to discover what approval is being sought.

The main document can then present the evidence in a logical sequence: current state, strategic alignment, options, financial analysis, risks, delivery approach, governance, and benefits realisation. Appendices can contain architecture diagrams, detailed requirements, assumptions, market research, security controls, and evaluation methodology.

Use consistent terminology throughout. If “availability,” “response time,” “implementation,” or “benefit” has a defined meaning, keep that meaning stable. Avoid unexplained acronyms and distinguish confirmed facts from estimates. A short glossary can help when the proposal includes specialist concepts.

Before submission, ask independent reviewers to challenge the case. Finance can test the cost model, procurement can examine the route to market, security can review controls, operations can assess feasibility, and service owners can verify outcomes. Reviewers should be encouraged to identify unsupported claims rather than simply proofread the document.

Practical checks for a stronger case

The following actions can make an ICT procurement proposal clearer, more defensible, and easier to govern:

• Write the problem statement before discussing products, suppliers, or preferred technologies.
• Build a lifecycle cost model that includes implementation, operation, renewal, and exit.
• Compare several realistic options using published criteria and documented assumptions.
• Assign owners to outcomes, risks, benefits, and post-implementation measurement.
• Separate mandatory requirements from desirable features so the procurement remains focused.

A final quality check should confirm that the requested decision is explicit. State the amount or approval sought, the proposed procurement route, the next milestone, and the consequences of delay. If a staged approval is more appropriate, explain what evidence will be required before each later commitment.

A well-written business case does not guarantee that a procurement will succeed. It does something more valuable at the decision stage: it makes the reasoning visible. That visibility helps leaders challenge assumptions, compare alternatives, allocate resources, and establish accountability before public or organisational funds are committed.

Use this structure as a working document, validate it with finance, procurement, security, legal, and service owners, and keep the evidence current until approval. A clear case turns ICT procurement from a request for technology into a managed investment in better services, stronger controls, and measurable organisational performance.