The best financial metric you’ve never heard of
[Cost of Delay series — Part III: “Cost of Delay”]
“Time fleeth away without delay.”
(Unknown)
In a previous article, we discussed how the leader of a creative knowledge work team can measure team performance. Once she identifies a representative work unit, keeping track of cycle time and the amount of work simultaneously in progress will allow her to maximize throughput and ensure team capacity utilization isn’t pushed unproductively high. But even if our team leader now has some tools to manage operational performance, we haven’t given her financial controller counterpart the means yet to translate this to financial performance. Building that connection between operations and financials is our topic in this article.
Operationally, the team leader uses cycle time and work in progress (WIP) as important performance metrics. A nice way to visualize these for herself and interested stakeholders is the Cumulative Flow Diagram (CFD). A CFD plotts the count of the number of arriving and completed work units (y-axis) against their respective arrival and departure time. It looks like this.
As the y-axis keeps track of work units, the vertical distance between the arrival and departure curves corresponds to WIP. Likewise the x-axis records arrival and departure times, so the horizontal distance shows cycle time. (The team can also plot the same data for customer orders and customer delivery, resulting in a CFD showing queue size as the vertical distance and lead time as the horizontal distance.) Seeing this graph, the team leader will be worried. WIP is increasing, and cycle times are getting longer. The team completes work at a steady pace, but clearly the arrival pace of new work units is higher than the team’s capacity to process them. The team leader will see this adverse trend first in the growing WIP number, and only (much) later in the corresponding increase in cycle time. The reason is a new work unit immediately impacts the WIP number at arrival time, while its impact on cycle time only gets recorded at completion time. As a result, Work In Progress is a leading indicator, while cycle time is a lagging indicator. Seeing WIP go up, the team leader is very alarmed. She knows what happens if the team gets stretched beyond threshold capacity utilization. The cycle time to process a work item gets longer, which further increases WIP, which makes cycle times even longer and performance degrades. The only way she can get more work done faster is to reduce the number of items in WIP[1]. The CFD she wants to see looks like this.
The team leader now feels in control of operations and will rightfully argue she’s optimizing throughput, expressed in completed work units per unit of time. Her financial controller colleague, however, will still fret about two very real problems. First, he’ll point out that restricting inflow of work items into team WIP is the right thing to do, but it doesn’t make the work units waiting in queue disappear. From a financial perspective, those waiting units represent value just as much as the ones in WIP. From the customers’ perspective, the lead time they incur before they see their order delivered is long and getting longer (illustrated by the CFD if we assume for a minute that every completed work unit immediately gets delivered.)
The financial controller will also wonder if the team is working on the right work units. So far we reasoned about throughput, queue size and WIP in terms of counting work units. But simply counting work units doesn’t tell us anything about how valuable they are. What if the team leader systematically picks easy but low value work units out of the queue to take into WIP, and keeps others waiting which are harder but more valuable? How can team leader and financial controller know which work units are more valuable than others, and prioritize those to maximize throughput expressed in financial terms?
A value metric proposed by Don Reinertsen for this purpose is called “Cost of Delay” (CoD)[2]. Conceptually, it is associated with a specific work unit as the answer to the question: “What would we financially lose if the completion of this work unit was delayed by a week/month/year?” (or financially gain if it was accelerated by that period of time.) Cost of Delay is expressed as a rate, e.g. 10,000 EUR / month.
A financial controller is of course trained in methods to model and estimate the monetary value of a work unit. Usually these are expressed as a single monetary amount. However in this context, a rate is more useful since we are not only interested in whether or not a work unit is worth doing, but also when it should be worked on. To make that more concrete, imagine our financial controller is looking at two work units or project proposals A and B. He estimates the monetary value of both at 50,000 EUR and they both require one week of work by the team. Based on this information, the controller is indifferent to which project gets worked on this week. However it just so happens that if proposal A gets worked on first, one week from now the opportunity of proposal B will no longer be there. Whereas if proposal B gets worked first, one week from now the estimated value of A is still preserved and the opportunity still available to the team. So by basing his financial analysis starting from the question: “What would we financially lose if the delivery of this work unit was delayed by a week?”, the financial controller can incorporate the effect of execution time in the value estimates and prioritize the execution of B over A.
Before we dive into the details of how to make Cost of Delay estimates, let’s look at some practical uses we would have for such a “value per time” type metric. Making CoD estimates in monetary terms isn’t easy and there isn’t a lot of literature to fall back on, so the rest of this series will mostly be about grappling with the practical problems. But for now, let’s assume a genie gave us a magical CoD function, producing a CoD estimate for anything we want. What kind of business problems could the financial controller and team leader address with the metric?
First, they can use it as a better way to track the team’s throughput, expressing it in monetary terms instead of work unit count. Imagine the team delivers 5 work units in July and 5 in August. That looks like consistent throughput delivery, but defined this way the “throughput” is more a measure of activity than of customer value. Suppose every work unit in July had an estimated CoD of 10 / month and the August ones 20 / month, that’s a 2x difference in value delivery and therefore financial throughput. Had the team leader known this, perhaps she would have prioritized the August work units for earlier execution. Team leader and financial controller can therefore use CoD to measure the team’s financial performance over time. Furthermore they can analyze this record of financial performance in relation to the operational metrics (queue size and work in progress, lead time and cycle time). For example, rather than just believing that too high capacity utilization adversely affects cycle times and throughput, they now have the means to observe and validate this for themselves, and determine at which levels of WIP and capacity utilization performance begins to level off or deteriorate.[3]
Team leader and controller can also use the CoD function to keep track of the total value of queue and WIP. This is the metric to address the financial controller’s first problem mentioned above. If it turns out the value waiting in queue is consistently much higher than the average value being processed in WIP, it indicates the team doesn’t realize enough of the value it has pent up waiting for attention. Which immediately leads to the next application…
…which is to compare Cost of Delay with Cost of Capacity. The “capacity” of the team is essentially productive staff time, and the incremental cost of adding people to the team — salary — is also a rate i.e. money per unit of time. This makes it very easy to compare CoD and CoC. If the team needs to spend 1,000 EUR / week on staff to structurally reduce the queue with work units worth 10,000 EUR / week, that’s a no brainer. With these metrics and data available, the financial controller will be dying to add people to the team just as much as the team leader. (And if the data shows the additional unlocked CoD is not worth the CoC, it does not make sense to add staff.) So by combining the operational metrics of tracking queues with the financial metrics of estimating Cost of Delay, our team leader and financial controller have built a joint basis to reason about the value created by the team, and a quantitative method to plan for the optimal level of staffing. In the real world, it’s not always that simple — this isn’t a pure numbers thing. Just adding more people doesn’t always automatically result in higher productive capacity and more throughput[4]. The team leader will need to analyze the role and skill profile of the additional capacity making the difference. (She’ll find important clues in analyzing the main sources of WIP waiting time: work units will spend a lot of time waiting for the attention of understaffed sub-teams or experts.) But if they invest in staffing in certain areas, team leader and controller now have the metrics to validate if their intervention is successful: queue value will decrease and throughput increase… or it won’t.
In addition to their conceptual toolbox to build and manage budgets, team leader and financial controller can also use the CoD estimates for prioritization of work units. Of all work units waiting in queue, they’ll want to give priority to the one delivering the most value as quickly as possible. A useful metric for this is Cost of Delay divided by the expected duration of execution, a metric known as “CD3”. CD3 takes into account both decision elements: amount of value, and speed to value. Our duo will probably face some practical constraints or choices interfering with a strictly CD3-driven prioritization method. E.g. pulling in the highest value work unit may heavily rely on an already overloaded part of team capacity (such as access to an expert, or constrained test capacity). Or an executive may want priority treatment for a special request. If that’s the case, at least the team will now be able to tell the executive how much value is being delayed by fast tracking the pet project…
Having looked at all the goodness Cost of Delay can do, the only small detail left for us to do is to actually create our magical function, since we unfortunately don’t have access to a genie to give it to us. This is where most of the existing literature gets vague or stops altogether. But we will soldier on and tackle all the hard questions in the remainder of the series, starting with Part IV.
[1] …which is easier said than done. Coming back from a situation of overwhelm, bringing WIP back under control, is hard, and takes a lot more time than running up the excess in the first place.
[2] For an introduction to Cost of Delay, and extensive discussion of queues, read his excellent “The principles of product development flow”
[3] Some practitioners of Lean and Agile methodologies implement the Cost of Delay idea using point scoring, or relative ranking of work units. Those approaches make it easier to moderate CoD implementation workshops with a broad audience of participants. It also captures one other benefit of modeling approaches like CoD: working them in a group exposes the (often silent) assumptions people are working off, which now become open for debate and documentation. Personally I prefer quantifying CoD in financial terms, because this creates a feedback loop to improve the estimation models over time. No matter how crude the initial model and estimates are, they produce predictions which can be compared to actual outcomes to refine or calibrate the models. Creating such learning loops is harder to do for CoD approaches based on e.g. point scoring or forced ranking.
[4] This is essentially a problem of scaling, which will be the topic of a future article.
