Is Your Task Done? Or Just Ninety Percent Done?

We all love progress bars. Whether it involves copying a simple file, attaching something to a web based email or installing something on our machines - as human beings we like the idea of being in control. We like to be informed about:

1. How much of the work is done.
2. Home much of the work remains.
3. How much more time will it take to get remaining job done.

All we expect from progress bars is simple, definitive, true and honest answers to the above three questions. That is all we want from them. No More.

And at the first glance progress bars seem to suggest that they will in fact live up to our expectations. I mean, look at the one below. Doesn’t it say out loud that it is in fact, going to keep you informed about the answers to all of the above three questions?

Now go on, start another file copy process, then another. Then open up your Outlook and a couple of Microsoft Word instances and watch this progress bar get utterly confused.

Steve Teixeira in his post, describes how, in the web world now a days, true and honest progress bars are difficult to find. In fact he believes that progress bars have ended up being nothing more than a lie that we all accept. He explains the basic fundamental issue with progress bars back from the Windows 95 days using an application installer as an example:

Ever been through this frustrating experience where you saw the progress bar move up to 90% and then just sit there, mocking the trust that you placed in its ability to report the accurate status of the task back to you?

But the progress bar, by no means, is dishonest.

The simple fact of life is, things changed after it started. Things changed after the progress bar told you that it was 60% done. It needs more time to get the job done and the 1-to-100% window of reporting-the-progress does not allow the progress bar to break one simple fact to you - that it needs more time. Basically, the progress bar feels intimidated to report 180% of 100% work done, so it just sits there at 90%, slogging away.

Now, dear reader, take a pause and think. Have you ever been in a project where you were “almost” done in the first month and took another two months to be “done-done”? If you think about it, you were in fact the progress bar, weren’t you?

Have you ever heard the 90% done status from a team members and then seen them slog away at the remaining 10% for a long time? If you were leading the project, chances are you limited your team in a 1-to-100% window of reporting which did not allow him to break one simple fact to you - that things have changed since they started and they need more time.

While working with projects remember the Famous Quote from Tom Cargill:

Long story short, it's easy to be 90% done. Difficult to be done-done. As attractive as progress-bar-approach of reporting may sound, expecting the task status to be reported in a windows of 1-to-100% just does not work. Here is why - If you are a project Manager running around the office with a Gant-chart in your hand asking your developers what’s the percentage of their task that is done chances are your project will be successful till it’s 90% done. And then, it'll fail pathetically.

Johanna Rothman in her article provides advice on doing away with the 90%-done-game while reporting your project status. Go ahead, click the link and read the article. It is a good read indeed.

If I try to summarize what Johanna is suggesting in my words, it basically seems to boil down to really fundamental principles of Agile or for that matter, common sense:

1. Divide and Conquer - Break down your tasks into something you can do in a day-or-two. Something she calls Inch-Pebbles.
2. Track and Report Your Low Level Tasks In Boolean – It’s either done or not done. And done does not mean just done, it means Meets-The- Definition-Of-Done done.
3. Introduce Transparency – Allow your team members to become a little more shameless than a progress bar and talk about problems if they are not being able to get the feature done rather than just asking them the percentage of the job done and then hoping problems will fix themselves. If the problems are genuine and cannot be solved in the time-boxed sprints, prioritize and drop features.

Years after the progress bar was born, a lot of programmers figured out that it’s really difficult to answer the three questions progress bars attempt to answer correctly and honestly. The indeterminate progress bar was born. Today, even the smartest of developers around the world, can't give you a percentage-complete for everything and it sure does look like they are not ashamed to admit it: 

So why are you?

On a serious note, Trying to report individual task progress in percentage done and expecting the team to provide you with "percentage complete" numbers in a bi-weekly / monthly status meeting, is an obsolete project management technique that never worked even when it wasn't obsolete. If you have divided your tasks well, everyone knows where your project stands and most of the times your tasks, sub-tasks, inch-pebbles or whatever you choose to call them, are either done or not done. 90% done is as good as not done.

Next time you report your tasks, instead of percentage, try using boolean for task statuses. Get together as a team everyday and take an inventory of how many tasks / sub-tasks / inch-pebbles are done. Try prioritizing and respecting the iron triangle by dropping features if necessary. Chances are you’ll fail early and you'll fail often but in the end, if you keep reporting your tasks in boolean you’ll reach the hundred percent mark, successfully.

So dear reader, what are you working on today? Are you going to be done soon? Or just 90% done?