In my first Azure for Business article, I tackled the power of Azure Data & analytics as a conduit for driving business value and capabilities. In this part of the series, I’ll discuss the importance of understanding the theory of cost of delay and how it applies to creating a successful cloud strategy framework (CSF) and migrating to the cloud. Understanding this metric and using it as a critical consideration in decision-making is essential to creating a compelling and impactful CSF for your organization both from a technical and business perspective.

What is a cloud strategy framework?

Simply put, a cloud strategy framework (CSF) is the ‘True-North’ or ‘Guiding Star’ for an organization’s game plan in the cloud. From start to finish, it encompasses everything needed to drive meaningful and lasting organizational change as your business matures in the cloud from a people, process (business), and technology standpoint. Only when the three core areas of consideration can come together and are understood for the mechanical interactions, they create can the CSF’s actual value be realized.

Quisitive defines four buckets or phases in a successful cloud strategy framework: Plan, Move, Operate, Innovate, which I will cover in-depth in my next article in the series. Before jumping into your CSF, even the Plan phase once your organization is committed, it’s essential to understand the theory of the cost of delay and how it applies to the initial migration to the cloud and each subsequent step that follows.

What is the best part about learning how to use the cost of delay? You can apply this theory to almost anything financial to help make better data-driven decisions.

What is the cost of delay?

Creator Don Reinertsen describes the cost of delay as a “way of communicating the impact of time on the outcomes we hope to achieve.” It is the partial derivative of total expected value (tEV) with respect to time. This metric creates a formalized understanding that shows how time will erode the total available value for capture as it progresses. By correctly calculating the cost of delay, organizations can better plan to capture as much value as possible from their projects, evaluate the opportunity costs, and make better decisions along the way. Traditionally, this calculation method has been used extensively in lean and agile product development, but it is highly applicable to cloud migrations as well.

“If you only quantify one thing, quantify the Cost of Delay. – Don Reinertsen.

In a 2011 interview, Reinertsen estimated 85% of project managers do not know about the cost of delay or how to apply it to their projects. Even as a project manager myself, I find value in using this outside of the workplace. Once you learn it and truly understand how powerful this formula can be in reducing variability and maximizing value yield, the results are life-changing.

One of the potential pitfalls of the cost of delay calculation is that it is often oversimplified. Complexities in real life that are hard to quantify on paper can skew or invalidate critical assumptions used to determine the cost of delay. However, the theory is resilient enough to deal with some, if not all, so long as the team is prepared and ready to adapt to a shifting landscape.

If there’s one thing I’ve learned from working as a project manager and Professional Scrum Master in IT—no project will go as planned strictly. Blockers, complexities, delays, scope-creep, and variables we can’t control will surface throughout the duration of our projects. How we work as a team to overcome these obstacles determines the success of the project.

Traditionally, when the cost of delay is used in product development, a product will generate a total lifetime profit during its useful lifecycle. In IT, when considering the cost of delay, the lifetime profit is expressed in terms of the reduction in cost from the previous norm, and the sum of tangible and intangible value (where value = benefits – costs) all expressed in $ dollars gained through migrating the on-premises data estate to the cloud. Call the output of this formula the Net Lifetime Value.

The reduction in cost from the previous norm can be a negative figure if the cost of operating in the cloud is more than running a physical estate. The extra benefits and capabilities from moving to the cloud will likely result in a net-positive capture of value for the organization.

Intangible value is expressed in things such as having the ability to quickly scale and right-size resources without the need to own physical hardware. Agility in enhanced resource-management is one of the most compelling business cases for cloud migration.

As it would be with any project like this where the end goal is to generate a compelling return on investment, the work’s resulting value will be generated over time, not all upfront in a lump sum.

Net lifetime value will always be a function of when the new platform (in its core, most basic form) becomes available. This availability should establish all of the essential features that match or exceed the previous norm as a minimum to be considered ‘done.’

Many factors will go into the reduction of cost from the previous norm and the sum of tangible and intangible value from the migration. There are dozens if not hundreds of questions that business and IT leaders will need to tackle when fully understanding and creating a *realistic* roadmap to highlight the planned return on investment. Answering as many questions upfront as possible will eliminate some but certainly not all of the complexities that may arise while trying to understand the cost of delay related to cloud migration. Useful questions include:

• Do you have legacy hardware/software that is out of support from Microsoft? And does that generate additional extended support costs to keep your legacy workloads on life support?
• Will it be possible to sell or fully amortize the depreciated physical estate to recover some of the cost on the books?
• What is the dollar value of gaining new capabilities within the cloud for both the IT team and the business itself? What will it cost to generate those capabilities?
• What types of service interruptions with this cloud migration could create that will disrupt customers or employees and potentially lead to a (temporary) drop in revenue?

Illustrating cost of delay for a cloud migration

Now we will illustrate what the cost of delay looks like for a cloud migration, highlighting how missing (or hitting) certain milestones can burn or capture net lifetime value for the organization.

It is important to note that there are set asymptotes within the equation. If you were to migrate your entire estate perfectly instantaneously or infinitely early, there is a finite amount of value that can be captured. On the other end of the spectrum, completing the migration infinitely late will result in no ability to capture any lifetime value, potentially exposing your organization to infinite losses until the plug is pulled on the project.

Let’s illustrate the idea of these limits with a software release your firm plans to add to production. The company that sells ‘Software X’ has a planned product lifecycle for ten years. You can’t implement the software before it is released (being infinitely early), and you can’t (in good conscious) implement the software infinitely late as it will be useless. Implementing the software on the last day of its lifecycle would cause you to need an immediate replacement, thus generating no ability to capture any net lifetime value for the organization.

In our example scenario, we look at the total net lifetime value the organization can capture as a function of time. You will notice a considerable drop in net lifetime value from $40 to $10 over a short period of time. Each graph of net lifetime value over completion/implementation date will look different, but I chose to highlight something drastic and rooted in real-world possibility.

Let’s say you are approaching the end of support date for a crucial component of your data estate, and you work in an industry like healthcare or finance where increased regulations are always a top concern.

Suppose you know that you will have to pay extreme extended support costs to maintain regulatory requirements and protect customer/patient data. In that case, there is a massive shift in the cost of delay for failing to remediate the issue and modernize. The cost of delay illustrates the massive loss in net lifetime value that can be captured by remediating the issue before the end of support date.

This scenario could also apply to the need for a hardware refresh. If you plan to move to the cloud but fail to do it before a big product launch where you know your organization will need net new or refreshed hardware within the physical estate, you could face issues. By purchasing new hardware that will become obsolete as your organization pushes for cloud migration, you further diminish the value of a cloud migration because those hardware refresh costs have already been incurred. Because the cost of delay is iterative, there is also a cost of delay should you choose to delay the product launch. There will be a resulting reduction of value captured due to its cost of delay.

Generally speaking, in any instance of cost of delay when the variables are mapped as accurately as possible to deal with complexities, there is always more value to be captured by implementing sooner as time carries overhead in any business.

How to use the cost of delay in a cloud migration

The cost of delay is not just one single equation. Each component of cloud migration will come with its own cost of delay, the loss in net lifetime value associated with failing to act on implementing one piece of the puzzle. In many cases, certain components will serve as prerequisites for others. For example, you can’t migrate a workload to the cloud if the proper landing zones have not been created. Cost of delay is still very much a factor as each delay in a prerequisite requirement component causes a subsequent cost of delay for every project component that follows.

In theory and set in a vacuum where no unexpected variability or complexities are introduced, it will always make sense to prioritize the task/job with the highest cost of delay in any stage of the project. In real-world practice, that isn’t always the case.

When the cost of delay is obscure, intuition is often used to determine the value of features or implementations that are difficult to quantify. Managers should decide if they want to trade components of value for more or less cycle time to finish the migration early.

Do I want to add PowerBI analytics right off the bat, or should we try to get the essentials up and running in the cloud as part of our migration? Which decision better enhances our ability to capture the net lifetime value of the platform?

Time carries an overhead cost, so trying to use intuition in decision-making rather than hard data results in variability in the price paid to ship new features—randomizing our ability to hit critical milestones and capture value according to plan.

When multiple decision-makers have a say in the migration to the cloud, an intuitively guessed cost of delay (VS relying purely on data) will carry much more variance as more decision-makers are introduced to the mix. Yes, you can average the data to try to reduce the variance.

However, it will still be there, and it will still interfere and randomize the results of the organization’s ability to capture value throughout the project’s lifecycle.

As you implement the cost of delay, look for better, more efficient ways of measuring and recording the costs and value-capture potential of different components of your IT estate.

Reduction of variability establishes predictability from the start, and it will improve your results.

If you’ve explored the Quisitive blog in the past, you know that our no-cost Azure Assessment Accelerator Program is all about helping organizations build out a compelling ROI for their partial or full cloud migration into Azure. Understanding the financial and business impact of cloud migration is an *essential* first step toward having the data you need to create and understand your organization’s unique set of cost of delay calculations.

Additional Resource: 3 Things to Expect From Your Azure Cloud Readiness Assessment

Calculating the cost of delay in the initial cloud migration is only one small piece of forming a highly successful cloud strategy framework. Stay tuned for my next article in the series, where I will break down the cloud strategy framework’s components and how your organization can leverage powerful tools and tricks to win in the cloud.