Thanks to Andrew Johnson, owner of these books and ducsk

Thanks to Andrew Johnson, owner of these books and ducsk

I was surprised, after RRD came out, when several readers emailed me to say they particularly liked how I'd described Eli Goldratt's Evaporating Cloud technique.  Some were TOC people.  Some were newbies.  That made me VERY happy because, despite liking my variation of the cloud, I almost ripped those chapters out of the book, twice.  What saved them?  First, Kelvyn Youngman - a fellow Kiwi,  one of the cleverest people I know (and, trust me, I know a few), and author of the best free TOC resource in the world - shared a new, simpler way of writing (and evaporating) clouds.  Second, after my editor said the cloud chapters were too long and boring, I spent hours and hours rewriting them and de-boring-ficating them.  

Sadly, not everyone is going to buy RRD, so I figured I'd share the chapter where Craig (the book's Yoda) introduces Steve, the book's reluctant hero, to clouds by running through a very real example.  

I *think* the chapter stands alone - as an introduction - but your best way to learn how to evaporate clouds is to find a problem worth solving then use the example here as a pattern.  Go on ... give it a shot.

[Check out the French version of this chapter here.]

CHAPTER THIRTEEN

I met Craig Lally on Tuesday morning, at 9:55, in the staff cafeteria as promised. I'd cleared my schedule until noon, and then I would head to the airport for my flight to Copenhagen. As I walked downstairs, FPP's requirements folder gripped firmly under my arm, I reminded myself that I only had to stay with Craig for long enough to appear open-minded when I described our meeting to Norbert in Malmö later that week.

I recognized him from his company photo. He sat at a table at the back, near the corporate gym. A small notebook sat in front of him on the table. He was tieless and wore a functional grey suit, and appeared to be late-50s. He looked like a man who'd climbed a lot of mountains in his time—for pleasure—and drove to the mountains in a twenty-year-old Volvo he maintained himself.

He stood when I approached him, smiling broadly, and held out his hand. We shook, and I laid FPP's requirements binder on the table. Then we went to the cafeteria counter to grab brunch. We returned a few minutes later, me with fruit and yogurt, a single slice of bacon and coffee, him with bacon and eggs and green tea.

He took a sip of his tea and nodded. "How long have you worked for the Wyxcomb Group, Steve?"

As I took the lid off my coffee to let it cool, I explained that I'd joined nineteen years earlier as a graduate programmer. I'd worked in different roles, rising through the company, until my most recent promotion as development manager. During my time with Wyx-Group, I'd lived for a few years in Sweden and Canada, until Fran and I had returned to live in Watt's Bridge with our family. From there I had commuted to Glasgow to one of Wyxcomb Bank's development centers, doing a job similar to the one I did now.

I didn't share this bit with Craig, but my Watt's Bridge job was a smaller, easier job than the Glasgow role, and under normal circumstances my position would be viewed as a demotion. When I returned to work following Fran's death, my predecessor at Wyx-Fin and I swapped jobs. She got a promotion and a considerably longer commute, and I got a less challenging job closer to my home and my kids. Since then, though the job had grown with FPP, and over time I'd deliberately taken on more work for Norbert. Which is why I traveled a lot now.

"I'd heard that promotion within Wyxcomb's IT departments was on a dead men's shoes basis. Have you had many bosses die under suspicious circumstances, or are you good at your job?"

"A little bit of both," I laughed. "I caught a lucky break early on in my career, and the luck seems to follow me.

"Norbert said your team, overall, consists of about one hundred fifty staff."

I nodded, and then shared a few facts and figures. I actually had nearer two hundred staff, if you included the two dozen contractors we'd brought on to deliver FPP. Most of them worked full-time on FPP, while the rest either worked on smaller projects or beavered away in Ron McKnight's Support and Maintenance team churning out hundreds of smaller fixes and enhancements each year. The remaining few worked in management and administrative roles, including my small project management office.

"How long have you been in this job?"

"Just over two years."

"So you've managed FPP's development from the start?"

"Yes."

Craig said, "Okay. Good. Let's get started."

He opened the notebook to a blank page.

"There's one tool—a simple diagram—I need to show you. It's a thinking tool. I can teach it to you in just a few minutes. It will help us both to understand your problems, and later it will help us generate solutions."

"Okay."

He cleared his throat. "Whenever I want to solve a significant problem, I describe it using this diagram called an evaporating cloud." He saw me lift a cynical eyebrow, and he raised his hand in response. "I know it sounds odd, but trust me, it's the most useful tool I've ever used."

He pulled an expensive-looking pen from his pocket and sketched a small stick person, with an unhappy face, in the middle of the blank page.

He added five big rectangles, one pair below the man's hands, one pair sitting above the stickman's shoulders, and one hovering over its head. He labeled the boxes, A, B, C, D, and D'. He drew arrows between the boxes then scribbled some text at the bottom of the page.

Craig turned the pad to face me, then started by holding his hands out in front of him. "The hand boxes represent conflicting options or choices." He curled his left hand into a fist. "On the one hand ..." He clenched his right hand. "But on the other hand ..."

He tapped his shoulders. "Each shoulder represents the weights we carry on our shoulders. The concerns or needs—the things that are threatened or jeopardized by choosing one option over the other."

Then, with both hands palms open, he circled around his head and upper body and said, "The top box represents your highest level needs and goals: the needs of the head, the heart, or the gut."

"Okay," I said, looking doubtful.

"Let's use the work I did with Wyxcomb Health as an example. We'll start with D and D-prime—the two hands, the two conflicting choices. In Wyx-Health's case, it was simply a conflict between buying or building a new system."

He wrote Build in the left box D', the one he called D-prime, and Buy in the right-hand D box.

"On the one hand they could build, on the other hand they could buy. With me?"

"So far, yes."

"Good. Let's move up a level to the C box. We need to find a short sentence which sums up the reasons why we want to Build. What concerns does building address?" He tapped the C box with his pen. "We find that sentence by listing out two things: first, the positives we get from building, and second, the negatives we avoid by not buying. Does that make sense?"

It took me a moment to figure out what the negatives we avoid by not buying meant. I said, "I think so."

"When we spoke, you pointed out several benefits of having Wyx-Health software build the replacement. Do you remember them?"

I didn't recall our conversation verbatim, but it was easy enough to list three reasons off the top of my head. He scribbled these under the D-prime box.

Pros for building in-house

(1) Our development staffs' hourly rates are lower than the vendors'

(2) We can customize the product how and when we want

(3) Our existing staff keep their jobs

He said, "Good. Now tell me, can you think of any cons of doing the opposite? Buying?"

I listed five cons out loud. Three were direct opposites of the pros I'd already listed and Craig said we could ignore them. He scribbled down the two distinct cons.

Cons for buying

(4) Future work might get delayed while the vendor works on our competitors' requests

(5) The vendor might overcharge us when doing our change requests because we can't easily switch—we become "hostages"

Craig took a sip from his green tea and said, "These three pros and two cons are the reasons we might choose to build. Can you take a shot at summarizing them all into one concise sentence?"

"Is that what goes in the C box?"

He nodded.

I read the five points over again twice before I ventured forward with a summary. "If we build, then we have more control over development."

"The Wyx-Health folk said something similar," he said, and wrote More control over development in the C box.

"Let's move to the B box." He tapped the tip of his pen on the B box. "This box is often harder to fill out. In fact, the Wyx-Health development team was so firmly in favor of building they couldn't think of any benefits of buying until they got in the same room as their business guys."

I nodded as I recalled my own reaction to our earlier phone conversation. "You said the Wyx-Health business wanted to get to market quickly, to start selling again, to start making money."

"Correct. That was the significant benefit of buying." He nodded and wrote Pro- Start selling far sooner under the right-hand side of the little stick

man. "There was also one significant con of building that drove the business guys to favor buying." He frowned, which I thought was ominous. "Can you think of it?"

I couldn't.

He grimaced as he spoke. "The Wyx-Health business had no faith in their technology team's ability to build a replacement."

I felt my shoulders rise, but I said nothing.

He sensed my reaction and leaned in towards me. "Don't get me wrong. They trusted the team's motives, just not their competence. It was a big project."

My shoulders relaxed as I realized he was right. That team had spent years keeping an old, broken system alive, so they were unlikely to have the managerial or technical experience to build a mission-critical, brand new system. I said, "That's fair. It would take them a long time to build a replacement, and it would be risky."

He wrote: Con- In-house development riskier and slower.

"Let me show you what they put in their B box." He wrote: Pull in Revenue ASAP. "With me?"

"Yes."

"Note that D and D' conflict but B and C do not."

Then he wrote Profitable Business in the A box over the stick figure's head, the one labeled Common Goal.

He said, "It's important when drawing your clouds to hunt for the mutual purpose, or common goal, that joins both sides together."

"What if there isn't a common goal?"

He frowned, as if he'd never seen that situation before. "Keep looking, I guess."

He carefully tore the page from his notepad and handed it to me. "There are several ways to evaporate clouds, but let's work through the pros and cons listed here to see how Wyx-Health evaporated this cloud. First, it's important to recognize that A, B and C are most important. D and D' are just alternative means to more important ends."

I said, "In order to achieve their goal of having a profitable business, they needed to do two things: bring in more revenue ASAP and also retain control of their future development work."

"Correct," he said. "Now, you know the way this thing went. Wyx-Health bought a replacement system, but they also worked with the new vendor to create a win-win contract. By choosing to build, they achieved the pros of buying and avoided the negatives of building. By negotiating a win-win contract they, hopefully, incentivized the vendor in a way that avoided the two cons of buying. I say 'hopefully' because you can never be sure about these things."

I nodded and mentally ticked off items #4 and #5 on the left.

"But that still left the three pros of building. Let's work backwards. They addressed #3 by getting the existing staff to work first on the new system, and then in time migrate from the old to the new system. The staff is, apparently, happy with that arrangement. The Wyx-Health business said they didn't want to customize their product, so #2 was a reasonable concern but an invalid assumption. And, since the development costs were trivial compared to the potential revenue gains, everyone agreed that #1 was a red herring. Make sense?"

I took my time and studied the diagram, then nodded. "So, to sum up: You drew the cloud, you picked a side, then you figured out how to make the bad bits from the other side irrelevant?"

"That makes it seem easy! We actually spent hours thrashing this out. And, we didn't just pick one side. The team looked seriously at both sides before choosing to buy. They also considered ways they could achieve B and C without building or buying. It was fun, for me, but it certainly wasn't easy. We had some hard conversations."

"I imagine."

He leaned forward and placed his pen on the table in front of me. "Now, it's your turn."