How much planning is enough? How much planning is too much? Do we want to try to anticipate every detail before we start moving, or rather start the project and figure out as we go?
In the project management arena I find this reflection to be quite relevant. Obviously, both options have advantages and disadvantages. Many project managers (or more often, their clients or their companies) will tell you the benefits of having a good plan. You can optimise that plan. You can communicate the plan to other stakeholders. You can track your progress (and know if you’re going to finish on time). Your client knows exactly what they’re (supposed to be) paying for.
On the other hand, those who swear upon agile and lean will differ. The world changes rapidly, and you’re often missing most of the information when you start. Your plan is bound to be a naïf interpretation of what you wish will happen. Not to mention the common fallacies in planning.
Both points of view are right for some projects, and wrong for others. Unfortunately, in my opinion a great amount of projects fall in an uncomfortable in-between. And that includes a number of volunteer projects that I have been involved in.
One solution that I have found useful is to plan on what we could call different levels of truth, depending on how reliable (or critical) that part of the plan is. Imagine having a plan for each of the following levels:
- “Absolute” truth (reliable at least). This includes parts of the project that are influenced by external elements that are… well, predictable. We can mark the date on our calendar. Maybe we’ll have to move the scope a little, but we know that there needs to be something by then. This is the place for milestones, or parts that affect other stakeholders. You’re quite sure that those things will happen, although it gives an extremely vague image of the future..
- Expected roadmap. This is a minimalistic plan. This can extend until the end of the project, but don’t spend too much time doing useless guesswork. Try to get information (if possible) from previous similar projects. Use averages. One day up or down here doesn’t matter (maybe even one week up and down), but it will let you know how feasible different strategies are. It will let you tweak the plan, so that you start with the right tasks, and you know, for example, what your critical path is. It’s a bit more sophisticated than the previous (it gives a better image), in exchange for a higher uncertainty.
- To-do’s. This one is short-term, with reliable estimates from your team. And it’s so short-term, that those estimates are bound to be accurate. It is often a detailed version of the roadmap, that you build as you go. If it starts to diverge too much from the roadmap, then you have to go back to the roadmap to redefine it. You’re quite sure you’ll accomplish it… because it only reaches out to the immediate tasks, the next two or three weeks.
You can keep three independent plans (and track them), of have three colours on your calendars, or three task lists. The key for it to work is that on each one you have the right mindset. That way you can still make decisions and react to the environment, while still acknowledging the uncertainty in the world.
Of course, this is not the solution for all projects. But it does create a bridge between planning-intensive and agile methodologies for project management. I can imagine people from both sides saying ‘oh, we do that, actually’.
Are you doing something similar in your projects? Does this make sense to you? How do you face uncertainty? Use the comment box below to share your experience!