Someone once asked me where to get historical data to improve her ability to estimate future work. My answer was, "If you write down what actually happened today, that becomes historical data tomorrow." Unless you record the actual effort or time spent on each task and compare them to your estimates, your estimates will forever remain guesses. Each individual can begin recording estimates and actuals, and the project manager should track these important measures on a project task or milestone basis. In addition to effort and schedule, you could estimate and track the size of the product, in units of requirements, lines of code, function points, classes and methods, GUI screens, or other units that make sense for your project.
We give ourselves a lot of partial credit for tasks we’ve begun but not fully completed: "I thought about the algorithm for that module in the shower this morning, and the algorithm is the hard part, so I’m probably about 60 percent done." It’s difficult to accurately assess what fraction of a sizable task has actually been done at a given moment. One benefit of using inch-pebbles for task planning (see Practice #6: Decompose Tasks to Inch-Pebble Granularity) is that you can break a large activity into a number of small tasks (inch-pebbles) and classify each small task as either done or not done—nothing in between. Your project status tracking is then based on the fraction of the tasks that are completed, not the percent completion of each task. If someone asks you whether a specific task is complete and your reply is, "It’s all done except ...", then it’s not done! Don’t let people "round up" their task completion status; use explicit criteria to determine whether an activity truly is completed.
An old riddle asks, "How does a software project become six months late?" The answer is, "One day at a time." The painful problems arise when you don’t know just how far behind (or, occasionally, ahead) of plan the project really is. Create a climate in which team members feel it is safe for them to report project status accurately. Strive to run the project from a foundation of accurate, data-based facts, rather than from the misleading optimism that can arise from the fear of reporting bad news. Use project status information and metrics data to take corrective actions when necessary and to celebrate when you can. You can only manage a project effectively when you really know what’s done and what isn’t, what tasks are falling behind their estimates and why, and what problems and issues remain to be tackled. The six basic dimensions of software measurement are size, time, effort, cost, quality, and status. And remember the cardinal rule of software metrics: Managers must never use metrics data to punish or reward individuals for their performance.
