DTU ProjectLab - User contributions [en-gb]

Application of Antifragility in Project Management

2015-09-27T13:59:29Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

==== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|center|600px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|center|600px|thumb|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.

==== Antifragility in Portfolio Caused by Fragility in Program/Project ====

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

==== 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)

[[File:Figure 3 - Trial-Error Experiment.PNG|center|750px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Discussion ==

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

=== 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 <ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 282 New York Times</ref> by Bent Flyvbjerg [https://en.wikipedia.org/wiki/Bent_Flyvbjerg], 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.

== Annotated Bibliography ==

#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.
#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.
== References ==

<references />

Talk:Application of Antifragility in Project Management

2015-09-25T15:01:29Z

Lassehoier87:

Josef: Hello, I really like your idea of looking at antifragility and its application in project management. However, I am not entirely sure if your discussion of "simulating failure scenarios" and "upside/downside risks" fits the heading. If you look at our PMI whitepaper, you will find a few categories/principles of Antifragiltiy and their application to project management. Nassim Taleb's book (which I reckon you must read if you were to write about Antifragility) contains many more possible points of "connection". I suggest to take that as a "point of departure", and see what you can apply how to project management.

=Feedback of s141506, Reviewer 2=

== Structure ==

* I didn't find really any grammar mistakes which is good.
* Are the first chapters part of abstract or introduction or what.. You could elaborate little bit more with headings in the start so it would be easier to reader to follow the text.
** ''I have created subheading for the introduction part, to improve the overview of this section.''
* In the article there is often mentioned number 1 and then bulletpoints. For example the chapter''' The definition of a good system is '''. Is it suppose be like this and also the other same kind of chapters?
**''I have deleted the numbers and just made bullet points.''
*Maybe samekind conclusion in the end would wrap the text better together. Now it is little bit scattered in different parts.
** ''In the end of the article I have made a new section called " Discussion" with subheadings of "Pros" and "Cons" to wrap everything up and comment on the limitations.''

== Content==

* Having the aviation of one example for antifragility is very good. It gives reader immediately better understanding of the whole consept.
*Pictures are nice looking and simple but still informative. Reader can easily understand what write have wanted to show with the picture.
* Like I wrote in structure that try to use more headings.
** ''I have added a couple of new headings.''
* You have used much New York Times articles as reference, it can be quite one-sided.
** ''the reference is not to a article, New York Times is the publisher of the book I have been using''.

== Overall==

* Good article about subject that for me personal didn't have much information.

==(S142899_I am not aware of whether I am reviewer ½ or 3)==

*Summary of the references are missing at the end.
**''I have made a section with reference and under the section "annotated bibliography" there are a few comments on the reference.''

''Thanks for the review, you made some good point and I have almost used all of them!''

A)
*Generally the level of grammar structure is in a good level. Some expression mistakes were found though for example:(….is not in balance with the laws of nature.
….. is fragile, repetition of the word “volatility”)– in the first paragraph expression mistakes
** ''I have rephrased the sentences and tried to correct the expression mistakes. Though I was not able to find the mistakes in the first sentence.''
*“The projects of our time are designed for stability and can be defined as highly complex, pursuit of effectivity and interdependency.” missing reference probably
** ''There is not reference in this part. The sentence is based on ideas from the book, but no direct reference. ''
*”For the past 2-3 decades, we have continued the pursuit of efficiency” - who we?
** ''This is corrected to emphasize the point I was trying to make.''
*“What we should do, is build a system that is not fragile to these events.”- comma in the wrong place
** ''corrected the comma fault.''
B) missing reference to the figure 1 and remember to mention it in the text before the figure
* ''I have made reference in the text to the figure, making it easier to the reader.''
* Why table of context is in the middle of the text?
** ''The content list should be in the correct place now.''
*Under the paragraph Create Project Portfolios that can Collectively Learn from Others’ Mistakes:
“The definition of a good system is:
"1."
 The amount of errors within the system is small
“remove the number “1”.”
**''The number is removed and replaced with a bullet point. ''
*” Concerning antifragility in management of portfolios, programs and projects. “ is unnecessary”
**''this sentence is removed totally and replaced with something else. ''
*In the BMW example insert reference not only to the text but also to the figure 2.
**''I have made a reference to the lectures from Josef ''
*Under the “Application” paragraph’s I would probably insert also the other examples that you use in the article in order to make this paragraph more concrete.
** ''I have decided to add another heading instead but still having two different "application" sections. The sections is dealing with two different ideas and I think this would be confusing to the reader. ''
* find reference for the production of the Lupo mentioned in this paragraph as well.
** ''This reference is found and added.''
*The fact that you are using so many quotes adds to the article but you could try to eliminate them into 2-3 max since it reduces reader’s “reading flow” at some point.
**''The topic of this article is new knowledge to me also, the idea of the quotes is to compact the essence of the topic into one line, and further elaborate in the rest of the section. But I see your point and maybe you are right.''

C)
*I would recommend to spend a little more time in reviewing the intro and the closing part of the article in order to provide a more solid base for the reader with more details and raping up of the scope of the article
** ''The introduction is divided into sub-sections, in order to make it easier to the reader and catch the interest. In the end of the article a section "discussion" is made with "pros" and "cons" in order to discuss the limitations of the ideas in practice. ''
*Adding subheading for example naming the different cases would also add to the context of the article
**''Good idea this is done''

''Thank you for a really good review, definitely somthing I could use and I think it made the final result much better.''

=Reviewer 3: s113665=

* The entire article is very well written with a good use of punctuation and a prober technically language.
** ''Thank you!''
* The first section of the article is quite long.
** ''The first section is divided into smaller part with sub headings''.
* Add a title.
** ''The title is added''
* Consider dividing it into a couple of subtitles as well.
**'' Yes, this is done and the I think it works better now. ''
* You have two sections named ‘Application’.
** ''The section is renamed with two different names.''
* As it however may be the prober way of division, it still adds unnecessary confusion.
* Nice graphics with good relevance to the subject!
* Well-made ‘References’ section!
* (I’m stealing some of that for my own article ;))
* There maaaay be a bit too many references in the text, and some of them are also quite extensive and could be shortened without loosing the ‘article’- and dramatic effect.
** ''I perfectly see you point, but as this a totally new topic to me (and properly also the reader) the idea of making one sentence which contains the main idea of the whole section is good sense to me. But you could also argue for the idea you are making. ''
** Would prefer to have the longer ones interoperated and incorporated in the main text instead of being an independent section in quotation marks.
** ''I tried to do that also, but many of the quotes is metaphors making it a bit more fun to read, I think at least. ''

There’s not much else to add, as it is by far the most finished article I’ve seen and reviewed! The article is neither in the need of additional proofreading, as there are next to no spelling-/grammar-/punctuation errors!
Bottom line it is a good article and I wish you good luck for the final review and grading!

''Thanks for the review, definitely something I used.''

Talk:Application of Antifragility in Project Management

2015-09-25T14:56:35Z

Lassehoier87:

Josef: Hello, I really like your idea of looking at antifragility and its application in project management. However, I am not entirely sure if your discussion of "simulating failure scenarios" and "upside/downside risks" fits the heading. If you look at our PMI whitepaper, you will find a few categories/principles of Antifragiltiy and their application to project management. Nassim Taleb's book (which I reckon you must read if you were to write about Antifragility) contains many more possible points of "connection". I suggest to take that as a "point of departure", and see what you can apply how to project management.

=Feedback of s141506, Reviewer 2=

== Structure ==

* I didn't find really any grammar mistakes which is good.
* Are the first chapters part of abstract or introduction or what.. You could elaborate little bit more with headings in the start so it would be easier to reader to follow the text.
** I have created subheading for the introduction part, to improve the overview of this section.
* In the article there is often mentioned number 1 and then bulletpoints. For example the chapter''' The definition of a good system is '''. Is it suppose be like this and also the other same kind of chapters?
** I have deleted the numbers and just made bullet points.
*Maybe samekind conclusion in the end would wrap the text better together. Now it is little bit scattered in different parts.
** In the end of the article I have made a new section called " Discussion" with subheadings of "Pros" and "Cons" to wrap everything up and comment on the limitations.

== Content==

* Having the aviation of one example for antifragility is very good. It gives reader immediately better understanding of the whole consept.
*Pictures are nice looking and simple but still informative. Reader can easily understand what write have wanted to show with the picture.
* Like I wrote in structure that try to use more headings.
** I have added a couple of new headings.
* You have used much New York Times articles as reference, it can be quite one-sided.
** the reference is not to a article, New York Times is the publisher of the book I have been using.

== Overall==

* Good article about subject that for me personal didn't have much information.

==(S142899_I am not aware of whether I am reviewer ½ or 3)==

*Summary of the references are missing at the end.
**I have made a section with reference and under the section "annotated bibliography" there are a few comments on the reference.

Thanks for the review, you made some good point and I have almost used all of them!

A)
*Generally the level of grammar structure is in a good level. Some expression mistakes were found though for example:(….is not in balance with the laws of nature.
….. is fragile, repetition of the word “volatility”)– in the first paragraph expression mistakes
** I have rephrased the sentences and tried to correct the expression mistakes. Though I was not able to find the mistakes in the first sentence.
*“The projects of our time are designed for stability and can be defined as highly complex, pursuit of effectivity and interdependency.” missing reference probably
** There is not reference in this part. The sentence is based on ideas from the book, but no direct reference.
*”For the past 2-3 decades, we have continued the pursuit of efficiency” - who we?
** This is corrected to emphasize the point I was trying to make.
*“What we should do, is build a system that is not fragile to these events.”- comma in the wrong place
** corrected the comma fault.
B) missing reference to the figure 1 and remember to mention it in the text before the figure
* I have made reference in the text to the figure, making it easier to the reader.
* Why table of context is in the middle of the text?
** The content list should be in the correct place now.
*Under the paragraph Create Project Portfolios that can Collectively Learn from Others’ Mistakes:
“The definition of a good system is:
"1."
 The amount of errors within the system is small
“remove the number “1”.”
**The number is removed and replaced with a bullet point.
*” Concerning antifragility in management of portfolios, programs and projects. “ is unnecessary”
**this sentence is removed totally and replaced with something else.
*In the BMW example insert reference not only to the text but also to the figure 2.
**I have made a reference to the lectures from Josef
*Under the “Application” paragraph’s I would probably insert also the other examples that you use in the article in order to make this paragraph more concrete.
** I have decided to add another heading instead but still having two different "application" sections. The sections is dealing with two different ideas and I think this would be confusing to the reader.
* find reference for the production of the Lupo mentioned in this paragraph as well.
** This reference is found and added.
*The fact that you are using so many quotes adds to the article but you could try to eliminate them into 2-3 max since it reduces reader’s “reading flow” at some point.
**The topic of this article is new knowledge to me also, the idea of the quotes is to compact the essence of the topic into one line, and further elaborate in the rest of the section. But I see your point and maybe you are right.

C)
*I would recommend to spend a little more time in reviewing the intro and the closing part of the article in order to provide a more solid base for the reader with more details and raping up of the scope of the article
** The introduction is divided into sub-sections, in order to make it easier to the reader and catch the interest. In the end of the article a section "discussion" is made with "pros" and "cons" in order to discuss the limitations of the ideas in practice.
*Adding subheading for example naming the different cases would also add to the context of the article
**Good idea this is done.

Thank you for a really good review, definitely somthing I could use and I think it made the final result much better.

=Reviewer 3: s113665=

* The entire article is very well written with a good use of punctuation and a prober technically language.
** Thank you!
* The first section of the article is quite long.
** The first section is divided into smaller part with sub headings.
* Add a title.
** The title is added
* Consider dividing it into a couple of subtitles as well.
** Yes, this is done and the I think it works better now.
* You have two sections named ‘Application’.
** The section is renamed with two different names.
** As it however may be the prober way of division, it still adds unnecessary confusion.
* Nice graphics with good relevance to the subject!
* Well-made ‘References’ section!
** (I’m stealing some of that for my own article ;))
* There maaaay be a bit too many references in the text, and some of them are also quite extensive and could be shortened without loosing the ‘article’- and dramatic effect.
** I perfectly see you point, but as this a totally new topic to me (and properly also the reader) the idea of making one sentence which contains the main idea of the whole section is good sense to me. But you could also argue for the idea you are making.
** Would prefer to have the longer ones interoperated and incorporated in the main text instead of being an independent section in quotation marks.
** I tried to do that also, but many of the quotes is metaphors making it a bit more fun to read, I think at least.

There’s not much else to add, as it is by far the most finished article I’ve seen and reviewed! The article is neither in the need of additional proofreading, as there are next to no spelling-/grammar-/punctuation errors!
Bottom line it is a good article and I wish you good luck for the final review and grading!

Thanks for the review, definitely something I used.

Talk:Application of Antifragility in Project Management

2015-09-25T14:48:54Z

Lassehoier87:

Josef: Hello, I really like your idea of looking at antifragility and its application in project management. However, I am not entirely sure if your discussion of "simulating failure scenarios" and "upside/downside risks" fits the heading. If you look at our PMI whitepaper, you will find a few categories/principles of Antifragiltiy and their application to project management. Nassim Taleb's book (which I reckon you must read if you were to write about Antifragility) contains many more possible points of "connection". I suggest to take that as a "point of departure", and see what you can apply how to project management.

=Feedback of s141506, Reviewer 2=

== Structure ==

* I didn't find really any grammar mistakes which is good.
* Are the first chapters part of abstract or introduction or what.. You could elaborate little bit more with headings in the start so it would be easier to reader to follow the text.
** I have created subheading for the introduction part, to improve the overview of this section.
* In the article there is often mentioned number 1 and then bulletpoints. For example the chapter''' The definition of a good system is '''. Is it suppose be like this and also the other same kind of chapters?
** I have deleted the numbers and just made bullet points.
*Maybe samekind conclusion in the end would wrap the text better together. Now it is little bit scattered in different parts.
** In the end of the article I have made a new section called " Discussion" with subheadings of "Pros" and "Cons" to wrap everything up and comment on the limitations.

== Content==

* Having the aviation of one example for antifragility is very good. It gives reader immediately better understanding of the whole consept.
*Pictures are nice looking and simple but still informative. Reader can easily understand what write have wanted to show with the picture.
* Like I wrote in structure that try to use more headings.
** I have added a couple of new headings.
* You have used much New York Times articles as reference, it can be quite one-sided.
** the reference is not to a article, New York Times is the publisher of the book I have been using.

== Overall==

* Good article about subject that for me personal didn't have much information.

==(S142899_I am not aware of whether I am reviewer ½ or 3)==

*Summary of the references are missing at the end.
**I have made a section with reference and under the section "annotated bibliography" there are a few comments on the reference.

A)
*Generally the level of grammar structure is in a good level. Some expression mistakes were found though for example:(….is not in balance with the laws of nature.
….. is fragile, repetition of the word “volatility”)– in the first paragraph expression mistakes
** I have rephrased the sentences and tried to correct the expression mistakes. Though I was not able to find the mistakes in the first sentence.
*“The projects of our time are designed for stability and can be defined as highly complex, pursuit of effectivity and interdependency.” missing reference probably
** There is not reference in this part. The sentence is based on ideas from the book, but no direct reference.
*”For the past 2-3 decades, we have continued the pursuit of efficiency” - who we?
** This is corrected to emphasize the point I was trying to make.
*“What we should do, is build a system that is not fragile to these events.”- comma in the wrong place
** corrected the comma fault.
B) missing reference to the figure 1 and remember to mention it in the text before the figure
* I have made reference in the text to the figure, making it easier to the reader.
* Why table of context is in the middle of the text?
** The content list should be in the correct place now.
*Under the paragraph Create Project Portfolios that can Collectively Learn from Others’ Mistakes:
“The definition of a good system is:
"1."
 The amount of errors within the system is small
“remove the number “1”.”
**The number is removed and replaced with a bullet point.
*” Concerning antifragility in management of portfolios, programs and projects. “ is unnecessary”
**this sentence is removed totally and replaced with something else.
*In the BMW example insert reference not only to the text but also to the figure 2.
**I have made a reference to the lectures from Josef
*Under the “Application” paragraph’s I would probably insert also the other examples that you use in the article in order to make this paragraph more concrete.
** I have decided to add another heading instead but still having two different "application" sections. The sections is dealing with two different ideas and I think this would be confusing to the reader.
* find reference for the production of the Lupo mentioned in this paragraph as well.
** This reference is found and added.
*The fact that you are using so many quotes adds to the article but you could try to eliminate them into 2-3 max since it reduces reader’s “reading flow” at some point.
**The topic of this article is new knowledge to me also, the idea of the quotes is to compact the essence of the topic into one line, and further elaborate in the rest of the section. But I see your point and maybe you are right.

C)
*I would recommend to spend a little more time in reviewing the intro and the closing part of the article in order to provide a more solid base for the reader with more details and raping up of the scope of the article
** The introduction is divided into sub-sections, in order to make it easier to the reader and catch the interest. In the end of the article a section "discussion" is made with "pros" and "cons" in order to discuss the limitations of the ideas in practice.
*Adding subheading for example naming the different cases would also add to the context of the article
**Good idea this is done.

Thank you for a good review, definitely somthing i could use and I think it made the final result much better.

=Reviewer 3: s113665=

* The entire article is very well written with a good use of punctuation and a prober technically language.
* The first section of the article is quite long.
** Add a title.
** Consider dividing it into a couple of subtitles as well.
* You have two sections named ‘Application’.
** As it however may be the prober way of division, it still adds unnecessary confusion.
* Nice graphics with good relevance to the subject!
* Well-made ‘References’ section!
** (I’m stealing some of that for my own article ;))
* There maaaay be a bit too many references in the text, and some of them are also quite extensive and could be shortened without loosing the ‘article’- and dramatic effect.
** Would prefer to have the longer ones interoperated and incorporated in the main text instead of being an independent section in quotation marks.

There’s not much else to add, as it is by far the most finished article I’ve seen and reviewed! The article is neither in the need of additional proofreading, as there are next to no spelling-/grammar-/punctuation errors!
Bottom line it is a good article and I wish you good luck for the final review and grading!

Talk:Application of Antifragility in Project Management

2015-09-25T14:47:18Z

Lassehoier87:

Josef: Hello, I really like your idea of looking at antifragility and its application in project management. However, I am not entirely sure if your discussion of "simulating failure scenarios" and "upside/downside risks" fits the heading. If you look at our PMI whitepaper, you will find a few categories/principles of Antifragiltiy and their application to project management. Nassim Taleb's book (which I reckon you must read if you were to write about Antifragility) contains many more possible points of "connection". I suggest to take that as a "point of departure", and see what you can apply how to project management.

=Feedback of s141506, Reviewer 2=

== Structure ==

* I didn't find really any grammar mistakes which is good.
* Are the first chapters part of abstract or introduction or what.. You could elaborate little bit more with headings in the start so it would be easier to reader to follow the text.
** I have created subheading for the introduction part, to improve the overview of this section.
* In the article there is often mentioned number 1 and then bulletpoints. For example the chapter''' The definition of a good system is '''. Is it suppose be like this and also the other same kind of chapters?
** I have deleted the numbers and just made bullet points.
*Maybe samekind conclusion in the end would wrap the text better together. Now it is little bit scattered in different parts.
** In the end of the article I have made a new section called " Discussion" with subheadings of "Pros" and "Cons" to wrap everything up and comment on the limitations.

== Content==

* Having the aviation of one example for antifragility is very good. It gives reader immediately better understanding of the whole consept.
*Pictures are nice looking and simple but still informative. Reader can easily understand what write have wanted to show with the picture.
* Like I wrote in structure that try to use more headings.
** I have added a couple of new headings.
* You have used much New York Times articles as reference, it can be quite one-sided.
** the reference is not to a article, New York Times is the publisher of the book I have been using.

== Overall==

* Good article about subject that for me personal didn't have much information.

==(S142899_I am not aware of whether I am reviewer ½ or 3)==

*Summary of the references are missing at the end.
**I have made a section with reference and under the section "annotated bibliography" there are a few comments on the reference.

A)
*Generally the level of grammar structure is in a good level. Some expression mistakes were found though for example:(….is not in balance with the laws of nature.
….. is fragile, repetition of the word “volatility”)– in the first paragraph expression mistakes
** I have rephrased the sentences and tried to correct the expression mistakes. Though I was not able to find the mistakes in the first sentence.
*“The projects of our time are designed for stability and can be defined as highly complex, pursuit of effectivity and interdependency.” missing reference probably
** There is not reference in this part. The sentence is based on ideas from the book, but no direct reference.
*”For the past 2-3 decades, we have continued the pursuit of efficiency” - who we?
** This is corrected to emphasize the point I was trying to make.
*“What we should do, is build a system that is not fragile to these events.”- comma in the wrong place
** corrected the comma fault.
B) missing reference to the figure 1 and remember to mention it in the text before the figure
** I have made reference in the text to the figure, making it easier to the reader.
* Why table of context is in the middle of the text?
** The content list should be in the correct place now.
*Under the paragraph Create Project Portfolios that can Collectively Learn from Others’ Mistakes:
“The definition of a good system is:
"1."
 The amount of errors within the system is small
“remove the number “1”.”
**The number is removed and replaced with a bullet point.
*” Concerning antifragility in management of portfolios, programs and projects. “ is unnecessary”
**this sentence is removed totally and replaced with something else.
*In the BMW example insert reference not only to the text but also to the figure 2.
**I have made a reference to the lectures from Josef
*Under the “Application” paragraph’s I would probably insert also the other examples that you use in the article in order to make this paragraph more concrete.
** I have decided to add another heading instead but still having two different "application" sections. The sections is dealing with two different ideas and I think this would be confusing to the reader.
* find reference for the production of the Lupo mentioned in this paragraph as well.
** This reference is found and added.
*The fact that you are using so many quotes adds to the article but you could try to eliminate them into 2-3 max since it reduces reader’s “reading flow” at some point.
**The topic of this article is new knowledge to me also, the idea of the quotes is to compact the essence of the topic into one line, and further elaborate in the rest of the section. But I see your point and maybe you are right.

C)
*I would recommend to spend a little more time in reviewing the intro and the closing part of the article in order to provide a more solid base for the reader with more details and raping up of the scope of the article
** The introduction is divided into sub-sections, in order to make it easier to the reader and catch the interest. In the end of the article a section "discussion" is made with "pros" and "cons" in order to discuss the limitations of the ideas in practice.
*Adding subheading for example naming the different cases would also add to the context of the article
**Good idea this is done.

Thank you for a good review, definitely somthing i could use and I think it made the final result much better.

=Reviewer 3: s113665=

* The entire article is very well written with a good use of punctuation and a prober technically language.
* The first section of the article is quite long.
** Add a title.
** Consider dividing it into a couple of subtitles as well.
* You have two sections named ‘Application’.
** As it however may be the prober way of division, it still adds unnecessary confusion.
* Nice graphics with good relevance to the subject!
* Well-made ‘References’ section!
** (I’m stealing some of that for my own article ;))
* There maaaay be a bit too many references in the text, and some of them are also quite extensive and could be shortened without loosing the ‘article’- and dramatic effect.
** Would prefer to have the longer ones interoperated and incorporated in the main text instead of being an independent section in quotation marks.

There’s not much else to add, as it is by far the most finished article I’ve seen and reviewed! The article is neither in the need of additional proofreading, as there are next to no spelling-/grammar-/punctuation errors!
Bottom line it is a good article and I wish you good luck for the final review and grading!

Application of Antifragility in Project Management

2015-09-25T14:14:29Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

==== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|center|600px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|center|600px|thumb|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.

==== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ====

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

==== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|center|750px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Discussion ==

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

=== 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 <ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 282 New York Times</ref> by Bent Flyvbjerg [https://en.wikipedia.org/wiki/Bent_Flyvbjerg], 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.

== Annotated Bibliography ==

#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.
#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.
== References ==

<references />

Application of Antifragility in Project Management

2015-09-25T14:13:39Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

==== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|center|600px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|center|600px|thumb|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.

==== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ====

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

==== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|center|750px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Discussion ==

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

=== 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 <ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 282 New York Times</ref> by Bent Flyvbjerg [https://en.wikipedia.org/wiki/Bent_Flyvbjerg], 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 project 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.

== Annotated Bibliography ==

#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.
#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.
== References ==

<references />

Application of Antifragility in Project Management

2015-09-25T14:12:15Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

==== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|center|600px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|center|600px|thumb|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.

==== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ====

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

==== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|center|750px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Discussion ==

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

=== 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 mentioned in <ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 282 New York Times</ref> by Bent Flyvbjerg [https://en.wikipedia.org/wiki/Bent_Flyvbjerg], a famous Danish economic geographer, states that this 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 project 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.

== Annotated Bibliography ==

#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.
#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.
== References ==

<references />

Application of Antifragility in Project Management

2015-09-25T14:11:38Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

==== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|center|600px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|center|600px|thumb|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.

==== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ====

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

==== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|center|750px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Discussion ==

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

=== 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 mentioned in <ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 282 New York Times</ref> by Bent Flyvbjerg [https://en.wikipedia.org/wiki/Bent_Flyvbjerg], a famous Danish economic geographer, states that this 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 project 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.

== Annotated Bibliography ==

#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.
#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.
== References ==

<references />

Application of Antifragility in Project Management

2015-09-25T14:10:15Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

==== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|center|600px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|center|600px|thumb|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.

==== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ====

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

==== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|center|750px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Discussion ==

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

=== 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 however is not always possible, as mentioned in <ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 282 New York Times</ref> by Bent Flyvbjerg [https://en.wikipedia.org/wiki/Bent_Flyvbjerg], a famous Danish economic geographer, states that this 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 project 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.

== Annotated Bibliography ==

#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.
#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.
== References ==

<references />

Application of Antifragility in Project Management

2015-09-25T14:09:24Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

==== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|center|600px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|center|600px|thumb|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.

==== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ====

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

==== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|center|750px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Discussion ==

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

=== 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 however is not always possible, as mentioned in <ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref> by [https://en.wikipedia.org/wiki/Bent_Flyvbjerg], a famous Danish economic geographer, states that this 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 project 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.

== Annotated Bibliography ==

#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.
#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.
== References ==

<references />

Application of Antifragility in Project Management

2015-09-25T13:53:18Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

==== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|center|600px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|center|600px|thumb|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.

==== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ====

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

==== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|center|750px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Discussion ==

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

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

== Annotated Bibliography ==

#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.
#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.
== References ==

<references />

Application of Antifragility in Project Management

2015-09-25T13:44:59Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

==== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|center|600px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|center|600px|thumb|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.

==== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ====

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

==== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|center|750px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Discussion ==

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

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

== Annotated Bibliography ==

#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.
#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.
== References ==

<references />

Application of Antifragility in Project Management

2015-09-25T13:44:31Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

==== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|center|600px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|center|600px|thumb|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.

==== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ====

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

==== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|center|750px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Discussion ==

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

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

== Annotated Bibliography ==

#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.
#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.
== References ==

<references />

Application of Antifragility in Project Management

2015-09-25T13:43:59Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

==== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|center|600px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|center|600px|thumb|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.

==== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ====

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

==== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|center|750px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Discussion ==

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

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

== Annotated Bibliography ==

#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.
#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.
== References ==
HUSK AT SKRIV LIDT OM REFERENCERNE
<references />

Application of Antifragility in Project Management

2015-09-25T13:42:05Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

==== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|center|600px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|center|600px|thumb|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.

==== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ====

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

==== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|center|750px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Discussion ==

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

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

== Annotated Bibliography ==

#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.
#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.
== References ==
HUSK AT SKRIV LIDT OM REFERENCERNE
<references />

Application of Antifragility in Project Management

2015-09-25T13:41:26Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

==== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|center|600px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|center|600px|thumb|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.

==== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ====

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

==== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|center|750px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Discussion ==

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

=== 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”[[Link 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.

== Annotated Bibliography ==

#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.
#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.
== References ==
HUSK AT SKRIV LIDT OM REFERENCERNE
<references />

Application of Antifragility in Project Management

2015-09-25T07:07:14Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

==== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|center|600px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|center|600px|thumb|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.

==== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ====

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

==== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|center|750px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Conclusion ==

In the pursuit of showing how antifragility can be applied in management of project, program or portfolio, this article has been produced. As mentioned in the start, concepts as "complex, effectivity and interdependency" 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 orgranization/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.

In project organizations and projects, smallere size should be more common. In this way, smallere project organizations is more efficient and able to adapt faster at lower cost than a large organization. The scope of a smallere team is to devise a smart and simple solution to a complex problem. Large teams have a tendency to add to complexity and cost.

== Annotated Bibliography ==

#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.
#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.
== References ==
HUSK AT SKRIV LIDT OM REFERENCERNE
<references />

Application of Antifragility in Project Management

2015-09-24T18:46:19Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

==== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|center|600px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|center|600px|thumb|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.

==== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ====

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

==== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|center|750px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Conclusion ==

In the pursuit of showing how antifragility can be applied in management of project, program or portfolio, this article has been produced. As mentioned in the start, concepts as "complex, effectivity and interdependency" 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 orgranization/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.

In project organizations and projects, smallere size should be more common. In this way, smallere project organizations is more efficient and able to adapt faster at lower cost than a large organization. The scope of a smallere team is to devise a smart and simple solution to a complex problem. Large teams have a tendency to add to complexity and cost.

== Annotated Bibliography ==

#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.
#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.
== References ==

<references />

Application of Antifragility in Project Management

2015-09-24T17:43:54Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

==== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|center|600px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|center|600px|thumb|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.

==== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ====

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

==== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|center|750px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Conclusion ==

== Annotated Bibliography ==

#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.
#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.
== References ==

<references />

Application of Antifragility in Project Management

2015-09-24T17:43:00Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

==== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|center|600px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|center|600px|thumb|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.

==== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ====

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

==== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|center|750px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Conclusion ==

== Annotated Bibliography ==

#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.
#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.
== References ==

<references />

Application of Antifragility in Project Management

2015-09-24T17:42:03Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

==== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|center|500px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|none|500px|thumb|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.

==== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ====

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

==== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|none|650px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Conclusion ==

== Annotated Bibliography ==

#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.
#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.
== References ==

<references />

Application of Antifragility in Project Management

2015-09-24T17:40:57Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

==== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|middle|500px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|none|500px|thumb|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.

==== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ====

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

==== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|none|650px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Conclusion ==

== Annotated Bibliography ==

#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.
#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.
== References ==

<references />

Application of Antifragility in Project Management

2015-09-24T17:39:38Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

==== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|none|500px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|none|500px|thumb|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.

==== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ====

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

==== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|none|650px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Conclusion ==

== Annotated Bibliography ==

#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.
#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.
== References ==

<references />

Application of Antifragility in Project Management

2015-09-23T12:00:16Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

==== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|none|500px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|none|500px|thumb|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.

==== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ====

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

==== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|none|650px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Annotated Bibliography ==

#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.
#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.
== References ==

<references />

Application of Antifragility in Project Management

2015-09-23T11:59:47Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

==== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|none|500px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|none|500px|thumb|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.

==== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ====

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

==== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|none|650px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Annotated Bibliography ==

#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.
#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.
== References ==

<references />

Application of Antifragility in Project Management

2015-09-23T11:59:15Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

==== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|none|500px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|none|500px|thumb|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.

==== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ====

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

==== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|none|650px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Annotated Bibliography ==

#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.
#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.
== References ==

<references />

Application of Antifragility in Project Management

2015-09-23T11:44:37Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

==== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|none|500px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|none|500px|thumb|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.

==== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ====

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

==== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|none|650px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Annotated Bibliography ==

#Nassim Nicholas Taleb, Antifragile - Things That Gain From Disorder, New York Times
#Josef Oehmen, Christian Thuesen, Pedro Parraguez Ruiz and Joana Geraldi, PMI Whitepaper, Complexity Management for Projects, Programmes and Portfolios: An Engineering Systems Perspective
== References ==

<references />

Application of Antifragility in Project Management

2015-09-23T11:43:31Z

Lassehoier87:

== Introduction ==

==== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

=== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|none|500px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|none|500px|thumb|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.

=== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ===

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

=== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|none|650px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Annotated Bibliography ==

#Nassim Nicholas Taleb, Antifragile - Things That Gain From Disorder, New York Times
#Josef Oehmen, Christian Thuesen, Pedro Parraguez Ruiz and Joana Geraldi, PMI Whitepaper, Complexity Management for Projects, Programmes and Portfolios: An Engineering Systems Perspective
== References ==

<references />

Application of Antifragility in Project Management

2015-09-23T11:42:55Z

Lassehoier87:

== Introduction ==

=== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

=== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|none|500px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|none|500px|thumb|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.

=== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ===

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

=== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|none|650px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Annotated Bibliography ==

#Nassim Nicholas Taleb, Antifragile - Things That Gain From Disorder, New York Times
#Josef Oehmen, Christian Thuesen, Pedro Parraguez Ruiz and Joana Geraldi, PMI Whitepaper, Complexity Management for Projects, Programmes and Portfolios: An Engineering Systems Perspective
== References ==

<references />

Application of Antifragility in Project Management

2015-09-23T11:42:05Z

Lassehoier87:

== Introduction ==

=== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

=== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|none|500px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|none|500px|thumb|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.

=== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ===

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

=== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|none|650px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Annotated Bibliography ==

*#Nassim Nicholas Taleb, Antifragile - Things That Gain From Disorder, New York Times
*##Josef Oehmen, Christian Thuesen, Pedro Parraguez Ruiz and Joana Geraldi, PMI Whitepaper, Complexity Management for Projects, Programmes and Portfolios: An Engineering Systems Perspective
== References ==

<references />

Application of Antifragility in Project Management

2015-09-23T11:41:41Z

Lassehoier87:

== Introduction ==

=== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

=== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|none|500px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|none|500px|thumb|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.

=== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ===

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

=== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|none|650px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Annotated Bibliography ==

#Nassim Nicholas Taleb, Antifragile - Things That Gain From Disorder, New York Times
##Josef Oehmen, Christian Thuesen, Pedro Parraguez Ruiz and Joana Geraldi, PMI Whitepaper, Complexity Management for Projects, Programmes and Portfolios: An Engineering Systems Perspective
== References ==

<references />

Application of Antifragility in Project Management

2015-09-23T11:41:19Z

Lassehoier87:

== Introduction ==

=== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

=== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|none|500px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|none|500px|thumb|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.

=== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ===

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

=== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|none|650px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Annotated Bibliography ==

#*Nassim Nicholas Taleb, Antifragile - Things That Gain From Disorder, New York Times
#**Josef Oehmen, Christian Thuesen, Pedro Parraguez Ruiz and Joana Geraldi, PMI Whitepaper, Complexity Management for Projects, Programmes and Portfolios: An Engineering Systems Perspective
== References ==

<references />

Application of Antifragility in Project Management

2015-09-23T11:40:31Z

Lassehoier87:

== Introduction ==

=== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

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

=== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|none|500px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|none|500px|thumb|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.

=== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ===

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

=== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|none|650px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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.

== Annotated Bibliography ==
Nassim Nicholas Taleb, Antifragile - Things That Gain From Disorder, New York Times
Josef Oehmen, Christian Thuesen, Pedro Parraguez Ruiz and Joana Geraldi, PMI Whitepaper, Complexity Management for Projects, Programmes and Portfolios: An Engineering Systems Perspective
== References ==

<references />

Application of Antifragility in Project Management

2015-09-23T11:27:32Z

Lassehoier87:

Application of Antifragility in Project Management

2015-09-23T11:26:37Z

Lassehoier87:

== Introduction ==

=== Fragility in Projects ===

''“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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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.

=== Complexity in Projects ===

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

=== 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|none|500px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|none|500px|thumb|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.

=== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ===

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

=== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|none|650px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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 ==

<references />

Application of Antifragility in Project Management

2015-09-23T11:19:49Z

Lassehoier87:

== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|none|500px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|none|500px|thumb|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.

=== ''Antifragility in Portfolio Caused by Fragility in Program/Project'' ===

----
Volkswagen (VW) manufactured in 1998 the car VW Lupo [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

=== ''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)

[[File:Figure 3 - Trial-Error Experiment.PNG|none|650px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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 ==

<references />

Application of Antifragility in Project Management

2015-09-23T11:13:22Z

Lassehoier87:

== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|none|500px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|none|500px|thumb|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 [<ref>https://da.wikipedia.org/wiki/Volkswagen_Lupo</ref>], 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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)

[[File:Figure 3 - Trial-Error Experiment.PNG|none|650px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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 ==

<references />

Application of Antifragility in Project Management

2015-09-23T11:10:53Z

Lassehoier87:

== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|none|500px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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 <ref>Josef Oehmen, lectures on management within project, program and portfolio</ref> 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)

[[File:Figure 2 - Antifragility in PPP.PNG|none|500px|thumb|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, 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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)

[[File:Figure 3 - Trial-Error Experiment.PNG|none|650px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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 ==

<references />

Application of Antifragility in Project Management

2015-09-23T11:05:37Z

Lassehoier87:

== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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)

[[File:Figure 1 - Black Swan.PNG|none|500px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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. Concerning antifragility in management of portfolios, programs and projects. The idea is to have “a handful of pebbles instead of one big stone” considering the weight of the stones. 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 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)

[[File:Figure 2 - Antifragility in PPP.PNG|none|500px|thumb|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, 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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)

[[File:Figure 3 - Trial-Error Experiment.PNG|none|650px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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 ==

<references />

Application of Antifragility in Project Management

2015-09-23T07:18:05Z

Lassehoier87:

== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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.

[[File:Figure 1 - Black Swan.PNG|none|500px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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. Concerning antifragility in management of portfolios, programs and projects. The idea is to have “a handful of pebbles instead of one big stone” considering the weight of the stones. 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 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.

[[File:Figure 2 - Antifragility in PPP.PNG|none|500px|thumb|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, 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

[[File:Figure 3 - Trial-Error Experiment.PNG|none|650px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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 ==

<references />

Application of Antifragility in Project Management

2015-09-23T07:17:24Z

Lassehoier87:

== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

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.

[[File:Figure 1 - Black Swan.PNG|none|500px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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. Concerning antifragility in management of portfolios, programs and projects. The idea is to have “a handful of pebbles instead of one big stone” considering the weight of the stones. 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 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.

[[File:Figure 2 - Antifragility in PPP.PNG|none|500px|thumb|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, 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

[[File:Figure 3 - Trial-Error Experiment.PNG|none|650px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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 ==

<references />

Application of Antifragility in Project Management

2015-09-23T07:10:20Z

Lassehoier87:

== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

For the past 2-3 decades, we have continued the pursuit of efficiency, 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.

[[File:Figure 1 - Black Swan.PNG|none|500px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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. Concerning antifragility in management of portfolios, programs and projects. The idea is to have “a handful of pebbles instead of one big stone” considering the weight of the stones. 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 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.

[[File:Figure 2 - Antifragility in PPP.PNG|none|500px|thumb|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, 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

[[File:Figure 3 - Trial-Error Experiment.PNG|none|650px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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 ==

<references />

Application of Antifragility in Project Management

2015-09-23T07:09:39Z

Lassehoier87:

== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

For the past 2-3 decades, we have continued the pursuit of efficiency, 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.

[[File:Figure 1 - Black Swan.PNG|none|500px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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. Concerning antifragility in management of portfolios, programs and projects. The idea is to have “a handful of pebbles instead of one big stone” considering the weight of the stones. 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 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.

[[File:Figure 2 - Antifragility in PPP.PNG|none|500px|thumb|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, 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

[[File:Figure 3 - Trial-Error Experiment.PNG|none|650px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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 ==

<references />

Application of Antifragility in Project Management

2015-09-23T07:06:56Z

Lassehoier87:

== 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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

For the past 2-3 decades, we have continued the pursuit of efficiency, 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.

[[File:Figure 1 - Black Swan.PNG|none|500px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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. Concerning antifragility in management of portfolios, programs and projects. The idea is to have “a handful of pebbles instead of one big stone” considering the weight of the stones. 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 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.

[[File:Figure 2 - Antifragility in PPP.PNG|none|500px|thumb|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, 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

[[File:Figure 3 - Trial-Error Experiment.PNG|none|650px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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 ==

<references />

Talk:PRINCE2 - For successful Project Management

2015-09-22T21:22:31Z

Lassehoier87:

[[(S142899_I am not aware of whether I am reviewer ½ or 3)
In general this is a good article with minor improvements needed.
A)
1. Introduction: Clear description of the prince2 method. The word “right” is purposely mentioned 3 times in the same sentence. Is this acceptable? Grammatically I could not identify any obvious error at the introduction.
2.Probably, the use of commas (,) will help the reader to read the text easier.
In the PRINCIPLES paragraph, in the last sentence capitals after commas could be changed into small letters.
3.In the CONTINUED BUSINESS JUSTIFICATION paragraph the words: Business Case, start with capital letters. I would recommend to switch in small letters.
In the same paragraph, check if reference is missing.
4.In the paragraph LEARN FROMEXPERIENCE, overlapping of the “ lessons learned” meaning exists.(probably reform it in a more concrete way)
5.References for tables are missing
6.In paragraph “Manage by exception” : Refer the references for the four managing levels
7.Focus on Products paragraph according to prince 2 ( reference missing).
8.In the themes paragraph, I would firstly introduce the themes and then I would explain the strength of Prince2.
9.In the PROCESSES Paragraph, when referring to processes use “…” instead of capital letter in each word.
10.Also reference for the figure 2 and table 3 are missing.
11.At the last paragraph, the expression “That is,…” Could be changed in order to ensure a more scientific way of expression.

B. The paragraph PROJECTS IN A PROGRAMME ENVIRONMENT might be evaluated again if it should be fitted in this order on not. Perhaps, it seems too generic and does not follow the flow of the other paragraphs.

c. The article seems convincing enough. Changes are mentioned above in order to create a more solid outcome. Extra information in the THEMES paragraphs could probably be added. (not necessary though)]]

----

'''LasseHoier87 reviewer 1'''

First impression is good, especially the use of illustrations is good. The layout is nice and the use of illustrations makes it more interesting reading the article.

Formal aspects: (Wiki article Peer Review template is used)

*The article is as clearly stated in the article following a “method”
*No gramma faults or spelling. Small typing errors or plural mistakes. E.g. line 1 “six performance aspect'''s'''”
*Written in a fine engaging style. In the start, the sentence is too long and may be a bit too much direct style. Use more formal style.
*I think the figures are fine and illustrative, making the sense obvious.
*Good and understandable figures, maybe the figure 1 is a bit small. The text is almost impossible to see.
*No formal errors in the figures or tables as far as I can see
*Yes the figures and tables is referred to in the text
*Regarding copyright issue – It is not clear to me if you have cleared this with the author of the figures.
*I think the overall wiki formation of the article is fine. Good use of headlines, sub-headlines and so on. Excellent !

Content aspects:
*For practitioners it is a relevant article, because the topic is very relevant to practitioners.
*I think is linking good to APPPM course as it is dealing with project management.
*The length of the article is fine. I don’t think it should be longer, maybe too manu sub-titles. I would properly make it more coherent and try to leave out some of the sub-titles. E.g. bullet points and a short description to each bullet point.
*I think the overall red thread is fine. First introduction of the method, principles, themes, processes and projects in a program environment.
*The starting summary is good and works fine.
*The reference is good sufficient.
*The material used is both books and websites. The quality is sufficient.
*Yes, good section of annotated bibliography. Describing very good the books used.
*As far as I noticed, there were no link to other APPPM wiki article.
*Own opinion is clearly stated in “ limitations” where the reflections is dealt with. Nice to reflect and point out the limitations.
*There is no reason to think there is any type of plagiarism.

----

Talk:Construction modularization from a lean perspective

2015-09-22T20:49:19Z

Lassehoier87:

'''LasseHoier87 reviewer 2'''

First impression is good, especially the use of a real life case is nice. The layout is thought through and seems to “guide” the reader through the topic. However, it could be "spiced" a bit up if there were some nice pictures, illustrations or even a video. This would "catch" the reader more i think.

Formal aspects: (Wiki article Peer Review template is used)

*The article is as clearly stated in the article following a “case study”
*No gramma faults or spelling.
*Written in a fine engaging style, The sentence is too long and may be a bit too much direct style. Use more formal style.
*No illustrations at all, you mention a video on youtube why not use that one. Maybe the figures showing the building or similar.
*No figures
*No figures
*No figures
*No figures therefore no copyright issue
*I think the overall wiki formation of the article is fine.

Content aspects:

*For practitioners it is a relevant article, because the topic is very relevant .
*It is not specific related to PPPM. However, the idea lean and critical path is used in project management and scheduling.
*The length of the article is fine. I don’t think it should be longer, but maybe a bit more in the “Preface” and maybe it is too basic.
*I think the overall red thread is fine and the article seems coherent.
*The starting summary is good and works fine, but I think the “preface” and “abstact” could be merged together and be more precise in terms of starting the “red thread”.
*The reference is missing.
*I find it hard to say which material has been used. There should be a clear list of reference and link into the text.
*There is no section “annotated bibliography”.
*As far as I noticed, there were no link to other APPPM wiki article. But links to websites, that is fine.
*Own opinion is clearly stated in “ reflections on practice of modularization in the construction sector”
*There is no reason to think there is any type of plagiarism

----

Talk:Construction modularization from a lean perspective

2015-09-22T20:47:50Z

Lassehoier87: Created page with "'''LasseHoier87 reviewer 2''' First impression is good, especially the use of illustrations is good. The layout is thought through and seems to “guide” the reader through..."

'''LasseHoier87 reviewer 2'''

First impression is good, especially the use of illustrations is good. The layout is thought through and seems to “guide” the reader through the topic.

Formal aspects: (Wiki article Peer Review template is used)

*The article is as clearly stated in the article following a “case study”
*No gramma faults or spelling.
*Written in a fine engaging style, The sentence is too long and may be a bit too much direct style. Use more formal style.
*No illustrations at all, you mention a video on youtube why not use that one. Maybe the figures showing the building or similar.
*No figures
*No figures
*No figures
*No figures therefore no copyright issue
*I think the overall wiki formation of the article is fine.

Content aspects:

*For practitioners it is a relevant article, because the topic is very relevant .
*It is not specific related to PPPM. However, the idea lean and critical path is used in project management and scheduling.
*The length of the article is fine. I don’t think it should be longer, but maybe a bit more in the “Preface” and maybe it is too basic.
*I think the overall red thread is fine and the article seems coherent.
*The starting summary is good and works fine, but I think the “preface” and “abstact” could be merged together and be more precise in terms of starting the “red thread”.
*The reference is missing.
*I find it hard to say which material has been used. There should be a clear list of reference and link into the text.
*There is no section “annotated bibliography”.
*As far as I noticed, there were no link to other APPPM wiki article. But links to websites, that is fine.
*Own opinion is clearly stated in “ reflections on practice of modularization in the construction sector”
*There is no reason to think there is any type of plagiarism

----

Application of Antifragility in Project Management

2015-09-22T19:39:09Z

Lassehoier87:

''“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”''<ref>Taleb, N.N. Learning to love volatility. The Walls Street Journal</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Where the “efficient” is not efficient pg. 286, New York Times</ref>

For the past 2-3 decades, we have continued the pursuit of efficiency, 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.

[[File:Figure 1 - Black Swan.PNG|none|500px|thumb|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"''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Learning from the Mistakes of Others pg. 72, New York Times</ref>

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. Concerning antifragility in management of portfolios, programs and projects. The idea is to have “a handful of pebbles instead of one big stone” considering the weight of the stones. 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 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.

[[File:Figure 2 - Antifragility in PPP.PNG|none|500px|thumb|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, 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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Search and How Errors Can Be Investments pg. 192, New York Times</ref>

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.

[[File:Figure 3 - Trial-Error Experiment.PNG|none|650px|thumb|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”''<ref>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</ref>

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”''<ref>Taleb, N.N. Antifragility, things that gain from disorder, Small may be ugly, it is certainly less fragile pg. 278 New York Times</ref>

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 ==

<references />

Talk:Mindfulness and Cognitive Biases in Project Management

2015-09-22T19:26:29Z

Lassehoier87:

Anna: In regards to the choice of topic, I feel like this article does not really fit any of the two types of articles that we want to see for this course. An idea could maybe be to focus on a specific tool that could help a manager to be a "mindful manager" in order to narrow the scope of your article down.

----

'''LasseHoier87 reviewer 3'''

The article is not finished as stated in the section ”To the reviewer”. I have therefore not reviewed the part where the author is writing ideas to the rest of the article. I will comment on what is available at the time of the review.

(Wiki article Peer Review template is used. To see question see "Wiki Article Peer Review and Peer Evaluation")

Formal aspects:

*It follows the "method" structure in a good and clear way
*Free of grammatical, spelling and punctuation error. Maybe change “We” to more formal style
*Written in a fine engaging style, short sentences also leading nicely to the next point.
*I think the figures is ok, but maybe the figure with a lot of text is not suitable (you have a tendency to skip it) Maybe some bullet points with a very short description would be better?!
*The figures are understandable, but I think “figure 1” should be enlarged.
*The choice of figures is fine, but the label is missing. Use [[file….|none|thumb|caption]] or similar to get label on the figure
*The tables and figures is referred to in the text and works fine.
*Regarding copyright on the figures. I can not see any reference in relation to the figures.
*I think the overall wiki formation of the article is fine. There are some small things, as mentioned earlier, the placement of the figures, layout of figure. But overall the formation is nicely done.

Content aspects:

*For practitioners the early version may be a bit theoretical, but if some examples of use could be made, the full understanding would be good.
*I think the article fits the purpose of this course very good. It is dealing with some key issues in term of system engineering and the behavior behind the development towards high complexity in society.
*The article is relating to the project management category. But could be used in other aspects also. The article is categorized well within the content categories.
*It is hard to evaluate the length of the article at this point, but looking at the “thoughts” of the author – I doubt it will too short.
*The logical flow through the article is fine. It seems like there will be a red thread through the rest of the article as well.
*The starting summary of the article should describe the content in a more detailed way.
*The sources and reference material is illustrated fine in the end of the article, but should of course be completed with “full name of author, title, year etc.”
*The sources and reference material is fine and is mostly relying books, standards and journals. Fine
*There are no link to other Wiki APPPM articles, but one link to oxford dictionaries, which is of doubtful relevance.
*Difference between own opinion and statements from literature is hard to say at this point. The article is mostly describing the basic ideas of mindfulness and cognitive biases.
*There is no reason to think there is any type of plagiarism.

----