Ninety Percent Done


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.

Cause #1: Inadequate Task Planning

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 Start with these and tailor them to suit your own situation.

Cause #2: Too Much Partial Credit

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.

Cause #3: Forgetting about Rework

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.

Author: Karl Wiegers, Principal Consultant at Process Impact

Karl Wiegers is Principal Consultant at Process Impact, a software development consulting and training company in Portland, Oregon. He has a PhD in organic chemistry. Karl is the author of numerous books on software development, most recently Software Requirements, 3rd Edition (with Joy Beatty). He’s also the author of Successful Business Analysis Consulting: Strategies and Tips for Going It Alone, a memoir of life lessons, and a forensic mystery novel, The Reconstruction. You can reach him at or

Like this article:
  32 members liked this article


Wilco Charité posted on Friday, August 2, 2019 3:02 PM
Hi Karl, rework is an item in my daily work as an analyst and requirements engineer. When I was a developer, I was confronted with rework too offten in a too high amount, just because consultants had to deal with the issue you described above. I converted into an analyst and requirements engineer because I was convinced that "requirements first time right" is possible. Possible in that way, you can define tasks in advance completely. Okay, almost complete but always in such a way, rework is decimated compared to not applying analysis and requirements engineering. I can tell, it works, also because I consider myself quite detailed.Basically, what you wrote, is the root cause of why I am an BA and RE. But, why didn't you mention it?
MrWonderful posted on Saturday, August 3, 2019 12:02 PM
In an ideal world, yes we would like to have perfect requirements all available and stable upfront and conveniently planned. However I'm not sure if this reflects reality for all situations.

Sometimes the software product can be part of a POC which in inheritantly designed to elicit more requirements to test out business viability. External drivers for software development can influence a "speed to market" mentality and sometimes waiting until all requirements are captured is infeasible - this is why waterfall development lost its cachet. However to the point of the article, tasks do need to be planned based on a minimum level of complete critical requirements - but with an acceptable level of risk of the unknown. Internally, reward measures are more typically driven off of delivering actual product and less on better requirements and QA best practices. I think this is what motivates "90 percent done" behaviour.
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC