The business case, a key success factor for transformation programs

CIO Advisory

Preparing a business case will give you a better overall assessment of the transformation

Too many costly transformation programs or technology projects are still being undertaken without a concise, quantitative, and objective means of evaluating the economic benefits compared with the costs and risks of their implementation.

Digitalization programs and other technology-intensive initiatives require significant investments in hardware, software, services of all kinds, and in-house manpower, which must be allocated consistently with the expected benefits. Moreover, such an evaluation exercise must be carried out over the entire life cycle of the tools, applications, processes, and other resources implemented. Finally, the risk factor, the probability-based concept that dominates this type of initiative, must be carefully integrated into such an analysis.

Business cases can provide this type of global, quantitative, and impartial evaluation. This exercise, often distorted into to a pseudo-analysis of ROI, can be used to weigh the interests of each of the project’s goals and to precisely arbitrate between the various possible options.

Although the business case is best known for its role in evaluating a vision and promoting it in order to justify the allocation of resources, this essential tool is becoming a key ally in the implementation of initiatives. The business case now has a triple purpose in transformation programs:

  • To evaluate the scenarios and strategic options to be implemented (project or program planning and validation)
  • To steer the program in function of the desired results, throughout its implementation
  • To verify, post-project, the implementation of the expected value creation (i.e., business case benefits harvesting)

Any initiative that aims to improve the quality of a service must deliver a contribution to profit that can be measured in accounting terms. It is therefore necessary to manage each step of the project and each action required, primarily by the expected benefits. These benefits are not merely identified by an isolated quantitative evaluation, they must also be reconcilable with the operating statement and must be objectively validated.

Although having a quantitative economic model such as a business case is a matter of course for any decision-maker, two pitfalls generally hinder the success of their implementation:

Estimating benefits is difficult because many benefits initially appear intangible and therefore the economic function that governs them appears unquantifiable.

Costs, which are often based on a pioneering approach (few similar experiences), are very difficult to establish. And even if they can be estimated, they are subject to a considerable margin of error.

Two abundantly refutable assertions…

First, the estimation of expected benefits. Even when these appear to be non-market in nature, they can always be converted into an economic function. Largely inspired by the foundations of the monetarist doctrine of the 1980s, the consumption of a resource is merely an intermediate economic act aimed at creating final satisfaction. It is this final satisfaction that is modelled by the “benefit” function in economics. A curious exercise at first sight, but with a little practice, easily accessible.

On the other hand, the project’s costs are generally obtained by a call for tenders, a quotation for the various services that form the project. This is a passive approach, which involves transferring the calculation effort to external service providers. However, when these service providers are required to compete for the tender, they bid for their part in the project by offering a minimal service, which then tends to increase and multiply via a stream of amendments proposed on the pretext of incomplete specifications.

The abacus method of cost evaluation...

The abacus principle is a radically different option that can be illustrated by the following comparison: a purchaser wishing to build his or her own house in a given area can use two different methods to evaluate the cost. The first involves acquiring a plot of land and then establishing estimates for each of the services: structural work, carpentry, roofing, plastering, tiling, electricity, etc. This method will most likely lead to the cost slippages mentioned above. A second option is to obtain the actual construction costs of the neighboring houses with their synthetic dimensional values: surface area, number of rooms, land area, number of floors, architectural complexity factor, etc. This is the principle of statistical comparison.

Data relating to similar projects, or projects where certain factors are similar to the project to be implemented, becomes an essential tool for sizing the solution’s investment and operating budgets. These are abacuses, made up of several input parameters: directly quantitative values (number of users, number of sites, number of processes, etc.) and qualitative values, which allow us to integrate the notion of complexity (resistance to change, market maturity, etc.). Most large service providers (IT service companies, integrators, telecom operators, etc.) now use this type of evaluation tool, and charge a risk premium, which can be substantial, to their clients who do not have the equivalent counter-expertise tool.

Costing pioneering initiatives: the use of formal analogy

When the sector of activity or the type of project is truly pioneering, with no previously known equivalent, it is difficult to rely on a sufficient and representative statistical basis to establish the figures.

We therefore draw on the functional analogy principle: data is drawn from sectors with an, at least partially, overlapping approach. For example, a project to rationalize television frames at the end of the 1990s was tackled by drawing inspiration from the principles of software-based delayed differentiation as applied to automotive production lines in the late 1980s. Using a functional analogy during the scoping study also allows us to propose options that have already been partially tested in other sectors of the industry.

The business case, arbiter of implementation agility

Implementing a project is a significant process that takes place over several months and that is performed in conjunction with the company’s normal business activities, which it aims to disrupt as little as possible. No planning can infallibly predetermine the events and actions to be prioritized day after day. While an overall plan is essential in order to organize the implementation phases and key activities, the day-to-day organization of tasks must be coordinated in a flexible and agile manner in function of business priorities and other external contingencies.

The neutral and efficient arbitration of such agility is based on formal technical and economic criteria. The business case acts as a compass or safeguard to guide daily priorities. The principles of SCRUM-type agile project management, until now exclusively applied to software development, can be generalized to business transformation processes provided that a decision-making body is available to steer the project throughout its implementation by focusing on the expected results on a daily basis.

Verifying the success of the initiative: benefit harvesting

Last but not least, the final contribution of a business case program is verifying the successful completion of the initiative. In other words, to verify that the resources allocated have been used effectively, that they have returned more than they cost.

How can this “harvest” of expected gains be formally organized? We need to measure the level of performance delivered over the course of quarters or years for each of the targeted benefits. This implies that the initial performance was measured when the business case was established, i.e., measuring the initial situation. Some gains are immediate, accessible from the beginning of the transformation (quick win, billing of discontinued services, etc.), others are more progressive. In addition, the indicators used for this measurement will also be corrected for any variation in external influences (market trends, variations in the price of materials or in sales, etc.).

The analysis of the results must remain a simple, concise, but pragmatic exercise in order to enable a genuine economic evaluation. The multiplication of initiatives, the experience acquired, and the lessons learned from each initiative allow for the rapid and logical development of this type of tool and the appropriate monitoring of results.