Well-run projects go through three basic steps to create a software schedule. They first estimate the size of the project, then they estimate the effort needed to build a product of that size, and then they estimate a schedule based on the effort estimate.

Estimation and scheduling are development fundamentals because creating an inaccurate estimate reduces development efficiency. Accurate estimation is essential input for effective planning, which is essential for efficient development.

As Philip W. Metzger points out in his classic Managing a Programming Project, poor planning boils to the surface as a source of problems more often than any other problem (Metzger 1981). His list of software-development problems looks like this:

In his review of best projects, Bill Hetzel found that the industry's best projects are characterized by strong up-front planning to define tasks and schedules (Hetzel 1993). Planning a software project includes these activities:

Once you've planned a project, you track it to check that it's following the plan—that it's meeting its schedule, cost, and quality targets. Typical management-level tracking controls include task lists, status meetings, status reports, milestone reviews, budget reports, and management by walking around. Typical technical-level tracking controls include technical audits, technical reviews, and quality gates that control whether you consider milestones to be complete.

Bill Hetzel found that strong measurement and tracking of project status was evident in every "best project." Status measurement to support project management appears as a natural by-product of the good planning work and is a critical success factor (Hetzel 1993).

As Figure 4-1 suggests, on a typical project, project management is almost a black-box function. You rarely know what's going on during the project, and you just have to take whatever comes out at the end. On an ideal project, you have 100 percent visibility at all times. On an efficient project, you always have at least some visibility and you have good visibility more often than not.

Figure 4-1. Progress visibility for different kinds of projects. Efficient development provides much better visibility than typical development.

Capers Jones reports that "software progress monitoring is so poor that several well-known software disasters were not anticipated until the very day of expected deployment" (Jones 1995b). After assessing 59 sites between 1987 and 1993, the Software Engineering Institute found that 75 percent of the sites needed to improve their project tracking and oversight (Kitson and Masters 1993). When organizations have been assessed, tried to improve, and then been reassessed, the biggest problems for the organizations that failed to improve lay in the project planning and tracking-and-oversight areas (Baumert 1995).

Tracking is a fundamental software management activity. If you don't track a project, you can't manage it. You have no way of knowing whether your plans are being carried out and no way of knowing what you should do next. You have no way of monitoring risks to your project. Effective tracking enables you to detect schedule problems early, while there's still time to do something about them. If you don't track a project, you can't do rapid development.

One key to long-term progress in a software organization is collecting metrics data to analyze software quality and productivity. Virtually all projects collect data on costs and schedules. But this limited data doesn't provide much insight into how to reduce the costs or shorten the schedules.

Collecting a little more data can go a long way. If, in addition to cost and schedule data, you collect historical data on how large your programs are in lines of code or some other measurement, you will have a basis for planning future projects that's better than gut instinct. When your boss says, "Can we develop this product in 9 months?" You can say, "Our organization has never developed a product of this size in less than 11 months, and the average time for such a product is 13 months."

You need to have a basic knowledge of software measurement to develop efficiently. You need to understand the issues involved in collecting metrics, including how much or how little data to collect and how to collect it. You should have a knowledge of specific metrics you can use to analyze status, quality, and productivity. An organization that wants to develop rapidly needs to collect basic metrics in order to know what its development speed is and whether it's improving or degrading over time.

The first four volumes listed below discuss far-ranging software topics, including pragmatic issues such as what to do with a problem team member, theoretical issues such as how to model a software project as a system, and esoteric issues such as the importance of observation to software development. Weinberg's writing is entertaining and full of insights.

Weinberg, Gerald M. Quality Software Management, Vol. 1: Systems Thinking. New York: Dorset House, 1992.

Weinberg, Gerald M. Quality Software Management, Vol. 2: First-Order Measurement. New York: Dorset House, 1993.

Weinberg, Gerald M. Quality Software Management, Vol. 3: Congruent Action. New York: Dorset House, 1994.

Weinberg, Gerald M. Quality Software Management, Vol. 4: Anticipating Change, New York: Dorset House, 1996.

Pressman, Roger S. A Manager's Guide to Software Engineering. New York: McGraw-Hill, 1993. This might be the best overview available on general aspects of software project management. It includes introductory sections on estimation, risk analysis, scheduling and tracking, and the human element. Its only drawback is its use of a question-and-answer format that might come across as disjointed to some readers. (It does to me.)

Carnegie Mellon University/Software Engineering Institute. The Capability Maturity Model: Guidelines for Improving the Software Process. Reading, Mass.: Addison-Wesley, 1995. This book describes a management-level framework for understanding, managing, and improving software development.

Thayer, Richard H., ed. Tutorial: Software Engineering Project Management. Los Alamitos, Calif.: IEEE Computer Society Press, 1990. This is a collection of about 45 papers on the topic of managing software projects. The papers are some of the best discussions available on the topics of planning, organizing, staffing, directing, and controlling a software project. Thayer provides an introduction to the topics and comments briefly on each paper.

Gilb, Tom. Principles of Software Engineering Management. Wokingham, England: Addison-Wesley, 1988. Gilb's thesis is that project managers generally do not want to predict what will happen on their projects; they want to control it. Gilb's focus is on development practices that contribute to controlling software schedules, and several of the practices he describes in his book have been included as best practices in this book.

DeMarco, Tom. Controlling Software Projects. New York: Yourdon Press, 1982. Although now in its second decade, DeMarco's book doesn't seem the least bit dated. He deals with problems that are the same today as they were in 1982—managers who want it all and customers who want it all now. He lays out project-management strategies, with a heavy emphasis on measurement.

Metzger, Philip W. Managing a Programming Project, 2d Ed. Englewood Cliffs, N.J.: Prentice Hall, 1981. This little book is the classic introductory project-management textbook. It's fairly dated now because of its emphasis on the waterfall lifecycle model and on document-driven development practices. But anyone who's willing to read it critically will find that Metzger still has some important things to say about today's projects and says them well.

The following book is not specifically about software projects, but it is applicable nonetheless.

Grove, Andrew S. High Output Management. New York: Random House, 1983. Andy Grove is one of the founders of Intel Corporation and has strong opinions about how to manage a company in a competitive technical industry. Grove takes a strongly quantitative approach to management.