Crazy talk

I'm not necessarily the world's biggest Dilbert fan, but one Dilbert cartoon I saw recently really hits the nail on the head in describing the often tenuous relationship of IT to business in day-to-day software projects. In this cartoon, Dilbert says to one of the business guys:  "I'll design the system as soon as you give me the user requirements." The business guy replies, "Better yet, you could build the system, then I'll tell your boss that it doesn't meet my needs." Dilbert replies, "I don't mean to frighten you, but you'll have to do some actual work," to which the business guy quickly replies: "That's crazy talk." I laughed at this -- just before I remembered all the times this scenario has played out in one form or another in my own career.

The Dilbert cartoon was included as part of a talk on "requirements engineering" that one of the InfoWorld CTO Advisory Council members, Igor Shindel, gave to a group of about 30 CTOs at the monthly New York City CTO Club breakfast in early October. As a former CTO and consultant with his firm Result Architects, Shindel advises clients on strategic technology decisions, and in this case, provided me with all the data points you see in the rest of this column. Specifically, "requirements engineering" is one of the disciplines of the RUP (Rational Unified Process), a structured framework for managing the software development life cycle.  If you map it to XP (Extreme Programming), requirements engineering might be analogous to "release planning," but regardless of the specific approach, dealing with requirements is all about involving end-users in some structured way to give you a sense of what they need and then executing on those needs within some set of constraints involving time, people, and money. The only problem is that it's not even close to being that simple. In his book Applied Software Measurement: Assuring Productivity and Quality, Capers Jones asserts that 75 percent of enterprises are deficient when it comes to requirements engineering -- and remember, that's only the beginning of the process.

According to the well-known Standish Group CHAOS Chronicles (published in 1995 but still as relevant as ever in my opinion), only 16.2 percent of software development projects finish on-time and on-budget, 52.7 percent of projects end up costing an average of 189 percent of their original estimates, and nearly one-third (31.1 percent) are simply cancelled. The Standish Group found that the top three success factors for software projects were: user involvement, executive management support, and clear statement of requirements.