Using Inch-Pebbles to Track Project State

Computerworld - Drake, a technical contributor in your group, sends you his weekly status report. He's been reporting on this six-week task for the past six weeks:

Week 1:	Task 1 90% done
Week 2:	Task 1 95% done
Week 3:	Task 1 96% done
Week 4:	Task 1 99% done
Week 5:	Task 1 99% done
Week 6:	Task 1 99% done

Drake's task is now officially late. Given his progress, can you believe Drake's estimate that he will be done next week? You don't have enough information. You need to know how much of the task is actually complete and how much is left. Inch-pebbles, or miniature milestones, are one way to help estimate task size and monitor task completion. Inch-pebbles are one- to two-day tasks that are either done or not done—there's no "percentage done" with inch-pebbles. When you or members of your project team create inch-pebbles, first break down the larger tasks into smaller pieces, estimate the time each smaller task will take and then verify that you've accounted for interdependencies with other people. When I see a six-week task on someone's list, I ask that person to define all the pieces of that task—to break the task into inch-pebbles. The first reaction I generally get is "Huh?" Here's what I do to create inch-pebbles.

1. Define the component tasks. A large task has natural intermediate milestones. Each milestone reflects a component task. Here's an example of possible components for a software development task:
   • Verify the design; complete the low-level design if necessary.
   • Check the code out.
   • Implement the changes in the code.
   • Develop unit tests.
   • Compile, with all warnings turned on and zero warnings found.
   • Review the code with at least one other person, if not through a formal inspection.
   • Check the code in.
   • Develop initial documentation.
   • Build the system and verify, "This piece does what I thought it was going to do."
   
   

   	Johanna Rothman consults on managing high-tech product development, focusing on project management, risk management and people management. You can reach her at jr@jrothman.com or by visiting www.jrothman.com.

   There's a lot more here than just writing some code. Inch-pebbles help you see how big the task really is and the overall task composition. Some of you may be saying, "Why on earth do you even have tasks for checking the code out and checking the code back in?" Because there are times when you need to branch or label before you check out. Sometimes you need to check in to multiple branches -- for example, when fixing an already-released product and fixing the source under development. Checking out and checking in should be short tasks, but sometimes they're not.
   
   After the task's components are defined, you can determine how much time is required for each component task.
2. Estimate the time for each component task. Each component will take a certain amount of time. The smaller the task is, the easier it is to estimate task duration. The first time I did this with Drake, he had a larger estimate for the sum of the component tasks than for the overall task. We discussed why, and he decided that he hadn't thought enough about the whole task until he broke it down into component parts.
3. Account for interdependencies. Most of us work with other people in teams. We are dependent on them for information at the very least and sometimes for pieces of the product. In Drake's case, he was waiting for his reviewers to become available for a review. He had done everything else, short of checking the code into the public configuration management system. Until the other people became available, he could not finish his task.

Even if a task is late or incomplete, it's not too late to start breaking down the large task into its components. Then the task owner can review the components, figure out what's been done, what hasn't been done, and how and when it will all get done. In this case, Drake's project manager was able to discuss alternative reviewers and remove the review obstacle from Drake's task completion. If the PM had realized at Week 3 that Drake was waiting, the PM could have helped earlier.

Inch-pebbles can help you look forward, not just backward. When I plan a project, I break all my work down into one- to two-day tasks, and I ask the project staff to do so also, using a rolling three- to four-week window. This is a lot of work, and I receive significant return on this work. (No, I don't put the inch-pebbles into the project schedule. I ask the project staff to monitor their own inch-pebbles.) The payback:

• I understand the project very well, so I am able to monitor the project effectively. I can tell if a task is on time or not. If the task is on the critical path, I can quickly replan to avoid cascading project problems.
• The participants clearly understand what they will provide and when. Not every deliverable is time-critical, but the entire project team understands which ones are. Inch-pebbles can illuminate these interdependent hand-offs.

Tracking the project state skillfully is hard. You have to understand what needs to be done and what people mean when they tell you they are done. Not everyone has the same definition of done, so I use inch-pebbles to break down the tasks into small chunks. I can then get a yes or no (done or not done) answer about the state of each milestone. With inch-pebbles, I don't have to wait more than a couple of days to know if any given piece of the project is on schedule.

(Copyright 2004 Johanna Rothman)