TL;DR
In the previous post, we explain how other stakeholders will try to game your scheduling effort. Let’s define the first game, Bring Me A Rock. The post is based on a remarkable book written by Johanna Rothman, Manage It!
Bring Me A Rock
Johanna gives a project example. As a project manager, you decided to use A Hudson Bay Start to set the initial schedule. With the team, major technical risks had been identified. You presented your initial schedule to your boss, and the first game sets off:
Can’t you bring it in earlier?
You do a couple of iterations to close the project earlier, but none of those dates are good enough. This is a pattern for the Bring Me A Rock schedule game. The critical point of this game is that your sponsors do not provide two crucial information:
- When they want the project to be done.
- Why is your schedule not good enough.
With that information, you could rework your schedule to meet those requirements. What could you do when you hit the Bring Me A Rock schedule game:
- try to get more information. What is the preferred project end date? Could we get more team members? What about feature prioritization?
- If you get the desired date, what are the reasons for that date?
- Explain the reasoning behind your schedule; maybe the sponsor could offer some shortcuts.
- Be sure that the sponsor understands the project schedule confidence range for the delivery date. Maybe you misunderstood sponsor desires.
- Describe your release criteria. Maybe it contains too many features for the sponsor desired delivery date
To “fight” Bring Me A Rock schedule game, you should make your progress feedback visible as soon as possible:
- rank wanted features by priority
- implement by feature
- shorter timeboxes
Remember
You need to remember what is the pattern for Bring Me A Rock Schedule Game and which practices you should adopt to be ready for this game.
Comments are closed.