Ninety Percent Done

“Hey, Phil, how are you coming on that subsystem?"

“Pretty good. I’m about 90 percent done.”

“Oh. Weren’t you 90 percent done a couple of weeks ago?”

“Yes, but now I’m really 90 percent done!”

The fact that software projects and tasks are reported to be “90 percent done” for a long time has become something of an industry joke. (A related joke states that the first half of a software project consumes the first 90 percent of the resources, and the second half consumes the other 90 percent of the resources.) This well-intentioned but misleading status tracking makes it difficult to judge when a body of work will truly be completed so you can ship the next product release to your customers. Here are several typical causes of “90 percent done” syndrome and a few possible cures.

You might have actually finished 90 percent of the tasks you originally thought were needed to complete some body of work, only to discover that there was a lot more work involved than you thought. This often happens when implementing a change in an existing system, as you keep encountering additional components and files you need to modify and then verify. The underlying problem is that we don’t think of all the necessary tasks when planning and estimating some chunk of work.

To cure this problem, spend a bit more time looking for all the work you’ll have to do. You might create task-planning checklists that itemize the steps involved when performing common activities that recur in your projects. These checklists will help you better estimate how much time the activity will require, they’ll reduce the chance of overlooking a necessary step, and they’ll help you track your progress more accurately. Similarly, perform a thoughtful impact analysis when you’re asked to make a change in an existing system. Some impact analysis checklists and worksheets to get you started are available in Requirements Engineering Set #4 at www.processimpact.com/goodies.html. Start with these and tailor them to suit your own situation.

We have a tendency to give ourselves too much partial credit for tasks we’ve begun but haven’t fully completed. You might think about the algorithm for a complex module in the shower one morning and conclude that you’re about half done, because defining the algorithm was the hard part. It’s very difficult to accurately determine the percent completion of a large task, both because unidentified activities probably remain (see Cause #1) and because we’re overly optimistic about how smoothly the remaining work will go.

The first step to curing this problem is to break large tasks (milestones) down into multiple small tasks (inch-pebbles; get it?). Inch-pebbles should not be longer than one or two days in duration. The individual items on your task-planning checklist from Cause #1 might serve as the inch-pebbles. Agile project iterations typically consist of sets of inch-pebbles like user stories. Unless carefully assessed, though, some stories or other tasks might turn out to be more involved than they initially appeared.

Next, track your progress on these granular inch-pebbles in a binary fashion: a small task is either completely done or it is not done. You get no partial credit for incomplete tasks. None. Zero. Progress on a large task is then determined by what percentage of the inch-pebbles for that big task are entirely completed, rather than by guessing what fraction of a large, involved, and vaguely defined body of work is completed. If someone asks you how you’re coming on a task and you reply, “I’m all done except...”, then you’re not done and you get no completion credit for it. Agile burndown charts are a way to track inch-pebble progress, provided the team remembers to give themselves credit only when the work items are truly finished.

If you’ve used project tracking tools like Microsoft Project, you might be familiar with a control that you can use to indicate what portion of a task is complete when you’re viewing a Gantt chart of project tasks. I advise caution using those partial-completion controls. They can contribute to the delusion that you’re farther along than you really are. As an alternative, consider breaking the tasks down into bite-sized increments that you can mark as entirely done when they’re completed, and then let the tool calculate the percent completion of the overall task from those subtasks.

Some studies have shown that software development projects typically devote between 30 and 50 percent of their total effort to rework, doing over again something you thought was already done. However, project plans and estimates often ignore the reality of rework, apparently expecting that everything will go right the first time (it doesn’t). As a result, you might think you’re nearly done with a task only to discover that correcting the bugs found during integration and system testing adds another 20 percent or so onto your schedule.

The cure here is simple: include rework as an explicit task in your plans following every quality control task, such as testing or a peer review. You won’t know how much time you spend on rework on average unless you keep some records. For example, you might discover that you found eight defects while testing one module, which took you five hours to correct and re-test (another form of rework). Now you have some data to estimate how much effort you might expect to devote to rework on the next typical task, be it a code module, a user story, or whatever unit of “work” you’re using.

Maybe you won’t have to spend as much time as you estimated on rework, particularly if you focus on continuously improving how you do your work. In that case, you’re ahead of plan! This is permitted in all 50 American states and many other countries. Without having some past rework data available, you’ll always be guessing on your future planning. But if you don’t consider the possibility of rework when estimating tasks and assessing your current task completion status, you’ll almost always be too optimistic. As the bumper sticker indicates, it happens.

If you want to cure an organization’s chronic case of “90 percent done” syndrome, try to identify the root causes that lead your status tracking astray, and pursue these simple methods for more accurately tracking your project and task status.