Idea, team, technology, money, methodology - what does the success of a project really depend on?

Disclaimer:

Everything written below is only my thoughts, the result of exclusively my experience in participating in projects. I do not pretend to be a complete exposition of the subject, because the success of projects is studied in a huge number of books, communities, etc. If you have a different opinion, you can give a reasoned opinion here, I will be glad to have a substantive discussion.

By project here I mean a project to develop and promote a site or software.

About my experience, allowing me to draw conclusions:

My first startup was in 2005. It was an online store, for the promotion of which doorways and forum posting were used. Since 2006, I have been actively engaged in SEO and promotion of startups. My last (most recent) startup started over a year ago. Frozen a month ago. I have to say right away that not one of my startups has received world-wide fame, but there are a lot of cones filled, and how much more remains to be filled!

Further, I propose to analyze the factors that lead the project to success.
To do this, first, let's discuss what to consider a project success:
Many people know the classic triangle of project management (see Fig. 1)


Figure 1. Project management triangle.

I met such criteria for evaluating the success of a project:
1. The project is successful if completed on time, according to the approved scope of work and at the approved cost.
2. The project is successful if the customer is satisfied - regardless of the timing, cost, etc.
3. A project is successful only if it is financially successful.

From my experience, the criterion "satisfied customer" is the most working. As a rule, if the deadline, cost (and they often depend directly) are met and all the functionality is implemented, the customer will be satisfied. But this applies to custom projects (outsourcing).
When implementing your project (startup), the criterion of financial success is important - i.e. we can miss deadlines, implement not fully functional, the customer is dissatisfied, but it so happened that the project fought off financially and brings money.

My conclusion: Whatever criterion we take as the basis for success, there are common factors that influence whether a project will be successful.
Everything is very simple: if the project is successful - this is evident throughout .

We think the success of the project depends on factors:

In both cases (outsourcing or your own project), when we plan a project, we think that success depends on such factors:
• We have smart people we need, we can rely on them.
• We have the resources we need (which means we calculated them correctly), the work will be paid, and in the case of a startup we will all earn worthy.
• We are doing it right (that is, either we correctly understood the requirements of the customer, or correctly created our requirements).
• We use good technology to implement the project (that is, our project will not be mentally retarded).
• Our teamwork is configured so that we work as efficiently as possible on the project (methodologies, approaches, task tracking system, etc.).
• We know what to do with the finished project so that the market or the customer recognizes that this project is successful (in particular, there is a demand for the product on the market).

Realities - what we face:

Here I will give only examples from working in different teams on different projects. Perhaps someone finds out their cases, or maybe someone else in the projects in a different way.

1. People as a whole are kind of good, funny, joking, but each individually is not aimed at the result. Performs tasks for "leave me alone."
2. The developer says "the statement of the problem is not clear, write down in more detail what to get from, etc." - but after that it does it all the same incorrectly.
3. The developer says, “put such and such a tracker, and then I will start doing tasks”, but as a result, maintaining it neither in exel nor in jerk does not change the essence. The programmer is addictive with deadlines.
4. The developer says “we need to implement Scrum,” but even using scrum, instead of working, plays on the tablet.
5. The programmer says “I understand you. No need to talk further, I know how to do better, ”but he doesn’t.
6. The project sponsor says “yes, we will manage this budget, start”, and in the middle of the term it becomes clear that the programmer has already received less money and there is no money for promotion, but somehow the project needs to be successful.

There can be much more examples; I do not claim to be 80% basic. I will not even mention delaying the deadlines (it seems to me that this is in all projects, which means that this is already the norm).
It is far from always possible to change people during the project, you have to work somehow.

Why the project dies:

The problems that arise in the project are not terrible as long as the main participants are ready to solve them enthusiastically. Does a programmer want a big mac? Yes, for God's sake, I'm going to just write the code. A designer needs to buy a framework or templates - no problem.

Usually, when a project manager is “on fire” - problems are not terrible, they are solved.
It’s worse when people who move a project burn out. In my experience, this has always been due to a lack of trust. People at some stage ceased to trust each other.

Examples:
1. The project participant was promised a share. But not specifically, but in the style of "everyone will be in chocolate." But in fact, he saw that the founders are not fulfilling the promise, or they are fulfilling it, but in their own way. The specific% was not announced (and even if it was, everyone knows that% can be blurred, there would be a desire). Faith in the words of the founders dies, the project participant leaves sooner or later or fails the project.
2. The project participant was “burning” with the very idea of ​​the project (money did not matter). He saw that they were using him. Founders buy cars, live in a big way, and little falls into it. Although money was not the most important factor, trust in the founders disappears, and, accordingly, the participant “burns out” over time.
3. Partners have not built trusting open relationships. They talk a lot to each other, but each of them thinks one thing, says another, and does the third. This sooner or later leads to the fact that either it is not possible to adjust the mechanisms of interaction, or the partners, not trusting each other, begin to pull the blanket over themselves.
4. The programmer promises some deadlines, but all the time breaks the deadline, and even does not do the job correctly. Sooner or later, distrust of him as a competent executor arises.

Obviously, there may be other examples from life, but I repeat: I believe that the main necessary factor for the success of a project is trust .

Team members, partners, the customer and the contractor must all trust each other. Only then can we build a real partnership, maintain a “fuse”, and accordingly solve all the problems that arise during the project.

What is the conclusion?

Personally, my conclusion is to build open trusting relationships with people. If it doesn’t work, then change people, projects, companies. It is better to develop with those with whom there is trust than to spend time and energy without trust.