Summary
"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. Highlights include: 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. 0201728877B09102001
Author Biography
Donald J. Reifer is the president of Reifer Consultants, Inc., a firm that specializes in helping clients implement changes that are financially justified. During his more than 30 years of industry and government experience, he has grown businesses, managed major projects, led recovery teams, and implemented improvement strategies globally. Most important, he has helped clients sell change based on the numbers. His numerous other publications include several popular books on software management.
0201728877AB08212001
Table of Contents
Foreword |
|
ix | |
Preface |
|
xi | |
Acknowledgments |
|
xvii | |
PART I FUNDAMENTAL CONCEPTS |
|
1 | (102) |
|
Improvement Is Everybody's Business |
|
|
3 | (28) |
|
Viewing Software as a Business |
|
|
3 | (3) |
|
Change Is the Nature of Software |
|
|
6 | (3) |
|
Making the Giant Leap Forward |
|
|
9 | (4) |
|
Success Is a Numbers Game |
|
|
13 | (2) |
|
Improvement Cycles and Tricycles |
|
|
15 | (3) |
|
Improvement by the Numbers |
|
|
18 | (2) |
|
Business versus Technical Cases |
|
|
20 | (2) |
|
|
22 | (2) |
|
|
24 | (2) |
|
Getting Your Boss to Commit |
|
|
26 | (2) |
|
How This Book Can Help You |
|
|
28 | (1) |
|
|
29 | (2) |
|
|
31 | (22) |
|
The Whats, Whys, and Whens of Business Cases |
|
|
31 | (3) |
|
The Business Case Process |
|
|
34 | (1) |
|
Setting Improvement Goals Using the GQM Paradigm |
|
|
35 | (2) |
|
Developing Business Cases: The Front-End Process |
|
|
37 | (7) |
|
|
38 | (1) |
|
Demonstrate Technical Feasibility |
|
|
39 | (1) |
|
|
39 | (1) |
|
|
40 | (2) |
|
|
42 | (1) |
|
Presell the Idea and Develop Support Base |
|
|
42 | (1) |
|
|
43 | (1) |
|
Putting the Process to Work |
|
|
44 | (1) |
|
Tying the Business Process to the Software Development Life Cycle |
|
|
44 | (3) |
|
Business Cases: Stepping Through the Life Cycle |
|
|
47 | (3) |
|
Life Cycle Objective Milestone |
|
|
47 | (1) |
|
Life Cycle Architecture Milestone |
|
|
48 | (1) |
|
Initial Operational Capability Milestone |
|
|
49 | (1) |
|
|
49 | (1) |
|
|
50 | (3) |
|
Making the Business Case: Principles, Rules, and Analysis Tools |
|
|
53 | (24) |
|
|
53 | (1) |
|
|
54 | (2) |
|
Present Value and Future Worth |
|
|
56 | (3) |
|
A Smorgasbord of Analysis Techniques |
|
|
59 | (7) |
|
|
59 | (1) |
|
Cause-and-Effect Analysis |
|
|
60 | (1) |
|
|
60 | (2) |
|
|
62 | (1) |
|
Investment Opportunity Analysis |
|
|
63 | (1) |
|
|
64 | (1) |
|
|
65 | (1) |
|
|
65 | (1) |
|
|
66 | (1) |
|
|
66 | (4) |
|
Packaging the Business Case for Management Consumption |
|
|
70 | (1) |
|
Avoiding Taxes and Tax Penalties |
|
|
71 | (4) |
|
|
75 | (2) |
|
Business Cases That Make Sense |
|
|
77 | (26) |
|
The Parable of the Chinese Emperor |
|
|
78 | (1) |
|
Process Improvement Using Productivity Increases as a Justification |
|
|
79 | (4) |
|
Cost Avoidance versus Cost Reduction |
|
|
83 | (2) |
|
Software Capitalization Approaches |
|
|
85 | (3) |
|
|
88 | (1) |
|
Quick-to-Market Strategies |
|
|
89 | (3) |
|
Architecting Products Using Time to Market as Justification |
|
|
92 | (3) |
|
|
95 | (1) |
|
Moving to a Web-Based Economy |
|
|
96 | (4) |
|
|
97 | (1) |
|
Concerns Associated with Electronic Commerce |
|
|
97 | (1) |
|
Determining Value of Startups |
|
|
98 | (2) |
|
|
100 | (3) |
PART II THE CASE STUDIES |
|
103 | (132) |
|
Playing the Game of Dungeons and Dragons: Process Improvement Case Study |
|
|
105 | (38) |
|
|
105 | (6) |
|
|
111 | (5) |
|
|
116 | (8) |
|
Start the Process by Involving Stakeholders |
|
|
119 | (1) |
|
Develop a Top-Level Vision and Strategy |
|
|
120 | (1) |
|
Define the Work to Be Performed |
|
|
120 | (3) |
|
|
123 | (1) |
|
Plan to Sell, Sell, and Sell |
|
|
124 | (1) |
|
Process Maturity: Are the Investments Justified? |
|
|
124 | (7) |
|
Accelerating Productivity Gains Through Process |
|
|
125 | (2) |
|
Early Defect Detection and Correction |
|
|
127 | (1) |
|
|
128 | (1) |
|
Movement to Product Lines, Architecture, and Systematic Reuse |
|
|
128 | (3) |
|
Quantifying the Return on Investment |
|
|
131 | (5) |
|
Getting Everyone Involved in Playing the Game |
|
|
136 | (1) |
|
Reinventing and Refreshing the Organization |
|
|
137 | (2) |
|
|
139 | (4) |
|
Quantifying the Costs/Benefits: Capitalizing Software Case Study |
|
|
143 | (34) |
|
|
143 | (4) |
|
|
147 | (3) |
|
Initial Operational Concept |
|
|
150 | (1) |
|
Capital Decision-Making Process |
|
|
151 | (1) |
|
|
152 | (9) |
|
|
153 | (2) |
|
Improved Software Tool Licensing |
|
|
155 | (1) |
|
|
156 | (2) |
|
Equipment Lease or Purchase |
|
|
158 | (3) |
|
Putting Software Cost Models to Work |
|
|
161 | (7) |
|
Step 1: Estimate the Size of the Job |
|
|
164 | (1) |
|
Steps 2--4: Estimate Effort Using COCOMO II |
|
|
165 | (3) |
|
|
168 | (1) |
|
|
168 | (1) |
|
Which Equipment and Tools |
|
|
168 | (1) |
|
Addressing ``What-If'' Questions |
|
|
169 | (3) |
|
Making Your Numbers Believable |
|
|
172 | (2) |
|
|
174 | (3) |
|
Making Your Numbers Sing: Architecting Case Study |
|
|
177 | (32) |
|
|
177 | (7) |
|
|
184 | (4) |
|
|
188 | (4) |
|
|
192 | (7) |
|
WBS 1.0: Architecture Development |
|
|
192 | (2) |
|
WBS 2.0: Education and Training |
|
|
194 | (2) |
|
WBS 3.0: Infrastructure Development |
|
|
196 | (1) |
|
WBS 4.0: Process and Product Development |
|
|
197 | (1) |
|
WBS 5.0: Project Management |
|
|
198 | (1) |
|
|
199 | (2) |
|
Justifying Your Recommendations |
|
|
201 | (5) |
|
Why Pursue Product Lines in the First Place? |
|
|
206 | (1) |
|
|
207 | (2) |
|
Maneuvering the Maze: Web-Based Economy Case Study |
|
|
209 | (26) |
|
|
209 | (3) |
|
Finding a Likely Candidate |
|
|
212 | (5) |
|
Determining the ``Value'' of a Firm |
|
|
217 | (3) |
|
Computing How Much to Pay |
|
|
220 | (6) |
|
|
226 | (2) |
|
|
228 | (3) |
|
|
231 | (1) |
|
|
232 | (1) |
|
|
233 | (2) |
PART III FINALE |
|
235 | (22) |
|
Overcoming Adversity: More Than a Pep Talk |
|
|
237 | (20) |
|
|
237 | (1) |
|
You Too Can Be Successful |
|
|
238 | (3) |
|
|
241 | (3) |
|
|
244 | (1) |
|
Focus on the Things That Count |
|
|
245 | (2) |
|
Other Interesting Uses of Numbers |
|
|
247 | (5) |
|
|
247 | (2) |
|
|
249 | (1) |
|
|
250 | (2) |
|
Where's the Technology Heading? |
|
|
252 | (2) |
|
|
254 | (3) |
Appendix A: Recommended Readings |
|
257 | (8) |
Appendix B: Compound Interest Tables |
|
265 | (4) |
Acronyms |
|
269 | (4) |
Glossary |
|
273 | (10) |
Index |
|
283 | |
Excerpts
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/benefits, which typically involve the financials and business justifications. For example, engineers frequently fail to factor the cost of money and/or tax implications into the consideration (depreciation, R&D tax credits, and so on). If they had examined these considerations, they might have recommended a different course of action. Why Write This Book? 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. 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 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. What''s 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, 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 sh