Application of Antifragility in Project Management

Latest revision as of 16:51, 18 December 2018

Lasse Rasmus Hoier

[edit] Introduction

[edit] Fragility

“To see how large things can be fragile, consider the difference between an elephant and a mouse: The former breaks a leg at the slightest fall, while the latter is unharmed by a drop several multiples of its height. This explains why we have so many mice than elephants”^[1]

Organizations established on the idea that any volatility is poison to the system, is not in balance with the laws of nature. Such organizations is fragile and will properly suffer from times with high volatility. Exposed to high volatility has the ability to show vulnerability or weakness of an organization. As the immune systems thrives with viruses in order to keep being intact, the antifragility organization thrives with volatility in order to improve and grow. In this sense, nature gives the answer to high volatility in organizations.

The projects of our time are designed for stability and can be defined as highly complex, pursuit of effectivity and interdependency.

[edit] Complexity

In order to understand this; imagine how a project would look like in the past century. The projects were less complex, simply because projects had a lower technical level. Things such as the globalization also add to the complexity. While the parts for a building usually was build or assembled nearby in the past, things are usually shipped to the construction site from the other side of the world today. A lot of the processing of high complexity within an organization is divided into the various academic disciplines. This can be a great challenge to the project management and demands a high level of communication from each discipline. In order for the project manager to make the best planning, risk analysis etc., the complexity has to have more focus in the project management. High complexity has the tendency of surprising, because no one “saw it coming”.

[edit] Efficiency

Second, the efficiency is a huge driver to failure in projects. In the pursuit of efficiency, fewer and fewer things are controlling more and more.

“The stock exchanges have converted from “open outcry” where wild traders face each other, yelling and screaming as in a souk, then go drink together. Traders were replaced by computers, for very small visible benefits and massively large risks. While errors made by traders are confined and distributed those made by computerized systems go wild”^[2]

The thrives for efficiency has for the past 2-3 decades been rapidly increasing, but the risk is neglected. In projects were communication between each discipline is a key word, the high computerization can be a big challenge to handle. Within this computerization lies a high risk to the project schedule. This argues for more understanding of the computer systems in order to reduce the complexity. The term “Black Swan” defines a rare and unpredictable event, highly difficult to prepare for. “Black Swan” is a typical phenomenon in a fragile system. What we should do is build a system, that is not fragile to these events.(see figure 1)

Figure 1 - Black Swan

Thirdly, interdependency is the indispensable link between “efficiency” and “complexity”. The interdependency is a never-ending story, always seeking to be more efficient and thereby more complex. For the project to be successful, the project manager most learn to deal with an increasing level of complexity. The ability to identify areas of high complexity within the project is of great importance in future project management.

[edit] Create Project Portfolios That Can Collectively Learn From Others’ Mistakes

"So is often the mistakes of others that benefit the rest of us – and sadly not them"^[3]

In an antifragility project, the benefits from an error should be greater than the harm. This is properly one of the strongest aspects in relation to antifragility in projects. Often engineered projects have an integrated ability to withstand volatility. We just have to learn how to use it prospectively.

Think of aviation, if a plane crash is observed and the obvious reasons are somewhat unclear, the Aviation Authority would immediately “ground” all flights of that type. This is of cause a tragic for the people on the plane that crashed, but for all future people flying with that type of plane, the tragic will properly end up increasing the safety of the plane. This is a typically antifragile industry, because the error is ending up improving the system.

The definition of a good system is:

• The amount of errors within the system is small
• Each individual error is small, and will not cause a chain reaction (a small error should not lead to a bigger one)
• Negatively correlated to each other (lowering the odds for future errors each time a error is detected)

Having this information in regards to management of projects, program and portfolio, the idea of having a broad knowledge sharing across a whole industry is not new. In relation to antifragility in management of portfolios, programs and projects, the metaphor “a handful of pebbles instead of one big stone” considering the weight of the stones is essential. In order for the higher level to be antifragile, it may require the fragility of the lower level. In terms of management within portfolios, programs and projects, it is required for the portfolio to survived and be successful that each individual project is fragile. In the antifragile portfolio management, the error in a single (or several) projects will not cause any large harm to the portfolio.

The portfolio of cars in BMW ^[4] is all the different “series” spanning from 1-series to 7-series (incl. a series of electric cars), each “series” is a program and each “car type” is the project. For the system or portfolio in this case to antifragile, each projects or program should be fragile. For instance, if the market segment for big 4WD vanish due to rising price on gasoline, cars with a lower fuel consumption would properly prosper from this development. As the example of BMW, the completely new era of driverless cars, could argue that the portfolio of BMW has some challenges in terms of antifragility.(see figure 2)

Figure 2 - Antifragility in Project, Program and Portfolio

The impact each individual project has on the overall portfolio requires consideration. Each project will benefit from a well-proportioned distribution, allowing each project to perform trial-error experiments. The idea is to insure the overall status as antifragile, on the expense of fragile projects. This gives a project culture that thrives from mistakes and has the size to fail cheap.

[edit] Antifragility in Portfolio Caused by Fragility in Program/Project

Volkswagen (VW) manufactured in 1998 the car VW Lupo [^[5]], in this case VW had analyzed the market and decided to launch this “micro-car class” with low fuel consumption. Later on, the market for this car type disappeared along with the “start/stop” technology causing VW to stop the production of these “micro-cars”. A decade later in the aftermath of the financial crises, the segment for these car types showed up again. Several technologies from the Lupo are used today in the “blue-motion” cars. In the production of the Lupo, experience was also an important aspect to consider. The initial technology was vulnerable to hard wear and tear, caused by the several start and stop. Later on, design and experience from the Lupo was used in the “blue motion” technology, but only allowing the engine to start and stop when the engine is hot. Therefore, along with the failure of the initial Lupo car, several other projects within VW prospered from this failure.

[edit] Fail Often, Fail Cheaply

Trial and error have much more value than the general understanding. Conducting small-scale trial/error experiments will give much more value to the decision making, than just a success in the first trial. The rationale behind this idea is to use this tool in search of a much smaller risk of failure.

“If you are looking for your misplaced wallet in your living room, in a trial error mode, you exercise rationality by not looking in the same place twice. In many pursuits, every trial, every failure provides additional information, each more valuable than the previous one – if you know what does not work, or where the wallet is not located. With every trial, one gets closer to something, assuming an environment in which one knows exactly what one is looking for. We can, from the trial that fails to deliver, figure out progressively where to go”^[6]

Concerning trial and error experiments in management of projects, programs or portfolios, the definition of success should be clear:

• Project/products with a clear success/failure outcome (e.g. Edison’s light bulb)

Definition of success:

• Simply make it work

The level of innovation is typically defining the success or goal of this type of product. Often the technology in the time after the success of the product will tend to optimize the initial product. The knowledge from the previous trial-error experiment increases the chance of success in the next experiment. For the project where the success criteria is constant, this approach is adequate. This is often the case if the project/product is a highly innovative.

• Project/product where each stakeholder has a definition of success (e.g. large scale civil engineering project)

Definition of success:

• quality to the client
• cheapest project
• fastest time

Or even something else

In a large-scale project with multiple stakeholder interest, simulation to the end user would be a possibility of trial-error experiments. In this way, the success rate is increasing by every failed design of the building. Concerning trial-error experiments of projects, programs and portfolios, the best tool is to simulate different experiments in search of increasing the success rate. Making small-scale experiments such as simulations, mock-up models or 3D prints, the “search” can initial end up as a trial error mode. Further elaboration of experiments in project related context processed. In a practically sense, the term “BIM related tools” should be mentioned, making it possible to present the end user to a trial-error experiment. Conducting virtual simulations is often the strongest tool in large-scale projects.

[edit] Trial-Error Experiment in Construction Projects

The planning of a multi-story building along with the surrounding infrastructure is started. The simulation of both the erecting of the building, as well as the completion of the infrastructure is giving the project management team a chance to present the final design to the client. Being able to redesign the building, increasing the success rate significant. In addition, real-time mock-up can be used as a way of conducting an experiment, e.g. to see how a material deteriorate over time. Making it possible to the client to choose another type. (see figure 3)

Figure 3 - Trial-Error Experiment

[edit] Small Projects and Project Teams Are Efficient

“Large projects are inherently more risky than small projects – the maximum possible loss is bigger”^[7]

Large organizations or projects have a tendency to overrun budget or schedule, more often than smaller organizations or projects. Again looking at the laws of nature, large animals seem to be fragile to small things and have a harder time to adjust to new challenge. The idea of being small and agile and being able to adapt quickly is interesting in relation to management. Referring back to the stone and its weight in pebbles. The cost associated with large organizations or project tend to reach an exponential increase. Smaller organizations or project teams tend to do the job more efficient and transparent.

In terms of cost overrun, Nassim Nicholas Taleb is defines:

“A squeeze occurs when people have no choice but to do something, and do it right away, regardless of the costs”^[8]

In relation to portfolio management, the idea of organic growth instead of acquisitions is preferred. Large acquisitions have the tendency to cause “squeeze” to the acquiring company. This is also the case for large projects, where the costs seem to increase significant, but the efficiency seem constant or even slightly declining. The idea is to reduce fragility by reducing the size of the projects or the project teams. In this way, there is a good chance to act proactive, if the project is “off track” in regards of cost, schedule etc.. In some project, the dividing into smaller project teams seems logic, but this is not always the case. In projects where planning is monolithic, such as bridge and tunnels, the dividing into smaller project teams is preferred.

[edit] Discussion

[edit] Pros

Showing how antifragility can be applied in management of project, program or portfolio, several central topics has been mentioned. Concepts as "complex, effectivity and interdependency" in an organization is the perfects argument to start developing a more antifragile organization. Instead of preparing against times of high volatility, focus should be on creating an organization/portfolio that thrives from such impact. Additionally, the experience that lies within mistakes from others should be fully utilized. This is also in a sense redefining the term "fail", as it is used to increase the success rate. The benefit would without doubt be a more agile organization, making progressed from adversity. In project organizations and projects, smaller size should be more common. In this way, smaller project organizations is more efficient and able to adapt faster at lower cost than a large organization. The scope of a smaller team is to devise a smart and simple solution to a complex problem. Large teams have a tendency to add to complexity and cost.

[edit] Cons

The typically project structure for a construction project can be challenging in terms of concepts mentioned in “Create Project Portfolios that can Collectively Learn from Others’ Mistakes”. As the project changes, stakeholders is changed. This is obvious challenging, as the “collective learning from others mistakes” process clearly is dependent on commitment from all parties involved. The collectively learning is hard to initiate in industries that deals with changing projects and therefore changing requirements.

The collective learning is much more reachable within each company, across programs or project.

In addition to “Small Projects and Project Teams Are Efficient”, the idea of small project teams and projects is preferable. This is however not always possible, as stated in ^[9] by Bent Flyvbjerg [1], a famous Danish economic geographer, the idea would not be applicable to all types of projects. The size of each segment of the project is what matters not the size of the entire project. Large projects like bridges and tunnels is based on a monolithic planning. It is simply not possible to break these types of projects into smaller parts, making it hard to implement smaller project teams or project.

[edit] Annotated Bibliography

1. Nassim Nicholas Taleb, Antifragile - Things That Gain From Disorder, New York Times - The book addresses some very fundamental issues of the society, human behavior, uncertainty and decision making.
2. Josef Oehmen, Christian Thuesen, Pedro Parraguez Ruiz and Joana Geraldi, PMI Whitepaper, Complexity Management for Projects, Programmes and Portfolios: An Engineering Systems Perspective - The paper is containing new topics which could be relevant to PPPM. The paper is used to get a useful connection to PPPM.

[edit] References

1. ↑ Taleb, N.N. Learning to love volatility. The Walls Street Journal
2. ↑ Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times
3. ↑ Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times
4. ↑ Josef Oehmen, lectures on management within project, program and portfolio
5. ↑ https://da.wikipedia.org/wiki/Volkswagen_Lupo
6. ↑ Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times
7. ↑ J.Oehmen, Christian Thuesen, Pedro Parraguez Ruiz and Joana Geraldi, Complexity Management for Projects, Programmes and Portfolios; An Engineering Systems Perspective. Antifragility: Thriving on Uncertainty and Volatility, PMI
8. ↑ Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times
9. ↑ Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 282 New York Times