Failure

7 Factors of Failure

With the history of major success we’ve seen by society in the last 100 years, we can certainly see a parallel history of an overwhelming number of failures, often difficult to find because they simply fizzled out before they made any history book. But what causes us to fail? It’s common sense, really, but this section will walk through the reasons why failure occurs, and give you ways to understand your common factors that lead to failure.

A prerequisite: Success is often built on a foundation of failures

Before we get started, we need to understand that “success” and “failure” aren’t always definitive. Often, the success of a given effort comes only through the lessons learned during failure. Jumping from ground-zero to success is very rare. Quite often, failure is the right choice. Sinking your time and effort into what is almost certainly going to fail is foolish. With that said, understanding what causes failure will allow you to learn to either fail on purpose or avoid failure altogether.

Failure Factor 1: Quitting before you start

Quitting before you start isn’t a cardinal sin. In fact, as Seth Godin famously says, no is essential. One of the most important skills you can acquire is the ability to say no to the right things, and that means most things. However, if you’re quitting because something simply looks hard, that’s the bad kind of “no”. You’re here because you’re willing to do hard things. Here’s your opportunity to stop reading if you don’t want to do hard things.

Failure Factor 2: Skill/Requirement Mismatch

Sometimes your goal problem requires a skill you don’t have. As a developer, for instance, perhaps you don’t have experience with Assembly, and the visionary you’re working with wants to create a low-level hardware device that requires a significant amount of knowledge and experience with Assembly. If you try to attack that problem on your own, you will have a skill/requirement mismatch. If you don’t attack this problem head-on by matching your skillset to your requirements, you are obviously much more likely to fail.

With this factor, there are three options, each with their own implications: choose to fail, acquire the skills by learning, or hire new talent to fulfill the requirements.

Failure Factor 3: Leaping Too Far

As we will discuss in Part Two of this book, it’s essential that you approach your work in digestible pieces. Trying to attack too large of a problem all at once will trigger the “impossible” perspective, which leads to chaotic and unorganized work towards unclear goals.

Failure Factor 4: Indecisiveness and the Slow Grind

Sometimes the only thing standing in the way of progress is the ability to decide. Choosing Option A may have the same effect as choosing Option B, and what is needed is the diligence to simply choose. Without this skill, projects often slow way down, leading to leaking resources and a distinct lack of competitive edge.

Failure Factor 5: Money Problems

If you fail to manage money properly in a project, your project will fail. A classic example case of this is Iridium, a satellite network launched in the mid 90s. While Iridium is still in existence, the initial intention of the platform was to scale to widespread adoption. Unfortunately, the project was far too expensive and ended up being surpassed in adoption by the much cheaper cell phone network.

If your project ends up costing too much during the development phases, it can cause an expensive failure. While the cost of a given project isn’t always predictable, it’s incredibly important to put energy into understanding the return on investment and the costs versus the benefits of a given feature. Furthermore, keeping an eye on the market your idea will live in can help you avoid losing to a competing adjacent solution.

Failure Factor 6: Unavoidable Circumstances

This also happens to be a major factor of success.

There are many things we cannot, no matter what we do, control. We can’t control the entire economy, nor can we control the weather. We can’t control tragedies or disasters. We can’t directly control the behavior of the people we work with, nor can we control the competitors in a given market. Each one of these things may be the catalyst of failure for a given project.

To avoid failure as a result of unavoidable circumstances, we must practice responsible risk aversion. Often, this means diversifying and spreading resources and knowledge. For instance, don’t rely on one server – use a service provider that has distributed servers so that if a disaster occurs in one region, your business isn’t taken down completely. With a similar intention, you should never allow the core information of your project to be housed within only one or two people; it should be distributed and recorded, shared within your team so that if for any reason that person is suddenly removed from the picture, the knowledge is not lost. Remain keenly aware of the market, and base your idea in a niche to avert market competition. I can’t stress this part enough: record everything, in multiple locations. This is a protective technique against many sorts of loss.

Failure Factor 7: Broken Roadmap

Often, a project fails because the individuals working on the project do not have the same understanding of the project at its core level. The planning phases of the project were incomplete, or otherwise inadequate. Individual aspirations may even cause a different path for one person than for another. This problem is all about communication: if your team does not communicate effectively, the goals of a project can easily become skewed.

Communication isn’t as simple as emailing each other constantly, or sitting in a chatroom together; you must get to the place where you understand the fundamental communication styles that each other employ, and do so in an explicitly identified way. This is particularly important for those with vastly different Creative DNA.

Of course, learning to plan projects in a highly detailed way is of absolute importance as well. This problem is often solved by taking on your work in smaller, more digestible chunks, so that each and every subproblem is well defined and discussed before any work is invested in an improper direction. Of course, it’s impossible to plan every detail perfectly, which is why you should adopt some kind of agile framework that allows the details of your application to shift as the application is built, and evolve with changing requirements for the end goal problem.

Leave a Reply

Your email address will not be published. Required fields are marked *