Creating a positive culture around failure in project management
Contents |
Introduction
To fail is to learn. At least that is what might create a more innovative environment in your company. It is not at all as interesting to succeed in the first try as to fail, deal with it, get past it and know that your success wasn't accidental. If you manage to create a positive failure environment in your project teams the result of the project might develop into creative and innovative masterpieces. This article serves as food for thought for project managers to improve their efficiency in the Fuzzy Front End of the project 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 the Embracing Failure methodology and 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 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 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 is a viable starting point for a shift in practices.
How can failure be positive in such a critical stage?
Especially in critical stages it is important to make risk assessments and thereby provide the initial investors with a proof of concept. In this stage learning from every iteration and failure can be the best way to eliminate future risks. 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 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 the hardware developers can 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. In the initial stages the objectives are listed and translated to functions so there by the first invariant can be continuously defines modules and artifacts concurrently. A risk analysis is created and updated 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. 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 in corporation.
Another big difference is how the spiral is used as a critic tool in the Fuzzy Front End. 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.
Other important initiatives
Open culture
As previously discussed the implementation of 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.
Of course there many more that will be apparent when testing the model in a design process.
Discussion of the method
- More iterations • Opposite of what they say I believe the iterations can be a key element in making sure the requirements are rightfully translated in the research phase o - Proof of concept - Continue in to the first stage gates - Problem validation - The role of the project manager o Be sure you’re going the right way o Keep the time plan o Focus on the goal for next iteration - Test plan - Definite plan of what the next goal is - Constant ideal solution clarification - Visual criticizing - The culture around the model - The company it self
Limitations
- Limits in the article o Just one of the models o Due to time limits Few case studies
- Limits of the concept o Not been tested o May take more time in the initial stage but gain in later stages.
Conclusion
- A lot of already used models can be adapted to the fail - The spiral shows the importance of iterations to limit risks - Answer the research questions.
