The Three Ways to Make Your Project Resilient
Embracing resilience allows you to stop lying to yourself and your project sponsors about your lousy capability to predict the future. Instead of relying on luck, resilience affords you the luxury of being wrong, but succeeding anyway.
There are three levers you can use to make your project resilient:
Your means: Pick the right project management practices
Your ends: Be clever about the results your promise
Your circumstances: Wait for the stars to align in your favour
Let's call that the "Means, ends and circumstances framework of project resilience". If you scroll down a little (or keep reading), I will highlight a handful of practices in each category.
We talked about it at the 7th IDA International Risk Management Conference last week, and it is part of Morten Wied's PhD thesis that he defended successfully just yesterday (it is also under review at one of our favorite journals, and were are battling it out with the pesky reviewers). As customary in academia, the PhD student does all the heavy lifting - thank you Morten. My privilege as their advisor is to appropriate their results for blog posts (you are welcome).
What if... you designed a big research study on project resilience around one of your favorite comics?
Well, it turns out that the fabulous Randall Munroe, in one of his equally fabulous XKCD comics, summarized the results of this multi-year study. Even better, he did that BEFORE we even got started. While I did not acknowledge his genius in our other publications, I shall rectify that omission here.
Figure 1: Although it promises the best outcome, don't bring a gun to a gun fight, because you will still be in a gun fight (Source: Randall Munroe / https://xkcd.com/1890/)
We followed a highly innovative (and risky) project here in Copenhagen, developing an autonomous bus service to close the "last mile" connection between public transport and people's homes. The idea is that such a service will massively improve adoption rates of public transport. The problem is that getting an autonomous bus service to work in an urban environment is ... tricky. (Many thanks at this point to Kenneth Jørgensen at Gate 21 for his patience with us.).
Of the 12 major adverse events that we identified over the last 3 years, only 4 had been identified as critical risks prior to their occurrence.
Figure 2: Autonomous busses in urban environments - how hard can it be? (Image credit: Gate 21)
The project is on track, not because the project management team was particularly skilled at predicting the future and articulating detailed plans. But because the project team was able to detect, resist, recover, and learn from, significant adverse events quickly and effectively.
So, getting back to our "what-to-bring-to-what-fight" picture, we clustered these resilience practices into three major categories: Changing the means (i.e. what you bring to the fight), changing the ends (i.e. what outcomes you are happy with), and changing the circumstances (i.e. what fight to show up for in the first place). I will discuss those practices below, along with insights from two other studies (a literature review and a large interview study).
Project Resilience Practices, Part 1: What to bring to the fight - Changing your "means"
The first set of practices focuses on what you can change in your project execution to move away from trying even harder to predicting and planning the future, to monitoring and reacting to what happens in real life.
Sequential and incremental delivery instead of one-shot, monolithic "big bang" results: Achieve your ends one salami slice at a time, and allow yourself to correct course between slices (who just said "Agile"?). Yes, that is hard when you build a bridge or any other highly integrated system where the value goes from 0% to 100% when you fasten the final bolt. I didn't say resilience was easy.
Take action to generate information, instead of waiting for information to take action. Fail early, fail fast, and fail cheap. Make sure that your activities are designed as learning exercises around your biggest uncertainties. And make sure that your bosses understand what you are doing.
Look for big chunks of ignorance, not additional detail to things you already know. Your biggest problem is unrecognized ignorance, not missing additional details. Make sure you know enough about all critical requirement, technology and capability risks. If you focus your attention solely on one area, you expose yourself to big and bad surprises in the others.
Study projects that got it wrong and still did not fail. I positively hate firefighting as an excuse for bad up-front planning, and I hate how our organizations consistently promote firefighters. Your job is to learn from those examples on what the avoidable mistakes were (and how not to repeat them), and reserve the firefighting for the residual risks (a small chunk).
Practice what you preach, instead of expecting new skills to emerge the second you need them. Resilience capabilities fall neatly into four categories - detecting, resisting, recovering and learning. Practice those capabilities from the get-go. How do notice quickly that things are deviating from our expectations? (Hint: Ignoring reality for too long is the number 1 cause of promising project management careers tanking prematurely). How do we take corrective actions quickly, locally, without bureaucratic hurdles and excuses? How do we get back on track? And how do we make sure that this does not happen again? Have a look at our reslience workbook for inspiration.
Project Resilience Practices, Part 2: What outcomes are you happy with - Changing the "ends"
Your project will be more resilient, if you maintain flexibility around what constitutes success. While this may sound like a recipe for disaster (scope creep anyone?), skillfully exploiting the - what I like to call - 'useful ambiguity' surrounding your project can be a life saver. Specifically that means:
Go for reversible instead of irreversible results: Build in an option to go back and try again if you do not like the results of your project.
Deliver multifunctional performance instead of specialized capabilities: Do not semi-arbitrarily pick one very specific vision of the future that your project will succeed in. Plan for multiple scenarios, and a value proposition that makes sense for all of them. This includes "buffered" results, that can thrive under both higher demand (and revenue) and lower demand (and revenue), as well as "convertible" deliverables that can be repurposed at minimum effort.
Ballpark results and understate outcomes, instead of overpromising and underdelivering: The nuclear industry never recovered from one foolish promise by one foolish person in the 50ies, promising energy "too cheap to measure". Let that be a warning to you. Educate your steering committee on optimism bias and the virtues of being conservative, honest and trustworthy.
Think big menu of options, not long list of must-win-battles: Old military wisdom holds that the decision that gives you most options for future actions is the right decision. Do not fall into the trap of paralysis-by-analysis, but maintain options for course adjustments as long as you can.
Create many alternatives, and pick the winner later. Redundancy is a favourite method of management-by-deep-pockets. If your pockets are somewhat shallower, you can still pursue this option gate-to-gate: Develop and evaluate alternative options before committing to a specific course of action. Then rinse and repeat for the next project phase. This is the strategy that got us a COVID-19 vaccine at 10x the regular speed - just because it is expensive does not mean it is not worth it.
Project Resilience Practices, Part 3: What fight to show up for, and when - Changing your "circumstances"
The third and final group of resilience practices centers around the simple question of what fights to pick, and what fights to walk away from. And what fights to wait and see, and jump in when your chances have improved.
Pick projects with clear superiority over competing alternatives, instead of hotly contested ones: Sounds like a no-brainer? It is a bit more tricky, as your circumstances, among them what are considered viable alternative options to your project, will change over time. This makes an argument for short project durations - the shorter the project, the better your chances to understand your circumstances from the get-go.
Pick projects where all alternatives are variations of a theme, instead of projects with a long list of fundamentally different alternatives: This sounds similar to the previous point, but highlights a different aspect: If there is no clear winner among the viable alternatives, pick circumstances where you can cover a large swath of viable options WITHIN your project, instead of facing them as outside competition.
Wait and see: This one is really hard. Especially if you end up waiting too long and missing that massive opportunity you were looking at for months or years. Clearly articulate what your expectations are regarding the circumstances, giving yourself a chance to win. What are the economic factors, the minimum funding and staffing, the technology readiness, the market conditions that would make this project worth your while? And what are the cut-offs where you happily decide not to engage? The secret of the most successful poker players is not how they play their hand, but how they decide what hand not to play.
Why are we not doing always doing this?
Resilience is not free. As you read through the strategies, you will have paused at least at every second point, immediately coming up with a strong counterargument: If your project results are, say, reversible, then how do I lock in my organization and our sponsors to throwing good money after bad when things start going sideways? Wouldn't this make it easier for them to just cancel my project? And how are you supposed to incrementally deliver a bridge or a tunnel? The first 5 meters are not going to generate 10% of the value of covering a 50m span.
That is true. Plus the big question always is: Is the cost of a resilient project, e.g. building two solutions instead of one, worth the price? Or is it cheaper just to fail with one, and then see what's what?
Write to me if you have the answer. Please.
References and additional reading
Morten Wied's PhD thesis and other publications at the DTU Library.
Wied, M, Oehmen, J & Welo, T 2020, 'Conceptualizing resilience in engineering systems: An analysis of the literature', Systems Engineering, vol. 23, no. 1, pp. 3-13. https://doi.org/10.1002/sys.21491
Wied, M, Koch-Ørvad, N, Welo, T & Oehmen, J 2020, 'Managing exploratory projects: A repertoire of approaches and their shared underpinnings', International Journal of Project Management, vol. 38, no. 2, pp. 75-84. https://doi.org/10.1016/j.ijproman.2019.12.002
Stingl, V., Oehmen, J., & Wied, M. (2019). Surprise, Surprise! A workbook for finding the keys to resilience in your strategic initiatives. Technical University of Denmark. https://doi.org/10.11581/dtu:00000067