I am deeply interested in the Theory of Constraints' tools and techniques, so it's a pretty sure thing I will pick up any book that comes out of that community. This time it is Behind the Cloud, by Jelena Fedurko, an excellent guide to building and critiquing the Evaporating Cloud, a classic element of the TOC Thinking Tools. If you are curious and want step-by-step instructions with examples, this is the place to go.
What is an Evaporating Cloud? Trying to make a decision and feel stuck between two options? Or is your organization struggling with the classic don't spend money but then overspend to "hit the numbers." Or any number of personal Do X or Do Y decisions. Evaporating clouds are a way to think about the problem and uncover more information about the situation to assist in resolving - evaporating - the problem.
The goal of creating a cloud is to come to some kind of resolution. If you aren't interested in resolving the conflict, there is no point in drawing the cloud.
In the context of most of the traditional TOC training for manufacturing or project management, the cloud is used to help describe classic conflicts that managers find themselves working within: Do X or Do Y - and they usually find themselves swinging between extremes or devising a compromise that doesn't quite satisfy anyone. These are problem-solving clouds, usually associated with deeper struggles faced by an organization (company, family, society). Daily conflicts can also be cast in the Evaporating Cloud model - conflicts certainly come up in the daily life of people: deciding among a pair of actions, or conflicting actions being driven by different people.
The conflict cloud has a very specific form, and all the elements have a meaning. The boxes and arrows have a use, and there is a hidden aspect that I had forgotten. I'm not an expert, but this book has certainly helped shore up my understanding. The basic reading of the cloud is usually left to right, though you can reverse it to make sure it is clear. In order to satisfy the goal (A), I need both B and C. In order to satisfy need B, I must do D. In order to satisfy need C, I must do D'. However, D and D' conflict (I can't do both of them at the same time). The piece of reading these clouds that I had forgotten is that not only do D and D' conflict, but they also jeopardize the opposite needs: If I do D, then C won't be met. If I do D', then B won't be met. Of note for clouds, the needs in B and C are not the only needs associated with the goal in A. They are the needs that are creating the conflicting actions D and D'. Finding these sometimes takes a bit of work and discussion to understand the full situation.
Here is a classic example from either project management or manufacturing: Get the project/product out on time by holding people on overtime or hiring subcontractors, vs. Keep costs under control by disallowing overtime and subcontracting. This usually shows up as "no overtime" until it gets too close to the deadline and then it is overtime like crazy to make it happen. Manufacturing organizations often see this as "end of the month syndrome" as they have end-of-month ship dates. I have seen many clouds with Do / Don't Do as the conflicting actions, but this is only a subset of possible conflicts. You might have Deliver on Time vs. Deliver Full Scope. Or Take the new job in a new town vs. Keep looking where you are. Or Add more detail to project networks vs. Make less detailed networks.
In addition to the basic reading of the cloud, under each of the connections are a set of assumptions. The why behind the statement. This is where the analysis happens: evaporate the cloud by invalidating the assumptions that hold it together. It's sometimes difficult to build the basic Cloud, but the underlying assumptions are where things really get interesting, and where a deeper conversation really pays off with the people involved. Developing the assumptions sometimes comes right out of the conversations - the story people tell about the situation. In other cases, it may take a lot of asking why to understand the situation better. Behind the Cloud provides four basic checks to validate assumptions, plus two others to validate the D-D' conflict assumptions. This element seemed to take up a large part of the book, possibly because it isn't as heavily emphasized elsewhere. In the case of the example cloud here, the assumptions to look for have to do with the way work is managed in the business: what is creating the situation that you end up in the conflict.
One thing I've always wanted - and this book doesn't provide it either - is a catalog of "classic" cloud formulations. The challenge is that even for standard conflicts, the specific situation is different for everyone. But the archetypal clouds apply in many, many situations. I'd love to see a cataloging of these and the common places where the clouds are evaporated.