The Blind Men and the Elephant

David McClintock writes "In David A. Schmaltz's new book, The Blind Men and the Elephant: Mastering Project Work, we find a powerful metaphor for the collaborative work involved in software or systems development. The metaphor is simple -- like the book title, it comes from John Godfrey Saxe's famous poem about the six blind men from Indostan. Simply put, Schmaltz is saying that your project is an invisible elephant. It's standing in a room, waiting to be revealed by a group of groping teammates." Read on for McClintock's review to see how well the analogy stands.

The Blind Men and the Elephant: Mastering Project Work
author	David A. Schmaltz
pages	160
publisher	Berrett-Koehler
rating	10
reviewer	David McClintock
ISBN	1576752534
summary	With a powerful central metaphor, Schmaltz shows how to make your collaborative projects personally rewarding.

Each participant on a collaborative project encounters a piece of that project, rarely the whole elephant. We grasp whatever we can -- an ear, a tail, a trunk, a leg, a tusk, a broad, flat side. Based on what we grasp (our piece of the project) we extrapolate an understanding of the whole: a fan, a rope, a snake, a tree, a spear, a wall. Schmaltz develops these analogies in terms of project experience. We encounter a fan that brings us fresh air, a rope that binds us together, a snake that abuses our trust, a tree that evolves in structure above and beneath the surface, a spear that puts us on the defensive, a wall that challenges our personal progress. A chapter is devoted to each analogy.

This isn't a storybook, though. These simple metaphors are touchstones for Schmaltz's broad exploration of what makes projects meaningful. Schmaltz sheds light on the dark matter of project management -- the stuff that blocks us from succeeding on projects as individuals and as teams. He even leads us through the panicked self-talk that runs through a manager's head at the start of a project. With rich writing that's rare in management books, Schmaltz gives us a 360-degree view of project management itself -- project management is this book's invisible elephant. The elephant emerges.

You won't find any worksheets, diagrams, flow charts, procedures, instructions, or textbook problems in this book. Schmaltz gives us something more valuable and memorable: fresh ways to think about how we approach and manage projects. For example, managers should encourage each person to find a personal project within each project, something personally "juicy" to sustain interest and make the effort valuable. Going beyond the stated objectives of a project, each of us needs to ask ourself, "What do you want?" -- and to keep asking that until our personal goals emerge. These goals don't compete with the team's purpose -- they bind us to the project's success. This is the process of what Schmaltz calls "finding your wall."

Just as managers should encourage this kind of buy-in rather than try to externally motivate a team, managers should not impose a prefabricated structure onto a team. Schmaltz argues that when people find a personally juicy goal within a project, they will strive to organize their efforts in an efficient, organic manner -- without taking that twenty-volume project methodology off the shelf.

On a person-to-person level, Schmaltz asserts that despite the risk of getting cheated by snake-like deceivers, project members are most wise to interpret people's actions generously, assuming the best and freely offering trust and help. Using the results of a computer programming competition in which the Prisoner's Dilemma was solved by having the imprisoned conspirators refuse to implicate each other, Schmaltz shows that offering trust as a first principle can lead to bigger win-wins, more often.

Schmaltz consults on high-tech projects through his firm, True North project guidance strategies, based in Walla Walla, Washington. He hosts the Heretic's Forum, a Web space designed to "capture dangerously sane ideas." In addition to his periodic newsletter, Compass, he has published one previous book, This Isn't a Cookbook.

That invisible elephant, the powerful analogy at the center of this book, will enrich the way you approach new projects and reconsider problems -- especially the parts of problems that remain invisible to you on current projects. As Schmaltz wishes in a sort of benediction, "May this elephant emerge whenever you engage."

---

Reviewer David McClintock is president of Wordsupply.com. You can purchase The Blind Men and the Elephant: Mastering Project Work from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

This is not surprising

[heironymouscoward]

All human problem solving (especially the male approach) tends to be a exercise in discovery, generally done by making an approximate solution, testing it against the reality of use, then refining this until it's "good". Different people have different skills in this regard, some are good at overall designs, some at details.

elephant analogies

[Savatte]

Schmaltz is saying that your project is an invisible elephant. It's standing in a room, waiting to be revealed by a group of groping teammates

I thought the analogy was that each blind man felt a different part of the elephant and they couldn't reach a consensus on what it was, since all the parts felt different.

a different elephant analogy is that there is an elephant (a large problem) in the room that no one wants to acknowledge, so that no one has to deal with it.

Is this what the customer really wants?

[jea6]

In my experience, the customer wanted an elephant (probably because a Fortune article said elephant). They could be quite successful - and more profitable - without the elephant. But the sales guys told them that we know elephants like mad (when, in fact, the developers have only seen elephants from far away - really far away).

Anyhow, the developers keep insisting that the elephant is untenable and deadlines slip. Instead we roll out a beta elephant (which is really just a pile of dung molded to look like an elephant) and ask the client for feedback.

Naturally, the client has no buy in from the folks who are going to be using the elephant, so the change requests start pouring in until, budget exhausted, half the developers have been laid-off. At this point, the pile of dung does not look like an elephant but the client has spent so much money that, ala Emperors New Clothes, everybody marvels at what a great elephant it is. QED.

Feel Good

[theGreater]

I do, I feel all warm and fuzzy inside now. But how exactly does all of this apply to my day-to-day? I'm not sure when it started, but recently there seems to be a proliferation of Commanders of the Obvious who disguise their barely-adequate theories behind some sort of happy analogy. "Men are from Mars, Women are from Venus" maps roughly to "Boy != Girl". How is it possible that these charlatans continue to prosper? Is it possible that the public is so overly entertained and intellecutally starved that these sort of things are revealations to them?

-theGreater Ranter.

The Blind Elephant Meaning/Problem

[magicalyak]

The blind elephant analogy has often been used as a proof for different interpretations of God. One blind man grabs a tail and says this is what an elephant is. Anothing holding the trunk say "You have it all wrong, this is the way it is". Yet another holding the tusk says "You are both wrong, it feels like this". Finally, the Rajah (Indian Price) comes out and asks what the fuss is about. He tells the blind men they are all correct, they just need to put together what they have and they can have a sense of what an elephant is. This also implies that one may possible never fully know what an elephant is. To try to relate by babbling. The elephant (the collaborative project) can never be fully grasped and only through enlightenment or a guru, can we know the truth about the elephant (the collaborative project). This kind of smells like a 90s dot-com theory to me (but then maybe I only have a piece of the elephant! what do I know?) Of course, this analogy is a bit flawed anyway. It assumes there is an elephant (is there really a collaborative project, or do you just pretend there is like George Castanza?). And furthermore, it assumes you can somehow know the whole elephant, or at least know that the elephant is more than you know. This begs the question of how you can know that! Bad analogy, bad application....I don't know about the book, but so far, no good. I'm going to go back to my imaginary elephant (my project at work) because even though it's not real, maybe it will be if I just work hard enough.

The analogy doesn't hold

[Weaselmancer]

Unlike the blind men, the programmers on a given project know what the finished product is supposed to be.

If you know you're building an elephant, and someone hands you the tail...you're not going to think the whole thing looks like a snake. Sorry.

This strikes me as nothing more than a cutesey metaphor laden book for your PHB.

Weaselmancer

Re:Elements of Style

[Planesdragon]

Never use a fifty-cent word when a nickel word will do.

Care to cite a passage of such? The biggest word I saw in the review was "prefabricated", and that's hardly a word that's cumbersome to the intended geeky audience.

Re:Is this what the customer really wants?

[Angry Toad]

Well put.

I find it interesting that there are so many hostile responses to this book and/or review thus far. That more or less lets me know where most slashdotters are on the corporate totem pole. As I've recently started doing a great deal of project management work myself, many of the topics mentioned in the review that seem "fuzzy" or "stupid" merely reflect meta-generalizations about concepts and interactions that just don't enter into the strictly goal-oriented world of the people being managed.

Let me put that in a less obscure way: the day-to-day skills involved in molding order out of chaos when you're trying to get ten different people to achieve ten different but integrated goals, while simultaneously fielding nonsense requests from above and money strangulation from the side, are just not the same challenges that most people face. Hence talking about them sounds a great deal like mumbo-jumbo.

Or something like that.

The analogy does hold

[tds67]

Unlike the blind men, the programmers on a given project know what the finished product is supposed to be.

Maybe not. There are probably hotshot programmers out there who might decide to put wheels on the elephant instead of legs, just to soup things up a bit.

After all, if you can assemble an elephant Lego(TM) style, you shouldn't be limited to just legs, right?

Re:Is this what the customer really wants?

[DNS-and-BIND]

"meta-generalizations"?

Yes, I do believe you are a project manager. How many times this week have you told the customer, "yes, we can do that" before checking with the boys to see if it's actually possible?