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.
Looking back at the Dilbert cartoon in this light, Dilbert is on the road to getting totally screwed, but he doesn’t have to be. First of all, Dilbert made a mistake by not involving a senior IT person with real authority and organizational competence (both of which are in short supply in his world, of course), who could reinforce his requests and presumably involve a more senior person on the business side than the snarky cube dweller with whom he is working. Secondly, Dilbert clearly needs to work on his relationship with the person on the business side — the business guy has already scapegoated Dilbert before the project has even started. Lastly, Dilbert does a poor job of explaining why requirements gathering and user involvement are even necessary, and instead demands that they be done while questioning the work ethic of the business guy. He needs to arm himself with data; errors are five to ten times less expensive to correct during the requirements phase than during the coding phase, and errors in the requirements phase can ultimately consume 25 percent to 40 percent of total project budget.
That’s not “crazy talk” — it’s just good business sense.
