Assess the Project You’re Working On For Proper Inch-Pebble Scheduling

August 13, 2008 | Author: PM Hut | Filed under: Project Management Best Practices,Risk Management,Scheduling

Assess the Project You’re Working On For Proper Inch-Pebble Scheduling (#2 in the series How to Use Inch-Pebbles When You Think You Can’t)
By Johanna Rothman

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.

This article is an excerpt from the article “How to Use Inch-Pebbles When You Think You Can’t”, which can be found at:

Johanna Rothman consults, speaks, and writes on managing high-technology product development. Johanna is the author of Manage It!’Your Guide to Modern Pragmatic Project Management’. She is the coauthor of the pragmatic Behind Closed Doors, Secrets of Great Management, and author of the highly acclaimed Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People. And, Johanna is a host and session leader at the Amplifying Your Effectiveness (AYE) conference ( You can see Johanna’s other writings at

Related Articles

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories