How Value and Cost of Delay—Not Cost Savings—Applies to Centralization Decisions...

How Value and Cost of Delay—Not Cost Savings—Applies to Centralization Decisions, Part 2

In the first post, How Centralization Decisions Create Friction, Increase Cycle Time, and Cost Money, Part 1, I explained how centralizing even relatively small decisions to centralize has high costs. Why do organizations centralize? To supposedly capitalize on “economies of scale.”

That's the problem of understanding the cost of work—but not the value of that work.

To understand the value, let's look at the various Costs of Delay, especially for management decisions.

Assess the Cost of Delay for Management Decisions

In Why Minimize Management Decision Time, I showed a value stream map for portfolio decisions. That delay time was just six weeks. But too many managers spend an entire quarter trying to plan the portfolio for the entire next year. Those managers want to evaluate the time and costs of the work, before the work starts. They think the costs of the various efforts will help them understand the value of those efforts.

There are two problems with that thinking.

1. Teams cannot predict that work. They don't have enough specific information about that work and the environment, etc. (See Predicting the Unpredictable for what teams can do.) Instead, the teams can review their cycle time. Then, the team can offer 50%, 80%, and 90% possibilities for when they will finish which work. If you want to make better portfolio decisions faster, read Manage Your Project Portfolio.
2. The costs of the work often have little relation to the value of that work.

Here's an example from the project portfolio book. One Engineering organization of about 2000 people had a terrible time releasing anything “on” or even, “near” time. They hired me to do an assessment to understand why.

I discovered many delays, but the biggest delay was that it took a separate deployment team three to four weeks to create a clean build. Then, because everything had taken so long, they only deployed internally for at least a week. That's a minimum of four weeks for each team's feedback loop. (See Multiple Short Feedback Loops Support Innovation for how all the feedback loops work together.)

When I did the assessment, I asked people how long they thought fixing the build system would take. Their estimate was somewhere between six and nine weeks of about six very senior people's time.

But the math is what's most interesting.

The Math of Cost vs. Value

Let's start with the cost of the work and start with some assumptions:

• Each engineer costs the organization between $3000-$4000/week in salary plus overhead. (If you think this number is wrong, substitute your own number and follow along with me.) I chose those numbers because a $3000/week salary is roughly $150k/year. And the senior engineers made roughly $200k/year. If you prefer a $100k yearly salary, use $2000/week per person.
• The organization used primarily 6-person teams. So 6 people * $3000 = $18,000 weekly team cost. And that six-person team of very senior people would cost 6 * $4000 = $24,000/ week.
• Given the 6-person teams, the organization had roughly 333 teams. Let's just call it 300 so we have even numbers.

The organization had incurred these delays for over a year when they brought me in. That's a delay of three weeks every single week for 50 weeks. But even if you don't believe my math of three weeks for each week, we can simplify to one week of delay for each week of work.

Here's the weekly cost of trying to continue to work with a broken build system: 300 teams * $18,000 team cost/week = $5.4 Million dollars, per WEEK. (If my math is wrong, please do comment so I can fix it.)

The yearly cost of delay is mind-boggling: $5.4 Million * 50 weeks = $270 Million/year. And that's with even numbers because I want to make this easy for you to understand.

If you told your managers that you could somehow release one product a year and it would cost you $270 Million to do that, what would they say?

Probably what these managers said to me. They got quite angry and did not believe me. So I showed them a value stream map and then showed them the value of the short mitigation plan. (Also, read Diving for Hidden Treasures.)

Assess the Value of Delay Removal

Remember, fixing the build system looks like it's about six very senior people for six to nine weeks. Off the top of their heads, they explained the various Product Minimums and how long they thought those minimums would take. Why did I believe them?

• They had already lived with these build system problems for over a year. They understood the “easy” initial problems.
• Because they were senior, they had already tried to convince their managers to let them “attack” the build system. (Their word, not mine.)
• And because they'd already considered the problem, they knew they could deliver something every week or so.

This build system problem was not the same as their product development. (See the image about problem determinism in What Lifecycle or Agile Approach Fits Your Context? Part 7, Lifecycle Summary.) While their products required much more innovation, they understood much of what caused the build system problems.

So the cost to address this problem is 6 people * $4000/week * 9 weeks = $216,000. If we round this number, call it $250,000. And, the company would not be able to release anything for at least the first two weeks of this time. Maybe longer.

But step back for a minute and look at the order of magnitude costs of continuing to work this way: a weekly cost of $5.4 Million to the organization. And even if the project to fix the build system took a year, it would only cost (assuming nothing changed) $24,000/week * 50 weeks = $1.2 Million for the entire project.

That's a weekly cost of $5.4 Million vs a yearly potential cost of $1.2 Million, and much less organization-wide friction.

The managers had never considered the Cost of Delay as the value of the work. Instead, they saw the risk of not delivering anything for two weeks and always chose to do more work on the product, not the build system.

Short Summary of Predicted Cost and Predicted Value

Let me emphasize this: These managers were not stupid.

However, they worked inside a system that valued resource efficiency. That meant they predicted costs forward: Based on estimates even before the project started, the portfolio team decided what to do. And because all the projects needed these very senior people, since all the projects were so far behind, no one wanted to take the hit of not using these senior people in the projects.

Predicting cost or schedule is not easy. That's because we predict at the time we know the least about the work.

However, we can predict value much more easily. We don't even have to be totally correct to predict value—we only need an order of magnitude. Create a value stream map and review the delays. Ask why you have the delays. When I do this with my clients, most of the time, they have an excellent idea of a short or small change that can have some effect on the value stream. Then, use those feedback loops to make a small experiment and see what happens. (Yes, the essence of agility.)

In the next post, I'll discuss why a focus on resource efficiency, and a lack of an overarching goal can affect the project portfolio, especially when it comes to economies of scale. (In other words, why these managers were not stupid.)