ISBN-10:
0201728877
ISBN-13:
9780201728873
Pub. Date:
09/19/2001
Publisher:
Addison-Wesley
Making the Software Business Case: Improvement by the Numbers / Edition 1

Making the Software Business Case: Improvement by the Numbers / Edition 1

by Donald J. Reifer

Paperback

View All Available Formats & Editions
Current price is , Original price is $34.99. You
Select a Purchase Option (New Edition)
  • purchase options
    $34.99
  • purchase options

Product Details

ISBN-13: 9780201728873
Publisher: Addison-Wesley
Publication date: 09/19/2001
Series: SEI Software Engineering Series
Edition description: New Edition
Pages: 320
Product dimensions: 7.20(w) x 9.00(h) x 0.80(d)

About the Author

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

Read an Excerpt

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 show that your proposals are worth the effort involved.

What Is a Business Case?

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.

Organization of the Book

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.

The Unifying Glue

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.

Unique Features

Addison-Wesley hosts a Web site at http://www.awl.com/cseng/titles/0-201-72887-7 so that I can provide updates and additional resources as they become available. 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.

User Road Map

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. The first pointer and link that's available for reader's to access is to a "Project Diagnostic Tool and Process Improvement ROI Calculator"—http://www.spc.ca/pisn.

Table of Contents



Foreword.


Preface.


Acknowledgments.

I: FUNDAMENTAL CONCEPTS.


1. Improvement Is Everybody's Business.

Viewing Software as a Business.

Change Is the Nature of Software.

Making the Giant Leap Forward.

Success Is a Numbers Game.

Improvement Cycles and Tricycles.

Improvement by the Numbers.

Business Versus Technical Cases.

Why Change?

Are You Ready to Change?.

Getting Your Boss to Commit.

How This Book Can Help You.

Summary.


2. Making a Business Case.

The Whats, Whys, and Whens of Business Cases.

Relating Improvement Goals to Metrics Via Questions.

Developing Business Cases: The Front-End Process.

Tying the Business Process to the Software Development Life Cycle.

Business Cases: Stepping Through the Life Cycle.

Summary.


3. Making the Business Case: Principles, Rules, and Analysis Tools.

Tooling the Process.

Business Case Principles.

Present Value and Future Worth.

A Smorgasbord of Analysis Techniques.

Tools of the Trade.

Packaging the Business Case for Management Consumption.

Avoiding Taxes and Tax Revolts.

Summary.


4. Business Cases That Make Sense.

The Parable of the Chinese Emperor.

Improving the Process.

Cost Avoidance.

Capitalizing Software.

Quick-to-Market Strategies.

Architecting Products.

Make Versus Buy Analysis.

Moving to a Web-Based Economy.

Summary.

II: THE CASE STUDIES.


5. Playing the Game of Dungeons and Dragons: Process Improvement Case Study.

Setting the Stage.

Current Business Climate.

Developing a Game Plan.

Process Maturity: Are the Investments Justified?.

Quantifying the Return-on-Investment.

Getting Everyone Involved in Playing the Game.

Reinventing and Refreshing the Organization.

Summary.


6. Quantifying the Cost/Benefits: Capitalizing Software Case Study.

You've Got a Problem.

Organization Profile.

Initial Operational Concept.

Capital Decision-Making Process.

Make-Versus-Buy Analysis.

Putting Software Cost Models to Work.

Performing Risk Analyses.

Addressing "What If" Questions.

Making Your Numbers Believable.

Summary.


7. Making Your Numbers Sing: Architecting Case Study.

The Grand Proposal.

Developing a Strategy.

Readying the Financials.

Determining the Numbers.

Trimming the Fat.

Justifying Your Recommendations.

Why Pursue Architecture in the First Place?.

Summary.


8. Maneuvering the Maze: Web-Based Economy Case Study.

For Openers.

Finding a Likely Candidate.

Determining the "Value" of a Firm.

Computing How Much to Pay.

To Buy or Not to Buy.

Avoiding the Traps.

Going Global.

Timing Is Strategy.

Summary.

III: FINALE.


9. Overcoming Adversity: More Than a Pep Talk.

The Wary Traveler.

You Can Be Successful.

Change Tactics Abound.

Avoid the Many Bear Traps.

Focus on the Things That Count.

Other Interesting Uses of Numbers.

Where's the Technology Heading?.

Summary.


Appendix A: Recommended Reading List.

Appendix B: Compound Interest Tables.

Acronyms.

Glossary.

Index. 0201728877T05222001.

Preface

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 show that your proposals are worth the effort involved.

What Is a Business Case?

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.

Organization of the Book

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.

The Unifying Glue

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.

Unique Features

Addison-Wesley hosts a Web site at http://www.awl.com/cseng/titles/0-201-72887-7 so that I can provide updates and additional resources as they become available. 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.

User Road Map

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. The first pointer and link that's available for reader's to access is to a "Project Diagnostic Tool and Process Improvement ROI Calculator"--http://www.spc.ca/pisn.



0201728877P09062001

Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews