DTU ProjectLab - User contributions [en-gb]

Talk:Creating a positive culture around failure in project management

2014-11-28T17:13:55Z

Kikigaga: /* reviewed by Saeh0803 */

== reviewed by Saeh0803 ==

To start with I would place the Introduction in the beginning of the document, followed by a table of content and please add some more sentences in introduction to describe the topic :)
I miss introduction of your topic..

long sentences, make them a bit shorter :)

Over all i like your topic and your article, your English is understandable..
some part is very short, maybe you can describe a bit more, so it gives sense for reader. (if it is possible)

I hope you can use my comments
best of luck

''Thank you, hereby done''

== Sube - Review ==

Greetings

Congratulation! you have wrote a wiki style article:)
''Thank you ;)''

First of all, I think your writing skills are very sufficient, all text is readable and make sense! Which is very nice...

Secondly, I believe that the combination of topics your chose is relevant and I see the purpose, eventhough it havent been tried out in practice:)

Thirdly, NOTE that the review text will flow out of screen to the right hand side... I do not know how to fix this!

Nevertheless, I have made you some recommendations on how I believe the article can improve.

General Guidelines;
* Quotes are hidden in the text, maybe make them Italic, so they stand out from the normal text. Btw, you got a lot of quotes which I think is good:)
''Good idea! I will definitely integrate this''
* As a reader im wondering, which organisations benefits from the methodology you describe? Can any organisation benefit from this, or is it more innovation oriented organisation? - maybe in the limitation of the method. I know you write the method is for projects managers - but are there any other limitations...
''That is a good question and i see that i failed to mention is, so i will put it in limitations (that i also thought was lacking something, so thanks!)''
----
'''Start''':
* When I am entering the page, the first thing I see is a table of contents. I think it would be beneficial if you peptalked the topic a bit before the content is presented. That way around, as a reader you make more sense of the table of content, and know why this topic is even relevant.
* You could add the Article Category there aswell, maybe in the end.
''Yea, i didn't know we were ment to move this, but great! I found out how to do it. ''
----
'''Introduction'''
* I believe this section is more like "Research Area" or "Scope". I feel like an introduction is more about the topic and the reason why it is relevant - You could make a abstract/intro to intreak the reader and then rename the Introduction.
* Where are the Embracing Failure Key values? It sounds interresting:) I cannot find them!
''I see what you're saying. I will take it into account..''

----
'''Acceptance of failure'''
* Minor thing: I wondered who Cass was, untill it maked sense, Cassidy. Might want to edit Cass to Cassidy.
''I found it, done''
----
'''Learn from your mistakes'''
* Consider some general writing about Single and Double Loop learning...
''That is a great idea. I will try''

----
'''How is embracing failure used'''
* I think you might want to descibe what the Fuzzy Front End is all about, I kind of get it, but I am not sure...
* Revisit this sentence; Embracing Failures role in the Fuzzy Front End of a project The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project.
* Remember Fuzzy Front End, some parts it is fuzzy front end. - Maybe use the FFE - but personally I belive Fuzzy Front End sounds good:)
* Make sure you do this; "This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting."
''Well i think this misunderstanding comes from a spelling error. Hereby corrected and FFE is used Caption.''
----
'''The original Spiral Model'''
* Minor thing; Remember to make puncturemarks after each bulletpoint.
''Check''
----
'''Adaption of the Spiral Model'''
* I think adaptation or application is more correct - do not kill me if I am wrong.
''You're right''

----
'''Visualized testing and prototyping area'''
* Visualized testing and prototype areas?
* First sentence: Remove "from it".
''Check''

----
'''Discussion of the method'''
* Nevertheless is in one word:)
* Last section; long sentence...
''"Check"''
----
'''Conclusion'''
* The start is klumpsy "It has in this article been tried... " - rewrite:) Maybe something like; "This article provides projects managers with a method to improve their blabla.."
* Second section, revisit the whole sentence "...the Spiral Model should be able to help with in..." I get the point but make sure to visualise that it is a "indskudt sætning":)
''Super''

Nice article:) Hope you can make use of my recommendations... Good Luck Have Fun!
''Tak for hjælpen!''

Creating a positive culture around failure in project management

2014-11-28T17:12:03Z

Kikigaga: /* Conclusion */

=Introduction=
[[Category:Innovative Project Management]]
Project management can be seen as a linear continuous process, but it can also be seen as an continous iteration. The Embracing Failure movement and looking at your failures as a way to succeed has become very popular. When embracing your failures the ideal is that it is possible to learn from your failures and have better justification for your succes and thereby avoid a greater failure in the future. This article is intended as inspiration to see how embracing your failures serves as a philosophy in your company culture by defining your product development process.

=Research Area and Scope=
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

''Article category: Overview and summary of a relevant body of knowledge''

__TOC__

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: ''“How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”''<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy (Cass), lifelong innovator and creator of Klutz Press, taught them how to juggle. ''“Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”''<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. ''“Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”''<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: ''“Pushing yourself as far as you can lets you know what's possible“'' But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
[[File:singlelooplearning.png|200px|thumb|left| Single Loop Learning illustrated by Gareth Morgan <ref>Morgan, Gareth. ["Images of Organisation"], ''[[SAGE Publications]]'' 2006.</ref>]] [[File:doublelooplearning.png|200px|thumb|left| Double Loop Learning illustrated by Gareth Morgan <ref>Morgan, Gareth. ["Images of Organisation"], ''[[SAGE Publications]]'' 2006.</ref>]]
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his ''“I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”''<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks. The thought process of this can be seen in the figures by Gareth Morgan (See "Single Loop Learning" and "Double Loop Learning"). Here we see how an extra reflection incorporated in the process can be the only way for organisations to learn from their failed processes.

==How is Embracing Failure currently used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.

==Embracing Failures role in the Fuzzy Front End of a project==
The first stages of a project or the planning part of a program is identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. This is where a project takes form. Pointed out by Sebastian Lucae ''“Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “Fuzzy Front End” of the program.”''<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the Fuzzy Front End holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) ''“empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”''<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, ''“Fail fast, Fail often”'' as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design.
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market.
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaptation of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. ''“The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”''<ref name="success" />.

==Visualized testing and prototyping areas==
A big part of the failing and learning builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. ''“I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”''<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Nevertheless, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. ''“Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”''<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios. But the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.
The second thing is that the theory is focused on hardware design companies. More specifically it will be easier to implement for companies working with innovation but at the same time it might be the companies that haven't given innovative methods a thought that would experience the greatest benefits.

=Conclusion=
This article inspire project managers to improve their end-products by the Embracing Failure methodology. By adapting the Spiral Model to a hardware design process it can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-28T17:10:08Z

Kikigaga: /* Limits of the article */

=Introduction=
[[Category:Innovative Project Management]]
Project management can be seen as a linear continuous process, but it can also be seen as an continous iteration. The Embracing Failure movement and looking at your failures as a way to succeed has become very popular. When embracing your failures the ideal is that it is possible to learn from your failures and have better justification for your succes and thereby avoid a greater failure in the future. This article is intended as inspiration to see how embracing your failures serves as a philosophy in your company culture by defining your product development process.

=Research Area and Scope=
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

''Article category: Overview and summary of a relevant body of knowledge''

__TOC__

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: ''“How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”''<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy (Cass), lifelong innovator and creator of Klutz Press, taught them how to juggle. ''“Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”''<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. ''“Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”''<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: ''“Pushing yourself as far as you can lets you know what's possible“'' But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
[[File:singlelooplearning.png|200px|thumb|left| Single Loop Learning illustrated by Gareth Morgan <ref>Morgan, Gareth. ["Images of Organisation"], ''[[SAGE Publications]]'' 2006.</ref>]] [[File:doublelooplearning.png|200px|thumb|left| Double Loop Learning illustrated by Gareth Morgan <ref>Morgan, Gareth. ["Images of Organisation"], ''[[SAGE Publications]]'' 2006.</ref>]]
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his ''“I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”''<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks. The thought process of this can be seen in the figures by Gareth Morgan (See "Single Loop Learning" and "Double Loop Learning"). Here we see how an extra reflection incorporated in the process can be the only way for organisations to learn from their failed processes.

==How is Embracing Failure currently used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.

==Embracing Failures role in the Fuzzy Front End of a project==
The first stages of a project or the planning part of a program is identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. This is where a project takes form. Pointed out by Sebastian Lucae ''“Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “Fuzzy Front End” of the program.”''<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the Fuzzy Front End holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) ''“empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”''<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, ''“Fail fast, Fail often”'' as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design.
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market.
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaptation of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. ''“The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”''<ref name="success" />.

==Visualized testing and prototyping areas==
A big part of the failing and learning builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. ''“I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”''<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Nevertheless, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. ''“Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”''<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios. But the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.
The second thing is that the theory is focused on hardware design companies. More specifically it will be easier to implement for companies working with innovation but at the same time it might be the companies that haven't given innovative methods a thought that would experience the greatest benefits.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Talk:Creating a positive culture around failure in project management

2014-11-28T17:04:08Z

Kikigaga: /* Sube - Review */

== reviewed by Saeh0803 ==

To start with I would place the Introduction in the beginning of the document, followed by a table of content and please add some more sentences in introduction to describe the topic :)
I miss introduction of your topic..

long sentences, make them a bit shorter :)

Over all i like your topic and your article, your English is understandable..
some part is very short, maybe you can describe a bit more, so it gives sense for reader. (if it is possible)

I hope you can use my comments
best of luck

== Sube - Review ==

Greetings

Congratulation! you have wrote a wiki style article:)
''Thank you ;)''

First of all, I think your writing skills are very sufficient, all text is readable and make sense! Which is very nice...

Secondly, I believe that the combination of topics your chose is relevant and I see the purpose, eventhough it havent been tried out in practice:)

Thirdly, NOTE that the review text will flow out of screen to the right hand side... I do not know how to fix this!

Nevertheless, I have made you some recommendations on how I believe the article can improve.

General Guidelines;
* Quotes are hidden in the text, maybe make them Italic, so they stand out from the normal text. Btw, you got a lot of quotes which I think is good:)
''Good idea! I will definitely integrate this''
* As a reader im wondering, which organisations benefits from the methodology you describe? Can any organisation benefit from this, or is it more innovation oriented organisation? - maybe in the limitation of the method. I know you write the method is for projects managers - but are there any other limitations...
''That is a good question and i see that i failed to mention is, so i will put it in limitations (that i also thought was lacking something, so thanks!)''
----
'''Start''':
* When I am entering the page, the first thing I see is a table of contents. I think it would be beneficial if you peptalked the topic a bit before the content is presented. That way around, as a reader you make more sense of the table of content, and know why this topic is even relevant.
* You could add the Article Category there aswell, maybe in the end.
''Yea, i didn't know we were ment to move this, but great! I found out how to do it. ''
----
'''Introduction'''
* I believe this section is more like "Research Area" or "Scope". I feel like an introduction is more about the topic and the reason why it is relevant - You could make a abstract/intro to intreak the reader and then rename the Introduction.
* Where are the Embracing Failure Key values? It sounds interresting:) I cannot find them!
''I see what you're saying. I will take it into account..''

----
'''Acceptance of failure'''
* Minor thing: I wondered who Cass was, untill it maked sense, Cassidy. Might want to edit Cass to Cassidy.
''I found it, done''
----
'''Learn from your mistakes'''
* Consider some general writing about Single and Double Loop learning...
''That is a great idea. I will try''

----
'''How is embracing failure used'''
* I think you might want to descibe what the Fuzzy Front End is all about, I kind of get it, but I am not sure...
* Revisit this sentence; Embracing Failures role in the Fuzzy Front End of a project The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project.
* Remember Fuzzy Front End, some parts it is fuzzy front end. - Maybe use the FFE - but personally I belive Fuzzy Front End sounds good:)
* Make sure you do this; "This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting."
''Well i think this misunderstanding comes from a spelling error. Hereby corrected and FFE is used Caption.''
----
'''The original Spiral Model'''
* Minor thing; Remember to make puncturemarks after each bulletpoint.
''Check''
----
'''Adaption of the Spiral Model'''
* I think adaptation or application is more correct - do not kill me if I am wrong.
''You're right''

----
'''Visualized testing and prototyping area'''
* Visualized testing and prototype areas?
* First sentence: Remove "from it".
''Check''

----
'''Discussion of the method'''
* Nevertheless is in one word:)
* Last section; long sentence...
''"Check"''
----
'''Conclusion'''
* The start is klumpsy "It has in this article been tried... " - rewrite:) Maybe something like; "This article provides projects managers with a method to improve their blabla.."
* Second section, revisit the whole sentence "...the Spiral Model should be able to help with in..." I get the point but make sure to visualise that it is a "indskudt sætning":)
''Super''

Nice article:) Hope you can make use of my recommendations... Good Luck Have Fun!
''Tak for hjælpen!''

Creating a positive culture around failure in project management

2014-11-28T16:58:53Z

Kikigaga: /* Discussion of the method */

=Introduction=
[[Category:Innovative Project Management]]
Project management can be seen as a linear continuous process, but it can also be seen as an continous iteration. The Embracing Failure movement and looking at your failures as a way to succeed has become very popular. When embracing your failures the ideal is that it is possible to learn from your failures and have better justification for your succes and thereby avoid a greater failure in the future. This article is intended as inspiration to see how embracing your failures serves as a philosophy in your company culture by defining your product development process.

=Research Area and Scope=
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

''Article category: Overview and summary of a relevant body of knowledge''

__TOC__

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: ''“How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”''<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy (Cass), lifelong innovator and creator of Klutz Press, taught them how to juggle. ''“Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”''<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. ''“Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”''<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: ''“Pushing yourself as far as you can lets you know what's possible“'' But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
[[File:singlelooplearning.png|200px|thumb|left| Single Loop Learning illustrated by Gareth Morgan <ref>Morgan, Gareth. ["Images of Organisation"], ''[[SAGE Publications]]'' 2006.</ref>]] [[File:doublelooplearning.png|200px|thumb|left| Double Loop Learning illustrated by Gareth Morgan <ref>Morgan, Gareth. ["Images of Organisation"], ''[[SAGE Publications]]'' 2006.</ref>]]
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his ''“I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”''<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks. The thought process of this can be seen in the figures by Gareth Morgan (See "Single Loop Learning" and "Double Loop Learning"). Here we see how an extra reflection incorporated in the process can be the only way for organisations to learn from their failed processes.

==How is Embracing Failure currently used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.

==Embracing Failures role in the Fuzzy Front End of a project==
The first stages of a project or the planning part of a program is identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. This is where a project takes form. Pointed out by Sebastian Lucae ''“Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “Fuzzy Front End” of the program.”''<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the Fuzzy Front End holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) ''“empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”''<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, ''“Fail fast, Fail often”'' as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design.
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market.
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaptation of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. ''“The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”''<ref name="success" />.

==Visualized testing and prototyping areas==
A big part of the failing and learning builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. ''“I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”''<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Nevertheless, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. ''“Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”''<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios. But the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-28T16:55:07Z

Kikigaga: /* Visualized testing and prototyping area */

=Introduction=
[[Category:Innovative Project Management]]
Project management can be seen as a linear continuous process, but it can also be seen as an continous iteration. The Embracing Failure movement and looking at your failures as a way to succeed has become very popular. When embracing your failures the ideal is that it is possible to learn from your failures and have better justification for your succes and thereby avoid a greater failure in the future. This article is intended as inspiration to see how embracing your failures serves as a philosophy in your company culture by defining your product development process.

=Research Area and Scope=
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

''Article category: Overview and summary of a relevant body of knowledge''

__TOC__

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: ''“How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”''<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy (Cass), lifelong innovator and creator of Klutz Press, taught them how to juggle. ''“Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”''<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. ''“Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”''<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: ''“Pushing yourself as far as you can lets you know what's possible“'' But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
[[File:singlelooplearning.png|200px|thumb|left| Single Loop Learning illustrated by Gareth Morgan <ref>Morgan, Gareth. ["Images of Organisation"], ''[[SAGE Publications]]'' 2006.</ref>]] [[File:doublelooplearning.png|200px|thumb|left| Double Loop Learning illustrated by Gareth Morgan <ref>Morgan, Gareth. ["Images of Organisation"], ''[[SAGE Publications]]'' 2006.</ref>]]
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his ''“I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”''<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks. The thought process of this can be seen in the figures by Gareth Morgan (See "Single Loop Learning" and "Double Loop Learning"). Here we see how an extra reflection incorporated in the process can be the only way for organisations to learn from their failed processes.

==How is Embracing Failure currently used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.

==Embracing Failures role in the Fuzzy Front End of a project==
The first stages of a project or the planning part of a program is identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. This is where a project takes form. Pointed out by Sebastian Lucae ''“Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “Fuzzy Front End” of the program.”''<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the Fuzzy Front End holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) ''“empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”''<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, ''“Fail fast, Fail often”'' as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design.
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market.
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaptation of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. ''“The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”''<ref name="success" />.

==Visualized testing and prototyping areas==
A big part of the failing and learning builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. ''“I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”''<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. ''“Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”''<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-28T16:54:22Z

Kikigaga: /* Adaption of the Spiral Model */

=Introduction=
[[Category:Innovative Project Management]]
Project management can be seen as a linear continuous process, but it can also be seen as an continous iteration. The Embracing Failure movement and looking at your failures as a way to succeed has become very popular. When embracing your failures the ideal is that it is possible to learn from your failures and have better justification for your succes and thereby avoid a greater failure in the future. This article is intended as inspiration to see how embracing your failures serves as a philosophy in your company culture by defining your product development process.

=Research Area and Scope=
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

''Article category: Overview and summary of a relevant body of knowledge''

__TOC__

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: ''“How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”''<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy (Cass), lifelong innovator and creator of Klutz Press, taught them how to juggle. ''“Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”''<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. ''“Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”''<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: ''“Pushing yourself as far as you can lets you know what's possible“'' But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
[[File:singlelooplearning.png|200px|thumb|left| Single Loop Learning illustrated by Gareth Morgan <ref>Morgan, Gareth. ["Images of Organisation"], ''[[SAGE Publications]]'' 2006.</ref>]] [[File:doublelooplearning.png|200px|thumb|left| Double Loop Learning illustrated by Gareth Morgan <ref>Morgan, Gareth. ["Images of Organisation"], ''[[SAGE Publications]]'' 2006.</ref>]]
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his ''“I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”''<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks. The thought process of this can be seen in the figures by Gareth Morgan (See "Single Loop Learning" and "Double Loop Learning"). Here we see how an extra reflection incorporated in the process can be the only way for organisations to learn from their failed processes.

==How is Embracing Failure currently used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.

==Embracing Failures role in the Fuzzy Front End of a project==
The first stages of a project or the planning part of a program is identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. This is where a project takes form. Pointed out by Sebastian Lucae ''“Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “Fuzzy Front End” of the program.”''<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the Fuzzy Front End holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) ''“empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”''<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, ''“Fail fast, Fail often”'' as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design.
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market.
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaptation of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. ''“The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”''<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. ''“I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”''<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. ''“Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”''<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-28T16:50:30Z

Kikigaga: /* The original Spiral Model */

=Introduction=
[[Category:Innovative Project Management]]
Project management can be seen as a linear continuous process, but it can also be seen as an continous iteration. The Embracing Failure movement and looking at your failures as a way to succeed has become very popular. When embracing your failures the ideal is that it is possible to learn from your failures and have better justification for your succes and thereby avoid a greater failure in the future. This article is intended as inspiration to see how embracing your failures serves as a philosophy in your company culture by defining your product development process.

=Research Area and Scope=
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

''Article category: Overview and summary of a relevant body of knowledge''

__TOC__

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: ''“How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”''<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy (Cass), lifelong innovator and creator of Klutz Press, taught them how to juggle. ''“Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”''<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. ''“Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”''<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: ''“Pushing yourself as far as you can lets you know what's possible“'' But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
[[File:singlelooplearning.png|200px|thumb|left| Single Loop Learning illustrated by Gareth Morgan <ref>Morgan, Gareth. ["Images of Organisation"], ''[[SAGE Publications]]'' 2006.</ref>]] [[File:doublelooplearning.png|200px|thumb|left| Double Loop Learning illustrated by Gareth Morgan <ref>Morgan, Gareth. ["Images of Organisation"], ''[[SAGE Publications]]'' 2006.</ref>]]
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his ''“I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”''<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks. The thought process of this can be seen in the figures by Gareth Morgan (See "Single Loop Learning" and "Double Loop Learning"). Here we see how an extra reflection incorporated in the process can be the only way for organisations to learn from their failed processes.

==How is Embracing Failure currently used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.

==Embracing Failures role in the Fuzzy Front End of a project==
The first stages of a project or the planning part of a program is identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. This is where a project takes form. Pointed out by Sebastian Lucae ''“Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “Fuzzy Front End” of the program.”''<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the Fuzzy Front End holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) ''“empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”''<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, ''“Fail fast, Fail often”'' as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design.
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market.
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. ''“The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”''<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. ''“I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”''<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. ''“Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”''<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-28T16:50:02Z

Kikigaga: /* How is Embracing Failure used? */

=Introduction=
[[Category:Innovative Project Management]]
Project management can be seen as a linear continuous process, but it can also be seen as an continous iteration. The Embracing Failure movement and looking at your failures as a way to succeed has become very popular. When embracing your failures the ideal is that it is possible to learn from your failures and have better justification for your succes and thereby avoid a greater failure in the future. This article is intended as inspiration to see how embracing your failures serves as a philosophy in your company culture by defining your product development process.

=Research Area and Scope=
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

''Article category: Overview and summary of a relevant body of knowledge''

__TOC__

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: ''“How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”''<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy (Cass), lifelong innovator and creator of Klutz Press, taught them how to juggle. ''“Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”''<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. ''“Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”''<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: ''“Pushing yourself as far as you can lets you know what's possible“'' But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
[[File:singlelooplearning.png|200px|thumb|left| Single Loop Learning illustrated by Gareth Morgan <ref>Morgan, Gareth. ["Images of Organisation"], ''[[SAGE Publications]]'' 2006.</ref>]] [[File:doublelooplearning.png|200px|thumb|left| Double Loop Learning illustrated by Gareth Morgan <ref>Morgan, Gareth. ["Images of Organisation"], ''[[SAGE Publications]]'' 2006.</ref>]]
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his ''“I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”''<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks. The thought process of this can be seen in the figures by Gareth Morgan (See "Single Loop Learning" and "Double Loop Learning"). Here we see how an extra reflection incorporated in the process can be the only way for organisations to learn from their failed processes.

==How is Embracing Failure currently used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.

==Embracing Failures role in the Fuzzy Front End of a project==
The first stages of a project or the planning part of a program is identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. This is where a project takes form. Pointed out by Sebastian Lucae ''“Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “Fuzzy Front End” of the program.”''<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the Fuzzy Front End holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) ''“empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”''<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, ''“Fail fast, Fail often”'' as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. ''“The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”''<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. ''“I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”''<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. ''“Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”''<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-28T16:45:22Z

Kikigaga: /* Learn from your mistakes */

=Introduction=
[[Category:Innovative Project Management]]
Project management can be seen as a linear continuous process, but it can also be seen as an continous iteration. The Embracing Failure movement and looking at your failures as a way to succeed has become very popular. When embracing your failures the ideal is that it is possible to learn from your failures and have better justification for your succes and thereby avoid a greater failure in the future. This article is intended as inspiration to see how embracing your failures serves as a philosophy in your company culture by defining your product development process.

=Research Area and Scope=
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

''Article category: Overview and summary of a relevant body of knowledge''

__TOC__

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: ''“How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”''<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy (Cass), lifelong innovator and creator of Klutz Press, taught them how to juggle. ''“Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”''<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. ''“Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”''<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: ''“Pushing yourself as far as you can lets you know what's possible“'' But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
[[File:singlelooplearning.png|200px|thumb|left| Single Loop Learning illustrated by Gareth Morgan <ref>Morgan, Gareth. ["Images of Organisation"], ''[[SAGE Publications]]'' 2006.</ref>]] [[File:doublelooplearning.png|200px|thumb|left| Double Loop Learning illustrated by Gareth Morgan <ref>Morgan, Gareth. ["Images of Organisation"], ''[[SAGE Publications]]'' 2006.</ref>]]
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his ''“I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”''<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks. The thought process of this can be seen in the figures by Gareth Morgan (See "Single Loop Learning" and "Double Loop Learning"). Here we see how an extra reflection incorporated in the process can be the only way for organisations to learn from their failed processes.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae ''“Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”''<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) ''“empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”''<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, ''“Fail fast, Fail often”'' as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. ''“The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”''<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. ''“I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”''<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. ''“Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”''<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-28T16:39:53Z

Kikigaga: /* Learn from your mistakes */

=Introduction=
[[Category:Innovative Project Management]]
Project management can be seen as a linear continuous process, but it can also be seen as an continous iteration. The Embracing Failure movement and looking at your failures as a way to succeed has become very popular. When embracing your failures the ideal is that it is possible to learn from your failures and have better justification for your succes and thereby avoid a greater failure in the future. This article is intended as inspiration to see how embracing your failures serves as a philosophy in your company culture by defining your product development process.

=Research Area and Scope=
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

''Article category: Overview and summary of a relevant body of knowledge''

__TOC__

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: ''“How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”''<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy (Cass), lifelong innovator and creator of Klutz Press, taught them how to juggle. ''“Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”''<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. ''“Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”''<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: ''“Pushing yourself as far as you can lets you know what's possible“'' But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his ''“I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”''<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.
[[File:singlelooplearning.png|200px|thumb|left| Single Loop Learning illustrated by Gareth Morgan <ref>Morgan, Gareth. ["Images of Organisation"], ''[[SAGE Publications]]'' 2006.</ref>]] [[File:doublelooplearning.png|200px|thumb|left| Double Loop Learning illustrated by Gareth Morgan <ref>Morgan, Gareth. ["Images of Organisation"], ''[[SAGE Publications]]'' 2006.</ref>]]

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae ''“Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”''<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) ''“empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”''<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, ''“Fail fast, Fail often”'' as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. ''“The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”''<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. ''“I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”''<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. ''“Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”''<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-28T16:38:28Z

Kikigaga: /* Learn from your mistakes */

=Introduction=
[[Category:Innovative Project Management]]
Project management can be seen as a linear continuous process, but it can also be seen as an continous iteration. The Embracing Failure movement and looking at your failures as a way to succeed has become very popular. When embracing your failures the ideal is that it is possible to learn from your failures and have better justification for your succes and thereby avoid a greater failure in the future. This article is intended as inspiration to see how embracing your failures serves as a philosophy in your company culture by defining your product development process.

=Research Area and Scope=
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

''Article category: Overview and summary of a relevant body of knowledge''

__TOC__

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: ''“How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”''<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy (Cass), lifelong innovator and creator of Klutz Press, taught them how to juggle. ''“Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”''<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. ''“Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”''<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: ''“Pushing yourself as far as you can lets you know what's possible“'' But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his ''“I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”''<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.
[[File:singlelooplearning.png|200px|thumb|left| Single Loop Learning illustrated by Gareth Morgan <ref>Morgan, Gareth. ["Images of Organisation"], ''[[SAGE Publications]]'' 2006.</ref>]]

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae ''“Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”''<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) ''“empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”''<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, ''“Fail fast, Fail often”'' as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. ''“The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”''<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. ''“I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”''<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. ''“Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”''<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

File:Doublelooplearning.png

2014-11-28T16:35:01Z

Kikigaga:

File:Singlelooplearning.png

2014-11-28T16:34:45Z

Kikigaga:

Creating a positive culture around failure in project management

2014-11-28T16:21:13Z

Kikigaga: /* Acceptance of failure */

=Introduction=
[[Category:Innovative Project Management]]
Project management can be seen as a linear continuous process, but it can also be seen as an continous iteration. The Embracing Failure movement and looking at your failures as a way to succeed has become very popular. When embracing your failures the ideal is that it is possible to learn from your failures and have better justification for your succes and thereby avoid a greater failure in the future. This article is intended as inspiration to see how embracing your failures serves as a philosophy in your company culture by defining your product development process.

=Research Area and Scope=
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

''Article category: Overview and summary of a relevant body of knowledge''

__TOC__

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: ''“How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”''<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy (Cass), lifelong innovator and creator of Klutz Press, taught them how to juggle. ''“Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”''<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. ''“Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”''<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: ''“Pushing yourself as far as you can lets you know what's possible“'' But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his ''“I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”''<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae ''“Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”''<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) ''“empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”''<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, ''“Fail fast, Fail often”'' as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. ''“The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”''<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. ''“I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”''<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. ''“Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”''<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-28T16:18:53Z

Kikigaga: /* Introduction */

=Introduction=
[[Category:Innovative Project Management]]
Project management can be seen as a linear continuous process, but it can also be seen as an continous iteration. The Embracing Failure movement and looking at your failures as a way to succeed has become very popular. When embracing your failures the ideal is that it is possible to learn from your failures and have better justification for your succes and thereby avoid a greater failure in the future. This article is intended as inspiration to see how embracing your failures serves as a philosophy in your company culture by defining your product development process.

=Research Area and Scope=
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

''Article category: Overview and summary of a relevant body of knowledge''

__TOC__

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: ''“How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”''<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. ''“Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”''<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. ''“Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”''<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: ''“Pushing yourself as far as you can lets you know what's possible“'' But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his ''“I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”''<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae ''“Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”''<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) ''“empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”''<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, ''“Fail fast, Fail often”'' as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. ''“The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”''<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. ''“I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”''<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. ''“Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”''<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-28T16:08:10Z

Kikigaga: /* Discussion of the method */

=Introduction=
[[Category:Innovative Project Management]]
Project management can be seen as a linear continuous process, but it can also be seen as an continous iteration. The Embracing Failure movement and looking at your failures as a way to succeed has become very popular. This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

''Article category: Overview and summary of a relevant body of knowledge''

__TOC__

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: ''“How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”''<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. ''“Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”''<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. ''“Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”''<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: ''“Pushing yourself as far as you can lets you know what's possible“'' But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his ''“I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”''<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae ''“Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”''<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) ''“empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”''<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, ''“Fail fast, Fail often”'' as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. ''“The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”''<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. ''“I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”''<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. ''“Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”''<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-28T16:07:48Z

Kikigaga: /* Visualized testing and prototyping area */

=Introduction=
[[Category:Innovative Project Management]]
Project management can be seen as a linear continuous process, but it can also be seen as an continous iteration. The Embracing Failure movement and looking at your failures as a way to succeed has become very popular. This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

''Article category: Overview and summary of a relevant body of knowledge''

__TOC__

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: ''“How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”''<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. ''“Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”''<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. ''“Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”''<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: ''“Pushing yourself as far as you can lets you know what's possible“'' But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his ''“I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”''<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae ''“Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”''<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) ''“empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”''<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, ''“Fail fast, Fail often”'' as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. ''“The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”''<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. ''“I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”''<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-28T16:07:26Z

Kikigaga: /* Open culture */

=Introduction=
[[Category:Innovative Project Management]]
Project management can be seen as a linear continuous process, but it can also be seen as an continous iteration. The Embracing Failure movement and looking at your failures as a way to succeed has become very popular. This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

''Article category: Overview and summary of a relevant body of knowledge''

__TOC__

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: ''“How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”''<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. ''“Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”''<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. ''“Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”''<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: ''“Pushing yourself as far as you can lets you know what's possible“'' But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his ''“I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”''<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae ''“Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”''<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) ''“empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”''<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, ''“Fail fast, Fail often”'' as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. ''“The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”''<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-28T16:06:54Z

Kikigaga: /* How can failure be positive in such a critical stage? */

=Introduction=
[[Category:Innovative Project Management]]
Project management can be seen as a linear continuous process, but it can also be seen as an continous iteration. The Embracing Failure movement and looking at your failures as a way to succeed has become very popular. This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

''Article category: Overview and summary of a relevant body of knowledge''

__TOC__

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: ''“How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”''<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. ''“Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”''<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. ''“Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”''<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: ''“Pushing yourself as far as you can lets you know what's possible“'' But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his ''“I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”''<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae ''“Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”''<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) ''“empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”''<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, ''“Fail fast, Fail often”'' as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. “The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-28T16:06:36Z

Kikigaga: /* How is Embracing Failure used? */

=Introduction=
[[Category:Innovative Project Management]]
Project management can be seen as a linear continuous process, but it can also be seen as an continous iteration. The Embracing Failure movement and looking at your failures as a way to succeed has become very popular. This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

''Article category: Overview and summary of a relevant body of knowledge''

__TOC__

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: ''“How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”''<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. ''“Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”''<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. ''“Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”''<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: ''“Pushing yourself as far as you can lets you know what's possible“'' But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his ''“I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”''<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae ''“Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”''<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) ''“empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”''<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, “Fail fast, Fail often” as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. “The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-28T16:05:43Z

Kikigaga: /* Learn from your mistakes */

=Introduction=
[[Category:Innovative Project Management]]
Project management can be seen as a linear continuous process, but it can also be seen as an continous iteration. The Embracing Failure movement and looking at your failures as a way to succeed has become very popular. This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

''Article category: Overview and summary of a relevant body of knowledge''

__TOC__

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: ''“How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”''<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. ''“Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”''<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. ''“Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”''<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: ''“Pushing yourself as far as you can lets you know what's possible“'' But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his ''“I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”''<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae “Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) “empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, “Fail fast, Fail often” as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. “The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-28T16:05:11Z

Kikigaga: /* Overcoming fear */

=Introduction=
[[Category:Innovative Project Management]]
Project management can be seen as a linear continuous process, but it can also be seen as an continous iteration. The Embracing Failure movement and looking at your failures as a way to succeed has become very popular. This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

''Article category: Overview and summary of a relevant body of knowledge''

__TOC__

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: ''“How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”''<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. ''“Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”''<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. ''“Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”''<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: ''“Pushing yourself as far as you can lets you know what's possible“'' But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his “I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae “Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) “empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, “Fail fast, Fail often” as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. “The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-28T16:01:52Z

Kikigaga: /* Acceptance of failure */

=Introduction=
[[Category:Innovative Project Management]]
Project management can be seen as a linear continuous process, but it can also be seen as an continous iteration. The Embracing Failure movement and looking at your failures as a way to succeed has become very popular. This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

''Article category: Overview and summary of a relevant body of knowledge''

__TOC__

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: ''“How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”''<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. ''“Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”''<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. “Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: “Pushing yourself as far as you can lets you know what's possible“ But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his “I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae “Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) “empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, “Fail fast, Fail often” as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. “The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-28T16:01:17Z

Kikigaga:

=Introduction=
[[Category:Innovative Project Management]]
Project management can be seen as a linear continuous process, but it can also be seen as an continous iteration. The Embracing Failure movement and looking at your failures as a way to succeed has become very popular. This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

''Article category: Overview and summary of a relevant body of knowledge''

__TOC__

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: ''“How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”''<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. “Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. “Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: “Pushing yourself as far as you can lets you know what's possible“ But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his “I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae “Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) “empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, “Fail fast, Fail often” as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. “The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-28T15:57:13Z

Kikigaga:

=Introduction=
[[Category:Innovative Project Management]]
Project management can be seen as a linear continuous process, but it can also be seen as an continous iteration. The Embracing Failure movement and looking at your failures as a way to succeed has become very popular. This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

''Article category: Overview and summary of a relevant body of knowledge''

__TOC__

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: “How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. “Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. “Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: “Pushing yourself as far as you can lets you know what's possible“ But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his “I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae “Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) “empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, “Fail fast, Fail often” as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. “The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-28T15:50:53Z

Kikigaga: /* Introduction */

Article category: Overview and summary of a relevant body of knowledge

=Introduction=
[[Category:Innovative Project Management]]
Project management can be seen as a linear continuous process, but it can also be seen as an continous iteration. The Embracing Failure movement and looking at your failures as a way to succeed has become very popular. This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

__TOC__

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: “How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. “Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. “Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: “Pushing yourself as far as you can lets you know what's possible“ But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his “I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae “Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) “empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, “Fail fast, Fail often” as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. “The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-28T15:42:59Z

Kikigaga:

Article category: Overview and summary of a relevant body of knowledge

=Introduction=
[[Category:Innovative Project Management]]
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

__TOC__

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: “How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. “Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. “Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: “Pushing yourself as far as you can lets you know what's possible“ But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his “I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae “Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) “empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, “Fail fast, Fail often” as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. “The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Talk:Life Cycle Model

2014-11-25T23:11:26Z

Kikigaga: /* Review by kikigaga */

== Feedback from Dnhr0 ==

Hello! I enjoyed reading your article and I found a couple of good points on it that make it easy and nice to read:
* There is a nice, natural flow in the content. It was quite easy to structure and picture in my mind what I was reading.
* It was understandable, with a good use of vocabulary and, of course, examples.
* The figures clarify the content easily, and are quite interesting.
* It was nice to go through the text and see that some key words were linked to other articles in the Wiki. It is very helpful when trying to get more in-depth knowledge about a certain topic.
* The references used throughout the text are from reliable sources.
* I think the length of the article is fine, since you talk about the important things of this topic.

At the same time, I think there are some minor things that you may want to go through again in order to consider my opinion (if you find it useful). Some of my recommendations are:
* Spelling:
** Abstract: framework instead of frame work.
** Historic Background: article instead of articel.
** The Life Cycle Phases
*** Whether instead of wether (also in Development Phase).
*** “As suggested here” instead of “as suggest here”.
*** “As an activity” instead of “as a activity”.
*** In Main study: sufficiency instead of sufficiently (that is the idea I got but maybe the meaning is different).
*** Case Example Development Phase: through instead of trough.
*** Realisation Phase: tasks instead of task ?
*** Utilisation Phase. Its instead of it’s, and “performance is monitored” instead of “performance monitored”.
*** Activity Cycles within Individual Life Cycle Phases: Another instead of “an other”.

* Grammar: You may want to review these sentences:
** Under Detailed study: “Within this phase detailed studies of the subsystems and their interrelation, which lead to detailed information about each sub solution and gives advice towards the implementation of the Engineering System.” It seems that there is a missing verb (or a part of the sentence).
** Under Realisation Phase: “Examples are the production of machinery or in case of IT and service systems the full documentation of the system. The system is ready to be implemented.” The first one I would add some commas: ““Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system”. However, it looks like there is a link missing between the first and the second sentences.

* In the abstract or summary, it could be a good idea to state the four phases of the life cycle model before referring to them. You start talking about these phases in the third line of the paragraph; however, you mention them until the end of it. It might be the case that you do not want to mention them before, but it was quite complicated to know what I was reading about without knowing these phases. It may also be a good idea if you state more clearly in this part what the reader is going to read in the article (explanation of the four phases, examples, variations of the model, etc.).
* Don’t forget to reference the figures in the text. They are very useful, so it could be even better if the text guides you through them.
* It could be useful to mention (before explaining the four phases) why you have decided to take these four phases and not others. It is not clear if this is the way Rainer Züst and Peter Troxler do it, or if you got the idea from other sources. This also affects the figure with the life cycle phases and decision gates.
* I consider it important to mention what you consider throughout the article as “Systems Engineering”. You could go into small detail, probably referencing a couple of sources. I think that it might be useful to divide the background in to sections: Main Concepts and Historical Background. That way you may be able to clarify this concept and probably make explicit the relationship between this topic and project/portfolio/program management.
* You may want to make the bullet points under the Development Phase in bold letters; however, it is just a suggestion, it may not be that relevant.
* The figures could be shown a little bit bigger. As they currently are, the reader needs to click on them to actually read the content.
* The second figure may need to add a label on the Y-axis to clearly state that it reflects influence (very helpful chart).
* It could be nice to contrast in some way the Life Cycle Model to the variations shown in the last section. You could discuss some advantages and disadvantages that this model may have, and how the other variants help or fail to address some of the disadvantages. This might not be the case if they are suitable for different circumstances.
* I think we do not have a specific referencing format, but it would be better for your article if they were written in the same style.

==Review by kikigaga==
First of all I thought it was nice and easy to read. It was kept to the point.
The other reviewer (as I can see) covered a lot of my points so I will stick to the things that were extra;)
*Think about if you want a specific angle on the concept. I thought it was nice to hear about the area but as I also know about LCA and stuff I might want to know how this differs and what you found interesting about the subject?
*I liked the case company idea, but maybe you would want to introduce it in the beginning as a strategy for the article so the reader is prepared. Did you or someone else come up with the cases?
*Could there be some implementation advice?
*Are we going to know what happens to the case companies?
*I would like to see a longer discussion of the model compared to de other models. How is this better, why do companies choose other models and so on.

Thank you for making it interesting to read, I really enjoyed it!

Talk:Life Cycle Model

2014-11-25T23:10:42Z

Kikigaga: /* Review by kikigaga */

Talk:Life Cycle Model

2014-11-25T23:06:23Z

Kikigaga: /* Review by kikigaga */

== Feedback from Dnhr0 ==

Hello! I enjoyed reading your article and I found a couple of good points on it that make it easy and nice to read:
* There is a nice, natural flow in the content. It was quite easy to structure and picture in my mind what I was reading.
* It was understandable, with a good use of vocabulary and, of course, examples.
* The figures clarify the content easily, and are quite interesting.
* It was nice to go through the text and see that some key words were linked to other articles in the Wiki. It is very helpful when trying to get more in-depth knowledge about a certain topic.
* The references used throughout the text are from reliable sources.
* I think the length of the article is fine, since you talk about the important things of this topic.

At the same time, I think there are some minor things that you may want to go through again in order to consider my opinion (if you find it useful). Some of my recommendations are:
* Spelling:
** Abstract: framework instead of frame work.
** Historic Background: article instead of articel.
** The Life Cycle Phases
*** Whether instead of wether (also in Development Phase).
*** “As suggested here” instead of “as suggest here”.
*** “As an activity” instead of “as a activity”.
*** In Main study: sufficiency instead of sufficiently (that is the idea I got but maybe the meaning is different).
*** Case Example Development Phase: through instead of trough.
*** Realisation Phase: tasks instead of task ?
*** Utilisation Phase. Its instead of it’s, and “performance is monitored” instead of “performance monitored”.
*** Activity Cycles within Individual Life Cycle Phases: Another instead of “an other”.

* Grammar: You may want to review these sentences:
** Under Detailed study: “Within this phase detailed studies of the subsystems and their interrelation, which lead to detailed information about each sub solution and gives advice towards the implementation of the Engineering System.” It seems that there is a missing verb (or a part of the sentence).
** Under Realisation Phase: “Examples are the production of machinery or in case of IT and service systems the full documentation of the system. The system is ready to be implemented.” The first one I would add some commas: ““Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system”. However, it looks like there is a link missing between the first and the second sentences.

* In the abstract or summary, it could be a good idea to state the four phases of the life cycle model before referring to them. You start talking about these phases in the third line of the paragraph; however, you mention them until the end of it. It might be the case that you do not want to mention them before, but it was quite complicated to know what I was reading about without knowing these phases. It may also be a good idea if you state more clearly in this part what the reader is going to read in the article (explanation of the four phases, examples, variations of the model, etc.).
* Don’t forget to reference the figures in the text. They are very useful, so it could be even better if the text guides you through them.
* It could be useful to mention (before explaining the four phases) why you have decided to take these four phases and not others. It is not clear if this is the way Rainer Züst and Peter Troxler do it, or if you got the idea from other sources. This also affects the figure with the life cycle phases and decision gates.
* I consider it important to mention what you consider throughout the article as “Systems Engineering”. You could go into small detail, probably referencing a couple of sources. I think that it might be useful to divide the background in to sections: Main Concepts and Historical Background. That way you may be able to clarify this concept and probably make explicit the relationship between this topic and project/portfolio/program management.
* You may want to make the bullet points under the Development Phase in bold letters; however, it is just a suggestion, it may not be that relevant.
* The figures could be shown a little bit bigger. As they currently are, the reader needs to click on them to actually read the content.
* The second figure may need to add a label on the Y-axis to clearly state that it reflects influence (very helpful chart).
* It could be nice to contrast in some way the Life Cycle Model to the variations shown in the last section. You could discuss some advantages and disadvantages that this model may have, and how the other variants help or fail to address some of the disadvantages. This might not be the case if they are suitable for different circumstances.
* I think we do not have a specific referencing format, but it would be better for your article if they were written in the same style.

==Review by kikigaga==
First of all I thought it was nice and easy to read. It was kept to the point.
The other reviewer (as I can see) covered a lot of my points so I will stick to the things that were extra;)
*Think about if you want a specific angle on the concept. I thought it was nice to hear about the area but as I also know about LCA and stuff I might want to know how this differs and what you found interesting about the subject?
*I liked the case company idea, but maybe you would want to introduce it in the beginning as a strategy for the article so the reader is prepared. Did you or someone else come up with the cases?
*Could there be some implementation advice?
*Are we going to know what happens to the case companies?

Thank you for making it easy to read, I enjoyed it!

Talk:Life Cycle Model

2014-11-25T23:05:25Z

Kikigaga: /* Feedback from Dnhr0 */

== Feedback from Dnhr0 ==

Hello! I enjoyed reading your article and I found a couple of good points on it that make it easy and nice to read:
* There is a nice, natural flow in the content. It was quite easy to structure and picture in my mind what I was reading.
* It was understandable, with a good use of vocabulary and, of course, examples.
* The figures clarify the content easily, and are quite interesting.
* It was nice to go through the text and see that some key words were linked to other articles in the Wiki. It is very helpful when trying to get more in-depth knowledge about a certain topic.
* The references used throughout the text are from reliable sources.
* I think the length of the article is fine, since you talk about the important things of this topic.

At the same time, I think there are some minor things that you may want to go through again in order to consider my opinion (if you find it useful). Some of my recommendations are:
* Spelling:
** Abstract: framework instead of frame work.
** Historic Background: article instead of articel.
** The Life Cycle Phases
*** Whether instead of wether (also in Development Phase).
*** “As suggested here” instead of “as suggest here”.
*** “As an activity” instead of “as a activity”.
*** In Main study: sufficiency instead of sufficiently (that is the idea I got but maybe the meaning is different).
*** Case Example Development Phase: through instead of trough.
*** Realisation Phase: tasks instead of task ?
*** Utilisation Phase. Its instead of it’s, and “performance is monitored” instead of “performance monitored”.
*** Activity Cycles within Individual Life Cycle Phases: Another instead of “an other”.

* Grammar: You may want to review these sentences:
** Under Detailed study: “Within this phase detailed studies of the subsystems and their interrelation, which lead to detailed information about each sub solution and gives advice towards the implementation of the Engineering System.” It seems that there is a missing verb (or a part of the sentence).
** Under Realisation Phase: “Examples are the production of machinery or in case of IT and service systems the full documentation of the system. The system is ready to be implemented.” The first one I would add some commas: ““Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system”. However, it looks like there is a link missing between the first and the second sentences.

* In the abstract or summary, it could be a good idea to state the four phases of the life cycle model before referring to them. You start talking about these phases in the third line of the paragraph; however, you mention them until the end of it. It might be the case that you do not want to mention them before, but it was quite complicated to know what I was reading about without knowing these phases. It may also be a good idea if you state more clearly in this part what the reader is going to read in the article (explanation of the four phases, examples, variations of the model, etc.).
* Don’t forget to reference the figures in the text. They are very useful, so it could be even better if the text guides you through them.
* It could be useful to mention (before explaining the four phases) why you have decided to take these four phases and not others. It is not clear if this is the way Rainer Züst and Peter Troxler do it, or if you got the idea from other sources. This also affects the figure with the life cycle phases and decision gates.
* I consider it important to mention what you consider throughout the article as “Systems Engineering”. You could go into small detail, probably referencing a couple of sources. I think that it might be useful to divide the background in to sections: Main Concepts and Historical Background. That way you may be able to clarify this concept and probably make explicit the relationship between this topic and project/portfolio/program management.
* You may want to make the bullet points under the Development Phase in bold letters; however, it is just a suggestion, it may not be that relevant.
* The figures could be shown a little bit bigger. As they currently are, the reader needs to click on them to actually read the content.
* The second figure may need to add a label on the Y-axis to clearly state that it reflects influence (very helpful chart).
* It could be nice to contrast in some way the Life Cycle Model to the variations shown in the last section. You could discuss some advantages and disadvantages that this model may have, and how the other variants help or fail to address some of the disadvantages. This might not be the case if they are suitable for different circumstances.
* I think we do not have a specific referencing format, but it would be better for your article if they were written in the same style.

==Review by kikigaga==
First of all I thought it was nice and easy to read. It was kept to the point.
The other reviewer (as I can see) covered a lot of my points so I will stick to the things that were extra;)
Think about if you want a specific angle on the concept. I thought it was nice to hear about the area but as I also know about LCA and stuff I might want to know how this differs and what you found interesting about the subject?
I liked the case company idea, but maybe you would want to introduce it in the beginning as a strategy for the article so the reader is prepared. Did you or someone else come up with the cases?
Could there be some implementation advice?
Are we going to know what happens to the case companies?

Thank you for making it easy to read, I enjoyed it!

Talk:Life Cycle Model

2014-11-25T23:05:07Z

Kikigaga: /* Feedback from Dnhr0 */

== Feedback from Dnhr0 ==

Hello! I enjoyed reading your article and I found a couple of good points on it that make it easy and nice to read:
* There is a nice, natural flow in the content. It was quite easy to structure and picture in my mind what I was reading.
* It was understandable, with a good use of vocabulary and, of course, examples.
* The figures clarify the content easily, and are quite interesting.
* It was nice to go through the text and see that some key words were linked to other articles in the Wiki. It is very helpful when trying to get more in-depth knowledge about a certain topic.
* The references used throughout the text are from reliable sources.
* I think the length of the article is fine, since you talk about the important things of this topic.

At the same time, I think there are some minor things that you may want to go through again in order to consider my opinion (if you find it useful). Some of my recommendations are:
* Spelling:
** Abstract: framework instead of frame work.
** Historic Background: article instead of articel.
** The Life Cycle Phases
*** Whether instead of wether (also in Development Phase).
*** “As suggested here” instead of “as suggest here”.
*** “As an activity” instead of “as a activity”.
*** In Main study: sufficiency instead of sufficiently (that is the idea I got but maybe the meaning is different).
*** Case Example Development Phase: through instead of trough.
*** Realisation Phase: tasks instead of task ?
*** Utilisation Phase. Its instead of it’s, and “performance is monitored” instead of “performance monitored”.
*** Activity Cycles within Individual Life Cycle Phases: Another instead of “an other”.

* Grammar: You may want to review these sentences:
** Under Detailed study: “Within this phase detailed studies of the subsystems and their interrelation, which lead to detailed information about each sub solution and gives advice towards the implementation of the Engineering System.” It seems that there is a missing verb (or a part of the sentence).
** Under Realisation Phase: “Examples are the production of machinery or in case of IT and service systems the full documentation of the system. The system is ready to be implemented.” The first one I would add some commas: ““Examples are the production of machinery or, in case of IT and service systems, the full documentation of the system”. However, it looks like there is a link missing between the first and the second sentences.

* In the abstract or summary, it could be a good idea to state the four phases of the life cycle model before referring to them. You start talking about these phases in the third line of the paragraph; however, you mention them until the end of it. It might be the case that you do not want to mention them before, but it was quite complicated to know what I was reading about without knowing these phases. It may also be a good idea if you state more clearly in this part what the reader is going to read in the article (explanation of the four phases, examples, variations of the model, etc.).
* Don’t forget to reference the figures in the text. They are very useful, so it could be even better if the text guides you through them.
* It could be useful to mention (before explaining the four phases) why you have decided to take these four phases and not others. It is not clear if this is the way Rainer Züst and Peter Troxler do it, or if you got the idea from other sources. This also affects the figure with the life cycle phases and decision gates.
* I consider it important to mention what you consider throughout the article as “Systems Engineering”. You could go into small detail, probably referencing a couple of sources. I think that it might be useful to divide the background in to sections: Main Concepts and Historical Background. That way you may be able to clarify this concept and probably make explicit the relationship between this topic and project/portfolio/program management.
* You may want to make the bullet points under the Development Phase in bold letters; however, it is just a suggestion, it may not be that relevant.
* The figures could be shown a little bit bigger. As they currently are, the reader needs to click on them to actually read the content.
* The second figure may need to add a label on the Y-axis to clearly state that it reflects influence (very helpful chart).
* It could be nice to contrast in some way the Life Cycle Model to the variations shown in the last section. You could discuss some advantages and disadvantages that this model may have, and how the other variants help or fail to address some of the disadvantages. This might not be the case if they are suitable for different circumstances.
* I think we do not have a specific referencing format, but it would be better for your article if they were written in the same style.

==Review by kikigaga"
First of all I thought it was nice and easy to read. It was kept to the point.
The other reviewer (as I can see) covered a lot of my points so I will stick to the things that were extra;)
Think about if you want a specific angle on the concept. I thought it was nice to hear about the area but as I also know about LCA and stuff I might want to know how this differs and what you found interesting about the subject?
I liked the case company idea, but maybe you would want to introduce it in the beginning as a strategy for the article so the reader is prepared. Did you or someone else come up with the cases?
Could there be some implementation advice?
Are we going to know what happens to the case companies?

Thank you for making it easy to read, I enjoyed it!

Talk:Project Evaluation and Selection for the Formation of the Optimal Portfolio

2014-11-25T22:44:36Z

Kikigaga: /* reviewed by Saeh0803 and kikigaga*/

== reviewed by Saeh0803 ==

1. Very long summary, maybe you can make it a bit short and interesting for reader

2. you didn't referenced the first figure in the text, you also not referenced the figure number two on the text, I know you explain the points from figure, but you need to write something like "..as it shown in figure X".

* Is the article interesting for a practitioner? --> I think it is a bit boring, it is maybe the way of writing.. (long explanations and long sentences ) but over all I think it is a good article and you have all main points, but if I search for this topic at google and want to read about it, then I will chose one, which is short and precis.. because you have write it in too many details..

* Does the article clearly relate to a project, program or portfolio management topic? --> Yes

* Is it clear which one of the four “content categories” the article belongs to? --> yes

* Does the length of the article seem appropriate? Does it contain less relevant passages or excessive details? Does it miss critical details? (The suggested length is “on the order of 3500 words”. Articles can be longer or shorter if it makes sense to do so in order to deliver a quality argument.) --> I think this articles is more in 3500 words, I can't see it on WIKI, but it seems to be more than 3500..

* Is there a logical flow throughout the article? Are the parts “tied together” through a red thread? --> I think yes

* Is the article free of grammatical, spelling and punctuation errors--> I think yes, I have difficult to understand,maybe because my English is not so good, but its really difficult to understand and readers may read one sentence more than one time to understand it..

* Is the article written in an engaging style, e.g. short, precise sentences instead of long winded, hard to follow mega -sentences? --> Puhaaa, I think it is difficult to understand and follow, you both have long sentences and many explanations

* Are all main points illustrated with an appropriate figure?

* Are the figures free of formal errors--> yes

* Are the figures referenced in the text? --> the first figure is not referenced in the text

* Does the author have the copyright or right to use the figures (e.g.through Creative) common Non-Commercial share Alike attribution?) --> maybe, can't see

* Is the article formatted properly, i.e. are the typical Wiki-features such sub-headings, proper bullet-point list and Wiki-style references used? are graphics, videos ect. integrated correctly? --> Yes

as I wrote, overall your article is good, try to change the sentences, so its understandable, maybe make it shorts and use some every days words, so everyone can understand what they are reading about :)

I hope you can use my comments and best of luck :)

== Reviewed by kikigaga==

Hi, as a product engineer I think the subject is interesting. So great:)
I believe that the article might be too long compared to the content, but what do I know..

Some short comments, since the other reviewer went through all the points I will only go through the ones i thought was standing out.

*Clarify the introduction so that the user knows what he/she is reading about.
**As i said, it is interesting but the long introduction made me almost give up.
*Gramma fails in some sentences
** Maybe it is because of sentences referring to the sentence before all the time, it is hard to read.
*Refer to the models or keep them out
** As i could see non of the figures are referred to?
*There are 4 major sources of internal dependencies – Says who?
**Make it clear: When is it your voice and when the references? (The implementation advice e.g.)

Thank you, and good luck:)

Creating a positive culture around failure in project management

2014-11-23T21:38:11Z

Kikigaga: /* Introduction */

Article category: Overview and summary of a relevant body of knowledge

=Introduction=
[[Category:Innovative Project Management]]
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: “How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. “Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. “Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: “Pushing yourself as far as you can lets you know what's possible“ But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his “I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae “Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) “empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, “Fail fast, Fail often” as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. “The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

File:TheSpiralModelHARDWARE.png

2014-11-23T21:32:57Z

Kikigaga: Kikigaga uploaded a new version of "File:TheSpiralModelHARDWARE.png"

Adapted Spiral Model for Hardware development

Creating a positive culture around failure in project management

2014-11-23T21:31:29Z

Kikigaga: /* Discussion of the method */

=Introduction=
[[Category:Innovative Project Management]]
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: “How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. “Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. “Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: “Pushing yourself as far as you can lets you know what's possible“ But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his “I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae “Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) “empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, “Fail fast, Fail often” as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. “The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.”<ref>Petinga, Scott. [http://www.forbes.com/sites/theyec/2014/08/12/how-to-embrace-failure-in-order-to-become-successful/ "How to embrace failure in order to become successful"], ''[[Forbes]]'', 12 August 2014. Retrieved on 18 November 2014.</ref> . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-23T21:27:55Z

Kikigaga: /* Visualized testing and prototyping area */

=Introduction=
[[Category:Innovative Project Management]]
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: “How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. “Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. “Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: “Pushing yourself as far as you can lets you know what's possible“ But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his “I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae “Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) “empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, “Fail fast, Fail often” as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. “The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', Quote by Anjali Pastry, 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.” . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-23T21:26:39Z

Kikigaga: /* Other important initiatives */

=Introduction=
[[Category:Innovative Project Management]]
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: “How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. “Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. “Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: “Pushing yourself as far as you can lets you know what's possible“ But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his “I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae “Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) “empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, “Fail fast, Fail often” as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. “The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,”<ref>Gillet, Rachel. "What the hype behind Embracing Failure is really all about"], ''[[Fast Company]]'', 8 September 2014. Retrieved on 18 November 2014.</ref>.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.” . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-23T21:23:04Z

Kikigaga: /* Open culture */

=Introduction=
[[Category:Innovative Project Management]]
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: “How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. “Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. “Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: “Pushing yourself as far as you can lets you know what's possible“ But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his “I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae “Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) “empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, “Fail fast, Fail often” as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. “The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”<ref name="success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,” says Anjali Sastry.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.” . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-23T21:22:08Z

Kikigaga: /* Embracing Failure */

=Introduction=
[[Category:Innovative Project Management]]
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: “How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”<ref name="success" >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. “Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. “Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: “Pushing yourself as far as you can lets you know what's possible“ But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his “I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae “Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) “empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, “Fail fast, Fail often” as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. “The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”<ref name="Success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,” says Anjali Sastry.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.” . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-23T21:21:10Z

Kikigaga: /* Embracing Failure */

=Introduction=
[[Category:Innovative Project Management]]
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: “How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”<ref name=success >Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. “Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. “Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: “Pushing yourself as far as you can lets you know what's possible“ But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his “I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae “Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) “empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, “Fail fast, Fail often” as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. “The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”<ref name="Success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,” says Anjali Sastry.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.” . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-23T21:20:31Z

Kikigaga: /* Other important initiatives */

=Introduction=
[[Category:Innovative Project Management]]
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: “How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”<ref>Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. “Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. “Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: “Pushing yourself as far as you can lets you know what's possible“ But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his “I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae “Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) “empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, “Fail fast, Fail often” as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. “The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”<ref name="Success" />.

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,” says Anjali Sastry.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.” . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-23T21:18:26Z

Kikigaga: /* Using the Spiral Model as a concrete initiative */

=Introduction=
[[Category:Innovative Project Management]]
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: “How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”<ref>Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. “Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. “Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: “Pushing yourself as far as you can lets you know what's possible“ But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his “I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae “Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) “empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, “Fail fast, Fail often” as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B<ref name="Boehm" />.]]
The Spiral Model is ([[Media:TheSpiralModel.png]]) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process<ref name=Boehm >Boehm, Barry. "Spiral Development: Experience, Principles, and Refinements", ''[[Carnegie Mellon Software Engineering Institute]]'', 9 February 2000.</ref>.
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. “The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,” says Anjali Sastry.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.” . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-23T21:11:11Z

Kikigaga: /* References */

=Introduction=
[[Category:Innovative Project Management]]
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: “How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”<ref>Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. “Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. “Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: “Pushing yourself as far as you can lets you know what's possible“ But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his “I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae “Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) “empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, “Fail fast, Fail often” as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B.]]
The Spiral Model is (see figure XX) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process (Boehm, B).
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. “The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,” says Anjali Sastry.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.” . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
<references />

Creating a positive culture around failure in project management

2014-11-23T21:09:05Z

Kikigaga: /* Embracing Failure */

=Introduction=
[[Category:Innovative Project Management]]
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: “How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.”<ref>Plunkett, John. [http://www.success.com/article/why-failure-is-good-for-success "Why failure is good for success"], ''[[Success]]'', 13 December 2010. Retrieved on 18 November 2014.</ref> This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. “Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”<ref>Kelley, Tom and David. "Creative Confidence", ''[[Crown Business]]'', 2013.</ref>

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. “Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.”<ref>Greenberg, Scott. [http://www.boxingscene.com/motivation/2603.php "Nine reasons to embrace failure"], ''[[Boxing Scene]]''. Retrieved on 18 November 2014.</ref> Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: “Pushing yourself as far as you can lets you know what's possible“ But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his “I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?”<ref>Branson, Richard. [http://www.entrepreneur.com/article/229876 "Richard Branson on Embracing Failure"], ''[[Entrepreneur]]'' 11 November 2013. Retrieved on 18 November 2014.</ref> This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae “Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.”<ref name="Lucae">Lucae, Sebastian. "Diploma Thesis Nr. 1392: Improving the Fuzzy Front-end of Large Engineering Programs", ''[[Institute of Product Development Technische Universität München]]'', München, 15 Juni 2013.</ref> These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) “empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”<ref name="Lucae" />.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, “Fail fast, Fail often” as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B.]]
The Spiral Model is (see figure XX) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process (Boehm, B).
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. “The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,” says Anjali Sastry.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.” . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
{{Reflist}}

Creating a positive culture around failure in project management

2014-11-23T20:43:42Z

Kikigaga: /* References */

=Introduction=
[[Category:Innovative Project Management]]
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: “How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.” This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. “Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. “Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.” Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: “Pushing yourself as far as you can lets you know what's possible“ But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his “I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?” This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae “Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.” These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) “empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, “Fail fast, Fail often” as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B.]]
The Spiral Model is (see figure XX) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process (Boehm, B).
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. “The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,” says Anjali Sastry.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.” . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
{{Reflist}}

Creating a positive culture around failure in project management

2014-11-23T20:43:23Z

Kikigaga: /* References */

=Introduction=
[[Category:Innovative Project Management]]
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: “How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.” This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. “Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. “Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.” Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: “Pushing yourself as far as you can lets you know what's possible“ But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his “I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?” This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae “Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.” These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) “empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, “Fail fast, Fail often” as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B.]]
The Spiral Model is (see figure XX) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process (Boehm, B).
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. “The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,” says Anjali Sastry.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.” . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=
{Reflist}

Creating a positive culture around failure in project management

2014-11-23T20:37:04Z

Kikigaga: /* Adaption of the Spiral Model */

=Introduction=
[[Category:Innovative Project Management]]
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: “How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.” This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. “Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. “Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.” Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: “Pushing yourself as far as you can lets you know what's possible“ But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his “I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?” This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae “Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.” These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) “empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, “Fail fast, Fail often” as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B.]]
The Spiral Model is (see figure XX) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process (Boehm, B).
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
[[File:TheSpiralModelHARDWARE.png|200px|thumb|left|An adapted Spiral Model to fit the design process of hardware.]]
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. “The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,” says Anjali Sastry.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.” . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=

Creating a positive culture around failure in project management

2014-11-23T20:35:57Z

Kikigaga: /* The original Spiral Model */

=Introduction=
[[Category:Innovative Project Management]]
This article serves as food for thought for project managers to improve their end products by the Embracing Failure methodology. The article will seek to answer the following two research questions:

*How can the Spiral Model incorporate the Embracing Failure methodology into project management?
*What are the limits in incorporating Embracing Failure methodology in the Spiral Model?

When referring to the Embracing Failure methodology a number of different methods can be used as long as they live up to the Embracing Failure key values. In this article the Spiral Model will serve as an example of implementing Embracing Failure, while it will be kept in mind that this is not definitive and cannot serve as the project managers only initiative.
The concept of Embracing Failure and the Spiral Model will be described and sought adapted to a hardware product development process. The article will also contain a discussion of the limits of the method.

=Embracing Failure=
The concept of using your failures to rise to the next level is not new but has lately received a fair amount of attention in the business world especially as a tool in the entrepreneurial circles. A reporter once asked Thomas Edison about his 1,000 failed attempts to make the light bulb: “How did it feel to fail 1,000 times?” “I didn’t fail 1,000 times,” Edison responded. “The light bulb was an invention with 1,000 steps.” This is the way the methodology in Embracing Failure reasons. A failed attempt is jet another step towards success.

==Acceptance of failure==
The first thing you need to do in order to embrace the failure as a learning experience, Tom and David Kelley says, is to accept that failure is a natural part of any process. Tom and David Kelley described the initiative by how John Cassidy, lifelong innovator and creator of Klutz Press, taught them how to juggle. “Cass didn’t start us out juggling two balls, or even one. He began with something more basic: “The Drop.” Step one is simply to throw all three balls in the air and let them drop. Then repeat. In learning to juggle, the angst comes from failure— from having the ball fall to the floor. So with step one, Cass aims to numb aspiring jugglers to that. Having the ball fall to the floor becomes more normal than the ball not falling to the floor. After addressing our fear of failure, juggling becomes a lot easier.”

It is important not to think of failure as massive life changing failures every time. A failure is in this reference defined as mistakes, wrongful assumptions and flaws in communication and so on. Even though a lot of these can be harmless some are very important especially in the defining phase of a design process and therefore an interesting focus point for project managers.

==Overcoming fear==
The next element is to overcome the fear of the unknown. In a design process it can be harmful to the innovation and creativity not to explore new territories and new functions. This is why we as designers need to adapt to the key believes of the scientists’ methodology. Scott Greenberg focuses on the fact that failure teaches us. “Scientists rely on trial and error in their research. Each failed experiment brings them a little closer to revolutionary breakthroughs.” Embracing the thinking of the scientist can let the curiosity be the leader to new thinking through testing and prototyping. Scott Greenberg continues: “Pushing yourself as far as you can lets you know what's possible“ But to experience this you must overcome the fear of failing in order to challenge your way of thinking.

==Learn from your mistakes==
The goal with all this is to be able to learn from your failures. And to learn you need to dig deeper into what caused it. Entrepreneur Richard Branson shares his “I’ve always found that the first step in overcoming fear is figuring out exactly what you’re afraid of. In your case, I wonder: Is your anxiety a reflection of doubts about your business plan? Or is it rooted in your experience with your previous venture?” This step can be done by a root cause analysis to differ between root causes and aftershocks.

==How is Embracing Failure used?==
Embracing Failure is mostly perceived as a way of thinking. Most ideas behind the concept are changing the nature of how we perceive and react to failure, which is stored deep inside of us. In the research of this article it became apparent that there is a lack of explaining how to practically incorporate this thinking into ones daily decision-making process. This has also served as an inspiration to the thesis of the concrete implementation suggestions this article is presenting.
Embracing Failures role in the Fuzzy Front End of a project
The first stages of a project or the planning part of a program are identified as the Fuzzy Front End (FFE), which hold a lot of importance in the execution of the project. Pointed out by Sebastian Lucae “Significant problems in program execution can be traced back to practices performed, or more frequently not performed, in the so-called “fuzzy front end” of the program.” These stages often hold the lowest risk for the portfolio manager, which makes it easier to drop the project when the investments are still small. Contrary to this the fuzzy front end holds the highest risk for the project manager as his project is of high risk of being cut. This stage is thereby the biggest Go-Kill step in product development and a thorough execution would therefore have a significant impact.

According to MORGAN 2006 (p. 39) “empirical evidence shows that poor decisions early in the process have a negative impact on cost and timing, which increases exponentially as time passes and the project matures”. By putting more effort on thorough planning, problems can be solved “at a root cause level early in the process” to “nearly eliminate the traditional product development problems of late design changes (“quick fixes”), which are expensive, suboptimal and always degrade both product and process performance”.

This tells us that the Fuzzy Front End could be a viable starting point for a shift in practices.

==How can failure be positive in such a critical stage?==
The thesis of this article is that it is important to make risk assessments and thereby provide the initial investors with a proof of concept especially in critical stages. In this stage learning from every iteration and failure can be the best way to eliminate future risks, “Fail fast, Fail often” as the unofficial motto for the Silicon Valley says. By detecting the flaws of a design early in the process can save the costs of expensive development in favor of cheep pre-prototyping and quick mock-ups.

=Using the Spiral Model as a concrete initiative=
The Spiral Model is a project model made to balance the risk and cost of software development. It is used in this article as an example of incorporating Embrace Failure methodology into existing models and procedures. The model is adapted to a new environment by being taken out of its original used – software development – and incorporated into a hardware design process for the sake of argument. To make it clear, this changes some of the theories from the original model.

==The original Spiral Model==
[[File:TheSpiralModel.png|200px|thumb|left|The original Spiral Model, Boehm, B.]]
The Spiral Model is (see figure XX) shaped as a spiral and contains as a starting point three iterations of the project.

The model is based on six invariants that must be considered through the design process (Boehm, B).
*Define artifacts concurrently to create alignment in the objectives throughout the design
*Perform four basic activities in every other cycle: Define win conditions of each important stakeholder, be aware of how to satisfy the conditions, know the risk each stakeholder takes and obtain approval from the stakeholders.
*Risk determines level of efforts. Define project risks in test vs. early entry on market
*Risk determines degree of detail. Detail is put into the specification of risk-reducing functions and not the risk-increasing functions.
*Use anchor point milestones. To keep track on the process and be aware of the goals with each milestone.
*Focus on the system and its life cycle. Be sure to match the surrounding environment.

All in all it focuses on iterations that makes it possible to test and evaluate and reevaluate the product idea and execution. Software development processes is based on testing and sometimes launching a beta version of the product to make sure the market is ready for the product. This is something that would be interesting to see if hardware developers to learn from and try to incorporate more in the design process.

==Adaption of the Spiral Model==
Even though the model is primarily used in software design and therefore contains a lot of references to code and software requirements a lot can be directly translated to stages in hardware design.

To make it clear how important listing the objectives and translating them to functions are the initial stages it has been added as a step to the model. This makes it possible to comply with the first invariant to defines modules and artifacts concurrently. A risk analysis is created and updated for every iteration to fit the current projections. An early prototype is created to function as a proof of concept and the concept is reviewed both by the designers, the users and the stakeholders. These initial stages will often be enough to seek the first investors whether it is found inside of the company or outside, as it has been seen with foundations where applications only demand a proof of concept.

In the outer ring, that can be the third or higher iteration, a basic architecture for the design makes it possible to design modules concurrently and then do an integration test.
The main differentials in using the Spiral Model in hardware design is that a lot of the design will need more visual sharing tools since the designs will be designed in teams of industrial designers, mechanical engineers, software engineers and management.

=Other important initiatives=
==Open culture==
As previously mentioned simply the implementing the adapted Spiral Model will not be sufficient to truly incorporate and embrace failure in the project group. As a project manager there is a ton of work needed to create an open culture where sharing of ideas and non-conformed thoughts can be met with interest and trust there is value behind it. “The first is to consciously maintain a positive attitude so that, no matter what you encounter, you’ll be able to see the lessons of the experience and continue to push forward.”

==Visualized testing and prototyping area==
A big part of the failing and learning from it builds on constantly testing theories which in hardware means building early stage prototypes and proof of concept models. If the building and testing of these models is visual it will work as a conversation starter and push the creator to think about their choices in the process and not only as a result of user testing. “I believe that (the embrace failure movement has) taken off because it taps into a widespread sense that we, as individuals, teams, organizations, and even societies, live in an era where we cannot always get things right the first time, no matter how smart we are or how carefully we plan,” says Anjali Sastry.

==Usability testing and super users==
Testing outside the laboratory is just as important to make sure the product is viable in the thought user group and system. Every prototype should be presented to non-designers to get as many fails incorporated in the next iteration as possible. A group of super users or focus groups might be a good idea to openly critique the product in a safe environment.

=Discussion of the method=
This article is composed as an introduction to combining two concepts that are described in with two very different level of detail. Embracing Failure is, as previously described, introduced as a though process and a way of living and lacks a lot of concreteness. The Spiral Model is on the other hand very specifically described and practiced but have a greater span of usage than initially introduced by the author.

Even though Boehm is very specific it is of my own believe that models should be used an adapted to different situations as the user sees fit. Boehm’s model is made to focus on minimizing risk, which is also a key element in Embracing Failure by making the failures in the beginning of the process so the project isn’t thrown overboard when a lot of investments have been made. Never the less, risk is perceived differently in the two cases. In the general description of Embracing Failure risk is seen as extremely positive. “Find a place where you feel most uncomfortable, most uncertain and the most unsure of yourself. That’s the first step.” . This is of course meant as a very early step in the process and is focused on creating innovative thinking. This can then be let by the Spiral Models iteration steps that takes small risks, which combines the two methodologies.

It is my belief that it is possible to combine the two and be aware of which risks a project has and work it into the plan and be prepared for the expected failures.

In the hardware process the project manager should be prepared to do more iteration before taking a product to marked. Tests should be done in realistic user scenarios but the product should be as close as possible to the ideal product when entering the marked as it can not update the product continuously as a software product can.

=Limitations=
==Limits of the revised model==
Since the model has not been tested in the new user area the limitations are based on a theoretical foundation. It is expected that the model should be revised after first test. It is furthermore expected that using the model will make the Fuzzy Front End more time consuming, but could save some bigger iteration in the later stages.

==Limits of the article ==
This article is based solely on written material, wherefore the next step is to test out the theories and speak with stakeholders in the industry of hardware design. An interesting experiment would be to have project managers run concurrent projects to see the difference in using the spiral model and the current methods.

=Conclusion=
It has in this article been tried to inspire project managers to improve their end products by the Embracing Failure methodology. Adapting the Spiral Model to a hardware design process by taking the later launch into account can theoretically incorporate the Embracing Failure methodology into project management.

The most significant improvement the Spiral Model should be able to help with in hardware design is as a critic tool for the project managers. Every prototype will hold a lot of assumptions and flaws that every time the process passes the “Review” line will be corrected for the next iteration.

Even though software and hardware design are very different in some ways the methodology is very comparable and thereby the use of a revised Spiral Model should be implementable in the hardware process. However this has not yet been tested.

It is important to underline that the adapted Spiral Model cannot serve as the project managers only initiative. An open environment and a focus group might fit as one supplement.

=References=