Making the Software Business Case: Improvement by the Numbers
For years, I have watched software engineers struggle to justify investments of every kind and examine cost-effectiveness issues. Although they know how to present the technical issues and alternatives crisply and simply, they just can't seem to pull the numbers together. Those who try never seem to paint a convincing picture. While they fumble, the opportunity slips away; or, they are eaten alive as they pitch their ideas because they cannot answer the hard questions posed about costs versus benefits. Typically, such questions revolve around the financials and business justifications. For example, engineers frequently fail to factor in the cost of money and/or tax implications (depreciation, R&D; tax credits, and so on). After considering these, a different course of action might be recommended.Why Write This Book?  The failure of engineers to adequately address the business aspects of decisions has created an opportunity for me throughout my career. I built a profitable business and a national reputation by showing clients how to make the numbers "sing" for management. I have also learned many lessons in the course of these pursuits and have developed many tricks of the trade. These enabled me to repeatedly help clients win "the battle of the budget." The primary purpose of this book is to communicate these lessons to those who need them so that they can take advantage of what I have learned. Because of their importance, I believe that every engineer should be taught how to prepare business cases as part of their education.After thirty 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 once when I projected the results of a productivity analysis to executives. The numbers were so important that the CEO almost fell over backward as the chair he stood on wobbled when he strained to see them. The moral to this story is, independently of whatever else you say, that numbers do the talking for you when executives are in the room.Based on these observations, the primary goal of Making the Software Business Case: Improvement by the Numbers 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 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 within your own work environment. As part of that effort, you will need to figure out what will work at your organization based on the advice offered here.Business cases, typically, are prepared throughout the software development life cycle. Some are prepared along with the business plans that are used to justify new projects and product developments. Others are devised on the spot to justify changes and improvement activities. The focus in this book is on the latter because this kind of business case tends 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 cost/benefits. After you read this book, you will understand how to quantify the numbers; however, using them effectively within your organization will be up to you.   For Whom Is This Book Intended?  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 cost/benefits associated with pursuing them appealing to management in terms of cost savings, reduction in time-to-market, cost avoidance, and/or productivity improvement. Justifying an expenditure, in terms of its return-on-investment, for some good technical idea is just something that they either haven't been taught in their university training or at their first job in the "industry." To sell their ideas, software engineers and managers need to learn how to package them so that the ideas are convincing to management.My underlying assumption is that software engineers will have the task of justifying the improvements that they and their bosses recommend. If this is not the case, don't read any farther. Instead, give the copy of this book to those who need help in preparing business cases. Besides software engineers, I believe that people in the following other positions will benefit from reading 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 technical and business data to justify a variety of purchasing decisions (equipment, tools, training, and so on).Entrepreneurs--Those who package technical ideas in such a way that they stimulate investment by stockholders or venture capitalists.Process group leads--Those seeking to justify continued investment in process improvement (based on 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 of these academic disciplines need to know how to prepare and execute a business case.Researchers--Those doing research who, surprisingly, don't know how to prepare business cases aimed at soliciting industry sponsorship. This book will fill that void and help researchers acquire the support they need to put their ideas into practice.In other words, anyone interested in business cases will get a few pointers from the material presented here, especially in the case studies.What Is in the Book?  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, Making the Software Business Case was written to address software improvements and what you need to do to justify them in terms of their cost/benefits. Yes, it treats the business case, and it also provides you with instructions on how to build one. Plus, it does more. This book provides examples, in the form of case studies, of what it takes to succeed with the business case. Most of these cases are taken from real life. I have, however, embellished those within the text to hide identities and illustrate lessons learned. Improvements in this context 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.If you are looking for a cookbook on business cases, seek other guidance. Cookbooks by their very nature infer that results are repeatable. Put a pinch of this and an ounce of that together and cook them at 400 degrees for ten minutes and a similar result will be generated almost every time. However, the improvement opportunities that I have been associated with even when conducted within similar organizations, are by their very nature, different in almost every case. 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 can be used to gather and present the facts needed to show that your proposals are worth the effort.   What Is a "Business Case"? Within this manuscript, I use the term business case to refer to the materials that you would use, primarily, 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 on the numbers. Topics encompassed within this scope include breakeven, cost effectiveness and cost/benefit analysis. That's where I got the idea for the subtitle: Improvement by the Numbers.  Organization of the Book Table P-1, which will appear in the book, shows you its organization and summarizes the emphasis of each of its nine chapters and three appendices.  The Unifying Glue I use the "goals-question-metrics" framework and the business case development process, which I explain in Chapter 2, as the "glue" to keep this book together. This framework emphasizes the use of quantitative methods throughout software's lifecycle to select the technical improvement options that are under consideration based on their quantitative costs/benefits. It also helps those making improvements identify feasible options based on the organization's real problems, not just the symptoms. This is important because many organizations treat symptoms with action instead of a problem's root causes. Unique Features Addison-Wesley has provided a Web site (awl/cseng/0-201-72887-7) for this book, which will allow me to provide updates and additional resources as they become available. For example, I plan to put a set of more detailed discount tables online 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. In addition, between editions of the book, the site will contain any necessary errata, provide information about changes in technology, and list updates to my available literature. User Roadmap The roadmap in the book's Table P-2 provides suggested reading paths (designated with an "X") for various groups of people. Of course, anyone can read more if you want to. In addition, the materials in the Appendices will be useful as you apply what you've read on the job.0201728877P05082001