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 »
June 17, 11:30 AM - 12:30 PM U.S./ET (GMT-4)
Larry Bonfante, CIO of the U.S. Tennis Association, will discuss the skills and approaches that your rising IT leaders must learn to be effective in an executive capacity.
How to Handle Your New CEO: Managing Turnover at the Top
June 18, 11:00 AM - 12:00 PM U.S./Eastern (GMT-4)
Turbulent times have increased turnover at the top. Find out what Council CIOs have done to "break in" new CEOs—build relationships, set expectations, educate on the role of IT.
Mid-Market CIO Panel: Tips and Techniques for Improving Vendor Relationships
July 15, 4:00 PM - 5:00 PM U.S./Eastern (GMT-4)
We'll highlight relationship priorities and best practices identified in a Council study, and we'll interact with a CIO panel on the approaches they've used to improve strategic vendor partnerships.
Executive Competencies Assessment Tool
Assess Your Business Leadership Skills with the Council's new benchmarking tool. Rate yourself in change leadership, strategy, customer focus and more.
Learn more about the CIO Executive Council »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.