Rating: 
Summary: Practical Advice and Useful Examples!
Review: Don Reifer's book provides information not found in existing books on software engineering, process improvement, and project management. His primary audience is technical people who must sell a project to business people. In particular, he provides concrete, practical advice for selling a process improvement program. For example, Chapter 4 stresses the importance of focusing on cost avoidance instead of cost reduction to justify improvements. In Chapter 7 he suggests briefing middle managers individually to obtain their support. Based on my experience, this is sound advice because middle managers are often the most difficult people to convince in an organization. Giving personal attention to each manager pays big dividends later. He also suggests taking advantage of state tax laws to partially offset the costs of training employees. This is a win-win strategy for both the firm and the state. Training gives employees new skills and improves retention. This, in turn, helps the firm obtain more business and so generate more income for the local economy and more tax revenues for the state. He explains the difference between project and capital funds, and how to exploit this difference to obtain the resources you need. The book has many useful checklists. For example, one identifies the types and sources of information needed to prepare a business case. Another identifies the critical items to check when deciding to acquire a business.His book will also be of interest to marketing people who are preparing sales presentations for complicated technical products. For example, these individuals could prepare business cases to compare possible alternatives. Even experienced managers unfamiliar with software products and process improvement will find the case studies useful. Don Reifer illustrates the concepts presented in Part 1 with actual case studies in Part 2. These are based on his 30+ years of experience in the software field. The case study in Chapter 7 begins with what amounts to an engineering view of the problem and then the author provides comments indicating how a manager would like to see the information presented. This case study really shows the contrast between the technical and management ways of thinking. The case study in Chapter 8 shows how to assess the value of a company whose primary assets are intellectual property and knowledge capital. Overall, the book is concise and well written. I was able to quickly absorb the concepts and techniques without spending a lot of time. It is a valuable addition to my reference shelf.
Rating:
Summary: Practical Advice and Useful Examples!
Review: Don Reifer's book provides information not found in existing books on software engineering, process improvement, and project management. His primary audience is technical people who must sell a project to business people. In particular, he provides concrete, practical advice for selling a process improvement program. For example, Chapter 4 stresses the importance of focusing on cost avoidance instead of cost reduction to justify improvements. In Chapter 7 he suggests briefing middle managers individually to obtain their support. Based on my experience, this is sound advice because middle managers are often the most difficult people to convince in an organization. Giving personal attention to each manager pays big dividends later. He also suggests taking advantage of state tax laws to partially offset the costs of training employees. This is a win-win strategy for both the firm and the state. Training gives employees new skills and improves retention. This, in turn, helps the firm obtain more business and so generate more income for the local economy and more tax revenues for the state. He explains the difference between project and capital funds, and how to exploit this difference to obtain the resources you need. The book has many useful checklists. For example, one identifies the types and sources of information needed to prepare a business case. Another identifies the critical items to check when deciding to acquire a business. His book will also be of interest to marketing people who are preparing sales presentations for complicated technical products. For example, these individuals could prepare business cases to compare possible alternatives. Even experienced managers unfamiliar with software products and process improvement will find the case studies useful. Don Reifer illustrates the concepts presented in Part 1 with actual case studies in Part 2. These are based on his 30+ years of experience in the software field. The case study in Chapter 7 begins with what amounts to an engineering view of the problem and then the author provides comments indicating how a manager would like to see the information presented. This case study really shows the contrast between the technical and management ways of thinking. The case study in Chapter 8 shows how to assess the value of a company whose primary assets are intellectual property and knowledge capital. Overall, the book is concise and well written. I was able to quickly absorb the concepts and techniques without spending a lot of time. It is a valuable addition to my reference shelf.
Rating:
Summary: What it takes to make it happen...
Review: How many of us in software engineering know what it takes to sell an idea to people with no software development or software project management experience? How many of use know how to evaluate whether it makes financial sense to continue with a project. The software engineering community is continuously working to improve methodologies, algorithms, tools, etc. and has long ignored what has to happen to get and keep great ideas or innovations funded. I recommend this book because it addresses this important need. As stated in the book "A business case shows that the idea being considered is a good one and that the numbers that surround it make financial sense." The book lays out creating a business case in an easy to read style. However, don't be fooled by the easy reading, the author writes of what, in my experience, really has to happen to make a successful business case and some of it takes hard work. If you follow Reifer's process (depending on the business case type) you will be able to see the financial advantages of your proposal. In addition to explaining the "in's and out's" of developing business cases, the book is loaded with references for further information. If you don't know how to develop a software engineering business case - get started with this book!
Rating:
Summary: Much-needed insights
Review: Making the Software Business Case: Improvement by the Numbers covers an area too few software engineers have any exposure to: financial modeling and business analysis, as it relates to the IT domain. Reifer's concise (300 page) book provides a broad overview of how the IT area appears from the business side, including critical material on how to frame technical proposals in business terms. Amongst the many nuggets to be found in this book are: ·useful tips on where money can be found
·good insights into the politics of proposals and budgeting
·getting middle management buy-in
·countering executive challenges
·successful management of cross-project initiative dynamics
·software capitalization/depreciation
·Discussion of reuse from a cost avoidance perspective. This book is not only good in terms of its material, it is also an eminently readable book in terms of style. Reifer elaborates his argument through the clever use of case studies that provide human interest and momentum to otherwise dry material. These case studies include: ·A defense contracting firm implementing software process improvement
·A public utility replacing an outdated mainframe-based transactional system with modern client-server technology
·An industrial controls firm suffering from moribund products
·A firm seeking to Internet-enable its internal systems Reifert places strong emphasis on "making your numbers believable." He argues that this believability must address these nontechnical considerations:
·Cash flow
·Cost basis
·Cost/benefit
·Estimate fidelity
·Present value
·Profit and loss
·Risks
·Source of funds
·Tax implications He does an admirable job in placing these concepts in context, and providing a clear overview of each.
The utility case study demonstrates the importance of understanding the overall financial dynamics affecting one's enterprise. For example, the differences between capital and expense budgets can be key in determining whether to purchase or lease equipment. As Reifert elaborates in the utility scenario, "Because this has been a profitable year, an increase in expenses [i.e. leasing as opposed to purchase capital expenditures] could have a profound positive tax consequence." The book has many examples of this type of valuable, integrated business insight. Reifer has much sound general IT management advice mixed in with his financial message. A recurring theme through many of the discussions is the need for an executive sponsor, to provide political cover and tactical advice in forwarding the business case. He also urges the reader to frame benefits in terms of cost avoidance rather than cost reduction-promising cost reductions often lead to the question, "OK, then who are we going to let go?" Not a good way to win friends. I found his observations on the subject of central process quality assurance groups interesting: "Reinventing staff organizations such as process and quality assurance groups is a good idea. Engineers assigned to such staff groups get stale once they've put in more than three years of service. Being in an audit and support role, they forget how hard it is to develop and deliver quality products under extreme deadline pressures." (p 137). The book displays a continual awareness of the need to balance these contending issues of cost, schedule, and quality. The case study based on the industrial controls firm has an explicit architectural theme. This is an especially compelling discussion; software engineers are well aware how critical architectural decisions are, and how often they are compromised in the rush to write code. The discussion demonstrates how to make the case for architecture and include it in an overall work breakdown structure. Reifert is exceptionally creative in his case study creation, taking the opportunity to demonstrate hidden agendas, the pitfalls of contractor estimates, and developing a good working relationship with high-level consultants. The book provides a solid summary of software estimation. There are whole books written on this subject, so the chapter is necessarily at a high level (although it does dive into some detail on the COCOMO II model in particular). However, it provides a valuable discussion of aspects of high-level IT budgeting beyond tactical project estimation, presenting numerous examples of cost breakdowns covering all phases of the systems development lifecycle, from architecture to maintenance. The final case study moves into even more adventurous ground, discussing a company seeking to Internet-enable its internal systems via takeover (hostile if necessary) of a specialist firm. The ensuing narrative outlines the due diligence such a move requires, and the various tactical and strategic issues it may raise. A brief discussion of international intercultural relationships is excellent. The book has only one minor flaw: it was obviously written during the dot-com bubble. There are frequent references to industry dynamics such as a venture-funded firm's survival depending on extreme time-to-market pressures, and perhaps an overemphasis on faddish Web technology. This book is easily on my Top 10 software engineering book list. It provides a lucid, crisp overview of business issues that are all too mysterious to the average software engineer. Given the potential that well-architected, business-responsive software has to increase productivity, this volume is a service to both the software engineers and the enterprises that employ them.
Rating:
Summary: Well written, sensible and effective
Review: There are two books on business case development that have deeply influenced my thinking: this one and "IT Investment: Making a Business Case" by Dan Remenyi. Each book has a different focus. If your goal is to develop business cases to support procurement or development of large scale systems or strategic initiatives, Mr. Remenyi's book is better suited to your needs. However, if you are managing the incremental development or implementation of systems, or adding functionality and features to existing systems (or infrastructure), justifying tools and other similar activities, this book is better suited to your needs. What sets this book apart? First, the author focuses on tactical business cases, which are typically abbreviated. Unfortunately, they are also typically a morass of disjointed thoughts that are not backed up with numbers that the decision makers neither understand or consider relevant. He provides you with a focus and a solid foundation of what a business case needs to address. Second, instead of trying to teach business 101, the author provides you with some the basic principles and tools for developing a business case that you can sell to the folks who write the checks (a.k.a. "bean counters"). Third, and [in my opinion] most importantly, you are provided with a strategy for "selling" your business case by ensuring that it contains sensible assumptions, is linked to goals. Also, in keeping with the tactical nature of the business case approach it's also tied to life cycle stages. Among the parts of the book that I most like are: (1) development of the business case incorporates traceability - the author uses goal-question-metric as the framework, which is easily recognizable to business managers since it aligns nicely to objective-critical success factor-key performance indicator. (2) The case studies in Section II give you some real life examples of common scenarios. You can learn as much from the business cases as you can from the preceding discussions of concepts and techniques. This book represents a valuable resource that will augment your technical skills with some sound business skills. The book is clearly written and filled with both excellent advice and common sense. It is also written by someone who understands the technical professional's and business viewpoints, and imparts that understanding with great skill.
Rating:
Summary: A must have book for your IT Bookshelf
Review: This book is for anyone who wants to look good in an efficient fashion. To my mind that means knowing where to find good ideas, which you can reuse easily. This book is packed with examples that any software professional can take advantage of. The simple but complete explanation of the Goal Question Metrics approach is a fine example (page 36). For those of use without the benefits of an MBA it provides a solid basis to develop a business case that your boss will love in chapters 2 and 3. There are two books in my collection that I go back to again and again (Software Engineering Economics by Barry Boehm and Applied Software Measurement by Capers Jones. I have just added a third book to that list, Making the Software Business Case by Don Reifer.
Rating:
Summary: A must have book for your IT Bookshelf
Review: This book is for anyone who wants to look good in an efficient fashion. To my mind that means knowing where to find good ideas, which you can reuse easily. This book is packed with examples that any software professional can take advantage of. The simple but complete explanation of the Goal Question Metrics approach is a fine example (page 36). For those of use without the benefits of an MBA it provides a solid basis to develop a business case that your boss will love in chapters 2 and 3. There are two books in my collection that I go back to again and again (Software Engineering Economics by Barry Boehm and Applied Software Measurement by Capers Jones. I have just added a third book to that list, Making the Software Business Case by Don Reifer.
Rating:
Summary: Excellent approach that will work
Review: This book is the aggregation of Mr. Reifer's extensive experience in software management and economics of reuse. His earlier books, "Practical Software Reuse" (ISBN 0471578533), and "Software Management" (ISBN 0769511007) evidence his experience, and probably account for the realistic approach he takes in this book. Despite his technical background he takes a business-focused approach early in this book by explaining the difference between business and technical cases. Too many technical managers confuse the two, and this plus the other material in Chapter 1 explaining the fundamentals of business cases will set you on the right course. Chapter 2 is the essence of this book, with advice on relating goals to metrics (using the Goal/Question/Metric technique), and the development and alignment of business cases to development life cycles. This is followed by two excellent chapters covering principles, rules, and analysis tools, and strategies. Much of this material is standard fare, but Mr. Reifer's clear explanations are better than most books that cover this material. The second part of the book employs case studies that lead you through the development of a business case using principles, concepts and techniques given in the first part of the book. These reinforce part one of the book, as well as provide clear examples of business cases that work, and the process with which to develop them - including challenges, how assumptions were derived, and other nuances of which you should be aware. The final part of the book is a single chapter on overcoming major barriers, and the sage advice is well worth heeding. Overall, this is one of the best books on business case development because it is business-oriented, has an approach that is financially and tactically sound, and is written for technical-oriented managers in their own language.
Rating:
Summary: Excellent approach that will work
Review: This book is the aggregation of Mr. Reifer's extensive experience in software management and economics of reuse. His earlier books, "Practical Software Reuse" (ISBN 0471578533), and "Software Management" (ISBN 0769511007) evidence his experience, and probably account for the realistic approach he takes in this book. Despite his technical background he takes a business-focused approach early in this book by explaining the difference between business and technical cases. Too many technical managers confuse the two, and this plus the other material in Chapter 1 explaining the fundamentals of business cases will set you on the right course. Chapter 2 is the essence of this book, with advice on relating goals to metrics (using the Goal/Question/Metric technique), and the development and alignment of business cases to development life cycles. This is followed by two excellent chapters covering principles, rules, and analysis tools, and strategies. Much of this material is standard fare, but Mr. Reifer's clear explanations are better than most books that cover this material. The second part of the book employs case studies that lead you through the development of a business case using principles, concepts and techniques given in the first part of the book. These reinforce part one of the book, as well as provide clear examples of business cases that work, and the process with which to develop them - including challenges, how assumptions were derived, and other nuances of which you should be aware. The final part of the book is a single chapter on overcoming major barriers, and the sage advice is well worth heeding. Overall, this is one of the best books on business case development because it is business-oriented, has an approach that is financially and tactically sound, and is written for technical-oriented managers in their own language.
Rating:
Summary: The bean-counter skills needed to get a project funded
Review: This is not a book for software developers or managers who work in a small shop where there is focused development, little formal bureaucracy and a great deal of camaraderie. It is written for the person with responsibility in a large organization who has an idea for a major new project and needs to get it approved. Essentially, it tells you how to survive and thrive in a large organization that builds software.
The advice is fairly simple but quite accurate. Use numbers in your presentation that can be justified and are consistent with any previous numbers that relate to the project. Have solid data concerning the expected return-on-investment (ROI) from the project as well as any additional costs that may not be outwardly obvious. Quite accurately, the author is emphatic about the principles of present and future value. So much so that appendix B is just a set of basic compound interest tables. This is the most important advice that anyone in a large organization with a business case to plead can ever receive.
A lesser, but still critical point is that you must have a manager to champion your proposal through the managerial hierarchy. That champion must also know the expected ROI from the project very well, as upper echelons will consider a lack of knowledge on the part of the champion to reflect a lack of interest. Another point to reckon with is that if you receive the budgetary increase, it most likely means that someone else in your organization had theirs cut. Nasty, but also the way things are.
Finally, the author takes you through a case study as to when you should acquire a company rather than build a new internal division from scratch. His analysis of what to examine and consider significant is a solid strategy for determining which is the better option.
This is a book that really has two audiences, those who are lower level managers in large organizations with an idea for a new project and those who are starting a company and need to convince the people with the money to open their wallets. For them, it is priceless, but for all others it is difficult to see where they will find it of value.
| 
