Another Kind of IT Project Failure

Scott Rosenberg describes the trials and tribulations of building innovate computer software in his new book “Dreaming in Code” (ISBN 978-1-4000-8246-9). He reports the history of the Chandler project under development by Mitch Kapor’s Open Source Application Foundation. The subtitle of the book gives us a sense of the issues he addresses: “Two dozen programmers, three years, 4,732 bugs and one quest for transcendent software.”

Greenberg observed much of the Chandler project from the inside, sitting in on meetings, discussing issues with the participants, and recording what he heard and learned. It’s a great read, and I commend it to anyone interested in the development of software. (An extensive review appeared in the Chicago Sunday Tribune Book Section on March 4, 2007.)

As the book ends, Chandler is in a pre-release stage. Some modules have been released, but the system is incomplete. As of this writing (March 8, 2007), Chandler’s website – http://chandler.osafoundation.org/ - says “Our goal for our most recent release, 0.7alpha4, is to give a rough sketch of what Chandler will be by our first Preview release (Spring 2007).” So it is still not finished.

As you may know, I have been interested for some time in what causes IT project failures and how to prevent them. [http://www.ghco.biz/publications.htm] My research and consulting has been oriented toward development of information systems by user companies for their own use. “Dreaming in Code” offers us the opportunity to see how my results might apply to the somewhat different world on the shrink wrap developer.

In the course of my research on project failure, I identified seven root causes of project failure, any one of which would cause failure. They are:

1. Incomplete project planning and evaluation


2. Project plan misses non-technical issues


3. Roles and responsibilities of users, senior management, and IT are not well understood and agreed to by al parties.


4. Bad or non-existent communications among interested parties.


5. Inadequate project governance


6. Lack of post audit procedures and project archive.


7. Inconsistent application of good practices.

As I tried to go through the above list item by item to see how each root cause applied to the Chandler project, I had an epiphany. I suddenly realized that the Chandler effort was not a project at all! A project is, after all, an activity with a pre-defined beginning, a pre-defined end and a well-defined work product. It is not clear from the book whether Chandler had a pre-defined beginning; apparently Mitch Kapor simply started it. Certainly there was no pre-defined end. And apparently from the beginning to where they are now, there has been no well-defined product.

The author argues that no IT project has an end because changes are always being made. This, I think, is pernicious nonsense. The concept of project is a management concept, a methodology to get some thing done. The fact that the thing will change later – which almost every thing known to man will do – should not be used as an excuse for never finishing.

Chandler is a research effort, and a badly managed one at that. I spent some years in the chemical process industry. Our company had a 500 person research facility that did primarily applied research, much of it on new chemical engineering processes. We had a well-defined sequence of stages in the development of any new process:

1. Bench top work to see whether the chemistry at the heart of the idea actually worked.


2. A bench top model, in which all the process steps (not just the chemistry) were implemented and joined to one another.


3. Construction of a pilot plant, the smallest possible configuration that could make enough of the product to test.


4. A semi-commercial scale plant, the smallest possible plant that could actually earn a profit.


5. A full scale production plant.

Each of these stages included testing, modifications, retesting, and finally a formal approval to proceed to the next stage.

Chandler started by trying to execute Stage 5, after doing a little Stage 1 work. Is it any wonder that the developers had problems?

All of the old project management clichés apply: If you don’t know where you are going, it doesn’t matter what road you take; If you don’t know where you are going, you will never know when you get there; If you don’t know where you are going …..et cetera, et cetera, et cetera ….

What should Chandler have done in the beginning? It should have been treated as a project, complete with project plan and all the other impedimenta of project management. Such a plan should have identified the research needed to reach the goal, and provided for the execution of this research. Or, don’t even try to build a product until the relevant research is complete.

What should Chandler do now? What they are doing, as reported by Rosenberg: partial releases – which are often called picking the low hanging fruit; stabilize the technology; cut out, for now, anything that cannot be bounded and estimated, and thereafter, stabilize the scope of the project.

<><><><><>