Forget Precise Long-Term Plans – Focus on Risk Lenses Instead
TL;DR (AI-powered): For multi-year fixed-deadline projects: stop estimating every task. Chunk the work → gauge volume vs. proven throughput → hunt bottlenecks & uncertainty sources (scope, key teams, surprises). Lenses beat lies; conversations beat Gantt charts.
Short and sweet this time around – also a bit more on a conceptual level (although hinting at a practical example).
In the end, it’s all about the utility of the lenses you use and the conversations which are triggered by deliberately using them.
To be clear, I don’t mean that at all in some fluffy “hugging-tree-like” manner. On the contrary, I mean it in the most pragmatic sense. And let’s take as an example a matter like trying to project a rather long-term initiative – just something I am having to deal with at work, so it’s on my mind.
I can almost bet what some of you might be thinking – What’s the point of trying to project so far off in time?
Fair point. Only that sometimes we don’t have much of an option. Like when we are enabling technical solutions tied to a gigantic infrastructure project. Say, bringing live a whole new distribution center constructed across a few years.
Sure we will keep our options open in terms of trade-offs and working through the gritty details with agility as much as possible. But the date (to go live) is the date – non-negotiable; at least not without quite some practical implications. That brings us to the first useful lens.
Don’t aim at creating a (false) sense of certainty so far off. That shouldn’t be the goal so early in the process. Aim rather at understanding the level of risk you’re carrying and make sure that’s at an acceptable level.
What are some of the practical implications of that?
You will have to somehow systematically go through all that you have to take into consideration (let’s call them “requirements” or even better, “business needs”). But do we necessarily have to aim at estimating each and every piece of work in some form or fashion? I would place my bet rather on understanding roughly how many “chunks of work” we expect to have (give or take) – that can be helpful because it enables us to use a lens of contrasting that against what we have observed in delivery (throughput) historically and take that along with some other sensible assumptions (after all, most likely, that’s not all the teams will be working on in the period).
By going somehow systematically through it, you will likely get a sense of where the bottlenecks are. And that matters because those are the most common sources of uncertainty. And that in fact can be from a few different angles:
In scope: where and how much uncertainty is there on understanding of the problem and therefore the suitable solution (or options) to implement?
In workload: which teams are in the critical chain to deliver? Because those are the ones to focus on and make sure the assumptions on risk are at an acceptable level – which in turn informs how to keep that way.
In moving parts and potential emerging changes: are there assumptions we are taking today for which we have more of a feeling things could emerge, and change could come about that could have an impact on direction and affect execution against plans?
In other words, you make sensible use of some useful lens and that guides conversation. And if the right people are the ones having those, then we can have a chance – in fact, a solid chance to stand a chance against the largely unpredictable nature of trying to put in place so much upfront a plan.
People, in the end, are the ones who solve problems. Knowing what are the potential bottlenecks, “hotspots” (where we expect likely emerging changes) and things like are the first steps that can enable doing so.
Anything else is just tools – yes, even some of them are quite powerful already and potentially even more so.
By Rodrigo Sperb, feel free to connect, I’m happy to engage and interact. I’m passionate about leading to achieve better outcomes with better ways of working. How can I help you?