Software War Stories

Case Studies in Software Management

Donald J. Reifer

• Publisher: Wiley-IEEE Computer Society Pr
• Year: 2013
• Print ISBN: 9781118650721
• eBook ISBN: 9781118650745
• Edition: 1
• Topic: Computer Science
• Subtopic: Software Development
• Index: Computer Science

A comprehensive, practical book on software management that dispels real-world issues through relevant case studies

Software managers inevitably will meet obstacles while trying to deliver quality products and provide value to customers, often with tight time restrictions. The result: Software War Stories.

This book provides readers with practical advice on how to handle the many issues that can arise as a software project unfolds. It utilizes case studies that focus on what can be done to establish and meet reasonable expectations as they occur in government, industrial, and academic settings. The book also offers important discussions on both traditional and agile methods as well as lean development concepts.

Software War Stories:

• Covers the basics of management as applied to situations ranging from agile projects to large IT projects with infrastructure problems
• Includes coverage of topics ranging from planning, estimating, and organizing to risk and opportunity management
• Uses twelve case studies to communicate lessons learned by the author in practice
• Offers end-of-chapter exercises, sample solutions, and a blog for providing updates and answers to readers' questions

Software War Stories: Case Studies in Software Management mentors practitioners, software engineers, students and more, providing relevant situational examples encountered when managing software projects and organizations.

Chapter 1

Getting Started

Management is doing things right; leadership is doing the right things.

—Peter Drucker

Goals and Scope

This book is about managing software development efforts. By its very nature, management deals with people. It is a difficult job because you have to rely on others to perform the work. To accomplish the task at hand, you have to motivate your staff to do the right job right the first time. The job involves planning, organizing, staffing, directing, and controlling the delivery of complex software products. It requires leadership and teamwork. It requires discipline and organizational skills, as there is a lot to do and not a lot of time to do it. It requires being able to smell out the problems and address them before they have a chance to harm you. Many times, your destiny is shaped by others within enterprises who sometimes have trouble understanding what resources it takes to generate a quality product on budget and schedule. Other times, it involves working within enterprises where software workforces are underappreciated and viewed with distrust. Under such conditions, it is no wonder that such organizations have had a less than stellar success record.

By reading this book, I hope that you will learn what others have done to succeed in developing software even when the environment that they work in is not totally supportive. It is my contention that secrets of software success are known and can be communicated. Seasoned software managers know how to deliver quality products on time and within budget. Many have done it for years. The reason for software's seemingly high failure rate is that many neophyte managers do not put these secrets to work on the job. Sometimes, they cannot because they are just not in control of the factors that drive the development. For instance, if the schedule is driven by some hard deadline, such as a trade show, there is no way to postpone delivery. You either meet the schedule or have to wait for the next year when the promotional opportunity presents itself again. Other times, the people who are assigned to do the job just do not know what to do, when, and under what circumstances. They do not have the experience and have not developed the skills and knowledge needed to succeed at the job. Lastly, the task is difficult in its own right. Building software to aggressive schedules under severe budget constraints is neither for the weak nor the weary. Vigilance, self-control, initiative, and attention to detail are required to ensure that the software product delivered satisfies all the parameters that govern whether or not the development is viewed as successful.

To address these issues, I have written this book. It contains 12 case studies that provide new and experienced managers with pointers on what to do when placed in commonplace situations. It also provides exercises to stimulate the reader to think about what they would do when facing obstacles that can cause the effort to go astray. I deliberately chose the cases to address the most common issues that have plagued software projects in the past. For example, managers may spend a disproportionate amount of time at the beginning of the effort trying to get the requirements right. When this is the case, they often play catch up throughout the project because there just is not enough time and budget left to finish the job right. Based on experience, they might have been better served by developing requirements iteratively using a build-a-little and test-a-little philosophy. This book also focuses attention on management indicators and metrics. By analyzing the data gathered and using these indicators to identify trouble signs early, my hope is that those reading this book will be able to take the corrective actions needed to get back on track in a timely and responsive manner. I also believe that metrics do not lie, and when they indicate that something is amiss, it most surely is because the numbers are truthful.

Understanding the Enterprise

Software permeates just about every organization and enterprise engaged in commerce worldwide. For some firms, packaged software represents their bread and butter. They generate it for sale and it represents their business. For others, software represents an integral part of the information technology (IT) infrastructure that these industrial, government, and academic institutions use to conduct their business. According to Garner Research,* such enterprises will spend an estimated $3.8 trillion in 2012 on such IT services worldwide. These firms use software to help perform their administrative, customer support, human resources, management, marketing and sales, and manufacturing tasks. Most could not operate without it. Take an automobile manufacturing plant as an example. Their production and quality control systems are software driven, as are their inventory control, supplier management, distribution, and customer support systems. Software applications packages handle their payroll and accounting, human resources, travel, and benefits. Additional web-based systems facilitate access to these systems by their customers and employees. It should be noted that not a single aspect of their production process is unaffected by software, including the numerical control machinery, robotic controllers, and automated assembly units used for manufacturing. In addition, the resulting product, the automobile itself, often contains dozens of computers networked together to provide such functions as engine control, entertainment, driver controls and displays, parking assistance, active suspension, diagnostics, and collision avoidance. The world of the automobile and other products has become electronic based, computer controlled, net centric, and software driven.

Yet few automobile executive and plant managers come from a technical background. When you look at the corporate rosters of automobile companies worldwide, most senior managers in the business have marketing and sales, finance and accounting, and/or legal backgrounds. While most of these executives view software expenditures as a just and necessary expense, few understand these outlays well enough to make decisions that can have a profound effect on how either their IT or engineering organizations perform these tasks for the enterprise. One reason for this is that the enterprise's organizational architecture, which governs interactions and information flow, is often neither well designed nor understood. Instead, these executives rely on their chief information officer (CIO) to provide them with counsel and advice. While these executives may delegate the necessary authority to the CIO to run the IT shop, these same managers seem to constantly complain about the expenses and problems that occur when software is late, over budget, does not work, and/or generates incorrect results. They care because for premium automobiles, the cost of software and electronics can represent anywhere from 35% to 40% of the cost of the car.* Luckily for the software staff, the CIO often buffers the software teams from the pressures from above and provides them with room to operate in most industries, such as the automotive field, where electronics and software dominate.

You are probably thinking, “Why should I care whether senior management understands?” You need to be concerned because these people establish the policy infrastructure in which software groups must operate. This infrastructure by its very design creates guidelines for action for software and other groups within these firms. For example, you might have to go up the management chain to get signature after signature to hire a skilled software engineer without a college degree because company policies dictate that a degree is a prerequisite for employment. Yet this new hire may be one of the few people available who can program applications in some archaic language that you are still using in one of your legacy systems. A better approach would have been to delegate such hiring decisions (including the discretion for hiring waivers with justification) to lower tiers of management, especially when they can directly impact the performance of a critical task in the organization.

Review of Software Management Fundamentals

I will not spend any more time on management basics. If you are interested in learning more about management theory, there are lots of good books and articles on the topic, some of which are referenced at the end of this chapter. For those needing more of a refresher, I have included Appendix B, For Your Bookshelf, where I provide some additional recommended readings.

Software management is the act of motivating people to accomplish desired work-related goals and objectives using the resources available in the most efficient and effective manner. Management in such a context involves planning, organizing, staffing, leading or directing, and controlling activities within organizations comprised of groups of people charged with accomplishing a goal. Such goals can be product or service related. Product- or service-related goals can be accomplished via dedicated support teams or project organizations. Services can be rendered on-site or off-site, in person, by telephone, and via the Internet (blogs, websites, etc.). Resources available include people, equipment, facilities, licenses, and operating budgets, including funds set aside for capital expenditures and expenses. Subcontractors and suppliers can be used to augment internal resources so long as they are integrated into the management framework and viewed as part of the team.

Based on this definition, you are probably asking, “How does software management differ from management in general?” The answer is that it does not. It is not the principles that vary, it is the practice. Because software is intangible and hard to quantify, many have difficulty in applying proven concepts in practice as they go about their daily activities.

Most software organizations operate within the policy infrastructure established by their parent firm. They have to in order to survive and prosper. They follow its administrative practices and adhere to the processes and procedures that have been set up to guide accomplishment of just about every task from hiring and firing personnel to procurement and purchasing to fire safety. They take advantage of staff from their centralized accounting, legal, and human resources departments to handle things such as intellectual property concerns, bookkeeping and financial records, and privacy requirements. They guide their interaction with other engineering and support organizations within the firm as each group fights for attention, resources, and support from senior management. Even within firms that sell software products, the software group tends to be the minority, as the combined staff of the marketing, administrative, customer support, and other groups frequently exceeds their numbers by factors of 2 and 3 to 1. Success comes to those software managers who know how to play “the system” and get results.

Many of these firms have set up some form of engineering process group to develop, support, and institutionalize the disciplined use of common organizational software processes, such as requirements and supply chain management across their software and/or engineering organizations. Others have established independent quality assurance organizations whose job is to assess the quality of the software and other engineering products. Some of the quality groups perform independent testing as well. Others coordinate alpha and beta testing with third parties, when applicable. Still others are charged with performing configuration management and change-control duties as well. A variety of options exist as firms seek to combine functions to take advantage of the economies available through centralizing such activities.

Most software developments are managed using traditional project management techniques. Projects in this sense are temporary endeavors with defined start and end points and established objectives. Projects obey a life cycle (e.g., planning, requirements specification, architectural design, product development and test, delivery, distribution, maintenance and enhancement, and retirement), and their development may be ordered using one of many popular development paradigms (waterfall, agile, incremental, iterative, etc.). Projects consume resources (people, equipment, facilities, etc.), and their success and failure can be measured in terms of whether or not they deliver an acceptable product (i.e., one that works and satisfies requirements) that provides value to the user on schedule and within budget.

Some firms perform all of their software development work as projects, while others use functional organizations or centers of excellence to get the job done in a more piecemeal manner. Yet others may use some hybrid approach that employs functional groups to perform projects. The function...

Table of contents

• Cover
• Series page
• Title page
• Copyright page
• Dedication
• Foreword
• Preface
• Chapter 1: Getting Started
• Chapter 2: Industrial Case: Organizing for ERP within a Large Information Technology Shop
• Chapter 3: Industrial Case: What Is a Reasonable Cost and Schedule for a Telecommunications Project Upgrade?
• Chapter 4: Industrial Case: Getting Back on Track Within a Manufacturing Environment
• Chapter 5: Industrial Case: Staff Turnover Having an Impact in Financial Firm
• Chapter 6: Industrial Case: Acquiring Software for Pipeline Operations
• Chapter 7: Industrial Case: Launching Software Applications Sales on the Internet and Social Media
• Chapter 8: Government Case: Managing the Acquisition of a Large Defense Project
• Chapter 9: Government Case: Too Much Governance/Oversight Hinders Progress in Health Care
• Chapter 10: Government Case: New Concepts for Air Traffic Control
• Chapter 11: Government Case: Addressing Cyber Crime on the Internet
• Chapter 12: Academic Case: How Best to Educate Those Entering Industry
• Chapter 13: Academic Case: Research Agendas that Matter to Industry
• Chapter 14: Pulling It All Together
• Appendix A: Acronyms and Glossary of Key Terms
• Appendix B: Recommended Readings, References, and Resources
• Appendix C: Sample Solutions
• Index