I've been talking to a beleaguered colleague about his project schedule. “No matter what date I give them (senior management), they want an earlier date. I told them it doesn't take nine women to make a baby in one month, I need some time for this project!”
The Bring me a rock schedule game occurs when “they” want it faster, but don't tell you when or why. (In my experience, only senior management plays bring me a rock.) If they told you when, you could tell them what you can do. If they told you why, you along with the project team, could probably develop some creative solutions to meet their desires.
If you find yourself playing bring me a rock, stop and select one of at least these choices:
- Explain your confidence range for the date you provide. It's possible your management doesn't understand what your estimate means and it's possible you don't understand what they're asking.
- Include release criteria with your date, so you can ask specific questions about how good/full the release has to be.
- Ask some 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? Can our users live with more defects?
- Elicit the strategic reasons for this project and learn what success means.
If you agree to a too-short schedule, you're headed for project failure.
Great series! Keep them coming! It’s such a small world when you realize that others see some of the same patterns on projects as you have.
P.S. I posted a reference to this series on my site, but for some reason the trackback on your site isn’t picking it up. Not sure if it is a problem on your site or mine. Just thought you should know.
Hi Johanna,
I think we can do more than just ask questions like “Would you like X or Y?”. Instead of just asking decision makers to choose, we can explain the consequences of their choices – since often they don’t know what those consequences are. This ties in with you comment about needing to know the the strategic goals.
For instance, a customer recently asked me for a browser-based application. The catch was, we could develop the functionalty much more quickly if it wasn’t browser-based. Furthermore, the underlying (unstated) goal was not a browser solution itself, but simply ease of deployment. So we proposed options: the consequences and costs of the browser solution versus the consequen
Opps, comment got chopped off. Here’s the rest:
… versus the consequences and (lower) costs of an alternative solution and the customer made a choice.
In summary, I’m suggesting that when people ask us to fetch rocks they don’t necessary understand the options that exist, and the consequences of those options. Managers can’t read our minds, and often its only us – the technical people – who know those things. When faced with a “bad” request from a decision maker, it helps if we can assist them to better understand their choices.
Sounds like a negotiation…As Roger Fisher and William Ury suggest in their best-selling book “Getting to Yes” that understanding the interests that lie behind the request is key. Without understanding the interests, there is little option for mutual gain. It becomes a battle of wills and power – senior management usually wins because they have more power. But if we take the time to ask “Why do you want it then” or “Why not…” then we can uncover the real needs driving the request. It’s equally important to disclose your interests (keeping on track, not dooming yourself and the project from the start) so that don’t perceive it as pushback, but rather as an interest in seeing success. Uncovering interests is key to getting buy-in.
I really must read that book sometime – it crops up a lot on on-line discussions. I’m already in the habit of disclosing my own interests, as you describe, and it does help. Must read the book one day!