How to Use Inch-Pebbles When You Think You Can't

"When will the project be ready for Beta?"

"I think it will be ready next month. We're more than 90% done."

"NEXT MONTH? You said 'next month' last month. You said you were more than 90% done last month too. We're slipping this project a month every month. WHEN will you be done with this project?"

Many of us have had similar conversations, either as the senior manager wanting information, or as the beleaguered project manager. I prefer to avoid this conversation entirely, so I use inch-pebbles to at least determine all the tasks and their duration to know when I can meet a milestone.

Inch-pebbles, or miniature milestones, are defined as a best practice [1, 2]. Inch-pebbles are the breakdown of each task into very small components, no more than two days in duration, maybe only one day long. Inch-pebbles are either done or not done; they are not some percentage complete. Collections of inch-pebbles are the multiple-day or multiple-week tasks that we normally think of, when we build project schedules.

Some of us successfully use inch-pebbles to plan and monitor software projects. We use inch-pebbles to reduce the risk of missing the project schedule due to missing tasks. One frequent cause of missing tasks is the rework required. Commonly, project managers underestimate the amount of rework to do on a project. We may, for example, forget some piece of implementation or testing that we need to accomplish. When we do that, either we miss the scheduled delivery date because we completed the work anyway, or we run the risk of introducing defects by not following our normal methods of producing software. Using inch-pebbles can help us avoid such problems.

But while inch-pebbles may be a best practice, they're not commonly used. Sometimes, people don't want to use inch-pebbles. Sometimes it's hard to figure out how to use them. Nevertheless, while inch-pebbles may not be completely appropriate for every projects phase, every project can benefit from inch-pebbles at some point in its duration.

Inch-pebbles are useful when you know what you have to do. For many development tasks, you know what to do. But what happens when you don't know what to do? What do you do then?

Assess the Project You're Working On

First, consider the kind of project you're working on. These kinds of projects do not lend themselves immediately and totally to inch-pebbles:

A Really Big project. A colleague of mine, Ed, manages projects with 50-100 people for 5 to 10 years. He has a continual major risk to his projects; name, the requirements inevitably change. Ed creates inch-pebbles, only for the current phase of the project to achieve major milestones, and help manage the customer's and technical staff's expectations. He doesn't plan the entire schedule using inch-pebbles, he creates an overview plan for the project, and only plans the immediate work using inch-pebbles. Ed doesn't plan the inch-pebbles himself, he asks the project staff to create the inch-pebbles, and then his project office monitors the inch-pebbles. With inch-pebbles, he can clearly describe the current effects of potential requested changes.
A research project. When you do research, as my colleague Sally does, it's sometimes difficult to know when you're researching or going off into never-never land. Sally plans her work, by using a set of questions to know when she's discovered what she needs to know. Her questions are specific and detailed, so in a sense they work like inch-pebbles, but because she doesn't know where she's going, she does not create a specific plan to get there. When it's time to transition the research out of her lab, she creates a project plan and works with a project manager to create inch-pebbles for a successful transition.
A new product, where you haven't defined or created the enabling technology. If you don't know what the technology is, it's impossible to define the steps to get there. Fred is the engineering manager for a startup. The company has some product prototypes, but are developing new, never-done-before technology iteratively, within a given release and across releases. Fred uses inch-pebbles only for the end game, the activities required to ship the product. He does not use inch-pebbles starting in the requirements phase.

These projects have these attributes in common:

The project manager cannot completely define these projects at the beginning or even the middle of the project.
The project manager may not know what the final project deliverable will be.
The project manager is willing to take the risk of not knowing all the tasks up front, or of not knowing the state of task completion, because the schedule is not the major risk to the project.

These kinds of projects are inherently quite risky. Risk certainly increases if you don't precisely know what you have to do. Even so, defining all tasks as inch-pebbles at the beginning of a highly uncertain project is not appropriate. The project manager can get more benefit from illuminating and managing risk than by creating inch-pebbles.

Most of us do not work on huge, research, or brand new products. Most of us work on projects we know something about, and we have more than a vague idea of what we want to accomplish.

You have to know what you want to accomplish to be able to use inch-pebbles. When you don't understand your project, you can't use inch-pebbles at the beginning. You may be able to use inch-pebbles in a specific phase, especially if you want to better understand how long this phase will take, or to specifically define phase exit criteria. In contrast to the above projects, consider these kinds of projects:

A new product, but you understand the basic technology
A follow-on product, even a major release
A minor release of an existing product

These projects have some uncertainty and risk. Their risks are contained to the constraints and capabilities of getting the work done, not whether the work can be done at all. When you know the work to do, you can use inch-pebbles, even if you must use a phased approach to creating them.

Amy is managing a project for a new generation product. The new version of the product is replacing old technology (client/server) with new technology (web interface, Java beans). There is some new functionality, but nothing is brand new product technology. The implementation is the new and risky part of this project. The people on the project are learning how to use the new technology, and are learning how to package the product differently for the change in environment. Amy used inch-pebbles to plan her project carefully, to allow for enough time for training and rework. She realized that people might not be able to maintain their previous productivity in the face of new tools and new technology. Amy wanted to manage the knowable risks. She used inch-pebbles to create a common understanding of what was going to happen when and how people knew the tasks would be done.

Recognizing and dealing with concerns about inch-pebbles

If you're working on a project where inch-pebbles are useful, consider why people resist using inch-pebbles.

Many people, project managers and technical staff alike, resist defining inch-pebbles. They may not be sure which project to start using inch-pebbles on. They may be concerned they will not see any return on the time they invested defining the component tasks.

Since not everyone is willing to try using inch-pebbles, recognize people's concerns and the consequences of those concerns. You can then choose a multi-pronged approach in addressing their concerns.

Table 1: Possible concerns and consequences from using inch-pebbles

Concerned Person	Possible Sources of Concern	Perceived Consequences From The Concern
Technical staff	Senior management or project management will micro-manage them.	They might lose some freedom to plan their work
Project Manager	Senior management will try to micro-manage the schedule.	The project manager might lose her freedom to organize and replan the project where necessary.
Technical staff and Project Manager	It takes a long time to develop component tasks.	Project staff could feel that they are late before they start. Senior management may pressure project manager to "just get started".
Technical staff and Project Manager	They may find more tasks to do during planning.	They might be late before they start, especially if they committed to a date before generating the detailed schedule. They might lose flexibility to reorganize and plan their work and may feel pushed to just get started without planning.

Table 1 lists some common scenarios. Most of these scenarios deal with loss of freedom to the do the job, and to manage your own work. Below are some ideas to deal with the concerns about loss of freedom and flexibility to organize and manage the work:

Micro-Management Concerns

No one likes to be micro-managed. Ater all, we're professionals. It's hard to believe at first, but inch-pebbles can actually free you from project micro-management. Because you define the tasks in small increments, and a task is either complete or not, there is no need for continual status and task checking, for micro-management. Project status is obvious at any time in the project. (If you're working with a project manager or senior manager who inflicts help, inch-pebbles can't save you - but then nothing can.)

Can Planning Make You Late Before You Start?

I've only met one person who over-planned a software project. He was stuck on what the project should deliver, and took too much time before deciding what the product should deliver. Most projects run into trouble from under-planning, the planners miss tasks such as rework or in-process testing. Table 2 shows an example of the difference in planning a simple task, creating a specific module for an application, the "normal" way and the inch-pebble way.

In this case, the implementer was off by 50% in his original estimate. He had simply forgotten some tasks in his original planning.

Table 2: Original task time compared with Inch-pebble task time

Original task	Original duration	Inch-pebble component tasks	Inch-pebble duration
Develop module1	14 days	Verify module1 design with hardware group	1 day
		Implement the code and compile without warnings for functionality A, B, C. 2 days for each piece of functionality	6 days
		Develop unit tests for A, B, C	6 days
		Test module1 with pilot hardware, rework. 2 days per cycle, plan for 3 cycles	6 days
		Peer review with module2 developer	1 day
		Check the code into the mainline	1 day
		Develop initial documentation	2 days
		Have module2 developer review documentation	1 day
		Build the test system	1 day
		Verify module1 within the entire test system	2 days
		Run acceptance tests	1 day
Total	14 days		28 days

Flexibility of Planning and Working

I have found that I have the most flexibility in planning my work and the work itself if I spend more time on the planning part of the project. When I take the time to plan in detail, I frequently have ideas about how to shorten the critical path,. Fred, in the start-up project, used inch-pebbles to create a very short release cycle. By using inch-pebbles, he and the project team were able to orchestrate their work, and maintain a very short release cycle.

Starting With Inch-Pebbles

If you're still concerned about using inch-pebbles, try them on a short critical project, such as getting a critical fix to a customer. On a short critical project, you have to know all the tasks and be able to assess their status. This kind of projects is ideal for inch-pebbles. There are a number of benefits from using a critical project to pilot inch-pebbles:

The project manager needs to know all the tasks in a critical project, to create a highly accurate estimate.
The project staff needs to know all the tasks in a critical project, so they don't forget any tasks.
Short critical projects may not be subject to the same sorts of senior management micro managing as a longer project may be. The project manager may be freer to just get the project done without interference

The Benefits of Inch-Pebbles

When you work on a project under time pressure, as many of us do, inch-pebbles will help you easily determine whether the project is on schedule. I like to combine inch-pebbles with project plan iteration to further reduce schedule risk.

Project managers get these benefits from using inch-pebbles:

The project manager understands the project very well, so is able to monitor the project more effectively. If a task is late, you know within one or two days, so you have more options for replanning.
The participants clearly understand what they will provide and when. Inch-pebbles can illuminate any interdependent hand-offs.
Inch-pebbles can help reduce overall critical path duration. If you can enumerate all possible tasks, you may be able to overlap them in creative ways, reducing critical path time.
Inch-pebbles may help create a more accurate schedule. (I don't believe software people are "natural optimists", I believe they just forget to account for some pieces of the project.)

Inch-pebbles help project staff and project managers understand the schedule in more detail. That detail helps illuminate risks associated with each task in the project, and the handoffs between people.

Summary

Skillful project monitoring is difficult. As the project manager, you define what needs to be done, assess the progress of the work already completed, and then define your confidence in the team's ability to complete the tasks left to complete. Not everyone has the same definition of what each task means. Inch-pebbles can break down the tasks into small-enough chunks to make task completion clear. You can then get a "yes" or "no" ("done" or not "done") answer about the state of each task. When you break tasks up into 1-2 day chunks, you don't have to wait more than a couple of days to know if any given piece of the project is on schedule.

Acknowledgements

I thank the following reviewers for their helpful comments while writing this article: Mark Druy, Elisabeth Hendrickson, Brian Lawrence, Jerry Weinberg, Karl Wiegers, Don Willerton.

References

1. Brown, Norm. "Industrial Strength Management Strategies." Crosstalk: The Journal of Defense Software Engineering (August 1996).
2. McConnell, Steve. Rapid Development, Microsoft Press, Redmond, WA 1996.

Note to readers: I'm still researching the author of the term "inch-pebble". I believe it was Tom DeMarco, but have not yet found the formal reference.

Johanna Rothman observes and consults on managing high technology product development, looking for the leverage points that will make her clients more successful. You can reach her at jr@jrothman.com or by visiting www.jrothman.com.

What can we do for you? Go to: Writings and Presentations, Chronological Listing