In the new trailer to the forthcoming film “Dungeons & Dragons: Honor Among Thieves” we get the following entertaining exchange. A group of thieves are trying to recruit an elf for their adventure, but she is clearly sceptical—about one of them in particular:
Elf: What is it, exactly, that you bring to this?
Thief: I’m a planner. I make plans.
Elf: You’ve already made the plan, so—
Thief: If the existing plan fails, I make a new plan.
Elf: So you make plans that fail?
The film isn’t out until next year, so I can’t account for its general quality, much less whether the thief’s planning practices adhere very closely to PRINCE2 or any other well-known framework. Nevertheless, I’ve wondered what might make a good answer to the elf’s question. After all, almost no significant plan can be executed without adjustment for what real life will throw at us. But surely that doesn’t mean almost every plan is a bad one. What makes a good plan?
While the world has a habit of confounding our expectations, a good project manager will be able to spot problems from afar and take suitable counter-actions to avoid them. (By logical extension, if our project manager is sufficiently skilled it doesn’t matter what the plan says—they’ll get the thing delivered anyway.) But that is a characteristic of our project manager, not the plan.
We don’t just want to rely on our project manager being sufficiently skilled—we want to give them (and us) the best chance of success to start with, and make their job as easy as possible. In terms of our plan, that means it should present maxim optionality. That is, it should make those counter-actions easy to identify and execute.
One of the problems with so-called waterfall plans was that they didn’t provide much optionality, particularly in my world of software development. Mostly the only thing they allowed was buffers, or padding, which we could use up if things took longer than expected. There was almost no opportunity to rethink the substance of the delivery as they tended to be built with tight dependencies. In contrast, the more agile approach tries break those dependencies and makes replanning integral to the process, not an exception. Risk has been designed out of the system.
But the overall lesson is one of optionality: exposing options, and making them easy to identify and act on.
Meanwhile, we shall have to wait to see what happens to the adventurers in next year’s film. The “CE” in PRINCE2 stands for “controlled environments”, and I suspect that is very much not what they can expect.
@”There was almost no opportunity to rethink the substance of the delivery as they tended to be built with tight dependencies. ”
Fortunately, I never experienced such environments. Well, a few years ago I did (“customer signed the requirements with blood, that is what they get, then they have to pay”), which made me say: “Then you don’t need my coaching.” and I left the project. Of course, after suggesting them how to rethink the substance.
Remember the saying: “Every project is iterative. If it’s waterfall, iterations start after ‘final delivery’.”
I do admire people who walk away from projects on principle.
Meanwhile, I will try to remember that saying – thank you.