The concept of antifragility has been around for a couple of years but it remains less well-known than concepts like black swans which also originate from fields of philosophy and statistics. Imagine two projects facing the same budget cut. Project A collapses immediately. Project B not only survives but finds new ways to deliver better results with less money. What’s the difference? Project B is antifragile.


Antifragility was first defined by philosopher and former trader Nassim Nicolas Taleb as an ability to thrive and grow when exposed to volatility, randomness, and stressors. Between antifragility and fragility, there is also robustness, or more recently, resilience. This ability resists stressors and shocks, but it stays the same (Taleb, 2012). A resilient project is like a strong building in an earthquake which doesn’t break, but it doesn’t get better either. An antifragile project is like the human immune system. Each challenge makes it stronger for next time. Taleb encourages us to invite more volatility into our lives, societies and projects. The first motivation is that it’s an inevitable part of our existence; the second is that with a good approach, volatility can fix many complex systems like the human body, companies and organizations. In summary, Taleb states that anything fragile dislikes volatility (Taleb, 2012).

What Makes Projects Fragile?

The link between antifragility and project management might not be obvious at first sight. But the most common challenges we as PMs need to deal with are inflexibility, deficient response to change and risk aversion. All three challenges share one thing: fear of change. When we let these problems build up in our projects, they will become fragile very quickly with all of the downsides of fragility. Failing to face the volatility of these fragile projects will end up with budget overruns, postponed deliverables and frustrated and demoralized team members. These unpleasant consequences, which harm your PM reputation and disappoint project sponsors, are reasons to take a deeper look at making your projects more antifragile through the following steps.

Beyond Agile: Use The Advantage of Antifragility

A good example of where you can start being more antifragile is in projects managed using the Agile methodology. Agile provides plenty of useful tools like daily stand-ups, cross-functional teams, and a focus on continuous improvement in iterations which can be used for implementing the changes we’ll explore next. However, antifragility means thinking a few steps forward and just being Agile is not enough. Tomov says that the reactivity of Agile doesn’t satisfy the need for overcompensation required by antifragility. The project team needs to not only respond to changes in customer requests, but also partially predict them to produce results that are better than expected and earlier than expected (Tomov, 2019).

Build Options and Think Modular

Start by identifying the most fragile points in your projects. These places are the ones most vulnerable to the effects of volatility and randomness. So-called single points of failure can be irreplaceable decision-makers who insist on putting sign-offs on every single decision. You will have to create backup options for these weak points. Optionality is what Taleb refers to as the core of antifragility (Taleb, 2012). Strategies for creating optionality vary by case. Push decisions down to the people who do the work. That will lead not only to faster decisions, but also to more responsibility taken by the decision maker. For example: Marketing manager Marta managed two similar marketing campaigns. Campaign A had one approval path through the CEO. When the CEO got sick, everything stopped. Campaign B had three team leads who could approve decisions. When problems hit, they adapted quickly and delivered better results than planned.

Since optionality is a core value of antifragility, you should build your project in a modular way. Building a modular project means reducing complexity by breaking complex systems into sub-subsystems with a lower level of interdependence (Ramezani & Camarinha-Matos, 2020). Another way to promote optionality is to keep the redundancy of possible paths forward. This approach is closely connected with project risk management because creating alternative plans is based on adequately performed risk analysis and mitigation. It’s fair to say that it might become overwhelming sometime, so you should add alternative paths only to critical parts of your project where it will add (or save) the most value. 

Embrace Small Failures to Prevent Big Ones

Although managing projects and building processes with distribution, modularity, and optionality in mind is crucial, the most valuable assets on your project are the people. Mindset shift needs to happen on all levels and it’s critical in making your project antifragile. You’ll need to embrace uncertainty and change, rather than avoiding them, by encouraging your team to adopt a growth mindset and remain flexible. The number one advice on this is to maintain crystal clear communication including both celebrating success and acknowledging failures. The team should spend time together during daily stand-ups, where most of the time is spent on brainstorming risks and action items coming from recent team updates or, more extensively, from past retrospectives. The positive changes you’ll notice should be an improvement in team morale, stemming from accepting failures and mistakes as part of the progress. Nothing is more fragile than a team managed purely from a position of power and yelling at people for every mistake they make. When your project team realizes that sharing their failures and trying to fix them in front of others is welcomed, you’ll see much less frustration and even better innovation rate, or similar metrics based on the team’s ability to learn from past mistakes and continuously try to improve things. One of the primary challenges will be introducing new methods for measuring success. Many traditional metrics don’t allow failures.

As a project manager, you must take ownership of this mindset shift and serve as the primary advocate for this result. You’ll need to work on overcoming risk aversion within your teams and organization and implement a higher risk appetite into their DNA. To be clear, the change of project management approach can be very significant and implementing some of the changes would not be possible in some businesses with regulatory standards like construction, manufacturing or aerospace. 

Think Long-Term and Build Alliances

Putting more emphasis on long-term goals rather than short-term ones will create some tension between you as an Antifragile PM and the company leadership. Besides disorder and volatility, another thing antifragility likes is time. It’s caused by its non-linear nature where significant upsides are usually seen after some time. In today’s environment, driven by quarterly targets, it’s often more tempting to steer leadership’s (and sometimes the project team’s) focus on short-term gains, away from a strategic focus. You’ll need to get some allies for every successful transformation. Creating an antifragile community of practice (which may be part of an Agile community) within your organization, with presented success stories and impact, might be a way to get buy-in from senior leaders.

Antifragility as Your New Tool

Antifragility is not just another way to think about risk mitigation. We live in turbulent times, where volatility is reshaping how we manage projects. This is one of the main reasons why this powerful concept may become one of the pillars of the future of project management. Start small: identify one fragile point in your current project. Create a backup option this week – and observe the impact.

  1. Ramezani, J., & Camarinha-Matos, L. M. (2020). Approaches for resilience and antifragility in collaborative business ecosystems. Technological Forecasting and Social Change, 151.
  2. Taleb, N. N. (2012). Antifragile: Things that gain from disorder. Penguin Books.
  3. Tomov, L. (2019). Is Agile Antifragile? Computer Science and Education in Computer Science, (1), 14–20.