Every now and then you may run across stats that discuss failed projects. They are usually dreary and depressing, but they beg an important question – just what is a failed project exactly? What criteria does one use to determine that a project has failed? Or is a failure just a matter of perspective? That is, if we learn from our mistakes and eventually find success, did we actually fail?
There are a ton of examples of projects that were complete disasters to some, but when looked at from a different perspective, useful information and/or tools were gleaned from said failures. In other words, failure and success are relative. Need a better explanation? Check out the following examples for more clarity:
A Blessing in Disguise
A developer was tasked with building a backup system. He started from the scratch, with virtually no experience or pool of talent to rely on. As is expected, he made a ton of design-related mistakes. Some of the more serious ones caused him to lose valuable data and that was just the beginning.
Needless to say, the partnership was soon dissolved and the client decided to create a product development team on his own. You would probably say that this developer failed in a major way. But, the story’s not over yet – the information he learned from the project helped him create a product that’s still used by thousands of people today. When it comes to business, not everything is black and white. In fact, sometimes it helps to look at things from a philosophical perspective.
Here’s another example to drive the point home: The developer in this story was tasked with creating an online auction system for an overseas client. It was his first really big project and, after years of development, it still didn’t really amount to much.
The system was eventually launched but, it was only live for a little while. Although the concept sounded good during the conception and development stages, the business idea just wasn’t viable. It’s unfortunate but, sometimes things like this just happen. However, when tweaked a little, the architecture for the so-called failure laid the foundation for another project that has been active and evolving for over a decade now.
Requirements of Success
No matter what anyone says, there aren’t any cut and dry criteria that clearly stipulate the success of a project. Project managers may disagree, they use a number of metrics like schedule, budget, and scope to make this determination. And, to a certain extent, these metrics do have value. Still, it’s important to note that, they are relevant to the process itself, not the end product. Thus, they don’t have the ability to accurately categorize the complexity of a project and whether it failed.
There have been projects that were widely accepted as successful but, behind the scenes, completely wiped out all the specialists. Some of them are so depleted, creatively speaking, they quit their jobs.
Projects are very complex entities and cannot be defined by simple categories like failure and success. This isn’t to say that we don’t have our own individual understanding of these terms. But, for the purposes of this article, we are breaking it down to two main criteria:
- Whether a project goes live
- If the developer hasn’t done any project development on the content for three years or more
Everyone may not agree with the above criteria, there are some clients who think that years of production may be too long. They may want you to deliver the same result in half a year. So, if you look at it from this point of view, working together for years would be considered a failure, not a success.
So, What is a Failed Project? At the end of the day, failure and success are philosophical. It’s like asking if you’ve ever had a really bad day. And, if you think about it, those bad days are the ones filled with the most learning experiences. Failure teaches you to grow tougher skin and keep calm under pressure.
Errors are part of the learning curve and they should be embraced. Get an understanding of where the breakdown occurred and what can be done to fix it, make modifications, and create a better version next time.
A lot of times, the success of a project are dependent on its specific objectives and the capacity they are a met. But, if you don’t accomplish all the objectives, it doesn’t mean that you failed. If at the end of the project, you are able to see where things went wrong and why the goals couldn’t be reached, it is a success. People tend to underestimate the power of learning something new but it can help us prevent the same thing from happening another time. This saves time and effort, valuable commodities when working on a project.
Losing on Purpose is Good
Many developers use unprofitable projects to test for bugs, which can be a big hassle. But, if you made a conscious decision to study and fix bugs from the beginning, it can help you gain valuable expertise. In this way, a net loss is actually an investment in a new set of tools or a certain field of knowledge. And, if fixing a project’s bugs gives you the chance to master a niche, gain a competitive edge, get shortlisted as an expert, etc. why not give it a go? All of the best software testing companies go through a lot of trial and error before they get good at what they do, and are able to deliver satisfying results to customers.
The X Factor
Thinking outside of the box has helped many a company innovate and find success. So, why not try looking at things from the mind versus emotion perspective? Many people believe that they should analyze their mistakes and keep their feelings out of the equation. But, there’s value in finding a balance between the emotional and logical sides of doing business. Following your intuition isn’t always a bad thing and it can make for some pretty terrific results.
Sometimes in business, there are things that are more important than logic. Sometimes, you have to throw all caution to the wind. Sometimes, you have to take a risk.