Understanding the Business Case

Before the Project Begins, the Business Must Know Why

An enterprise implementation can have an approved budget, a selected platform and a committed delivery date while still lacking a clear explanation of the value it is expected to create.

The proposal may describe modules. The project plan may describe activities. The presentation may promise efficiency.

None of these, by itself, establishes a business case.

A business case connects an operational problem with a proposed change, a credible investment and measurable outcomes. It explains why the organization should act, which alternatives it has considered and what must happen for the expected value to materialize.

Part I established the foundations, lifecycle and implementation strategy. Part II now examines how the transformation becomes a responsible delivery commitment.

The starting point is simple: what business result makes this implementation worth doing?

The answer must remain visible after approval, through discovery, design, go-live and continuous improvement.

4.1 What Is a Business Case?

A business case is a structured explanation of a proposed investment and the decision it requires.

It describes the current situation, the desired outcomes, feasible options, costs, benefits, risks, dependencies and ownership.

It should allow leadership to approve, defer, reshape or reject the proposal with an understanding of its consequences.

It is different from a project budget.

A budget establishes the resources available to deliver the work. A business case explains why committing those resources is justified.

It is also different from a Statement of Work. The Statement of Work defines delivery obligations and boundaries. The business case connects those commitments to the customer's operating objectives.

An implementation partner can help develop evidence and estimates. The customer must own the investment decision and the expected business outcomes.

A sound business case does not guarantee success. It creates a basis for testing whether the implementation remains worthwhile as the organization learns more.

4.2 Start with a Business Problem

“We need Dynamics 365” identifies a possible technology choice.

“We cannot produce a reliable project margin view without three days of manual reconciliation” identifies an operational problem.

The second statement allows investigation.

Which information is missing? Which teams perform the reconciliation? How often does it occur? What errors or decisions result from the delay? Which causes relate to process, data, responsibilities or technology?

These questions connect the business case to the four foundations introduced in Chapter 1: People, Process, Data and Technology.

Consider a company experiencing late customer billing. The apparent solution may be an automated invoice workflow.

Discovery may reveal that the main delay occurs earlier: project managers approve time late, commercial milestones are unclear and customer reference data is incomplete.

The business case should address the complete cause of the problem. Automating the final screen may leave the underlying delay unchanged.

Describe the affected population and the scale of the issue. Avoid presenting one unusual incident as though it represents every transaction.

A useful problem statement identifies what happens, where it happens, who is affected and why it matters.

4.3 Establish a Trustworthy Baseline

Improvement requires a starting point.

Before agreeing a target, define how the current performance will be measured and which data supports it.

For billing cycle time, specify the start and end events. “Month end to invoice approval” is different from “service delivery to customer receipt of invoice.”

For project setup, distinguish elapsed time from employee effort. A request may take five working days to complete while requiring only two hours of active processing.

Both measures can matter, but they answer different questions.

Use representative periods and explain exclusions, missing records and unusual operating conditions. A baseline drawn only from the easiest projects can distort the expected benefit.

Where reliable historical data is unavailable, perform a bounded measurement exercise and label the estimate's confidence. Do not turn an untested assumption into an apparently precise fact.

Record the baseline owner, source, calculation and validation date.

Keep the original approved baseline available even when later information improves it. Changes should be explained so that progress cannot be manufactured by quietly changing the comparison.

The purpose is a fair account of what improves and why.

4.4 Translate Problems into Measurable Outcomes

“Improve efficiency” provides direction but gives the delivery team little guidance.

A measurable outcome identifies the process, baseline, target, population, time horizon and accountable owner.

An illustrative outcome might be: “Reduce median project setup time from five working days to two within three months of stabilization for the in-scope project types, while retaining required approvals.”

The target is a hypothesis to validate, not a result already achieved.

Include a balancing measure where improvement could weaken another outcome. Faster approval is not valuable if it creates unauthorized commitments or increases correction work.

Different programs will require different measures.

A warehouse implementation might monitor order cycle time alongside picking accuracy. A Finance implementation might monitor close duration alongside unexplained reconciliation differences.

For each outcome, ask what process change will produce it and which solution capability enables that change.

Then identify the behavior required from the business.

A notification feature cannot shorten a cycle if nobody takes responsibility for responding. The business case needs an operating change as well as a technology deliverable.

4.5 Classify Benefits Before Adding Them Together

Benefits are not interchangeable.

Some release cash. Some create capacity. Some improve service or strengthen control. Some enable future growth but depend on further investment or market conditions.

Classifying the benefit helps leadership understand what the financial model includes and what it excludes.

Suppose an automated process releases 200 hours each month. That may allow employees to handle additional work or reduce a backlog. It does not automatically reduce payroll by 200 hours.

To claim a cash saving, identify the expenditure that will actually stop or be avoided, the decision that makes this possible and the date on which it changes.

Likewise, faster invoicing does not create new revenue simply because cash may arrive sooner.

Treat a one-time release of working capital separately from recurring profit improvement. Any financing benefit depends on the organization's circumstances and Finance-approved assumptions.

The business case should retain important non-cash outcomes without disguising them as cash.

4.6 Avoid Double Counting

A strong-looking return can disappear when the same benefit is counted more than once.

An automation may release employee time, reduce overtime and increase throughput. These effects can coexist, but the model must show how the released capacity is allocated.

The same hour cannot be used in full to reduce paid overtime and in full to produce additional chargeable work.

A reduction in billing errors may contribute to fewer credit notes and less rework. If the rework estimate already includes the effort spent processing those credit notes, adding both labor amounts exaggerates the saving.

Use a benefit register to make these relationships visible.

Each benefit should have a definition, owner, calculation, source, dependencies, realization date and overlap assessment.

When several workstreams contribute to one result, agree attribution rather than allowing each workstream to claim the entire improvement.

For revenue opportunities, separate additional revenue from contribution after the related delivery costs. Demand, sales conversion and delivery capacity must support the assumption.

Credibility is more useful than an impressive total that cannot survive scrutiny.

4.7 Compare Feasible Alternatives

A business case should not be written only to justify a platform decision already made.

Compare realistic responses to the problem.

These may include improving the existing process, repairing or extending current systems, implementing a focused capability, introducing a broader platform or deferring the investment while taking a limited risk-reduction action.

The current operating model provides a comparison baseline. Continuing as-is may still require maintenance, support and replacement expenditure.

Use a consistent scope, assessment period and treatment of costs across options. A small automation and a full enterprise replacement should not be compared as though they solve the same problems.

Explain which objectives each option addresses and which remain unresolved.

An organization with slow approvals may gain substantial value from simplifying responsibilities before replacing technology. Conversely, a local workflow improvement may be inadequate where incompatible data structures prevent enterprise reporting.

Assess operational feasibility alongside cost and benefit. The lowest estimate is not useful if the option cannot support a required business process.

Chapter 3's rollout strategy becomes relevant here: different deployment approaches can change when benefits begin and how much coexistence costs.

4.8 Understand the Total Cost of Ownership

The implementation partner's estimate is only part of the investment.

Include the resources needed to introduce, operate and sustain the solution over the assessment period.

One-time costs may include discovery, design, configuration, development, integrations, data cleansing, migration, testing, training, cutover and transition.

Internal business participation also has a cost. Subject-matter experts may require backfill or reduced operational commitments while they support the program.

Recurring costs may include subscriptions, support, platform consumption, administration, regression testing, maintenance of extensions and ongoing adoption activities.

Where the current and future systems overlap, include the cost of coexistence. A legacy application does not stop costing money on the day the new system is deployed if some users and historical processes still depend on it.

Distinguish incremental cash expenditure from internal effort valued for economic comparison. Both may be relevant, but combining them without explanation makes the return difficult to interpret.

Record the basis of each estimate and its uncertainty. Separate expected cost from contingency, and explain how contingency is governed.

Avoid presenting an early planning range with the certainty of an approved supplier commitment.

4.9 A Worked Business-Case Example

Consider an illustrative enterprise program evaluated over three operating years after an initial investment. All figures below are fictional, in ₹ lakh, and demonstrate the method rather than any product's expected return.

Assume ₹50 lakh is paid at the outset. Incremental operating costs are ₹10 lakh in each of the next three years.

Finance has reviewed cash-releasing benefits of ₹20 lakh, ₹30 lakh and ₹35 lakh respectively. The ramp reflects staged adoption and the timing of expenditure reductions. Separate capacity and service benefits are recorded but excluded from this cash calculation.

Across the three operating years, gross benefits total ₹85 lakh. The initial investment and recurring costs total ₹80 lakh. The undiscounted net benefit is therefore ₹5 lakh.

Using a simple three-year ROI defined here as (total benefits minus total costs) divided by total costs, the result is ₹5 lakh ÷ ₹80 lakh = 6.25%.

This is a cumulative three-year measure, not an annual return.

The initial investment has not been recovered by the end of Year 2: cumulative net cash flow remains negative ₹20 lakh. Year 3 generates ₹25 lakh of net benefit.

If Year 3 net benefits arrive evenly, simple payback occurs after 2 + 20 ÷ 25 = 2.8 operating years. Actual monthly timing could change that date.

This simplified model excludes discounting, tax effects and any value beyond Year 3. Those exclusions must be visible.

Where the organization's appraisal policy requires discounted cash flow, Finance should apply an appropriate approved discount rate to consistently defined dated cash flows. The simple ROI above is not net present value.

A positive return of this size still leaves a narrow margin for estimation error. Leadership needs to understand what could change it before approving the investment.

4.10 Test the Assumptions

A single forecast can conceal the conditions on which a business case depends.

Test the assumptions that materially affect the decision: adoption, transaction volume, benefit timing, recurring costs, implementation effort and legacy retirement.

Using the same illustrative model, suppose only 80% of the forecast gross cash benefits are achieved while all costs remain unchanged.

Benefits fall from ₹85 lakh to ₹68 lakh. Total costs remain ₹80 lakh. The three-year undiscounted net benefit becomes negative ₹12 lakh, and simple ROI becomes −15%.

Alternatively, if the initial investment increases by ₹10 lakh while the original benefits and recurring costs remain unchanged, total costs become ₹90 lakh and net benefit becomes negative ₹5 lakh.

These are separate sensitivity tests, not a combined forecast.

The analysis shows that modest adverse changes can overturn the base case. It does not prove that the program should be rejected.

Leadership may identify additional evidence, reshape the scope, phase the commitment or proceed for important non-financial reasons. The decision should acknowledge the financial exposure.

Do not label a scenario “conservative” merely because it feels cautious. Explain which assumptions change, why they are plausible and whether they are correlated.

Sensitivity analysis is valuable when it changes a decision or identifies an assumption that deserves early validation.

4.11 Give Every Benefit an Owner

The project manager can coordinate delivery. The project manager usually cannot independently change staffing decisions, approval behavior or business operating practices.

Benefit ownership must sit with a person who has authority over the relevant outcome.

For a faster billing cycle, the accountable owner might be a Finance or operations leader. Supporting actions may belong to project managers, commercial teams and data owners.

Document how those contributions work together.

A benefit record should contain the baseline, target, measure, accountable owner, supporting actions, dependencies, forecast realization date and review cadence.

Also identify who will produce and validate the measurement after go-live.

For example, “reduce manual invoice preparation effort” needs more than a configured feature. It may require standardized customer references, timely approvals, revised responsibilities and retirement of a spreadsheet.

If the business continues preparing invoices twice, the expected effort reduction may never appear.

Ownership becomes meaningful when the owner accepts the actions and resources needed to realize the result.

4.12 Connect Value to Scope and Prioritization

A business case should help resolve scope choices throughout the program.

Trace important capabilities to the outcomes they support. This does not require assigning a separate financial return to every field, control or technical component.

Some requirements are enabling dependencies. Others protect essential operations or satisfy mandatory obligations.

Suppose the expected billing improvement depends on valid project structures, accurate customer data and a reliable approval process.

A visually attractive dashboard may be useful, but deferring those foundational capabilities to preserve the dashboard's delivery date would weaken the investment logic.

Prioritize with the complete process in view.

When a new request appears, examine its contribution to outcomes, dependency impact, cost of ownership and effect on benefits timing.

Use Chapter 1's principle of standardizing wherever possible and differentiating where business value requires it.

A custom extension should carry the cost of development, testing, support and future change. Its value should be assessed against feasible process and configuration alternatives.

The business case guides judgment; it should not become a mechanism for dismissing requirements that are essential but difficult to monetize.

4.13 Approval Is a Decision with Conditions

Business-case approval should specify what has been authorized.

Is leadership approving discovery funding, the full implementation budget, a first release or the complete rollout?

These decisions can carry different levels of uncertainty.

A staged approval can fund the work needed to resolve important assumptions before a larger commitment. It should define the evidence required for the next decision.

Record the approved scope, funding basis, benefit assumptions, accountable owners, principal risks and review points.

Separate an approval condition from a general action item. If the investment depends on proving that two systems can coexist, the unresolved condition must remain visible before dependent commitments are made.

The implementation partner should provide realistic estimates and clarify delivery consequences. Business and Finance owners should validate the investment assumptions within their responsibilities.

The sponsor integrates the recommendation and secures the appropriate decision.

Approval does not turn a forecast into a fact. It authorizes action based on a documented understanding of the evidence and uncertainty.

4.14 Keep the Business Case Alive

The business case should travel through the lifecycle.

Discovery may identify a different cause of the problem. Solution Design may reveal an expensive dependency. Testing may expose an operational limitation. A revised rollout sequence may delay benefits or extend legacy costs.

Assess material changes against the investment case as well as the project plan.

Maintain the original approved view, the current forecast and an explanation of the movement between them. This allows leadership to distinguish changed assumptions from delivery performance.

Review the case at meaningful decision points, such as scope baseline, major change approval, wave authorization and benefits review.

If the remaining investment no longer supports a credible outcome, escalation is appropriate. Money already spent does not by itself justify further spending.

The decision may be to continue, redesign, reduce scope, defer or stop. Evaluate the future costs and benefits of those options, including the consequences of interruption.

Good governance keeps the business objective visible even when teams are under pressure to protect the original plan.

4.15 Measure Benefits After Go-Live

Go-live demonstrates a production transition. It does not demonstrate that the investment has earned its expected return.

Use Chapter 1's three levels of implementation success.

Technical Success establishes that the solution works. Operational Success establishes that people can run the business reliably. Business Transformation Success establishes measurable improvement against the intended outcomes.

Measure at intervals that match the relevant business cycles and adoption plan. Avoid judging a monthly process before a representative cycle has occurred.

Use consistent definitions and explain changes in volume, staffing, process scope or business conditions. A reduction in processing time caused by lower transaction volume should not automatically be credited to the system.

Compare actual performance with the forecast and investigate gaps.

A benefit may be delayed because a capability is incomplete, users have not adopted it, a process owner has not changed a responsibility or the original assumption was wrong.

Each cause requires a different response.

Assign improvement actions and update the forecast transparently. The benefits register should remain owned after project closure, with a clear place in normal management reporting.

4.16 The Delivery Leader's View

A delivery leader should understand both the delivery commitment and the reason it exists.

Ask which outcomes are most important, which assumptions are weakest and which business actions lie outside the partner's direct control.

Make the effect of scope and schedule decisions understandable.

If a release is delayed, explain which benefits move with it. If training is reduced, explain the adoption assumption now at risk. If a customization is added, include its ongoing support burden.

Avoid allowing the business case to become an optimistic sales artifact or a document used only when funding is requested.

It is a shared reference for responsible decisions.

The customer owns the business outcome. The implementation partner helps create a sustainable capability. Both need a common understanding of the change required to turn that capability into value.