Software Development
Sometime in the late ’60s, when I was 15 or 16, my father brought home a book that he thought I’d be interested in. The title was Introduction to Operations Research, by Frederick S. Hillier and Gerald J. Lieberman (Holden-Day, 1967). The book languished on my shelf for perhaps 10 years. Then, as a young software professional, I pulled it down and, thumbing through its pages, noticed a chapter on PERT. I’d heard of PERT as a method of project management, so I started to read and learn.
Since those days, I’ve seen dozens of examples of PERT charts—along with tools for drawing them—and they always make me cringe. Invariably, these charts and tools miss PERT’s fundamental principle, which made it such a successful technique: the management of probabilities.
PERT (Program Evaluation and Review Technique) was developed in 1958 by the Department of Defense’s U.S. Navy Special Projects Office to help measure and control the progress of the Polaris Fleet Ballistic Missile program. The technique earned considerable respect for assisting in the management of thousands of different contractors and agencies, and is credited with helping to advance the program’s completion date by two years.
Simple Statistics
PERT is a technique for estimating and planning large projects, based on probability management. PERT uses simple statistical mathematics to create a probability distribution for the completion dates of the project milestones. For example, in PERT, tasks are estimated with three numbers indicating days to completion: the best, nominal and worst cases. These three estimates are combined into an expected duration and a standard deviation. Thus, the duration of each task is presumed to be a random variable with a known distribution.
The math is simple. Consider a task whose best/nominal/ worst estimate is 3/5/9. The expected completion time (m) is assumed to be (4 * nominal + best + worst) / 6, or in our case, (4 * 5 + 3 + 9) / 6, or about 5.33. The standard deviation (s) is assumed to be (worst – best) / 6; that is, (9 – 3) / 6, or 1.
Now consider a simple project consisting of three tasks. We represent this as a chart with circles (to denote events) and arrows (to denote tasks).
If the first task begins on day zero, what day can we expect the third task to complete? The following chart shows the expected durations, and we can just add them up. Thus, the expected duration of the project is 5.33 + 6 + 9.67, or 21 days.
| Task | x | y |
| 1 | 5.33 | 1 |
| 2 | 6 | 1.33 |
| 3 | 9.67 | 1.33 |
A more interesting question is the probability of making that date. A bit of simple reflection will convince you that if the estimates are correct, there’s a 50-50 chance that the project will finish on time—just as much chance that it will be late as early. Clearly, we can’t make a commitment based upon such poor odds, so what can we commit to?
The project’s end date is a random variable that has its own completion time (x) and standard deviation (y). We already know that x for the project is 21 days. The y for the project is the sum of the y for each task, or 1 + 1.33 + 1.33 = 3.66. Let’s say we’re comfortable committing to a date that has a 90 percent chance of being met. A little probability math tells us that we get this certainty by adding about 1.3y, or 4.75 days, to the project. So we should commit to 26 days.
Critical Path
One of the more common project estimation schemes is the Critical Path Method (CPM), invented by the DuPont Corporation in the 1950s. Project managers who use CPM ignore the probabilities and use only nominal case estimates.
Following this approach would lead us to commit to finishing the project in only 19 days. CPM is the method supported by most project management tools. This has always puzzled me since it seems to me that knowing the probabilities is critically important to managing a project, and such tools could easily provide those calculations. Indeed, I’d much rather use a tool to calculate probabilities than to draw bubbles and arrows.
Dependencies
Both PERT and CPM represent the project with a diagram that shows the tasks and their dependencies. The previous simple diagrams show three tasks that have sequential dependencies. The arrow from Task 1 to Task 2 indicates that the start of Task 2 depends on the end of Task 1; Task 2 can’t start until Task 1 finishes.
 [click for larger image] A Complex Task Diagram This chart represents a project with many tasks and dependencies. At the project’s start, three tasks (t1, t9 and t5) begin concurrently. Other tasks start as these tasks end. The longest path through this network is known as the critical path, from which CPM gets its name. |
The longest path through this network is known as the critical path, from which CPM gets its name. Shown in bold, this path tells us that the end event is 26 days from the start event.
If we were using PERT, the date of the end event would be a random variable based upon the x and y of each of the tasks on the critical path. We’d also be able to calculate the probabilities of other paths going critical.
The Wrong Choice
Over the last three decades, software project managers have become enamored with the power of these charts to represent dependencies. I’ve often seen projects represented as huge diagrams showing all the various software tasks and their interdependencies. These are often broken down well below the subsystem level to tasks that are measured in man-days. While I agree that the ability to represent dependencies on a chart like this is cool, it’s also fairly useless in a software project.
First of all, the number of concurrent tasks in a software project usually can’t exceed the number of people in the development team. If you have five developers, typically no more than five programming tasks can be going on in parallel; the sixth task can’t begin until one of those five completes. This represents a dependency that’s usually not shown on a CPM chart. Some automated tools attempt to address this problem by automatically allocating tasks to available resources. However, I’ve never found that kind of allocation to be very useful or accurate.
A more serious problem is that most dependencies in a software project are avoidable. It may make some kind of logical sense that you must finish writing the login servlet before you start the logout servlet, but in reality, you could write and test them in any order. Analysts often assert that you must complete the data model before you can start writing queries, but in fact, the queries and data model can evolve together, and the business rules can often precede both. Architects often insist that you must design and implement the infrastructure before you can begin writing the application itself; but again, we’ve found that application and infrastructure can evolve together.
So, despite their cool factor, fine-grained dependency charts almost always represent a set of arbitrary and irrelevant decisions. This may explain why these charts so frequently become useless as the project proceeds (one team I consulted for referred to them as the laugh track). The tasks just don’t get done the way the dependency chart says they should.
PERT was designed and used for huge projects involving thousands of contractors. Tasks were months long, truly parallel, and the dependencies were real. In this kind of environment it makes sense to create a dependency chart. It makes even more sense to use the best/nominal/worst estimation scheme and to calculate the probabilities. But for managing software projects at the man-day level, the dependency charts make little sense at all.
Managing Probabilities
What does make sense in a software project is the management of probabilities—not
in the formal sense of PERT, but in the informal sense of agile project management
(APM).
In APM, the project is broken down into tasks that are in the few-man-day range.
These tasks are estimated, but not in absolute units like man-days. Rather,
they’re estimated in terms of each other. One of the tasks is arbitrarily
assigned a number of points (usually three), and all other tasks are then given
a point value indicating their degree of difficulty compared to that reference
task.
The project is divided into iterations that are usually one or two weeks in length. At the beginning of each iteration, stakeholders arrange the tasks in the order they’d like to see them implemented. The developers work down this list in the order specified. At the end of an iteration, the team counts the number of points they completed. This number becomes their velocity for the iteration.
Two bar charts are kept on the wall. The first shows the velocity of the team for each iteration, and the second shows how many points remain in the project (see “Team Velocity” and “Remaining Points”).
[click for larger image]Remaining Points This bar chart tracks the number of points that need to be completed in the project week by week. The slope of the chart is a random distribution that predicts when the project will be done. |
 Team Velocity This chart tracks a team’s velocity week by week based on how many tasks are implemented. One task is arbitarily assigned a point value, and other tasks are assigned values based on their degree of difficulty to complete in comparison. |
Notice that the Team Velocity chart depicts a random distribution of velocities around a mean of about 45 points per iteration. The Remaining Points chart shows the effect of all this work on the project. Note, however, that sometimes the bars on the second chart don’t shrink by enough, and sometimes they even grow. This occurs as new features are added to the project, and the developers re-estimate certain tasks based on better knowledge.
The slope of the second chart is also a random distribution that predicts when the project will be done. Though it would be possible to calculate the probabilities, there isn’t really much point. With a nice straight ruler, the probabilities can be eyeballed with sufficient accuracy for the kinds of decisions that must be made.
Given these two charts, a good software manager can make decisions about schedule, staffing and scope, and thereby manage the project to a desirable outcome.
Measuring Randomness
Project plans are afflicted by uncertainties that turn schedules into random variables. Fortunately, we can measure that randomness and use it to determine the probable finish dates for specific tasks. Once we know the probabilities, we can manage the project by adjusting scope, staff and schedule to increase the chances of a desirable outcome.
While PERT is a scheme for managing probabilities for very large and complex projects, it doesn’t scale down to the level at which most software projects are planned. CPM shares this inability to scale down, and also ignores the randomness inherent in planning software systems.
By contrast, the techniques of agile project management are well suited for the kinds of tasks that make up software projects. APM also captures and characterizes the randomness and uncertainty that are inherently part of those projects. By using it, managers can achieve constant and accurate insight into the team’s effort—and optimize their chances of success.
Robert C. Martin is CEO, president and founder of Object Mentor Inc., in Vernon Hills, Ill., and a speaker at SD conferences.
