The only problem is the rules don’t help.

In our Jan. 15 "Bugs!" story about companies struggling with poorly written software, we suggested that CIOs frequently test and take ownership of the process. The year before, CIO ran "Another Trip to Hell" (Feb. 15, 2000), and about a year before that we published "To Hell and Back" (Dec. 1, 1998)?both stories 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.

We Begin with a Litany of Failures

A landmark 1994 white paper, "The Chaos Study," published by The Standish Group, a West Yarmouth, Mass.-based consultancy, reported that just 16 percent of software projects succeed. The rest either failed (31 percent) or were challenged (53 percent)?a term encompassing cost and time overruns and missing features.

Standish turned "Chaos" into a longitudinal study, collecting case studies (30,000 and counting) and each year publishing success, failure and challenge rates. Its 2000 report, "Chaos in the New Millennium," is about as encouraging as its cover art, which includes the grim reaper rising through clouds, brandishing his scythe.

Outright failures, Standish reported, have declined from 40 percent to 23 percent during the past five years, but challenged projects swelled from 33 percent to 49 percent in the same period. That’s bad because challenged projects often are more painful than projects that simply fail, like peeling off a bandage slowly instead of quickly. And they’re often just failures-in-waiting, dallying dismally until the patience (or the money) for getting them right runs out.