This month we take a break from our focus on IT innovation and its many facets and return to basics. Perhaps one of the most challenging aspects of life in the IT business is the difficulty we often face in selling projects internally to the organization. There are many reasons for this difficulty. In the collective mindset, the "IT guy" is seen as a person with questionable social skills who is much more comfortable in front of a computer than an audience -- especially an executive audience speaking a blend of marketing, finance, and strategy mumbo jumbo.

I am not sure how much truth this stereotype holds. What I am sure of, having spent my life at the intersection of management and engineering schools, is that much less emphasis is placed on communication and business fundamentals in technical programs. IT professionals are excited by the possibilities of technology and are typically doers, not talkers. After all, if it works well and it is efficient (and perhaps elegant), there isn't much to discuss or explain. I love the honesty of engineering and technology.

But the business world is rarely so clear-cut. First, you are often attempting to obtain resources for something that you have yet to build; thus we really don't know if it will work or not. Moreover, a good idea is not a good idea until it exists in the minds of others (particularly decision makers). This sounds a bit philosophical, along the lines of "if a tree falls in the forest and nobody hears it, did it really make noise?" Yet, when proposing a project, it is critical that those who have to approve it "see" the benefits that it will deliver.

Note that like any communication feat, the crafting of a sound argument is first and foremost an act of clear thinking. I was recently asked by a PhD student how I learned to write clearly in English, being that Italian is my mother tongue. After reflecting on the question, I responded that writing clearly is not a matter of grammar or vocabulary -- those come with time and a lot of reading (the kind of massive reading you do in a good PhD program)! But writing clearly is about thinking clearly. If you know exactly what you intend to say, putting it on paper is no problem. The same, in my opinion, holds for any argument designed to garner support and funding for a project. But while in theory this sounds fine, in practice making business cases and having them approved remains one of the greatest challenges IT professionals point to in their work.

Of course, no part of my diatribe above will probably shock or surprise you. You have heard (if not experienced) all this before. As I've said in many of my previous editorials, at CBR we don't just raise issues, we tackle them and try to provide guidance as to how to solve them. It is for this reason that we decided to produce a long overdue issue of CBR on crafting better business cases. Our intent is to evaluate how the organizations in our base of respondents make business cases today; to benchmark the success (or lack thereof); and to provide tangible guidance on improving the quality of your arguments and the odds of receiving approval for the projects that you propose.

Our academic contribution is provided by John Ward and Elizabeth Daniel. John is Professor of Strategic Information Systems at Cranfield University, School of Management (UK). John's main interests are the strategic uses of IS/IT, the integration of IS/IT strategies with business strategies, the development of organizational IS capabilities, and the management of IS/IT investments. Elizabeth is Professor of Information Management and Associate Dean for Research and Enterprise at the Open University Business School (UK). With John, she is coauthor of the book Benefits Management: Delivering Value from IS & IT Investments. She has applied the benefits management ideas in many organizations in both private and public sectors.

The practicing side is contributed by Mike Sisco. Mike is a Senior Consultant with Cutter Consortium's Enterprise Risk Management & Governance and Business-IT Strategies practices. He is also founder of MDE Enterprises, Inc., an IT manager training company whose mission is to provide practical insight and tools to help IT managers of the world achieve more success.

John and Liz provide a very thorough discussion of the role of business cases. They also provide substantial insight, drawing both on the current Cutter survey and previous data they have assembled in their independent research. They classify the respondents in four categories: the underappreciated IT function, the low value-added IT function, the high value-added IT function, and the IT function that is getting away with substandard results. Using this categorization, they draw conclusions as to the value of different behaviors related to the development of business cases, the identification of benefits, the estimation of cost, and post hoc evaluation of the investments. John and Liz's contribution ends with tangible guidance.

Mike begins his contribution by taking the perspective of those who read and approve (or reject) the business cases we write. Based on this evaluation, he identifies some of the biggest challenges we face. With this frame of reference in place, he evaluates the survey results and proposes a set of prerequisites for approval: credibility, trust, and business value. Mike also concludes his piece with a set of tangible guidelines that you can immediately implement.

I am very pleased with this issue, as I think our contributors have been able to go deeper than the standard stuff we read about crafting business cases. I think that this issue of CBR will be one of the best received and will find immediate use in many of our subscribing organizations.