Rolling up our sleeves — Building a first Cost of Delay model
[Cost of Delay series — Part IV: “Cost of Delay categories. Maintenance.”]
“Everybody knows time is money. But almost nobody has a good idea how much.”
(Stefan Verstraeten)
In the previous article, we introduced the Cost of Delay (CoD) concept as the answer to the question: “How much do we gain or lose if we advance or delay this work unit by x amount of time?” We saw it is useful to financially quantify the work of our creative knowledge work team, with practical applications such as prioritizing work units or determining optimal staffing levels. The only problem is… we still need to figure out how to calculate CoD.
Cost of Delay numbers aren’t precise mathematical objects, but estimates. Like all other estimates, the method we use to produce them can range from a pure guess to the output of a sophisticated model. We won’t dwell on the guess-making part too long — there isn’t that much to discuss — but starting a CoD journey with pure guesswork can still be interesting, for two reasons. First, if we ask experts to make those guesses, we can record those predictions and then compare with actual outcomes. The experts can learn from this how accurate their estimates were, and generally we can analyze who of our expert estimators were more accurate than others. If we work with such a calibration feedback loop, mere intuitive guesses can already produce quite useful estimates for decision making. Second, working with the experts we can review and discuss their underlying assumptions and rationale — individually, or better yet, collectively. Of course, the moment we start comparing their hypotheses, assumptions and mechanisms we’ve already taken a step towards modeling…
Conceptually, every CoD model we want to build has the following general properties.
Coming first, represented on the left, is execution time. The project or work unit we are considering has a certain start time E0 and a certain expected duration until execution is complete at an end time E1. Coming later than execution, represented on the right, is the payoff. As of a certain payday moment P0 (which may coincide with the end of execution E1 or only come later) we expect a financial payoff from our executed work. The payoff may continue for a while up to a final moment P1, or potentially go on forever. During the payoff period, the payoff amounts follow a certain expected pattern, e.g. a ramp-up period where the payoff amount increases, followed by a steady-state period of stable payoff amounts, and an end of life period when payoffs decrease and stop. To build a CoD model, we first need to describe this expected state of affairs in terms of execution period and payoff structure, and then model out what change to the payoff structure an execution delay Δ would cause. We express this change as a number and that is our CoD, the model’s output variable. As indicated in the graph, we can incorporate uncertainty in the model if we want by working with statistical distributions for parameters like the execution duration, beginning and end time of the payoff period, and the payoff amounts.
In all our discussion until now, we have only discussed the value-add productive work of our creative knowledge work team. And our biggest goal is definitely still to quantify the CoD of the work units involved in this creative production. However if we want to effectively use these CoD estimates for prioritization, we will need to compare them with CoD estimates for other types of work. For example, discretionary projects to save cost or reduce risk may not directly contribute to value-add production, but that doesn’t automatically mean they should be lower priority. The opposite case may also be true: the financial controller may push very hard for the team to implement a cost saving project, which in the big scheme of things is far less valuable than the core production time it would displace. We’ll therefore cast a pretty wide net to cover the types of work and projects we build CoD models for, and will not limit ourselves to work units only.
One approach is to classify projects in four categories, defined by the nature of the value they deliver[1].
> Maintenance projects: the value is generated on the cash income side, and its source is our existing business
> Growth projects: the value is generated on the cash income side, and its source is new or incremental business
> Savings projects: the value is generated on the cash outflow side, and its source is our current expenditure base
> Risk management projects: the value is generated on the cash outflow side, and its source is avoiding (as yet non-existing) spending
Viewed through the lens of the general properties described above, the typical nature of projects in each of these categories is quite different. As a result we’ll bump into characteristic challenges in building a model for each category. Unfortunately, we can’t have one easy CoD function covering all cases. Instead, we will create a library of different models we can draw from. And to reinforce an earlier point: like any other modeling project, the benefit to an organization of building CoD estimates is not just the numbers the model spits out. Building and discussing the model is a forcing function to articulate assumptions and hypotheses, and comparing the different opinions of different participants often leads to insight and understanding that are valuable in their own right.
Maintenance
Our first category is Maintenance: cash income generated from our existing business. We have (or can record) cycle time data on historical work units supporting our existing bread and butter, meaning E1 and execution time properties, such as average duration and variability, are typically well understood. By definition we also have a lot of data on the payoff function: this is literally our existing business, generating existing revenue every day. So work classified in this category is the most factory-like. Building CoD estimates is not that hard, and having them is mostly useful as the baseline reference for work in other categories.
In its simplest form, we can think about Maintenance CoD starting from the perspective of the entire company as a single team. Suppose we had a company in steady state, neither growing nor shrinking. This business generates a certain current run rate of cash income, say 12 million EUR per year. To produce it, the company processes a number of work units, e.g. 1,200 per year or 100 per month. The payoff function is a steady 1 million EUR per month. So as a first approximation, we can value the execution delay of 1 work unit by 1 month as representing a CoD of 10,000 EUR payoff per month.
The math in our example is simple. This is the right moment to pay some attention to the units we use though. When calculating CoD this way, we use a time unit twice: once as the unit of the delay (which is execution time), and a second time as the denominator for the payoff amounts which we express as a run rate (EUR per month of payoff time). As a result, our CoD estimate is expressed in terms of EUR per time squared. Our example estimate of the CoD of one work unit is: “10,000 EUR per month (of payoff time) per month (of delay time).” It is possible to express CoD differently — as a lump sum amount per month of delay time — and we’ll discuss how to translate between both methods in the article on cost savings. For now, the thing to remember is we’ll need to pay attention to the method use when we interpret results for decision making.
With this simple model as starting point, we can refine model assumptions to our heart’s content. Here’s a couple of examples of things we could consider.
> If we delay a number of work units, or even skip them altogether, the income from our business will probably not decline instantaneously. There’s a certain inertia in running business: running customer contracts, retainers… and dropping the ball on a small portion of work may have zero impact. But for some businesses, it’s possible the impact is immediate and tangible. E.g. for a newspaper business, with the publication of one edition as the work unit, there will be an immediate Cost of Delay impact, even for missing just one work unit for just one day. If we fail to print the daily paper, we’ll miss out on kiosk sales and have to compensate unhappy subscribers. We can model and measure inertia or degradation effects if they are material enough to influence the decisions we take.
> If modeling at the company level is too coarse, we can model at a more finely grained product or value stream level. Instead of one big company team box, we draw several smaller division boxes, and count work units and income separately for each. There’s a big watchout involved in using division income, especially for our finance person. The CoD estimate will only be meaningful if the income allocation method is genuinely related to each product’s market value. Some companies allocate revenue by product based on e.g. employee headcount or total cost base in that product division. If that is the case, our Cost of Delay metric will not reflect customer value, it will essentially just report us back the Cost of Capacity!
> Similar to carving total maintenance income up by product, it may be tempting to start differentiating by worker type or role within a division. Some team members will directly contribute to the production of a work unit, while others have overhead or indirect, supporting roles. There is an element of truth in this thinking. If the overhead person is not there for a month, we probably won’t see throughput go down. Contrast that with a critically important expert in the team, whose absence would immediately result in disruption of the workflow. In theory, we could assign all of the CoD to the expert and none to the overhead person. In practice, the question is whether this will lead us to taking different decisions. We’ve seen in a previous article how managing throughput is all about managing the time spent by a work unit in the team, not the time spent by each individual. The majority of the decisions that matter concern the operation of the system as a whole, not the individual operation of a single part of that system (with the exception of employee performance issues, but that isn’t a CoD topic.) So unless we really need to worry about delays caused by specific individuals, we don’t need to have a separate model trying to capture Joe-the-coordination-guy’s contribution to Cost of Delay.
In conclusion, “Maintenance” is hardly the most exciting category, but it got us thinking about the general structure of a CoD model and dip our toe in the water with a first simple implementation. In our next article, we’ll tackle “Growth” and study how an execution delay affects the timing of the payoff function.
[1] This categorization was proposed by Cost of Delay practitioners at https://blackswanfarming.com/ which hosts many other interesting articles and case studies.
