Post mortem
After completion (with any result) of the project, the manager is obliged to write a so-called. "Post mortem". The goal is obvious: to make good and bad, which was obvious during the project both for yourself and for others. If the genre of such post mortem had become more popular with us, I am sure that the percentage of successful projects from this would have grown, whatever the criteria for "success."
In this text, I will describe part of the project’s history in the very rapidly developing domain TNC (Transportation Network Companies), and more precisely, ROD (Ride on Demand). If in a very simple way, a taxi ordering service. In the middle of last year, one fairly large western TNC (hereinafter referred to as the “Enterprise”) acquired a regional player in Russia, b.ch. whose business was concentrated in central Russia. This player, let's call him “Taxi 666”, had a family of proprietary products: Android applications for customers and drivers, as well as a number of Delphi applications needed to manage such a business (accepting drivers, viewing statistics, etc.). Separately, it is worth mentioning the Delphi-application for operators receiving applications by phone. The feature that distinguished the Taxi 666 business model from the most well-known TNCs like Uber was that telephone orders accounted for about 80%, while there was no tendency to increase the share of orders through the application. Nevertheless, the Enterprise perceived this state of affairs not as a problem situation (beyond which many things were hidden - see below), but as a kind of competitive advantage for Russia with its vast expanses and on the whole still low (but rapidly growing) share of mobile penetration. The internet.
So, the audit, incl. technological, was carried out, and the transaction took place. The first mistakes were made at that moment:
')
Error number 1 . The agents of the Enterprise had no backup plan in case the founder of Taxi 666 and its permanent CEO (hereinafter referred to as the “General”) decided to leave the company. Search for a replacement he did not even begin. Having understood this, the General used this fact to gradually establish almost complete control over the agents. So "the tail began to wag a dog."
Error number 2 . The IT audit was carried out superficially and did not reveal one of the two main risks for the implementation of Napoleon’s Enterprise plans for expansion into Russia. The name of this risk is “Firebird”. All Delphi-applications were tied to the use of this DBMS, selected as the standard by the head of the R & D team (hereinafter referred to as “Chief Gad”, “GG”) Taxi 666 about 15 years ago. The main problem, which in the future was constantly disturbing the whole complex, was the instability of work, caused by the inability of Firebird to cope with sharp peak loads at CNN (Maximum Load Clock). This problem was especially hard-to-remove in light of the presence of stored procedures in the database, in which the BH was concentrated. logic complex. The number of these "market" was measured in the hundreds. There was a second important risk that was not revealed by the audit. About him will be discussed below.
As already mentioned, Taxi 666 had its own R & D department, which was permanently headed by GG. The relationship between HS and his department and the rest of the business was complex. So complicated that some ordinary members of the department haggled over to the “side” of the company's products, and the short time before the deal with the Enterprise, the company agreed with a competitor. As a result, after almost 2 months from the date of closing the deal, all R & D withdrew completely from the scene, boarded a plane and flew to a competitor to distant warm regions. In fairness, I would say that such force majeure was difficult to predict, and it was a risk that did not fit into any matrix. However, it could be minimized in at least two ways:
Method number 1 . Register the requirement for the transaction to create detailed documentation of the complex. This documentation in Taxi 666 did not exist from the word “in general”, and this fact was also not perceived as a potential risk.
Method number 2 . To register for the seller of the acquired company the obligation to ensure the maintenance of the R & D department during a certain transitional period. With draconian sanctions in case of non-compliance. M & A specialists, if you read me, take note of this.
Before proceeding, I should say a few words about the “Napoleonic plans” of the Enterprise at the time of acquiring Taxi 666. They suggested an increase in the number of cities of presence from dozens to hundreds in time, measured in 1.5-2 years. Having ambitious plans is good. Not having a process to revise such plans in the event of a dramatic change in circumstances is very bad. And so another mistake was made:
Error number 3 . The sudden complete loss of the development department was not regarded as a dramatic change in circumstances. Napoleonic plans remained the same.
However, it was impossible not to admit that a crisis had broken out in the company: the complex elementary demanded people for technical support. Since it was impossible to delay, several intelligent specialists were hired by agents who urgently arrived from Moscow for breathtaking wages. They were able to stabilize the operation of the complex. This, by the way, was one of the few correct steps throughout the project.
The correct step is â„–1 . Under the threat of the worst case scenario, it is necessary to act swiftly and not to reckon with costs.
At the same time, after the peak of the crisis, the necessary measures were not taken to minimize the “anti-crisis headquarters”: replacing extremely expensive specialists with cheaper ones and finding a permanent manager in the department. So the following error was made:
Error number 4 . The anti-crisis IT manager for Enterprise was appointed as the IT director for Taxi 666. This was a bad decision for a number of reasons. First, a person with three small children had to be on business trips on a “4 days after 3” schedule for several months. Secondly, this person did not know the local specifics of the labor market in the IT sphere, which led to both annoying mistakes (such as hiring Junior Developer for the position of Senior for 100 pp), and on the whole a very slow recruitment process. Thirdly, his appointment went "by" General, as a result of which the work of both was soon further complicated by the smoldering conflict.
Further developments are easiest to describe as a series of implications of previously made assumptions:
Of course, this story is not an example of complete failure. The rest of the team will probably be able to finally understand the complex architecture of the complex and stabilize its work. Business will continue to be profitable for a long time - until the older generation, which is more accustomed to making an order by voice, than through a smartphone screen, will leave. At the same time, the dream of making Best Product by the efforts of a regional team was not destined to come true ...
Who did I write this text for? First of all, for senior management. If you have large financial resources at your disposal, make sure that they are managed by competent managers who know how to find hidden risks and understand that each of them must have an action plan developed in advance. In the second - for ambitious young people like me, who think that their ideas can change the world for the better. Before embarking on a new enterprise, sensibly assess not only the goals and resources of your partners, but also the adequacy and professionalism of their managers. Need to work in a team of like-minded people.
In this text, I will describe part of the project’s history in the very rapidly developing domain TNC (Transportation Network Companies), and more precisely, ROD (Ride on Demand). If in a very simple way, a taxi ordering service. In the middle of last year, one fairly large western TNC (hereinafter referred to as the “Enterprise”) acquired a regional player in Russia, b.ch. whose business was concentrated in central Russia. This player, let's call him “Taxi 666”, had a family of proprietary products: Android applications for customers and drivers, as well as a number of Delphi applications needed to manage such a business (accepting drivers, viewing statistics, etc.). Separately, it is worth mentioning the Delphi-application for operators receiving applications by phone. The feature that distinguished the Taxi 666 business model from the most well-known TNCs like Uber was that telephone orders accounted for about 80%, while there was no tendency to increase the share of orders through the application. Nevertheless, the Enterprise perceived this state of affairs not as a problem situation (beyond which many things were hidden - see below), but as a kind of competitive advantage for Russia with its vast expanses and on the whole still low (but rapidly growing) share of mobile penetration. The internet.
So, the audit, incl. technological, was carried out, and the transaction took place. The first mistakes were made at that moment:
')
Error number 1 . The agents of the Enterprise had no backup plan in case the founder of Taxi 666 and its permanent CEO (hereinafter referred to as the “General”) decided to leave the company. Search for a replacement he did not even begin. Having understood this, the General used this fact to gradually establish almost complete control over the agents. So "the tail began to wag a dog."
Error number 2 . The IT audit was carried out superficially and did not reveal one of the two main risks for the implementation of Napoleon’s Enterprise plans for expansion into Russia. The name of this risk is “Firebird”. All Delphi-applications were tied to the use of this DBMS, selected as the standard by the head of the R & D team (hereinafter referred to as “Chief Gad”, “GG”) Taxi 666 about 15 years ago. The main problem, which in the future was constantly disturbing the whole complex, was the instability of work, caused by the inability of Firebird to cope with sharp peak loads at CNN (Maximum Load Clock). This problem was especially hard-to-remove in light of the presence of stored procedures in the database, in which the BH was concentrated. logic complex. The number of these "market" was measured in the hundreds. There was a second important risk that was not revealed by the audit. About him will be discussed below.
As already mentioned, Taxi 666 had its own R & D department, which was permanently headed by GG. The relationship between HS and his department and the rest of the business was complex. So complicated that some ordinary members of the department haggled over to the “side” of the company's products, and the short time before the deal with the Enterprise, the company agreed with a competitor. As a result, after almost 2 months from the date of closing the deal, all R & D withdrew completely from the scene, boarded a plane and flew to a competitor to distant warm regions. In fairness, I would say that such force majeure was difficult to predict, and it was a risk that did not fit into any matrix. However, it could be minimized in at least two ways:
Method number 1 . Register the requirement for the transaction to create detailed documentation of the complex. This documentation in Taxi 666 did not exist from the word “in general”, and this fact was also not perceived as a potential risk.
Method number 2 . To register for the seller of the acquired company the obligation to ensure the maintenance of the R & D department during a certain transitional period. With draconian sanctions in case of non-compliance. M & A specialists, if you read me, take note of this.
Before proceeding, I should say a few words about the “Napoleonic plans” of the Enterprise at the time of acquiring Taxi 666. They suggested an increase in the number of cities of presence from dozens to hundreds in time, measured in 1.5-2 years. Having ambitious plans is good. Not having a process to revise such plans in the event of a dramatic change in circumstances is very bad. And so another mistake was made:
Error number 3 . The sudden complete loss of the development department was not regarded as a dramatic change in circumstances. Napoleonic plans remained the same.
However, it was impossible not to admit that a crisis had broken out in the company: the complex elementary demanded people for technical support. Since it was impossible to delay, several intelligent specialists were hired by agents who urgently arrived from Moscow for breathtaking wages. They were able to stabilize the operation of the complex. This, by the way, was one of the few correct steps throughout the project.
The correct step is â„–1 . Under the threat of the worst case scenario, it is necessary to act swiftly and not to reckon with costs.
At the same time, after the peak of the crisis, the necessary measures were not taken to minimize the “anti-crisis headquarters”: replacing extremely expensive specialists with cheaper ones and finding a permanent manager in the department. So the following error was made:
Error number 4 . The anti-crisis IT manager for Enterprise was appointed as the IT director for Taxi 666. This was a bad decision for a number of reasons. First, a person with three small children had to be on business trips on a “4 days after 3” schedule for several months. Secondly, this person did not know the local specifics of the labor market in the IT sphere, which led to both annoying mistakes (such as hiring Junior Developer for the position of Senior for 100 pp), and on the whole a very slow recruitment process. Thirdly, his appointment went "by" General, as a result of which the work of both was soon further complicated by the smoldering conflict.
Further developments are easiest to describe as a series of implications of previously made assumptions:
- Errors №2 and №3 led to the fact that instead of a necessary pause for the deep processing of the architecture of the complex, when all the team’s resources would be directed at solving this task, the team was divided into those who supported the complex, which remained for them as a “black box” and those who prepared him for the transfer “to the cloud” (where such progressive things as the remote opening of new cities, distributed control centers, inaccessibility for the Bloody Gebni, etc.) were awaited. As a result, over the next six months, none of these tasks was qualitatively solved.
- Error number 4 led to “holes” in the staffing table, which for a long time did not allow to “decipher” that same “black box” inside the complex, which gave rise to new problems with the stability of its work. This angered the General and pushed him to more and more actively oppose the plans of the Enterprise.
- Errors №1, №2 and №4 led to the fact that investors from the Enterprise, tired of not spending any profit, were reconciled, finally, with the collapse of Napoleon's plans. Thus, they completely gave up the initiative to the General, who (under the pretext of “cutting costs”) was happy to clean only the newly equipped R & D department from everyone who prevented them from doing business “as before.” Those. without “clouds” and managers with their own vision. Including me, the former Product Manager.
Of course, this story is not an example of complete failure. The rest of the team will probably be able to finally understand the complex architecture of the complex and stabilize its work. Business will continue to be profitable for a long time - until the older generation, which is more accustomed to making an order by voice, than through a smartphone screen, will leave. At the same time, the dream of making Best Product by the efforts of a regional team was not destined to come true ...
Who did I write this text for? First of all, for senior management. If you have large financial resources at your disposal, make sure that they are managed by competent managers who know how to find hidden risks and understand that each of them must have an action plan developed in advance. In the second - for ambitious young people like me, who think that their ideas can change the world for the better. Before embarking on a new enterprise, sensibly assess not only the goals and resources of your partners, but also the adequacy and professionalism of their managers. Need to work in a team of like-minded people.
Source: https://habr.com/ru/post/332762/
All Articles