Why do many IT projects fail? / Hebrew

Why do many IT projects fail? / Hebrew

For people who did not have experience working with IT projects, everything seems quite banal – they discussed the scope of work, paid, received the project. However, in reality, this is not the case.

Story #1. Come prepared, and we’ll discuss it there.

One of our first projects was as follows:

We discussed the project, signed a contract on firm conditions for a price, received an advance payment, and started work. The client says: “We have discussed everything, come with the finished project.” Well ok

They came to show the intermediate result (project design) to the client.

Customer says:

– Ok, not bad.

We take the design to work, edit, develop, integrate, test and deliver the finished project, the client says:

– What did you bring me here?

We say:

– “How? Here is the project you ordered.

He tells us:

— This design of the project does not suit us. “I said not bad at all.” Recycle everything.

After all, what happened? At the time of signing the contract and even approving the design of the project, the client saw one picture of the project. And after looking at the final project, he wants something else.

There is a classic project story here that the Client does not want to manage the project, but wants the result. With a high probability, he will not be satisfied with the result, because he does not want to make design decisions during the project, because he does not understand and does not want to take responsibility for the project (“well, you said so, so we did it”). Why delve into it, when you can look at the finished product and evaluate it? When the project is completed, you can look at the finished product and say what is wrong. In this case, the risk of reworking the project in any case rests with the Executor (if we don’t sign the act, let them rework it as we want).

What to do? Let’s then make a precise description of the project (TOR). But, as it turns out, detailed TK is not a panacea either.

Story No. 2. There is a TK, but it’s still not done right, or you are professionals and should understand what we wanted.

OK, let’s talk about TK. We write technical specifications – we describe everything that needs to be done on the project.

The first question is how much should the client pay for writing the TOR?

Option No. 1. Absolutely / Free. Then include these costs in project costs or what? Ok, and if the client does not agree to what we have designed (in terms of price, term, etc.). Work for free? It must be admitted that designers are probably the most expensive specialists, because they understand both business language and development.

Option #2. Not free? And how much? How much does it cost to study the company’s business and answer the question of how they should be organized under the new system? Ok, let’s take some metric, for example, the number of jobs, entities with which the Customer works. How will we evaluate the quality of work? Pages? At the level of a design solution?

Well, let’s assume that we have managed even with these questions and we have some estimate of the effort required by the designer who will collect the requirements and describe them.

How detailed should the client’s requirements be described?

Conditionally, when collecting requirements, the user said that such a report was needed, and a month or two later, when the project was being developed, it turned out that in fact there are two reports, they are just called the same.

A management message appears: “It is not included in the TOR – shall we not do it?” and the corresponding answer of the Customer: “Well, you are professionals, you should have understood that we cannot live without it. It’s not difficult – here’s a little change. And here it is. And otherwise, he himself understands, we will not sign the acts for you. Or return the money.”

OK. Then let’s write TK in more detail, prescribe everything. Fine. Then let’s put in more designer clocks and push the deadlines. And we get: “Mlinets, why are you writing technical documentation for so long, it’s still clear – here’s the report, and here’s the form, and here the fields need to be filled in by users.” or “Why should we pay for work that does not give us any results? You write TK for yourself.

Okay, let’s say we wrote a detailed TOR, just went through all the business processes, dived in, described every pixel of the project. It is clear to everyone, we do according to the TK and that’s it. What is unclear here?

And here another story takes place:

“Guys, a user came here and said that what he said at the design stage is no longer relevant to him, and he has another, hotter task. What are we doing?”

Option #1. “How? Nothing. This is not in the TK. Let him continue to suffer. It was necessary to think earlier.” See the answer above about the act and the return of money.

Option #2. “Let’s write a new TOR and launch it again according to the approval procedure, it can and will appear in a year. »

As we understand, neither the first nor the second option suits the Customer or the Contractor.

So, what we have: The second classic history of project work. TK does not save, because it is expensive/long and the project will change in the course of life anyway.

Story #3. You set the task, we do it, and you pay for it.

There is an option when the items described above can be resolved, although some issues are replaced by others.

Let’s put it simply – you give us tasks, we do them, and you pay for them? Well, as if you hired us to work, and we work. If we work poorly, you fire us, if we do well, you raise our salary.

What are the risks here:

Hiring the wrong team (by analogy with an employee) who will not produce the required number of correctly solved tasks (for example, will spoil the project and it will be very expensive to refine it further).

Need to manage the project (need expertise to evaluate and make decisions about the project).

And how do you like working with projects?

Related posts