The Evaporating Cloud — A powerful and forgotten technique for finding win-win solutions to impossible problems.
Evaporating Cloud Diagrams were first dreamed up by Eli Goldratt a few decades ago. I was first introduced to the book Critical Chain (1997) by Eliyahu Goldratt and have since used them a few times to solve difficult problems, problems which may seem like there is no clear solution.
The evaporating cloud is a tool that helps to logically visualise a problem, surface hidden assumptions, and to summarize the problem in such a way as allow focus attention on specific questions. When a solution is found then the unsolvable problem becomes solved, and the cloud evaporates — thus the name.
In The Critical Chain, cloud diagrams are used in a manufacturing setting to break the conflicting assumptions “The only way to achieve good cost performance is through good performance everywhere” and “There is no way to achieve good throughput performance through good performance everywhere”.
The evaporating cloud technique works well with situations that tend to be settled by a compromise, win-lose, or lose-lose situation. One of the common hallmarks of an evaporating cloud is that there is a realisation that there is a false assumption at play in the problem which is preventing a win-win situation.
How to construct an evaporating cloud?
An evaporating cloud typically looks like this:
Box A is the common goal or objective which requires both B and C to be true.
D is a prerequisite to B being true and E is a prerequisite to C being true
The way to read a diagram is:
In order for A we must have B and C. In order for B to the true D must happen and in order for C to be true E must happen. The problem is that D and E cannot happen simultaneously.
The arrows between each box show the relationships and the arrow between D and E shows the unreconcilable conflict.
Often the most challenging part of using the Evaporating cloud tool is to accurately describe the problem in a way that it fits into this structure.
Now the diagram is constructed, next comes the fun part — Evaporating the cloud.
Evaporating the cloud
Now that the cloud is constructed, it is easy to see and find the assumptions. The assumptions are simply hiding underneath the arrows. If one of these arrows can be removed, the conflict is resolved. There are two ways of evaporating a cloud.
1. Show that one of the assumptions is not valid. Thinking critically about an assumption might be enough to break the conflict. Maybe there is a company policy, or way of working that is the root cause of why the assumption. Simply changing an unwritten rule might be sufficient to resolve the conflict.
2. By injecting a creating solution to break one of the assumptions.
When thinking about the assumptions, some arrows break better than others. The best arrow to break, if possible, is the conflict arrow between D and E. Often breaking this arrow will shatter the cloud and provide the best win-win scenario. The next best arrows to break are the necessary condition arrows. Policy solutions often live under these arrows.
An example
I used it when I was doing some project work for a local product development consultancy. The way they ran their business was that a prospective client would come to them with the outline for a project. They then spent quite a bit of their own time upskilling on the domain, researching, requirements gathering and doing an initial architecture plan. They did this while in constant conversation with the prospective client. What typically transpired was that the project would take several hundred thousand dollars of work to complete over a period of 6–12 months.
Due to trying to minimise the risk of spending too much time on projects which didn’t go through, the proposal they produced would only be bare-bones, just enough to give an estimate with wide error bars and there would still be a lot of unknowns. The consultancy would then present its proposal to the client, and the client would look at the proposal and the wide estimate and have second thoughts about outsourcing the work. Half the time the project would not proceed and all the work on the research and preliminary architecture would have to be written off. What’s worse, is that this architecture phase is where the most value is added to the project.
Enter the cloud diagram. Upon realising that this is exactly the type of problem that cloud diagrams are designed to solve, we got about constructing a diagram, and after a bit of trial and error the evaporating cloud diagram we ended up with was something like this:
The diagram reads:
“For a correctly estimated project proposal to be accepted the customer needs a high degree of confidence in the consultant before proceeding. At the same time the consultant needs to produce a detailed report and preliminary architecture before an estimate with a high degree of accuracy can be produced.
The problem is for the customer, they want an accurate price without being able to articulate what they need in sufficient technical detail.
The problem for the consultancy is that in order to produce the technical detail required to give an estimate a lot of time and effort is needed.
So how was the conflict solved?
After focusing on the assumptions for some time, we came to realise that the biggest disconnect was between the customer not knowing their needs well enough and the consultancy not investing enough to understand the needs well enough.
We went for injecting a creative solution:
“By selling a small discovery phase project, the consultancy can have enough time to do enough research to give a considered architecture and accurate estimate while at the same time giving the customer confidence in the consultant without needing a large outlay of money.”
This also has the added side effect of clients having a chance to experience the consultant in a contracted arrangement, which gives them the confidence to say “yes” to the rest of the project.
What were the results?
It took a little bit of convincing the sales staff to try the new format, and it took a bit of effort to work out what should go into a discovery report. But 12 months on from the initial implementation work, it is working a treat. Serious clients are happy to spend a few thousand dollars on a discovery phase. And even if the project does not proceed immediately — they still get something of value. Clients who are not serious turn their noses up at having to pay for discovery — and that is just fine! The conversion rate of clients who have completed a discovery phase and have gone on to do full projects is nearly 100%. The evaporating cloud process has turned a lose-lose situation into a win-win situation.
Thanks Eli!
