“Failed” Projects: How to Learn and Grow from Business Mistakes

7 min.

From time to time, I see these statistics about failed projects in the press. What is a failed project, anyway? What criteria would I use to label a project as ‘Failed’? Are there failed projects at all, or do we make mistakes to learn something important in the process and ultimately find success?

There are plenty examples from my experience of projects that had disastrous results from the outside, but turned out to be very useful or super successful in some of its parts, not so obvious to an outside observer. If you think about it — success and failure are largely relative categories. Let me give you a few examples.

Blessings in Disguise

One of my friends was building a backup system. He started essentially from scratch, with no pool of talent and no sufficient experience in the domain. Of course, he made a ton of mistakes in the design, which sometimes led to losing data and other serious issues. As a result of continuous problems, the client chose to organize an independent team focused on software product development, and the two parties went their separate ways. For my friend’s company in general, it seemed liked a huge failure. However, as a result, a product was created that made his name, and is used by thousands of people to this day. Not everything is black and white in business, and I think it sometimes helps to be a little bit of a philosopher.

In another memorable example, Itransition was creating an online auctions system for an overseas client. It was one of the first projects done by our company, which, after years of development, resulted in nothing much, and even though the system was launched, it was live only for a very short time. It was nobody’s fault, as they say; the business idea at the core of the project unfortunately didn’t turn out to be viable and no one was able to predict it at the conception and development stage, as it sometimes happens. But the innovations in architecture incorporated in its foundation, with a few modifications, became the basis for another project that has been active and dynamically evolving for the last 15 years. They say there is no bad without the good. Or is it the other way around? Not sure, but it works both ways, in my opinion.

Success Criteria

I don’t really think there is a silver bullet or one system of criteria that clearly determines the success of a project. Yes, from the project manager’s perspective, we can find a number of metrics such as budget, schedule and scope that reflect the success of the project to a certain extent. At the same time, they are more descriptive of the process and not the end product, therefore cannot characterize the project and its multilayer complexity in full.

I have witnessed projects that were conventionally celebrated as successful but squeezed all the juices out of talented specialists and even caused them to leave the company. I’d put it like this: a project is such a complex, living-breathing-changing organism, that it’s difficult to pin down its essence to categories like ‘success’ and ‘failure’. Obviously, everyone has his or her own system of metrics based on a personal understanding of those terms. Mine is this: I would not consider the project and the relationship with the client “successful” if:

  • We do not go live (i.e. the product is not delivered to active users, where an active user is not just the client)
  • We have not worked with the client on the development of the project or projects for at least 3 years

For other people, a selling end product or even many fruitful years of collaboration may not be enough for success – it is all very subjective. In fact, the clients’ perception of the same metrics can be the opposite of mine: for example, for some clients three years of production may be way too long. They may expect us to deliver the same result in six months – and three years would be a sign of failure, not success. I consider these two points just the most necessary requirements, but certainly not sufficient criteria for determining success, which in each individual case may depend on a set of unique circumstances, requirements and metrics.

Are There Any Failed Projects?

It’s a philosophical question, indeed. It’s similar to asking: “Are there any failed days in your life?” Often, the worst day may teach you much more than a clear sunny day. You learn to grow a tough skin through failure, and in business a tough skin is a must. It’s also clear that everything is relative: for some people a day when they did nothing and watched the rain out the window is a complete failure, for others, however, such a day may be the best day in their life.

“The snow falls, each flake in its appropriate place”

I also think that if something happens, it happens for a reason. It can well be a life’s lesson disguised as “failure”. At the same time, I don’t advocate being a slave to the circumstances. If this principle is part of the learning curve, I embrace it fully. If something went wrong, I want to understand why and what I can do to fix it, change it up, and do better next time. To paraphrase the Zen Buddhist saying, yes, the snowflake is in the right place at the time of falling, but it doesn’t have to fall in the same place next time, if that’s not what we intend.

Project Goals

A lot depends on the goals of the project, and in which capacity they have been reached. If you haven’t reached all goals, it doesn’t mean failure, but in all-or-nothing cases where the main objective is achieving all goals, it can mean the project did fail. If at the end of the project you can clearly understand the reasons why objectives could not be reached, that’s success by all means. If we have learned something new, and we can now offer safe cushioning measures to avoid the same scenario next time around – even better. If the reason for the failure of the project was clear even before the start of the project and we have not been able to do anything to turn the situation around or warn the client beforehand, this is not success.

The Value of Planned Loss

Many people consider unprofitable projects testing ground for bugs. I only see them as such if that was planned and premeditated from the very beginning. If this was a conscious decision to invest additional funds in order to study and fix bugs, then it can really increase the expertise of a company. Then I would consider the net loss as an investment of the company in a particular field of knowledge or a new set of tools. In general, the success of this investment can be assessed via the quality of their portfolio and the efficiency of the business unit. Again, if the project allows us to occupy a niche, get short-listed as important experts or have a competitive advantage in a particular business niche or technical domain – why not?

The Business X Factor

It’s a cliché, I know, but I would like to look at it from the perspective of mind vs. emotion. Many people think it is very important to be able to find and analyze mistakes with a cold mind, without getting personal or creating drama to achieve longevity in business. Personally, I appreciate and prefer the ability to balance between the logical and the emotional side of a person. If at any point you can turn off all rational calculations and follow your intuition – it’s not always a bad thing, in my opinion, as it often yields pretty amazing results. So a certain X factor is sometimes more important in business, because at some point you need to take big risks, and it’s not all based on logic. After all, we all buy products or services on emotion.

The formula for success is quite simple, really — double your rate of failure. You are thinking of failure as the enemy of success. But it isn’t as all. You can be discouraged by failure — or you can learn from it. So go ahead and make mistakes. Make all you can. Because, remember that’s where you will find success.

Thomas J. Watson

Tell me about your failed projects. What did you learn? Are you doing anything differently now? Do you agree with my points? Share your thoughts below and good luck!