I’m participating in a panel discussion on the future of IT education at one of our local business schools this week. I’ve been asked to bring the industry perspective: What do real organizations really need their IT professionals to know?

This discussion has been going on for some time now within both the academic and business communities, and it typically revolves around the question of how much technology knowledge should be taught in the schools versus general business knowledge and management skills. Clearly this is not an either/or question; good IT professionals need both, and everyone knows that. It’s more a question of proportion (how much technology, how much business management) and philosophy (how much theory, how much practice).

It seems to me that the issue of requirements definition and management—whether for system capabilities or for broader sets of project specs—offers some pertinent lessons that may not resolve but at least clarify this debate. For instance, in our cover story, "Fixing the Requirements Mess" on Page 52, Technology Editor Christopher Lindquist reports that 70 percent of software project failure can be attributed to poor requirements management. Seventy percent! That means that if only people were able to agree to what, precisely and minimally, they need a system to do and to stick to it, there would be 70 percent fewer software project failures, even if nothing were done to improve bad code or poor project- or change-management discipline. This is astonishing.

And in "Offshore Allies," Page 74, the second of a three-part series on outsourcing strategies and models, Senior Editor Stephanie Overby reports that 37 percent of co-sourcing arrangements (in which clients and vendors share management responsibilities for application project initiatives) end in failure. According to research jointly conducted by MIT’s Center for Information Systems Research (CISR) and CIO, to be successful in this type of arrangement, each party must play to its strengths (business knowledge on the client side; technical expertise on the part of the vendor), set up the relationship so those capabilities can mesh well, and define the separate contributions of each as clearly as possible without detracting from the collaborative effort. "The lesson I’ve learned with any partner is that being very formal in the communication process and setting expectations clearly up front is paramount to success," says Michael Agnew, managing director of project management at software provider Omgeo. "All throughout the project lifecycle, it should be clear who’s handling what. There needs to be clear accountability."