Offering regional and national programs, CIO (and CSO) events bring together some of the most respected names and thought leaders in information technology and security. Presented by CIOs and other senior level executives, these invitation-only programs offer timely topics and strong networking. Learn More »
Public Teleconferences
Join CIO Executive Council members and participate in the following live one-hour teleconferences:
* Transforming IT Teams
September 16
* Global CIOs: How to Lead on the World Stage
September 18
* Social Responsibility's Strategic Benefits
October 29
Apply today for a FREE subscription to CIO Magazine!
July 01, 2001 — CIO —
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 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.
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.
Just the basics, please. Sometimes we all need a refresher or we need to make sure our team and our colleagues are all on the same page.
Over 25 tutorials on everything from business intelligence to virtualization.