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!
Thanks for this interesting post, Daniel. I set a company three months ago and I started to operate after months of planning and anticipating what could happen. What I experienced is that I didn’t consider some important factors in my plan, (how could I, it was the first time!) so I had to reforecast everything. As it was the first time planning the creation of a company, now I reckon that the best way is learn-by-doing, although here you need some sort of plan. The paradox is that the time I spend in planning is a time I don’t spend in doing and learning, and in terms of value it is more important to learn that to forecast. So what I put now on the table is this: what is more valuable, the time I spend in (trying to) forecasting or the loss of things going wrong? Better, what is the equivalence between a “unit of loss” if things go wrong and a unit of time spent in planning?
Thanks for your comment Jesus! What you’re pointing out happens to a lot of entrepreneurs. That’s why ‘modern entrepreneurship’ actually preaches the dogma ‘fail fast’. Have you heard about the book from Eric Ries ‘The lean startup’, for example? I strongly recommend it! I’m sure you’ll love it. The core idea is that you should get out there into the market as soon as possible. In a startup, a detailed plan is no more than glorified guesswork. Instead of that, what he recommends (and I side to that) is to plan the first steps, and the learning you expect to get from them. The key thing is what you learn in the process (if you learnt how to do things better, it’s not a loss!). Figure out what your assumptions are, come up with a minimum viable product (a.k.a. the simplest product that would test your assumptions; tip: it doesn’t even have to work) and introduce it to your customers. This seems like a good approach for most startups (if not all). Let me know how it goes in trying it!