Introduction
There are stories everywhere about the successful launch of major startups from scratch. There is a feeling that to start, you just need to begin, and everything will work out by itself.Maybe that’s why 90% of startups fail. But bad luck is not written, and only “survivors”write about them.
By the nature of their activities (web application development), they had to observe successful and failed projects. Most of them are failures. And this has nothing to do with the technical factor. In this article, we will analyze the main factors that lead to the unsuccessful completion of the project.
We do not pretend to be objective at all, we just analyze the results of projects, do a retrospective and get some conclusions.
Main reasons for project failure
1. Solutions in search of a problem
This is the most common reason. You came up with something, you thought it was cool. You invested in development and promotion, and then it turns out that there is no buyer who would need it and who could pay for it.
This fatal error is allowed at the project vision level. No amount of excellent management and development will save such a project. Sooner or later, the money will run out, the user will not come, and the project will gradually go out.
To avoid this, you need to push your offer against the market as early as possible.
Customer feedback should be received at the earliest possible stage — at the idea stage.
At the stage of creating a working minimal prototype, your hypothesis should already be supported by feedback facts. The more closely you feel the pulse of the consumer of your future product, the less risk that the project will get lost and will search for its target audience in the dark.
2. Weak team (led by a Manager), incorrect assessment of their capabilities
Imagine that you have a football team, everyone is playing very well, except the goalkeeper. Any shot in goalposts is a goal. No matter how hard you try, you can’t win with a goalie like that in the team. Paradoxically, in some projects, there is no goalkeeper at all!
Quite a lot of money is spent on the project, some plans are being made, but at the same time large parts of the project are not covered at all. In my experience, I have seen situations when a serious web project starts to be promoted by a relative of the customer without experience in promotion. Promotion of a business card site is not easy, but promotion of a large site is easy, because Peter will do everything in a week. Obviously, this approach negates all other efforts.
A particularly painful topic is a weak product owner, because this is the person who moves the product, who invests his time and money in it.
The product owner must have sufficient knowledge of all aspects of the web product: design, requirements development, usability, promotion, operations, finance, marketing, sales, etc.
Some people hope that some hired specialist will solve all these issues for them. In 99% of cases, this is not the case. No one cares about your product. They do their job, get paid for it, and that’s it. They have their own product (service), and they are focused on it, not on your product.
And another point, a weak product owner will find the same weak (or cunning) team members.
The lesson is to learn, to learn and to learn again. Only by improving your skills will you be able to differentiate contractors and see the difference in their work, and not rely on their decency and professionalism.
3. Immediately a full-fledged product is created without a MVP
There is such a stupid belief “Well, how can I show people an unfinished building, you must first do everything, and then launch clients on it”. This is the most harmful belief for an IT project. In the real world, improvements to a physical object are really difficult. It is difficult to imagine that the Museum decided to launch in an unfinished building: visitors look at paintings, and in parallel there is a repair, laminate flooring, etc. But in the virtual world, everything is changeable and can evolve in the course of operation. This is a very important point.
The project can be started with primitive functions, and then gradually overgrown with features.
What is the advantage of this approach — to reduce risks. There is a risk of not guessing what the user needs. How to avoid it? Make a hypothesis, implement a prototype, and give it to the client. Then get feedback and refine the features in the right direction.In this way, you create your solution more consciously with reference to the requirements of the market.
In most cases, the prototype of the solution can be just a presentation or layouts of the future site. In our Falcon Space platform, we have achieved that, by and large, it is easier for us to do everything at once within the framework of the web platform, rather than making separate layouts (i.e., immediately outline the standard functionality, perhaps without prescribing detailed logic).
In any case, forget about the “we make minced meat, and until we do, we won’t start” approach. This approach usually leads to frustration: money runs out, customers say they wanted other features, the decision is made for a very long time and is very disconnected from the market.
Again, this is an error at the level of the project leader (at the level of the product owner’s principles of work). No super specialists in development, design and promotion can solve this problem.
4. Frivolity of the customer, unwillingness to work for a long time
It happens that the customer simply does not adequately set the project goals. He talks about huge goals (competition with Avito), while not having even minimal resources and competencies for a project of this scale. For me, this is always a stop factor for participating in the project. All this immediately indicates that the customer is not serious and a deep misunderstanding of the complexity of the project.
After all, in the end, with a complete failure of the project, such a customer will consider himself infallible (he came up with a brilliant idea-a clone of AliExpress for dogs), but the suppliers were not the right ones.
There are also customers who are just looking for a place where you can easily make money. They are somewhat like moths flying towards the fire that Sears their wings. As a result, it is not possible to cut down quickly (it turns out that everything is not as simple as in the stories of successful startups on the network, which are described in the video on Youtube). Plus, they are stuck in the project, because they have already incurred some costs, and now it turns out that the project is hanging in the air.
A good customer is a prepared customer who understands the ins and outs of the project, sees the project path in detail, and understands that there is no quick random success of the project.
Such a customer does not come for quick money, but for creating an important asset that will give tangible benefits to their business in the long term.
Don’t be a layman who has heard about the online El Dorado (gold mine) and runs here in the hope of quick and easy profit, but who eventually becomes food for those who sell shovels, sieves and picks.
5. The prolongation, change of priorities
It happens that the project starts to drag on indefinitely. A lot of approvals, a lot of changes, then the customer is not up to the project and everything is waiting for the customer to agree on the points.
This is also a bad story for the project. Why? The longer the deadline, the more costs, the higher the probability of leaving the team members (they need to eat something while the customer is engaged in other projects).
The project is gradually forgotten and maintained in a comatose mode. I believe that it is better to just honestly admit that the project is unsuccessful and either close it immediately, or create a plan to restructure it for another task.
The reason for this delay is a change in the customer’s priorities. If the mastermind of the project starts to give up on it, then it is stupid to expect that other team members will treat the project with the same zeal.
To avoid this, you need to plan the project in such a way that you end up with an intermediate result. In other words, if you plan to get something, you should get it, regardless of any changes in your wishlist during the project.
Set the desired intermediate result and go to it no matter what.
Conclusion
This is a subjective analysis of the reasons for the failure of projects. And it can be concluded that the main danger for the project is its leader, the product owner. It sets the outline of the product movement.
A strong product owner can make a product with a weak development team, poor design, and mediocre promotion.
A weak product owner has almost no chance of success under any circumstances — he will still ruin it with his management decisions (given that the budget is not rubber).
P.S. We previously recorded a series of videos on YouTube #провалпроекта. There we look in more detail at the factors that lead to negative development of the project.
Originally published at https://falconspace.site.