Consulting Journal: Methods - Cooking the elephant

Methods: Cooking the elephant

by David Blakey

The difference between eating an elephant and cooking an elephant.

[Monday 19 November 2007]

I am continually surprised that some people find simple concepts quite difficult to understand.

I spoke to a project manager a while ago about the large IT project he was working on. The conversation went something like this.

David:	Is the project being developed in phases?
PM:	Yes. We develop and test each core module before we start work on the modules that depend on it.
David:	So the users are getting phased deliverables?
PM:	In some ways. Some of the core modules just support other modules. They provide functionality but might not produce an output.
David:	So have the users seen any deliverables?
PM:	The users on the project team have, because they're involved with testing each module. So they've seen the prototypes.
David:	Prototypes?
PM:	Yes. We have to be sure that the core modules are working, so we build prototypes of the user modules that sit on top of them.
David:	And these prototypes work?
PM:	Yes. They don't have all the validity checking and they don't use the presentation layer, but, yes, they do work.
David:	And when will the presentation layer be available?
PM:	About [18 months from now].

I did not ask him if he knew how to eat an elephant. He would probably have replied One bite at a time without understanding what that really meant.

That project is typical of many. The developers write code that performs basic functions, then they write code that performs the main functions, and then finally they write code that will allow users to interact with all the other code. The managers of these projects probably think that they are eating the elephant one bite at a time.

If you want a new analogy, what these developers are actually doing is cooking the elephant. They have chopped the elephant up into bite-size pieces. They now cook all the bite-size pieces. When they have finished doing that, they will call in the diners, point to an enormous pile of cooked pieces and say There you go. You can eat your elephant.

The diners will still be confronted by something that is the size of the elephant. It will still be hard work to eat it all.

If the elephant has not been cooked to their taste, it will be difficult to correct that.

The original analogy is of eating, rather than cooking, the elephant, and the distinction is important. To eat an elephant, you have to cook and eat one bite at a time. Cook and eat a bite. Cook and eat another bite.

Of course many of these projects fail. They continue to use resources without presenting any tangible results to their users. Users lose interest, there are no tangible outputs, and the sponsors start to question where their money is going. The planning of these projects should be changed so that users start to get products early and continue to get products. If that means going back and changing the core layers of the project as new functions are added, then that is how the project needs to defined.

[ List articles on Methods ] [ View printable version ]