One of the most underestimated costs in the software industry is what I would call waiting cost.
Waiting cost includes the money you are losing (or not making) while waiting for a particular feature to be ready, delivered to your customers, and generating revenues.
Interestingly this cost is usually caused by having an organizational design that is not aligned with the goal of producing value and was there much before the software industry started to become this important.
The ideal system
To simply let's step out of the software industry and let's analyze what would happen in an ideal system that needs to transform raw materials into sellable goods. In such a system you would have a machine where you introduce the raw material on one side and almost instantly you get your gizmos ready to be sold on the other side.
Here the cost of waiting is zero because 100% of the time required to transform raw material into sellable goods is spent on value-adding operations.
A sub-optimal system
Let's say we are not that lucky to have a single machine that can turn raw material, instantly, into sellable goods.
In this scenario, we have three different machines. To produce the sellable goods we need to:
- insert the raw material into machine A, wait for this machine to perform its job, and then collect the half-processed A
- take the half-processed A and insert it into machine B, wait again for machine B to perform its job, and then collect the half-processed B
- take the half-processed B and insert it into machine C, wait again for machine C to perform its job, and finally collect the ready to sell gizmo
Here the waiting cost is becoming to be visible. Every time you have stocked raw material or half-processed goods waiting to be processed you are paying the waiting cost. Depending on how fast your machines are, how frequently they broke or stop working this cost can be higher or lower.
Of course, there are good reasons to have three machines instead of one, and one could simply be that for complex goods it's impossible to have a single machine producing it starting from raw material; but as you can see your waiting cost will increase as the number of steps and specialized machines increase.
Back to software
In our industry things gets more interesting because we don't have such machines that, automatically, can turn raw material (ideas) into sellable goods (features).
We are dealing with fuzzy requirements, trying to solve different and new problems every day: knowledge/creative work.
Hint: if you are trying to solve problems that have been already been solved in the same way as you are doing, stop it, you are wasting time and energy!
To understand how much your system (organization) is leaning toward an ideal or sub-optimal one try to answer this question: how many groups need to do something on your feature to be ready and delivered to your customers?
Usually, in many organizations, this number is higher than you expect. It also includes all the people doing product discovery, analysis, design, developing, testing, deploy, marketing, customer care, training, etc
To get things even worse in our industry you cannot simply take the output of one group and hand-off it to the next, because as we know, we are dealing with fuzzy things that people need to understand and contextualize before they can do something meaningful on it.
And... given the total time required to get from an idea to a feature generating revenues in production, how much of this time people are doing value-adding activities on it? (note: coordination is not a value-adding one)
In some organizations, I can roughly estimate that this can go down to single-digit percentages (like 1% or 2%).
Most of the time consumed is usually spent:
- waiting for someone to start working on something
- coordination activities such as writing documentation for hand-off, meetings, email, etc
- clarification of what needs to be done and agreements across different groups of people
Theory of constraints
Introduced by Dr. Goldratt in its masterpiece βThe Goalβ the theory states that: the maximum throughput of a system is constrained by its slowest part.
For example, in the sub-optimal system example, if machine A can produce 10 parts per minute, machine B 30, and machine C 25 the overall throughput of the system will be 10 parts per minute (if everything goes well).
This is quite clear and it's usually how the theory is applied... but what if your major bottleneck is not one of the "machine" (step), but how you organized the system in the first place?
Then you can work on improving the single steps as much as you want, like introducing better technologies or methodologies, but you are still working on optimizing the smallest part of the total cost.
If your goal is to reduce the time to market but your system is generating tons of waiting and coordination costs spread across all the steps, my advice would be to look at the bigger picture and rethink the system.
It's not that simple...
Yeah, I know. Changing the structure of an organization is something that sounds crazy, scary, and complicated.
But on the other hand, if you are in a similar situation as described before, don't you feel frustrated by spending a lot of energy in trying to improve things and not getting only margin gains?
Top comments (0)