ROLL WITH THE PUNCH

Introducing the next level in project risk management: antifragile project management

73666.png

In this second article in a series, we get into what antifragile is all about (from a projects- perspective) and explore some ways in which it can make project management adaptive without giving up the perceived benefits of resilience or robustness.


Resilience and robustness can both absorb the punches. Or so it would seem. What if someone has a bigger punch? That’s the problem with rigidity: there is a limit to what can be absorbed.


In projects, there are many such punches: replacement of team members … or key stakeholders such as the project manager, business owner or sponsor; scope changes … or that essential scope change that cannot be accommodated by the architecture; time compression … or that date which is impossible to achieve but is agreed to anyway—you get my drift. Any one of these could destroy a project.


A project that is antifragile is one that can absorb even such mega-punches, and survive. I am not saying that it will be a walk in the park. Of course, big punches will hurt. They may even bring the project to the brink of destruction, but it will survive. That is what antifragility is all about.
As author Nassim Nicholas Taleb points out ad nauseum, a slap on the back can be handled an infinite number of times, but replace the hand with a wrecker’s ball and that is a completely different matter. Compare a fall of 10cm to a fall of 10m. A thousand falls of 10cm are not the same as one fall of 10m, even if the cumulative distance travelled is the same.


How do you survive the wrecking ball? By using the slaps to teach the body to compensate for slaps rather than absorbing them (rolling with the punches).


Ah! you say, that’s agile project management. Not really. As Boehm pointed out, there are scenarios where agile is not going to be equally useful (BOE04). In any event, if you have not purposely set out to manage the project using agile techniques, that may be the killer punch.
Taleb describes how, by changing our outlook, we can introduce antifragility.


Our age is one that worships the positive and abhors the negative. This may be our Achilles’ heel. When we get the slightest pain, we immediately reach for the painkillers (in fact, we may even take painkillers in anticipation to nullify it in advance when we expect to engage in pain-inducing activity.)


Pain is a friend, not an enemy; it is one of the indicators or gauges on our wellbeing dashboard (YANC99). In dealing with pain, the body can learn how to deal with future attacks. Pain acts like a project’s RAG (Red–Amber–Green) system. It should be a warning, not punishment (which is what it is if we ignore it.) Negating pain is like disabling an indicator on the car’s dashboard.


Taleb recommends that rather than seeking immediate gratification, immediate positive results, we should expect to invest before we enjoy returns. Pain should precede gain. In a payoff scenario (return on investment), Taleb speaks of convex and concave graphs.


Illustration 1 (left) shows two graphs. The top one is convex and shows losses (shortfalls) gradually reducing until they turn into gains (surpluses). This is an indicator of antifragility. The bottom graph, however, show gains initially, which then turn into losses. This is what happens when brokers receive bonuses upfront, and then, when the market crashes, all the profits (on which bonuses were paid) are suddenly wiped out. However, the bonuses are not paid back. This then leaves a shortfall which, in the 2008 banking crash, was covered by the taxpayers.


Just how much are you paying for the sloppiness of others? Large software companies discontinued issuing disks with software updates some time ago. Now you have to pay for it in the downloads many times over. In a country where not everyone has access to unlimited data cap, that can be quite costly. The alternative is to not update. The cost is then the virus that slips through, or another failure. Who bears that cost? Not the company that took the profits.


Obviously, when one applies an approach developed in one field in another, some reorientation is required. The principles, however, often remain the same.


So, for example, when measuring quality, one way is to measure failure rates. In engineering, this may be MTTF (mean-time-to-failure) and MTTR (mean-time-to-repair). Quality is good if MTTF is long, and MTTR is shorter. (The longer and the shorter, the better.)


In software development, another factor could be defect discovery rates. So, for example, studies showed that there was a correlation between the number of defects found and the rate at which they were found and the as-yet undiscovered defects (or ‘bugs’, as defects in software are usually referred to).


So, one development shop may identify that the defect rate was 5:1 (five undiscovered bugs for every discovered bug). The number of bugs found in a given time is counted—say, 10 within 30 minutes of testing. If that threshold is breached, the tester stops testing and passes the module back to the developer. (From a sociology point of view, high-performance shops found they had to disconnect testers completely from developers to prevent sweet-hearting from occurring: this is where a developer and a tester become friends and the process breaks.)


Variations of this, called ‘Cleanroom development’, were used to build the software that controls high-reliability systems such as the Space Shuttle or the Mars Exploration Rover (try sending a technician to repair that one!).


These and other techniques have improved software development enormously, but you have to decide upfront which approach to use—and if you choose the wrong one, that is not antifragile. An antifragile system learns and is able to change after it has learnt (and not just wait for the next project).


Which is why I was intuitively disappointed when the editors of PMBOK removed the Corrective Action and related deliverables and activities after PMBOK3. When these are included obviously and specifically, it affects how project managers think about things.


In the next article, we will discuss ways in which projects can be made more antifragile. Many useful ideas that have been around—such as atomicity, cohesion, coupling, a risk mindset and the dangers of naïve optimisation, ‘small is beautiful’, selective redundancy, project audits, the role of programme management—and consider the implications of Taleb’s view that “the fragility of the whole system comes from two elements: the ability to hide the risks, and the fact that people have no skin in the game.”


References


BOE04: Barry Boehm, Richard Turner. (2004) Balancing Agility and Discipline. Addison-Wesley.
TALE13: Taleb, Nassim Nicholas. (2013) Antifragile. Things that gain from disorder. Penguin Books.
YANC99 : Yancey, Phillip. Brand, Paul. Pain: The Gift Nobody Wants. (1999) DIANE Publishing Company.
The author, Elmar Roberg, has more than 40 years’ experience in managing projects, programmes and portfolios in a variety of industries. He can be reached at roberg@iafrica.com.

 

comments powered by Disqus

RW1
R1
R1
R1

This edition

Issue 29
Current


Archive


TPM_Editor Don’t avoid risk, manage it better – SRK https://t.co/fTvan5fhkW https://t.co/rRE2vRrvqA 2 days - reply - retweet - favorite

TPM_Editor There's still time to secure your seat at the 2018 Tomorrow's Leaders Convention taking place at at Emperor's Palac… https://t.co/R26Vx9yviZ 12 days - reply - retweet - favorite

TPM_Editor High risk and complex infrastructure projects https://t.co/IQbvV4WQz8 https://t.co/l3GRmOYwcE 2 months - reply - retweet - favorite

  • Moses Matshiana
  • Thabang Willy Mokhari
  • Naomza Serongoane
  • Terrence Damster