Software Management
By Donald J. Reifer John Wiley & Sons
ISBN: 0-7695-1100-7
Chapter One
Introduction Under any social order from now to Utopia a management is indispensable and all enduring ... the question is not "Will there be a management elite?" but "What sort of elite will it be?" -Sidney Webb
Overview
The four papers selected for this introductory chapter provide insights into the concerns and challenges associated with software management and the framework composed to study ways to deal with them. Although each paper makes a unique point, most were selected because they searched for the root causes to what many of us in the industry have called "the software crisis." All too often, managers tend to treat the symptoms and not the root causes of their problems. They then use "gut feel" instead of "hard" data to develop a "quick fix" to the dilemma. For example, a manager might try to tie task progress to an impossible schedule when his group is falling behind instead of trying to convince the boss that rescheduling based on more realistic goals is a better option. The manager may not realize that rescheduling doesn't mean the end date has to change. In addition to permitting workers to dedicate more time and effort to the tasks that are causing the delays, rescheduling will allow them to refocus their resources and take advantage of opportunities to perform other tasks that are not on the critical path in parallel.
The papers included in this chapter were selected to provide you with help in figuring out the root causes of your problems. All too often, we treat the symptom because we don't know or can't figure out what the real root cause of the problem is. In the rescheduling example above, is progress behind because the people aren't productive enough, the task is tougher to perform than expected, or the original schedule was overly optimistic? These are difficult questions. To develop answers, I have selected papers that establish frameworks to help you understand how different software process, product, and people considerations relate to each other and the many life cycle management options that are available for use today. These frameworks are important because they establish a foundation that we will build on and reference in later chapters in this tutorial.
Article Summaries
Software Management's Seven Deadly Sins, Donald J. Reifer, pp. 5-8
This is a reprint of an editorial I wrote for IEEE Software magazine about my reflections on the state of software and software management worldwide. The paper summarizes the results of a straw poll of experts from 20 organizations who identified what they believed were the major problems when it came to managing software. What is surprising about the results is that they reflect problems that have been haunting software managers for the past 20 years. The seven sins include volatile requirements, poor planning, unrealistic schedules and budgets, inadequate controls, undercapitalization, the "we're different" syndrome, and lack of focus on quality. Read on if you are interested in reflections on what we've learned during the past two decades.
Principles of Software Engineering Project Management, Donald J. Reifer, pp. 9-15
I wrote this article to serve as an introduction to this tutorial The article reinforces the message that software can be managed using classical project management approaches. It ties chapters together and provides you with a road map through this tutorial. The paper has been rewritten for this volume to reflect the state of the practice of software management and the current content of this volume. The paper's findings, conclusions, and recommendations are presented as principles that you can use to guide your management actions. These principles have not changed much during the past decade. They provide you with basic truths or rules by which to manage software.
The "3P's" of Software Management, Donald J. Reifer, pp. 17-23
This paper communicates principles devised to improve how we address what I call the "3P's" of software management (i.e., the processes we use, the products we generate, and the people who perform the work on our software projects). The paper has been rewritten to show more clearly how these three important factors are related to one another and the methods, tools, and techniques that we use for software project management. My hypothesis in the paper if that you can increase your chances of success on a software project by reducing the conflicts that arise between the "3P's." Such conflicts arise as the factors take on different levels of importance as a project unfolds.
Critical Success Factor in Software Projects, John S. Reel, pp. 25-30
This excellent article looks at the things you can do on a software project to increase its chances of success. It suggests that you start off on the right foot by setting realistic objectives and expectations for those working on the project. Then it recommends that you focus on building the team by carefully selecting the members and furnishing them with what they need to get the job done. To maintain your momentum, the paper recommends that you focus on tracking progress, keeping attrition low, and gathering the "hard" data required to make smart decisions. The paper concludes by suggesting that you put a postmortem process in place that allows you to learn from your mistakes.
Key Terms
For those worried about terminology, I have include an updated and expanded glossary at the end of this tutorial volume. To communicate the meanings of the words, I have sometimes taken liberties with standard definitions to make them more understandable. Common acronyms used in this chapter follow right after the definitions.
Eight key terms, which are defined as follows, are important to understanding the articles provided in this introduction:
1. Attrition: A gradual, natural reduction in the workforce caused by various means like retirement.
2. Case study: An example employed to communicate lessons learned from trial use of a concept or idea.
3. Critical success factors: Those characteristics, conditions, or variables that have a direct influence on your customer's satisfaction with the products and services that you offer. 4. Lessons learned: The knowledge or experience gained by actually completing the project,
5. Motivation: In management, the act of influencing the behavior of others through the combined use of incentives and rewards.
6. Practice: In management, a preferred course of action for getting the job done.
7. Resources: In management, the time, staff, capital, and money made available to a project to perform a service or build a project.
8. Tracking: In management, the process of identifying cost and schedule variances by comparing actual expenditures to projects.
Acronyms
The following acronyms are used within the articles within this chapter:
3P's Process, product, and people
CMM Capability Maturity Model
GUI Graphical user interface
IEEE Institute of Electrical and Electronics Engineers
IS Information systems
PC Personal computer
SEI Software Engineering Institute
For Your Bookshelf
Although many books and articles on management theory are available, few of them apply this theory within the context of software projects. Few of these provide software project managers with help in identifying issues, bounding solutions, and resolving their day-to-day problems. The texts that I have listed in the annotated bibliography that appears at the back of this tutorial volume bridge the gap and provide practical guidance aimed at helping get the software management job done.
Most of the books in this list are relatively new. I have deliberately tried to make sure that they cover the latest concepts. I have eliminated most of the more technical texts and referred readers instead to more management-oriented books like McConnell's Software Project Survival Guide and my new book Making the Software Business Case: Improvement by the Numbers. I have also kept several classics on the list of recommended readings when they are easy to read and have something important to say. For example, I believe that everyone in the field should read the Mythical Man-Month by Fred Brooks. His messages are as relevant today as they were when he first published the book in 1975. They should also ponder Tom DeMarco's thoughts about measurement and management in his 1982 text Controlling Software Projects.
In addition, the Project Management Body of Knowledge (PMBOK(tm)) prepared by the Project Management Institute provides you with an excellent framework for putting the lessons learned that are discussed into action on your project. I highly recommend that you become familiar with its content.
I will point out books you should consider for your bookshelf in my introduction to each chapter of this volume. I will also provide you with pointers to additional information that is available to help you in this paragraph.
Finally, I will put updates to this volume and errata on my Web site (go to reifer.com). Use of the site will allow me to keep you posted on developments in the software management field.
Software Management's Seven Deadly Sins
Donald J. Reifer
During the past month, I have participated in an online discussion to look at the state of software and software management worldwide. What a revelation! Apparently, at least for the past several years, I have been living a sheltered existence.
That's because most of my consulting clients have had their acts together when it came to software management. These software organizations run like businesses, delivering what they promise-on schedule and within budget. Like well-lubricated machines, they crank out products for their customers-in the aerospace, process control, A medical, petrochemical, and telecommunications industries-that work the first time around. These firms have problems, as you might expect, but not overwhelming ones. Most track progress, use metrics, and employ risk management techniques to solve their problems early.
Others in the discussion group contended that I haven't been living in the real world. They argued that software organizations still have a tainted reputation because most software groups fail to deliver what they promise when they promise it. In many firms, senior managers still view software with disdain. To them, it represents the tall pole in the tent: with hardware now typically purchased off the shelf, software consumes most of their engineering resources and represents most of the risk their firms face. As evidence, my interlocutors pointed to statistics recently published by the Software Engineering Institute (SEI), which indicate that most firms recently rated using the Software Capability Maturity Model are still at Level 1. Group members also pointed to the horror stories appearing far too often in the professional literature, documenting what many call death-march projects and software mismanagement.
I decided to poll my industry friends to determine who was right. I drafted questions and conducted fact-finding using email. In all, senior managers from 20 organizations responded to my questions. To my surprise, most of them indicated that we still have major problems when it comes to managing software (see Table 1). Even more surprisingly, this table could have been built 20 years ago. Have we made no progress?
While these findings are not statistically significant, they are revealing. Most of these senior managers view software as a drain on their organizations rather than a contributor. Many think software people are unmanageable prima donnas. Many perceive software organizations as unable to deliver what they promise when they promise it. Interestingly enough, when I called several of these managers and asked them to characterize their firms' software groups, three themes echoed through their answers: software groups never seem to have the time to do the job right, their cost and schedule expectations are unrealistic, and I'm scared of them (because these managers do not understand software).
As one of the field's old-timers, I remember how things were the 1970s and early 1980s. Then, as companies increasingly bought their hardware off the shelf, they discovered that their products were becoming software-intense. Observers likened software development to hardware engineering, and the "software crisis" was on everyone's lips. Of course, the public did not have a clue about software. The PC was new and general use of the Internet was far in the future. To cope with this so-called software crisis, leading firms pursued software initiatives. Most embraced the following three-pronged attack:
Standardize the process.
Standardize the product.
Professionalize the workforce.
The leaders among them also educated their senior members to set expectations. In the late 1980s, the SEI software maturity model came out. This model formed the framework that enabled many firms to adopt the practices, methods, and tools needed to pursue process improvement. In the mid-1990s, architecture technology became the rage. These same firms then could use their processes to develop standard products using product-line management techniques. Because the technology used to develop software continued to change throughout this period, focus shifted to developing the workforce's skills. However, entire new industries emerged and software development moved away from the world of the large monoliths to the Web.
As Table 1 illustrates, some of us are apparently reliving this history. If so, perhaps we can reorient the solutions that worked in the past to help now. Let's turn our attention to what I call the seven sins of software management and see how solutions that worked in the past might again be our salvation.
Sin 1: Volatile requirements
In the old days, requirements were where the action was. The software industry developed better specification techniques to reduce volatility and get the user involved in the process early. We adopted object-oriented techniques to provide better mapping from problem to solution domains. We learned that we couldn't stabilize the software architecture and design if we let our customers alter requirements at will.
Today's quick-to-market projects seem to be teaching us this lesson anew. Although managers of such projects might use enlightened techniques such as prototyping and modern paradigms such as Mbase and the Rational Unified Process, they succeed only marginally when their organizations let requirements change whenever marketing staffs or customers and users suggest new features and functions. Clearly, better requirements-management processes are fundamental to making improvements. Sally Lee
Sin 2: Poor planning
Years ago, project teams would forsake requirements development and planning because management wanted them to get on with the coding. To cope with this foolishness, we likened software to hardware to illustrate the need for improvement. Firms developed planning templates only after they developed or bought into a life-cycle methodology. Then they brought in classical project-planning tools and techniques such as work breakdown structures and milestone schedules that worked for other disciplines. The software development community learned that we had to plan our future work in detail so we could control it and report its status. We invented terms such as inch pebbles to describe the depths to which our plans had to go so management would understand what we wanted.
Today, many firms have placed increased attention on planning, because they are trying to shorten the time-to-market interval by scheduling tasks in parallel using iterative and spiral techniques instead of sequential development approaches. They do so because there isn't enough time to plan all the options. To cope with such contingencies, we have learned that we can do planning in a just-in-time manner. We have also learned that plans should be living documents, iteration and evolving over time.
(Continues...)
Excerpted from Software Management by Donald J. Reifer Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
