ORACLE

The Builder’s Parable

Doug Samuelsonsamuelsondoug@yahoo.com

The house remodeling crew was taking a break. The OR/MS analyst, welcoming the temporary respite from the noise of hammers and power saws, took the opportunity to stroll over and ask the builder, “How’s it going?”

“Just fine,” the builder replied. “We’re right on schedule. This will be a nice-looking sun room and a much roomier kitchen, and I’m sure you’ll enjoy them.”“Well, it looked good in the plans,” the analyst said, “but you know how things can go wrong.”

“True,” the builder conceded, “but mostly when the architect didn’t have practical building experience. If there was a builder in on the design, things tend to work a lot better.”

“How so?” the analyst asked.

“Designers who have actually built a structure like the one they’re designing,” the builder explained dryly, “tend to remember little things like lining up all the plumbing fixtures as much as you can, so you don’t end up having to run pipe all over the place, and when a drain clogs and backs up it’s less likely to short out a major appliance.”

“Hmm,” the analyst responded, suddenly lost in thought. “Maybe this is what’s wrong with the project I’ve been flailing away at for the past few months. I thought I was having trouble communicating with the client, but now I think I see a different explanation.”

And then he scowled.

“What’s going on?” the builder inquired.

The analyst told him, “I’m part of a design team, pulled together from a dozen or so different organizations, supposedly working out the plans for a big, complex model of – well, let’s just say a major set of activities with all kinds of public policy implications. There are a lot of parties with a role in the pubic policy issues: multiple federal agencies, several states, a bunch of county and local governments, some big businesses – you get the idea. So the coordinating agency decided to get a lot of experts together and figure out how to build this model. What looks like the most promising way to tackle it requires some new techniques and software that not everyone knows. Those of us who do know those techniques pretty much agree on how to get started, but we can’t get the client to let us try!

“Unfortunately,” the analyst continued, “a couple of the companies in this team are big, well-known consulting firms with a lot of experience in many areas, but not much experience in this kind of modeling. They keep raising ‘what-if’ questions that get the client all concerned about making a mistake, and then they recommend doing a detailed requirements analysis, or a thorough review of possible related prior studies to prepare a detailed work plan.

“They always mention their good working relationships with highly regarded universities, which makes their recommendations seem to carry more weight,” the analyst added. “I’ve checked those schools, though, and they, too, are mighty short of people who have actually done this kind of applied model. So every one of these recommendations takes six months, stops everyone else and gives those consulting companies more say in what gets approved, while not much gets produced. And then the requirements they define are often wildly impractical, while something nearly equivalent would be a whole lot easier.

“So we keep meeting,” the analyst grumbled, “and we’re getting remarkably good at having a meeting to plan another meeting to set up working groups that will produce white papers we can discuss at yet another meeting, and so on, and so on and so on!

“Now, thanks to you,” the analyst went on, “I think I see what’s really going on here. Since those prestigious consultants don’t have relevant experience, they don’t know what’s easy and what’s hard! That’s why they come up with specifications that are hard to meet, and why they’re so afraid of failure that they’re reluctant to let any recommendation for action become final and get carried out. Meanwhile, they’re buying time, while they try to learn what we modelers already know. I hate to think they’re trying to sabotage our work, or even steal it, but at the very least they’re taking a huge share of the time and resources for not much product. And they’re manipulating the client into buying more and more planning that doesn’t add much value, while postponing the demo modeling tasks that would help a whole lot more in defining what can and should be done.”

“Sounds about right,” the builder acknowledged. “So what are you going to do about it?”

“At our very next team meeting,” the analyst declared grimly, “I’m going to recommend that the design be turned over to a subcommittee composed exclusively of people who have already done this kind of modeling successfully. I’m going to tell the story about builders and architects and plumbing, and make sure the client understands that they can fail by studying the problem to death even more surely than by trying something reasonable based on a good first draft of a set of specifications. When my distinguished colleagues from those big consulting companies start to protest, I’ll just ask, ‘Have you ever actually done anything like this before? And if not, how would you know what to specify?’

“And if that doesn’t get things turned around,” the analyst concluded, “I believe I’ll walk away from this project and find some new clients! If they don’t understand what they want to

buy and won’t listen to the people who know how to address their problem, they won’t appreciate whatever we can deliver!”

Doug Samuelson (samuelsondoug@yahoo.com) is president and chief scientist of InfoLogix, Inc., in Annandale, Va., and a senior operations research analyst with Group W, Inc., in Merrifield and Triangle, Va., supporting the Marine Corps Combat Development Command (MCCDC). This “classic” ORacle first appeared in the August 2009 issue, but the problem remains as relevant today as it was then.