Refocusing: 90% Done is Not Almost Done

Feature Article: 90% Done Is Not Almost Done

Back when I was a new developer, my boss asked me how long it would take to complete a specific task. I looked at it for about 20 seconds, and said “Four weeks.” “Great,” he said.

At the end of the first week, I was 25% done—that’s what I reported on my status report. At the end of the second week, I was 50% done. At the end of the third week, I was 75% done. At the end of the fourth week, I was 90% done. At the end of the fifth week, I was 92% done. At the end of the sixth week, when I reported I was 92.5% done, my manager finally took pity on me.

“Johanna, do you know when you will be done?”

“Nope. Not a clue.”

“Would you like a little help learning how to know when you’ll be done?”

“You bet!”

My manager knew that 90%, 92%, and especially 92.5% done was not anywhere near done. Rather, it was a good clue that I had no idea when I would be done. I'd run smack dab into the 90% Done syndrome.

My manager sat me down and asked me questions that helped me break the large tasks into many smaller tasks. Like most people, I’m good at estimating smaller tasks and not so good at estimating larger tasks. Then, I listed all the test cases I would have to check, to know if this code was done. I didn’t call them test cases back then; I called them “done criteria.” My boss and I both knew that once I’d finished the tasks and made sure my code met the “done criteria,” I would actually be done.

That work took me almost ten weeks to complete. Luckily, I had an understanding manager who helped me plan and test my way out of the 90% Done syndrome.

Here are actions you can take, whether you are the one stuck in 90% Done or the manager of a person stuck in 90% Done:

1. List everything you need to do, to finish the big chunk of work. I include any infrastructure work such as setting up branches in the source control system.
2. Estimate each item on that list. This initial estimate will help you see how long it might take to complete the entire task.
3. Now, look to see how long each item on that list will take to finish. If you have a task longer than one day, break that task into smaller pieces. Breaking larger tasks into these inch-pebbles is critical for escaping the 90% Done syndrome.
4. Determine a way to show visible status to anyone who’s interested. If you’re the person doing the work, what would you have to do to show your status to your manager? If you’re the manager, what do you need to see? You might need to see lists of test cases or a demo or something else that shows you visible progress.
5. Since you’ve got one-day or smaller tasks, you can track your progress daily. I like to keep a chart or list of the tasks, my initial estimated end time and the actual end time for each task. This is especially important for you managers, so you can see if the person is being interrupted and therefore is multitasking. (See the article about the Split Focus schedule game.)

Sometimes, people fall into 90% Done because they're implementing across the architecture, writing all the GUI or writing all of one layer at a time. If you shift people to implementing by feature and have them work in short iterations, they start trying to estimate and complete smaller chunks of work. Their estimates will be more accurate, and they are more likely to finish the work.

Public Project Management Workshop, Sept 22-24, 2008