A generation of projects have come and gone, and almost three-quarters have gone awry. Now, Agile Development is promising nothing less than 100 per cent success.

Reader ROI

- Learn why software disasters continue and why tolerance for them may finally be running out.

- Read about two major project failures and why they went wrong.

- Find out about a new concept called Agile Development.

Everyone knows the rules for managing software projects. You're supposed to test the code. Frequently. You're supposed to take ownership of the process, have a business sponsor and keep an eye on developments. You're supposed to be alert to problems and potholes, and you're supposed to be ready to step in to fix the glitches as they arise. Or kill the project if it looks hopeless.

The only problem is the rules don't help.

In our March "Bugs!" story about companies struggling with poorly written software, we suggested that CIOs frequently test and take ownership of the process. And in this issue, the stories "Projects From Hell", and "The Dirty Half-Dozen", are about software project failures and the lessons they teach: "Test, test and test again", "Ownership is essential" and "Don't let a doomed project run on".

And lest you think this is a relatively recent development, you should know that in 1967, Ken Kolence, cofounder of Boole & Babbage, a pioneering software testing company, published a paper for the first NATO Software Engineering Conference outlining some best practices for the new field of software engineering. It featured instructions on how to test code, assign a manager to own a project and kill projects that were going nowhere.

That's right. The accepted wisdom for managing software development hasn't changed in almost 35 years.

And what has the accepted wisdom achieved?

Not much.