Making the Software Business Case: Improvement by the Numbers [Paperback]

"Just the understanding and insights you will pick up about how people encounter and cope with combinations of technical, social, political, and economic opportunities and challenges make the book a joy to read and worth much more than the price of it alone."
--Barry Boehm, from the Foreword

This practical handbook shows you how to build an effective business case when you need to justify--and persuade management to accept--software change or improvement. Based on real-world scenarios, the book covers the most common situations in which business case analyses are required and explains specific techniques that have proved successful in practice. Drawing on years of experience in winning the "battle of the budget," the author shows you how to use commonly accepted engineering economic arguments to make your numbers "sing" to management.

The book provides examples of successful business cases; along the way, tables, tools, facts, figures, and metrics guide you through the entire analytic process. Writing in a concise and witty style, the author makes this valuable guidance accessible to every software engineer, manager, and IT professional.

• How and where business case analyses fit into the software and IT life cycle process
• Explanations of the most common tools for business case analysis, such as present-value, return-on-investment, break-even, and cost/benefit calculation
• Tying the business process to the software development life cycle
• Packaging the business case for management consumption
• Frameworks and guidelines for justifying IT productivity, quality, and delivery cycle improvement strategies
• Case studies for applying appropriate decision situations to software process improvement
• Strategic guidelines for various business case analyses

With this book in hand, you will find the facts, examples, hard data, and case studies needed for preparing your own winning business cases in today's complex software environment.

The failure of engineers to adequately address the business aspects of decisions has created opportunities for me throughout my career. I have built a profitable business and a national reputation by showing my clients how to make the numbers sing for management. I have also learned many lessons and developed many tricks of the trade, which have enabled me to repeatedly help my clients win the battle of budget. The primary purpose of this book is to communicate these lessons to other people who need them so that they can take advantage of what I've learned. Because of their importance, I believe that every engineer should be taught how to prepare business cases as part of their undergraduate and graduate education.

After 30 years in the field, I have an endless supply of case studies that I can use to illustrate why this important topic needs to be taught to everyone involved in an organization, from the top executive to a new recruit. For example, can you envision the CEO of a major international firm standing on a chair to see the charts from the back of the room? That's exactly what happened when I projected the results of a productivity analysis to executives. The numbers were so important to the CEO that he almost fell over backward as the chair he stood on wobbled in his effort to see them. The moral of this story is that, independently of whatever you say, your numbers will do your talking for you when executives are in the room.

The primary goal of this book is to help you understand how to develop a successful business case. To help you learn, I present principles and case studies. Because of its importance, the book focuses attention on the process of business case development, not the case itself. After reading the book, your task is to generalize and apply what you have learned in your own work environment. As part of this effort, you will have to figure out what will work for you and adapt the advice offered accordingly.

Business cases are typically prepared throughout the software development life cycle. Some are prepared along with the business plans used to justify new projects and product developments. Others are devised on the spot to justify changes and improvement activities. My focus in the book is on the latter because they tend to be the most difficult to pull off. Because such initiatives ask for money, the expenditures involved must be justified quantitatively in terms of the costs/benefits. When you finish this book, you will understand how to quantify the numbers. But using them effectively in your organization will be up to you.

I wrote this book primarily for software engineers and managers, who frequently don't seem to have the foggiest idea of what it takes to prepare a business case. They may have great technical ideas, but most find it difficult to package the concepts to make the costs/benefits associated with pursuing them appealing to management. To do this, they need to highlight the cost savings, reduction in time to market, cost avoidance, and/or productivity improvement. Justifying expenditures for some good technical idea in terms of its return on investment is something that they haven't been taught in their university training or their opening stint in industry. To sell their ideas, they need to learn how to package them so that they are convincing to management.

My underlying assumption is that software engineers will be tasked to justify the improvements that they and their bosses recommend. If this is not the case, don't read any further. Instead, give your copy of this book to someone who needs help in preparing business cases.

As well as software engineers, I think people in the following positions could benefit from this book:

• Managers and executives: Those who act as sponsors and champions of a change when they're convinced that it has both technical and business merits
• Buyers of products and services: Those who use the technical and business data presented to justify a variety of purchasing decisions (equipment, tools, training, and so on)
• Entrepreneurs: Those who package the technical ideas in such a way that they stimulate investment by stockholders or venture capitalists
• Process group leaders: Those who seek to justify continued investment in process improvement (based on the returns, competitive reasons, and so on)
• Programmers: Those who use the architectures, processes, tools, and techniques that software engineers generate or select to develop and/or maintain software products and systems
• Students: Those pursuing undergraduate or graduate degrees in either computer science or information management. Both have a need for a book that shows them how to prepare and execute a business case.
• Researchers: Surprisingly, many researchers don't know how to prepare business cases aimed at soliciting industry sponsorship. This book will help them acquire the support they need to put their ideas into practice.

In other words, anyone interested in the topic could get a few pointers from the material presented, especially in the case studies.

If you are looking for a general-purpose textbook on business plans and cases, look elsewhere. This book isn't written for you. There are general management textbooks on the subject that will address your need for structure and guidance. Instead, this book addresses software improvements and what you need to do to justify them in terms of their costs/benefits. Yes, it treats the business case and provides instructions on how to build one. But it also provides examples of what it takes to succeed with the business case in the form of case studies. Most of these cases are taken from real life; I've embellished them to hide identities and illustrate lessons learned. However, software improvements involve more than just process. They might entail justifying capital investments, moving to product line architectures, or valuing the purchase price to be paid for a firm.

This is not a cookbook on business cases. Cookbooks by their nature infer that results are repeatable. Put a pinch of this and an ounce of that together and bake the mixture at 400 degrees for 10 minutes and a similar result will be generated almost every time. However, the improvement opportunities I've been associated with, even when conducted within similar organizations, are by their nature different almost every time. That's because there are so many factors involved that it is almost impossible to develop a generic formula for improvement. In response, I provide a process framework, not recipes, for making improvements.

The underlying message of this book is that there needs to be some compelling reason for making organizational changes or proposed improvements. Otherwise, why pursue them? Within this context, business cases are used to gather and present the facts needed to show that your proposals are worth the effort involved.

In this book, I use the term business case to refer to the materials you would use to show decision makers that the idea under consideration is a good one and that the numbers that surround it make financial sense. The focus is primarily on the numbers. Topics encompassed include breakeven, cost effectiveness, and cost/benefit analysis. That's where I got the idea for the subtitle, Improvement by the Numbers.

The table on page xv shows you the organization of the book and summarizes the emphasis provided in each of its nine chapters and two appendices.

I use the Goals-Question-Metrics framework and the business case development process that I explain in Chapter 2 as the glue to hold this book together. This framework emphasizes the use of quantitative methods throughout the software life cycle to select technical improvement options under consideration by their quantitative costs/benefits. It also helps those making improvements to identify the feasible options that will solve the organization's real problems, not the symptoms. This is important because many organizations treat the symptoms, instead of the root causes of their problem, with action.For example, I plan to put a set of more detailed discount tables on line so that you can use them to compute present value and future worth of money. If I have the time and energy, I will put these tools on the Web site in spreadsheet format. I also plan to use the site to address errata, identify changes in technology, and update the Recommended Readings list between editions of this book. Please feel free to recommend improvements to the book and/or the site via e-mail (dreifer@earthlink.net). I want you to use it as a resource to help build business cases.

The table on page xvi of the book provides you with a suggested reading road map through the book. An X designates chapters I suggest various individuals read. Of course, read more if you want to. Use the materials at the back of the book as you apply what you have read to projects you're working on.