Application of Antifragility in Project Management

Revision as of 12:13, 23 September 2015

Introduction

“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.

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”.

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.

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.

Application

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.

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.

Application

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

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.

Limitation

The aim of making project portfolios learn from others mistakes, is easier in companies which have a product competing on innovation, because it is easier to address a certain need from the market. In a construction project, there are typically a consulting company and a contractor. This type of project organization can be challenging, in terms of making projects within portfolios learn from others mistakes. In the car industry, the manufacturer is both “consultant” and “contractor”, in the sense that the car company is both designing, researching and producing the cars. This gives a very important possibility to share and learn experience within the company, but also being able to research and develop cars for the needs of the client (market). In the construction industry, the consultant and the contractor are typically not in the same company. Often they work together for the first time on a project, this is increasing the demand for good communication between both parties. To have completely control of the process from idea to product is clearly an advantage in terms of making your portfolio antifragile.

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