One of the biggest problems I have had over the years with the people who report to me is a fundamental disagreement of what the word "done" means. When I was a brand-new supervisor, I would ask my people how they were doing on whatever tasks they were working on. They would tear themselves away from their computer screens and say, "Fine. I'm almost done." I would walk away feeling good about them and about the project, confident that they had things covered. A week or two later, I would check in with them again. They would look up at me and say, "Fine. I'm almost done."

Another variation of this is the high-precision answer. How are you doing? "Fine. I'm 95% done." The purpose of this degree of precision is to convince the interrogator that everything is under control. In fact, nothing could be further from the truth. I have formulated "Clark's Law of Misappropriated Precision": When it comes to estimating completeness, the greater the precision, the greater the inaccuracy. I have been told that an activity was 97% done and required no more than two weeks to complete. I have then waited four months for completion.

The problem isn't that my people are being mendacious. The problem is that we have a disagreement on what the meaning of "done" is. When I, as a manager, say "done" I mean that the task is complete and this person is ready for her next assignment. Therefore, when people say that they are 97% done, I expect that only 3% of the work remains. On a 100-hour task, I foolishly assume that only 3 hours remain and I should be able to assign them something new tomorrow.
What do my people mean when they say "done"? It varies. If I have asked them to create a new module, "nearly done" may mean:

• I have thought about it, and I am ready to start coding.
• I have coded it, and I am ready to think about testing it.
• I have tested it, and I just have to fix all of the bugs.
• I am tired of working on this, and I am ready for something new.
• I have found a horrible bug, and I am ready to rewrite the module from scratch.

Projects can float along in a dream-like haze for months in this manner. Oftentimes you don't know whether something is really done until integration. When you go to put all the pieces together, you then find out that a lot of them are missing or wrong.

There are things you can do to avoid this. For common tasks, like coding a module, I create a description of the meaning of "done." This includes:

• A description of what is included in this activity: for example, coding, unit testing, inspection, documentation of insertion of the module into the revision control system
• A brief list of related activities that are not included in this activity, to prevent gold plating and distractions
• A list of any predecessor tasks to this one
• A list of inch stones, along with the percentage of the overall task that is finished when that inch stone is complete

Predecessor tasks are important because your staff will often jump the gun to work on something that they like. For example, they will begin working on the code before the requirements have been finalized. You need to establish the gate they must pass through before they can start working on a task or your sweet daydream will quickly turn into a nightmare of blown schedules and budgets.

The inch stones are valuable for several reasons. First of all, they serve as a checklist of all of the parts of the task. For example, programmers almost always view coding as the largest part of the task. When coding is done, they believe that they are "97% done." The checklist reminds them that there are other, equally important, tasks that must be completed.

Inch stones are also invaluable in overall project tracking. Take, for example, a programmer who has burned 50% of the budget, but has completed only 30% of the inch stones. You can then multiply the remaining budget by 5/3 to get an expected cost at completion for that task. You can then use this to adjust your completion date for the scheduled task.

Inch stones are binary - they are either done or not done. Also, the completion criteria for inch stones should be extremely simple and easily verified. For example, the completion criteria for unit testing a module might be that the unit test plan has been executed and the unit test record checked into the revision control system. When receiving status on inch stones, you should repeatedly verify that these criteria have been met until it becomes reflex for your people to complete them.

A disagreement over the meaning of done is always a recipe for disaster as it allows you to proceed as though everything is fine, when in fact it is not. You often don't learn of your problem until it is too late to do anything about it.