How to Value Digital Transformation Projects

The best way to get a green light for a digital transformation project is to demonstrate that your numbers stack up.

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.

This guide will equip you with actionable steps that you can start using today.

But what if you don't want to go it alone?

We've got you covered.

Join our SME Growth Cohort where you can bring your questions to weekly, live Q&As and hear from peers who are also determined to unlock tech based growth at their businesses.

Graham’s SME Growth Cohort has been packed full of useful takeaways, relevant to any forward-thinking business owner. As the founder of a new tech startup, it was great to be able to ask direct questions and learn from the experience of not just Graham, but the other members of the cohort too. From introductions, to tech knowledge and strategy, these sessions are an absolute must for any SME business owner that is keen to learn how to do things better than they already are. Would definitely recommend!

-- Tom Dalton, Stealth Startup

Reserve Your Cohort Space (Limited Availability)

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:

CFO (Cash flow from operations)
Capex (Capital expenditure)
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:

Write down who you are undertaking the project for. Who's problems are you solving? Who will feel the value you are creating?
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?
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
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.
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
Review your requirements with all stakeholders - you will have missed details. Add new requirements to your list
Carefully think through the end to end processes you will deliver. What is missing? Add them to your list.
Repeat steps 6 & 7 until the requirements list stops growing
Review every requirement in your list with relevant stakeholders and delete the ones that aren't important - I guarantee you'll find some
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.

Join our newsletter for more playbooks, frameworks, deep dives and peer experiences.

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

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

Execute a thorough requirements gathering exercise
Embrace uncertainty and factor it into your estimations
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 contact us and we'll be delighted to send you a link.

If you like what you've read but would like some support, then our SME Growth Cohort is ideal.

It is a group of highly motivated small and medium sized business owners/execs seeking growth acceleration strategies through modern technology adoption.

We meet virtually once a week for a live Q&A and discussion around trending topics such as transformation, value creation, AI adoption and automation.

You can ask your own questions or just listen in to soak up ideas and experiences.