Idea, team, technology, money, methodology - what really depends on the success of the project?

Disclaimer:

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

By project here, I mean a project to develop and promote a website 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 posting on forums were used. Since 2006, I have been actively involved in SEO and startup promotion. The last (freshest) my startup started over a year ago. Frozen a month ago. I have to say that not a single start-up has received world fame, but there are quite a lot of cones, and how many have yet to fill!
')
Further, I propose to analyze the factors that lead the project to success.
To do this, first let's discuss what is considered a project success:
Many people know the classic triangle of project management (see fig. 1)


Figure 1. The project management triangle.

I met the following criteria for assessing the success of the 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 “satisfied customer” criterion is the most working. As a rule, if the deadline, cost (and they are often directly dependent) are met and all the functionality is implemented, the customer will be satisfied. But it concerns projects to order (outsourcing).
When implementing your project (startup), the criterion of financial success is important - i.e. we can break deadlines, realize not fully functional, the customer is unhappy, but it so happened that the project got out financially and brings money.

My conclusion : no matter what criterion we take as a basis for success, there are common factors that influence whether a project will be successful.
It's very simple: if the project is successful - it can be seen throughout .

We think the success of the project depends on the factors:

In both cases (outsourcing or your project), when we are planning a project, we think that success depends on such factors:
• We have smart people we need, you can rely on them.
• We have the resources we need (which means we calculated them correctly), the work will be paid for, and in the case of a startup we all earn decently.
• We do the right thing (i.e., we either understood the customer’s requirements correctly, or created our own requirements correctly).
• We use good technologies for project implementation (i.e. our project will not be morally backward).
• Our teamwork is set up in such a way that we work as efficiently as possible on a project (methodologies, approaches, task tracking system, etc.).
• We know what to do with the finished project so that the market or the customer acknowledges 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 work in different teams on different projects. Maybe someone will know their cases, and maybe from someone in the projects in a different way.

1. People in general seem to be good, funny, joking, but each individual is not aimed at the result. Performs tasks on the "leave me alone."
2. The developer says “the formulation of the task is not clear, register in more detail what to get from, etc.,” but after that it still does not work correctly.
3. The developer says “put such a tracker, and then I will start doing tasks”, but as a result, keeping it in either Excel or in jire does not change the essence. The programmer delays with deadlines.
4. The developer says “it is necessary to implement Scrum”, but even using a scram, instead of working, he plays on a tablet.
5. The programmer says “I understand you. No need to talk further, I know how to do better, ”but does not.
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 must be made successful.

There may be more examples, I do not pretend to 80% of the main ones. I’ll not even mention the deadlines (it seems to me that this is in all projects, which means that this is already the norm).
It’s not 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 with enthusiasm. Does the programmer want big mac? Yes, for God's sake, I go, just to write the code. A designer needs to buy a framework or templates - no problem.

Usually, when a manager “burns” with a project, problems are not terrible, they are solved.
Worse, when people who move the 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. A 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 do not fulfill the promise, or they fulfill it, but in their own way. Specific% was not voiced (and even if it was, we all know that% can be washed away, there would be a desire). Vera, according to the founders, dies, the project participant sooner or later leaves or floods the project.
2. The project participant “burned” with the very idea of ​​the project (money did not matter). He saw that he was being used. The founders buy cars, live in a big way, and little that falls to him. Although the money was not the most important factor, the credibility of 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 interaction mechanisms, or the partners, not trusting each other, begin to pull the blanket over themselves.
4. The programmer promises one time, but all the time he breaks the deadline, and he still doesn’t do the job right. Sooner or later, there is distrust of him as a competent performer.

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

Team members, partners, customer and performer must all trust each other. Only then can a true partnership be built, the “fuse” maintained, and, accordingly, all problems that arise during the project can be solved.

What is the conclusion?

Personally, my conclusion is to build an open, trusting relationship with people. If not, then change people, projects, companies. It is better to develop with those with whom there is trust than to waste time and energy without trust.