Project Management, Category 30+

Stop, stop it, clean it immediately! In order to close a failed project, you need two things: you need to understand that the project has failed, and you need to close it. But not so simple.



This article is based on a report by Maria Belkina from SEMrush, from the OKR-mitap in St. Petersburg : “The Experience of Switching from OKR to Spotify Rhythm”. Although the title of the report implies a demonstration of the shortcomings of OKR, the advantages of Rhythm and the way to replace one with another, its main topic was the question: “What to do with failed projects?”. This is an acute and painful topic that is interesting to understand.

Startup culture is committed to success. If you can achieve the goal, you need to continue in the same spirit. But not all projects are successful, in most cases only mediocre results can be achieved, or worse. What happens to such projects? - They go on. For everyone: both for management and for performers it is much easier to continue to invest in an unsuccessful project than to acknowledge its failure. The escalation of the problem can lead to conflict in the team, so it can ruin the relationship with colleagues. Nobody needs this. But if you do nothing, the development will become bogged down in futile projects, and the product will turn into an unsupported mishmash of useless features. This is also no good.

Money is always important, but people are a key development resource. For a month of work, a group of one hundred people will burn an equal amount of money, regardless of the result. Of course, to organize the best result is the main thing in the development management. But when a new idea appears, “this is what we need to do!”, It often turns out that there is no one to tackle it. All developers are busy with current tasks, and not that the most important, but you can’t leave them. This is typical of a mature product.

The older the software product, the greater the proportion of resources spent on its support, and the slower the new development. Even if the features are used by two hundred users out of a hundred thousand, the bug in it will still have to be fixed. The introduction of new technologies will require fixing all the code, regardless of whether the method is called every millisecond or once a month. A started project is better to finish than to leave unfinished. Any global changes will require full testing and so on. All this is a bit sobering and makes you think critically about prospects.

Not all projects will be successful, this is reality. You can live with this, but at some point, management should have an understanding that you can’t just continue to scatter toys on the floor. Periodically, they need to be collected back into the box, otherwise there will be a mess. Yes, tidying up is boring. Yes, it takes time. Yes, someone may be upset that his favorite toy was put back into the box. But we are adults.

What does it mean to close a failed project? It is not only to write off ten man-years of work at a loss. All developed functionality also needs to be removed from the product, and this is additional work and additional costs. There will also be dissatisfied users who for some reason liked the functionality of the project. Do not forget about missed opportunities. Time and effort spent closing the project, it seems, can be used with greater benefit. Close the project - expensive. In order to take such a step, you need the will, determination and understanding that long-term product health is more important than tactical savings. But even if there is a willingness to put in place such drastic measures, the trigger is still needed, a way is needed to understand that the project has failed.

Project failure criterion. Typically, it is customary to define a success criterion. It would seem that if success criteria were defined and the project did not reach them, then it failed. Absolutely not. Between success and failure lies a large gray area. Not reaching the values ​​of indicators that determine success, there is always the feeling that "we just have not done enough," "just a little more and then everything will work out." Perhaps this is so. But evaluating the project according to success criteria poses only the question “continue or not?”, And such a question does not imply the answer “close and destroy!”.

The criterion for the failure of the project is that lower boundary of indicators, falling below which the project must be destroyed. Like a ship that got a hole below the waterline, it should go down. With all possible pride, grandeur and professionalism.

Just as success should not lead to envy, failure should not incite hatred in a team. In the long run, all this is a routine of the work process. In order for the failure of the project not to lead to conflicts, the criteria for failure must be determined and agreed upon in advance, as well as the criteria for success. Also, a project termination plan needs to be prepared ahead of time, even earlier than the project plan itself. Then, having determined that the project has failed, there will be no doubt what to do in this situation. You can immediately proceed to decisive action. All in an adult way.

It is reasonable to argue that our brain is so arranged that, thinking about failure in advance, we set ourselves up for failure. May be. But the ability to think about the consequences is a sign of mature thinking. And the difficulties associated with this, as it seems, can be overcome.

---

Dmitry Mamonov,
Wrike

PS In continuation of the topic about how, why and when to remove features from the product, I can recommend a report from my colleague, Yuri Andreikovich.