©2002 Johanna Rothman
You’re a project manager who’s just been assigned the biggest project of your life. You’ve planned the project work with your project team. You’ve gathered the project plan and the project schedule, for your upcoming meeting with the Operations Committee, OC, to explain how you’re going to manage the project and when the project will be ready.
If this is your first visit to the OC, you’re a bit nervous. After all, these are the executives of the company. You start talking about the project, the benefits to the company, and then a stentorian voice rings out, “When will it be done?”
You think to yourself, Ok, we’ll skip to the end. Aloud, you say, “June 30.” The COO, the owner of the stentorian voice says, “Sorry, not good enough. Give me another date.” You think for a few seconds, and say, “Well, if we cut this feature, we could maybe make June 15.” “NOT GOOD ENOUGH”, exclaims the COO. You’re confused,“ Well, what date did you have in mind?” “I certainly don’t know. You’re the project manager. You tell me.”
Now you’re stuck. Clearly the COO is looking for a particular answer. But what is the right answer? If your palms weren’t sweaty before, they are now. Welcome to the Bring-me-a-rock schedule game.
Bring-me-a-rock occurs when your management or sponsors want the project done earlier, and they won’t tell you the date. You say, “Here’s a date.” Your sponsor says, “Not that date. That date isn’t good enough. Bring me another date (the rock).” You two play this game, where you keep bringing management new dates (rocks), and management keeps asking for another date. Management won’t tell you for a variety of reasons: they’re afraid the date is so impossible that you’ll leave rather than manage the project; they only have some small idea about what they really want; they want you to “own” their date; or they don’t know, but they do know your date is “too late.”
Bring-me-a-rock doesn’t just occur with schedules. It also occurs with other project deliverables: requirements, specs, hiring plans, test plans, you name it. Here’s the general case of Bring-me-a-rock:
“Bring me a rock.”
“OK, here's a rock.”
“No, not that rock. A different rock.”
“OK, here's another rock.”
“No, not that one either…”
If you take the bait and start playing Bring-me-a-rock, you’ll rework the schedule or attempt to negotiate with your management until you capitulate and agree to some unreasonable date, just to stop discussing the problem or to keep your job. You might believe that once you’re back with the project team, you have a chance of creating a reasonable project, now that you’ve pacified your management.
The problem with Bring-me-a-rock is that you can’t create a reasonable project schedule, unless you rework the project requirements, and possibly change the project staff. If you succumbed to Bring-me-a-rock, now you’re stuck. Bring-me-a-rock is different from being told the end date, because if you know the end date, you can choose which requirements to implement, who you have on the project, how to organize the project, and how good the product has to be. With Bring-me-a-rock, your management will take the commitments you made for the number of people, requirements, defects, and then hold you to the new date. If you play Bring-me-a-rock, you’re stuck in a no-win position and a project headed for disaster. Bring-me-a-rock assumes that all the project variables: features, schedule, staff, how you organize the project, what you’re willing to invest in the project, and defects are independent. However, the project variables are interdependent—the choices you make for one project variable affect the other project variables.
If you want to avoid playing Bring-me-a-rock, here are some techniques:
- Explain your confidence range for the date you provide. (See Metrics Toolbox, page 6)
-
Include release criteria with your date, so you can ask the question, “What piece of the project do you want me to drop to meet an earlier date? If you tell me what we can drop, I can come up with a new date.”
-
Ask some hypothetical questions before attempting to fetch more rocks: Would you prefer a short schedule or a longer one? More people or fewer? What if we implemented this feature with incredible performance, and ignored that feature? How defect-sensitive are our users? Can they live with more defects?
-
Elicit the strategic reasons for this project. Ask several questions: Who wants this project? What does a successful solution look like? What is the project worth to you? Why are these results desirable? What problems do we solve with this project? Does the project create other problems? The answers to these questions will help your management articulate (and you understand) their underlying concerns. Then, once you understand management’s concerns, you can specify some tradeoffs your management could accept for a new date.
If your management persists in playing Bring-me-a-rock, you have options for how you choose to manage the project: you can “yes” your management and proceed with your own project plan, or you can find another project or another company to work in. Whatever you do, don’t play along with Bring-me-a-rock, because that trains your management to ask you and your project team to work on death-march projects.