The original deadline for our software project had come and gone, and every week the new finish date was sliding farther into the future. The Vice President of Development decided that he needed to call a project summit meeting, bring the finish date in sooner, and nail down a schedule once and for all. He called all the important managers (but none of the programmers) into a room. They shut the door and vowed not to emerge until they had shortened the schedule.
One of the managers laid a rock on the table, solemnly turned it over, and said they should "leave no stone unturned" in their effort to shave time off the schedule. They re-examined each task in the project list, shortened many of them, made some tasks concurrent, and eliminated a few others. They emerged several hours later with a tightened schedule, and an earlier end date.
All the managers were happy. They had accomplished their goal of shortening the schedule.
In hindsight, it is not surprising what happened: The managers' effort was a waste of time. The new schedule had no effect on the pace of development at all. The project was finished at the about the same time it would have been, except that five or six highly paid resources wasted a half-day looking at a rock in a room.
Another true story... I worked on a project to create a new ATM machine to compete with the established vendor. This was a complex hardware/software project, using an embedded processor board, a cash dispenser mechanism, a deposit-taking device, a receipt printer, a screen, and a communication link to the bank's mainframe. The software was written in assembly language, and we debugged via an in-circuit CPU emulator. Not surprisingly, this project schedule started slipping also. Upper management (in another city) was not happy.
So, our local manager began keeping two versions of the project schedule. He kept an "official" version, with an aggressive completion date, which he reported out to his boss at headquarters; and a "real" version that he kept in his desk drawer. He assured us that he only expected us to work toward the schedule in his drawer.
These stories are humorous, in a Pointy-Haired-Boss way, but they raise an important question that haunts many software projects: What is the relationship between software schedules and reality? In the second example above, there was clearly no relationship, and the official schedule was useful only for doodling and wrapping fish. But how about honest schedules, that all team members really hope reflect an actual completion date?
In my experience on software teams, both large and small, and in my academic research, there are some common factors that lead to a reliable schedule. Ignoring these factors may turn your project into fodder for eye-rolling party conversation years later.
Completion dates can be progressively refined as projects move along.
The classic view of software development is to perform all of the design and planning at the start, estimate a completion date, and then begin programming. This would be a great method for software development, if it worked. A more realistic approach is cyclical development, which repeats the design, estimation, programming, testing, and delivery phases, several times over. Steve McConnell advocates such iterative development and refers to schedule refinement as narrowing "the cone of uncertainty ." Agile development takes this idea further and estimates work in very short chunks, finishing and delivering each phase, before estimating the next small set of development tasks. Everyone in the software world would love to pin down a completion date and total cost at the start of a development project, but it is probably beyond human ability to do so.
Reliable schedules are based on commitment (buy-in) from all participants.
Participants include management, marketing, architects, programmers, testers, and the documentation team, among others. The meeting I described at the beginning of this article did not include anyone doing the hands-on project tasks, dooming the meeting (and its resulting schedule) to failure. Buy-in means active participation in planning, project design, and estimating. It does not mean "they agreed to the schedule because they feared for their jobs if they did not."
There is a subtle danger about buy-in, however, that you must guard against. Most people want to perform well—especially young, motivated engineers eager to show their programming chops. Software team members may voluntarily commit to a schedule, which they truly believe in, even when that schedule is unrealistic. The key ingredient to accurate estimates is informed consent, based on sufficient experience with projects of this type.
Accurate schedules are based on the experience of the same team, using the same technologies, solving similar problems.
This is the most frustrating part of software estimation, and requires a large ego check by technical people when looking at a new project. Programmers tend to think that the new project is not much different than something they have done before. The thinking goes, "I have been working with Java for two years, so this new Java project shouldn't be hard" or "We have put up an Apache server on Windows 2003 before, so we'll just do it again." The reality is that even if everyone on your team has a computer science degree and ten years of programming experience, new software projects are often very different from previous projects.
Consider the following scenario from outside of the software world.... A commercial building company is experienced and fast at constructing standard office buildings between three and ten floors tall, using a steel frame, brick exterior, open interior design, on stable bedrock sites. They can confidently and accurately predict the time and cost for constructing another such building, with minor variations from their previous projects. Now, imagine that you ask this company to construct a hospital that is 100 stories tall, using a radical tilting design, on top of a seismic fault. The hospital is to be built from standard steel and bricks.
The construction company would make a major blunder if they thought they could provide a time and price estimate for this hospital. Even though it uses the same raw materials they normally work with, the design and constructions problems are far outside their scope of expertise (and perhaps beyond anyone's expertise). Many software projects suffer from the same "we've done something like this before" problem. A new piece of software written in Java on Linux may be nothing like anything ever created by humans, even when the team has lots of experience with Java on Linux.
If your software team has built ten compilers, for modern procedural programming languages, generating machine instructions for industry-standard CPUs, and you are asked to build an eleventh such compiler, you can confidently estimate this project. But, don't fool yourself into thinking your team is in this enviable situation; you usually are not. Solving new software problems is hard, and hard to estimate, even if you have previously used some of the raw materials.
This is a major point of the CMMI process framework from the Software Engineering Institute at Carnegie Mellon. In their terminology, software schedules are accurate only when the software process is "repeatable."
I know what you might be thinking: "This is nice software engineering theory, Chuck. And it is swell of you to dispense this wisdom from an ivory tower. But, I have a real project right now, and my boss wants to know how long it is going to take."
Yes, there are real pressures from customers, competitors, and managers. I've been there. Unfortunately, large software projects tend to have a life of their own. The lines of code you are writing don't know that XYZ Corp is about to release a competing product before yours, or that your boss's boss is yelling at you. Wishing that your program will work quickly won't make it so.
Showing up for work each day to battle an impossible project deadline consumes a huge amount of time and energy. Ironically, an ongoing schedule battle takes time away from doing a good job on the software. Recognizing that a software project is hard, and hard to estimate accurately, frees you to work on it in a realistic manner. Fred Brooks made this point twenty years ago in his essay No Silver Bullet and it is still true today.
About the Author
Chuck Connell is a software consultant in Woburn, MA and a PhD student at Tufts University, focusing on software engineering. He can be reached at www.chc-3.com.
- The origin of the phrase "cone of uncertainty" is unclear, based on a Google search. It is likely that a diagram of this cone, and the general concept, was introduced by Barry Boehm, while the phrase was coined and popularized by Steve McConnell.