Definitions of IT project failure

I would like to share a summary of stories from IT-project customers, with whom I managed to communicate and work. These stories are very similar, so you can learn from them by drawing the necessary conclusions.

So it turns out that my company receives projects with a complicated history: the first deadline has passed, the second one has passed, there is no release, investors are in despair, the project is ready to throw out and recognize it as a failure. We pulled out more than one such project and made a successful release.

History of failed projects

Problems with projects appear in different sizes of companies, on different development platforms or in different countries. History repeats itself equally in Russia, the USA and England. It is repeated in almost every detail. Analyzing the history of such projects, I noticed a tendency and highlighted the general essence.

Scene one – Encouraging

When a project starts, the work on it boils up, the customer gets many new functions very quickly. You need to add registration – please. News feed – please. Dividing into roles – no problem. Passing documents on the main branch of the business process – very quickly.

The system components are almost unrelated to each other. The system is growing at a high rate, the growth is stable. At the same time, the complexity increases linearly, in proportion to the number of components added.

The first stage is the easiest for developers. It does not require strong engineering skills.

At this stage, the customer is happy. He sees that the tasks are implemented quickly, perhaps faster than the plan, the new functions flow into the river.

This stage of happy ignorance can last quite a long time. History knows cases when teams work in the “add-on only” mode for up to six months.

Scene two – Disappointing

Changes in the initial requirements have begun. For example, the business changed or competitors came or the customer saw new ways of development. And it turned out that the system was not ready for changes. Adding a new one is not the same as changing what has already been created. It turns out that one part of the system wasn’t made flexible enough, the other code was fragile, and a lot of errors were detected when changing. Now the customer has to wait a long time for the developers to make the changes.

Logic of registration changes, registration through social networks, registration through internal services of the company, through promotions from third-party partner sites.

When components change, the system breaks down in unexpected places, there are complex links between different parts of the system. Filling new versions becomes more and more complicated and even better if someone takes care of automatic integration and deployment of new versions. Duplication in the code is detected, but there is no time for fixing it, the customer already goes into the category of dissatisfied people.

The customer who asks “just to add a button” does not understand why it takes 2 weeks. Previously, it received several new functions in two weeks, but now small changes require significant costs. After the releases, problems are identified in already debugged parts of the system, i.e. in already paid parts of the system.

Scene three – Failure

The customer is unhappy, he’s demanding the previous speeds. He demands, at the very least, that what was already in working order should work.

Next, two variants of development of events:

  1. The team realizes that it is not competent to develop the project. It simply “merges” and follows the next project. The customer stays with a lot of bad code and burning deadlines.
  2. The team is not aware of its incompetence, so the web of code is curled until someone says the cherished phrase: “Let’s throw everything away and rewrite it”. What does it mean for the customer? At best, the loss of money and time, at worst, the loss of business.

Drawing beautiful facades

Writing such projects can be called deceit of the customer. Conscious or unconscious, but deceitful. You have probably seen in your city houses, which instead of repairing a banner printed:

There comes a moment when the printout is removed and it turns out that inside the collapsed facade. The same thing happens to projects. The customer learns the real situation when he comes to me, brings the project, asks to understand what is going on. He says: “We did it for six months, everything was so fast, we were ready to release and here once, nothing works. Of course, it doesn’t work, and it never actually worked, alas, it just looked like it did.

Real cases of such “facades”:

  • The project works when it is used simultaneously by no more than 10 people. Everything was fine on the demo, but in reality the server was falling under “load”. There is a practice of load testing, but who did it?
  • The program runs on only one operating system, loads it 100% and usually falls with BSOD. The customer was convinced that otherwise there is no way.
  • “Everything is ready,” says the customer, “just add editing of the newsfeed and manage news filtration. There are only 5 of them on the main page, and we need to add some fresh ones. We look into the code, and there all the news in static HTML-files without any business logic, as well as the control of their filtration.
  • One project for B2B sector was already launched and worked well. The management had big plans for it, but the first change made us rewrite a lot. The point is that there was a lot of duplication in the code. One business rule could be written in 5-6 parts of the system. Rapid growth was replaced by stagnation and led to the closure of the project.
  • The developers learned how to simulate the work instead of the real effective work. Effective managers have learned to convince customers that the current situation on the project is a norm that IT-market can work only in this way and in no other way.

Engineering pride

Such projects resemble self-deception of developers. They are sure that it is impossible to do better. Creators of “facade” projects tell the customer: “We have built a scalable system that can expand well under any load. You have to understand that no really experienced developer will say that. He will make a lot of reservations about the real scalability, drive it into the limits of restrictions and describe the possible risks.

Statements of reliability of 146% are typical for programmers who are in the square of unconscious incompetence. Don’t look at the number of years worked as a programmer (someone thinks it’s an indicator of experience), nothing depends on them. It is bad when such “leading” programmers have the gift of convincing the customer or are the leaders on his part, because the customer is left all alone in this unequal battle for truth. In such situations I am called to hold public hearings.

A tool for customers

I’m sure the failure scenario can be interrupted. The best way to do this is to do it right from the start, at the stage of selecting the performers. The problem is that with this level of certification and licensing in our industry, it is almost impossible to compare IT companies. It is difficult to compare even two developers.

The most real opportunity to save a project is to understand that it is going to the abyss. There is a small percentage of customers who can look into the source code and understand whether it is good or bad. But there are practically no customers who could estimate the architecture, limitations and flexibility of the solution created.

Someone relies on efficient managers, but without strong engineers a good IT-product will not work. Management in the project is also important, but the code is primary. A good team of programmers with a bad manager can make a working project. But a great manager with a bad team just doesn’t have a chance.

I have been analyzing projects from time to time but it was not my regular work. Now I want to take more projects for analysis, I believe that you can save many projects going into the abyss.