Creating a positive culture around failure in project management

Introduction

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

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

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

Single Loop Learning illustrated by Gareth Morgan

Double Loop Learning illustrated by Gareth Morgan

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

The original Spiral Model, Boehm, B.

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.

• 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

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

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.