How to Value Digital Transformation Projects

Returns matter a lot. It's our capital. Abigail Johnson, CEO of Fidelity Investments

It's an exciting moment when you spot an opportunity to deploy people, processes and technology in a novel way to create value for your business. But having identified an opportunity to improve your business with some form of digital transformation, how do you secure agreement from your peers, your superiors, the C-suite and the board to initiate that transformation?

As with most things in business, you need to demonstrate that the project creates value. That value might be delivered in the form of revenue creation, for example increasing the lifetime value of a customer, or it might come from reducing costs, for example automating manual processes. But regardless, the project will be one of several investment opportunities available to your company. Since investment prioritisation relies heavily on comparing value and expected returns, if you can't estimate the amount of value the project can create it might get put on ice causing the company to miss out on a great opportunity.

Since numbers facilitate comparison, measurement, management and many more things, to get buy-in for your project, you need to nail the numbers.

A large part of a CEO's role is strategic capital allocation. They are tasked with allocating capital to the right investments in order to maximise growth potential. A CFO supports this process and will ensure those capital allocation decisions are compatible with the financial policy agreed with the board.

Therefore, don't reinvent the wheel when modelling the numbers for your transformation. Model the numbers in a way that is consistent with commercial finance analysis. Use established practices to model what the project will cost, what it will return and when those cash inflows and cash outflows will occur.

Measuring the Value of a Transformation

There are many commercial finance metrics that could be used to assess the merits of an investment opportunity.

NPV (Net Present Value)

NPV considers the time value of money and therefore discounts future value by the company's cost of capital.

If your interested in how financial markets can impact a company's cost of capital, take a look at our article titled How Are Technology Investment Decisions Impacted By Bonds Yields, Interest Rates and Exchange Rates

Payback

Payback measures how long it takes to recover an initial investment. This measure is simple to use but ignores both the time value of money as well as any value created beyond the payback period

IRR (Internal Rate of Return)

IRR is very similar to NPV. Whereas NPV solves for present day value, IRR solves for comparison with a company's cost of capital.

FCF (Free Cash Flow)

Each of the previous metrics can be helpful in terms of comparing the value of an investment with other investment opportunities, but what they don't consider is how that value can be measured. Defining that "how" is vital. It is what gives your proposal credibility and demonstrates that you have done more than simply pluck aspirational numbers out of the air.

FCF is a metric that helps us measure the value of our project in a way that is comparable with other capital allocation opportunities open to your CEO, CFO and board of directors. Your project might be competing with other tech initiatives, construction of a new warehouse, M&A opportunities or even paying a dividend to shareholders. Your project has to seem to like a better prospect than those alternatives in order to get funded.

Our goal is to estimate and value the future cash flows that our project will produce. To do this we require the following three inputs:

1. CFO (Cash flow from operations)
2. Capex (Capital expenditure)
3. CNCWC (Change in non-cash working capital)

Once we have the free cash flow for each period, we can insert those cash flows into either the NPV or IRR formulas to get a robust view of the relative strength of our digital transformation initiative.

But how do we go from thinking about digital transformation, technology, software, people, processes etc, to financial terms like FCF and working capital?

First we need to understand the construction of FCF:

FCF = CFO - Capex + CNCWC

1. CFO

CFO, or cash flow from operations, will be the amount of cash generated by the project through operations such as generating revenue and paying expenses. We will make a reasonable simplification in our calculations by only considering cash inflows and outflows that are relevant to our project. We don't need to worry about cash flows across the whole business.

2. Capex

Capex, or capital expenditure, is the amount we expect to invest in our transformation project to bring it to completion.

On large IT projects there will be a lot of uncertainty at the outset because you will have an immature set of requirements and you are probably yet to decide on a tech stack, team and architectural design patterns.

Nonetheless, you need to have a good idea of the requirements to be delivered and you need an estimate for the cost of delivering them.

You may have heard that big design up front is dead, that estimation is a waste of time and that due to the cone of uncertainty now is a bad time to make estimates. In the proper context it is quite plausible that all of these statements are true. However, you must avoid falling into the trap of thinking this means you should avoid preparing estimates and planning your project.

By failing to prepare, you are preparing to fail. Benjamin Franklin, Founding Father of the United States

There is a massive difference between detailed technical design and requirements gathering. There is a massive difference between micro level task estimation and applying relative scale estimations to components at the macro level. There is a massive difference between organising tasks in project delivery mode versus milestone scheduling in project governance mode.

Estimating effort for a transformation project is difficult, time consuming, uncertain, filled with assumptions and dependent on input from numerous stakeholders. The most crucial step is requirements gathering followed closely by requirements refining. If you build the wrong thing you can be worse off than before you started. If you build more than is necessary you are wasting time, money and agility as you build excess complexity.

You can start to build out your requirements using this process:

1. Write down who you are undertaking the project for. Who's problems are you solving? Who will feel the value you are creating?

2. Next write down why you are undertaking the project. Are you generating revenue? Are customers complaining about the status quo? Are team members demoralised by painful processes?

3. Describe what business value you will create by delivering the project and what business problems will emerge and grow if you do not deliver the project

4. Create a list of some of the complexities and risks you think you might face. This could be based on knowledge of established business processes, peaks and troughs in terms of demand, experience of an IT landscape that is creaking at the seams etc.

5. Now start writing your requirements keeping those first 4 points in mind. Be granular. Lots of small requirements are better than a few big ones

6. Review your requirements with all stakeholders - you will have missed details. Add new requirements to your list

7. Carefully think through the end to end processes you will deliver. What is missing? Add them to your list.

8. Repeat steps 6 & 7 until the requirements list stops growing

9. Review every requirement in your list with relevant stakeholders and delete the ones that aren't important - I guarantee you'll find some

10. Review your requirements with the implementation team - they will spot some gaps, add them to your requirements list as well.

By now the list should be taking shape, a few more iterations and you'll have something to move forward with.

Once you have a set of requirements the next task is to convert it into time and money. It goes without saying that the better the job of requirements gathering, the better your estimates will be. But of course, they are still uncertain. We are trying to build a reasonable range for our project to fall within, accepting that our requirements will have gaps and our estimates will have errors. Uncertainty is the nature of the best at this stage. We don't have to like it but we do have to accept it and we must deal with it.

One approach is to:

• Classify each requirement by relative size that represents implementation effort. The smallest unit of effort I use is 1 day and then I increment as follows: 7.5 days, 20 days, 40 days.

• Apply an uncertainty factor. The larger the unit of effort estimate, the more uncertainty there is likely to be so include greater scope for variance in your estimate.

• Derive estimates for other aspects of project delivery such as project management, design, testing etc using a percentage of overall estimated effort.

• Consider different delivery methods such as offshore, nearshore and local developers to get a range of price points from the market

Here is an example Digital Transformation Project Estimation Template Google Sheet.

3. CNCWC

CNCWC, or change in non-cash working capital, might sound very far removed from your world of technology, but in fact, it shouldn't be.

For starters though, non-cash working capital is:

NCWC = CURRENT ASSETS WITHOUT CASH - CURRENT LIABILITIES

Under current assets without cash we expect to see items that can be quickly converted to cash to pay for day to day expenses, such as:

• Accounts receivable - the amount of money we are waiting to receive from customers
• Inventory - goods or products sat in the warehouse, which for most DX projects will be irrelevant

Under current liabilities we expect so see expenses that the company must pay within the next 12 months, such as:

• Short term debt
• Accounts payable - amounts owed to suppliers

The change in non-cash working capital is simply the difference between NCWC in one month compared to the previous month.

This accounting concept can be vitally important for a digital transformation project because the choices you make that impact working capital requirements can be the difference between success and failure.

If your customers pay for your service instantly and all associated costs are paid instantly, then you have zero working capital required to operate your service. If your customer pays quarterly but your suppliers are paid monthly then you need sufficient working capital to pay your suppliers while you are waiting for your customer payments to hit the bank. You need to find that cash from somewhere. However, if your customers pay instantly but suppliers are paid on 30 day terms, then you have negative working capital required, in other words you get to keep extra cash in your bank, even though you will ultimately have to use it to pay your suppliers.

Consider the potential difference in working capital requirements between buying, building and configuring bare metal servers to run your operation in advance versus provisioning on-demand, elastic resources in the cloud and paying in arrears.

As the working capital requirements of your project increase, the money that is generated that is free from business obligations decreases. Conversely, if you can improve payment terms and reduce your working capital requirements then the money that is generated from your project that is free from business obligations increases. Engineering your working capital requirements could turn an unattractive investment opportunity into a golden opportunity by transforming the free cash flow that it generates.

Looking at this from an alternate perspective, if your customers pay you quickly, but your suppliers offer you long payment terms, your early customers can fund subsequent iterations of the product that allow you to expand your target audience.

Worked Example

Let's assume that your transformation project will create an on-demand service for your clients. You will sell access on a subscription basis, like a typical SaaS (software as a service) product. Your customer will make their first subscription payment to you on day 0, the moment they start their subscription for your service, and monthly thereafter.

To provide your service to this client you will incur various costs, for example:

• Customer acquisition costs
• A client specific database instance
• Compute resource
• Object storage

It is reasonable to assume that cloud suppliers will bill you for those resources and services at the end of each month, probably on 30 day terms, giving a clear 60 days to keep customers' cash before having to pay suppliers.

Since we will receive customer payments before paying our suppliers let's assume our working capital requirements are -20% of revenue, yes negative 20%. For every £1000 in revenue that we generate, we keep £200 cash in our bank for 60 days, that is ultimately due to suppliers.

Assumptions

1. Our requirements gathering and subsequent estimation indicates that we will need to make a £100,000 capital investment
2. The delivered solution has an expected lifetime of 5 years
3. The SaaS product will acquire 120 new customers each year
4. Customers will be charged £100/month
5. Cost of sale due to shared resources is estiamted at £50,000
6. Incremental cost of sale for each customer is £500/year
7. £50,000 of SG&A expenses are incurred every year
8. Corporation tax is 25%
9. NCWC is assumed to be -20% of revenue
10. Cost of capital is 7%

The NPV of the project's free cash flows is just over £471,124.19.

Is that good? Maybe.

It sounds like a decent return on £100,000, but how do we know?

If it is higher than the NPV of other projects, then it is stronger than alternative opportunities.

If it is higher than the target IRR, then it has enough value creation potential to be of interest to the company.

On the face of it, this looks like a project that should go ahead.

But look what happens if our customer and supplier payment terms deteriorate such that we must operate with non-cash working capital of +20% rather than -20%, but all other parameters, such as the profitability of the service remain the same.

Even though the profitability remains the same, the impact on cash flow has cut the NPV and IRR in half, and that could kill the project.

Conclusion

An effective way to value your digital transformation is to:

1. Execute a thorough requirements gathering exercise
2. Embrace uncertainty and factor it into your estimations
3. Model your project using established financial metrics like free cash flow

That will allow your project to be compared with alternative opportunities. If it is a high value project the numbers should do the talking and the green light will be yours.

What Next?

If you'd like to download and adapt the resources linked in this article just drop us an email and we'll be delighted to send you a link. If you need help, feel free to get in touch today for a no strings chat or read more about our Digital Transformation Consulting.