One of the popular hobbies of modern progressive managers is the so-called "project approach". He once again got me, so I first wrote a thread on Twitter, and now I decided to put a more detailed version here.
The project approach is to view an activity as a set of completed projects with goals, objectives, and deadlines. For example, when a new product, service, event, and so on is launched. It really looks reasonable when it comes to something that has goals and deadlines. For example, we decided to hold a conference — it, of course, has several goals at once, we can determine the expected effect, there is a necessary budget, a set of tasks to be completed, deadlines for each of the tasks, and so on. The same story with a new service or product. And, since a conference or a large new service project itself is not a small one, they often break up into subprojects. It is not uncommon for an existing project to organize the addition of a new feature as a separate project.
But emboldened by success, managers go further and achieve the strange in two or three steps.
First, a profitability or payback goal is added to each project. Like, we don't do unprofitable projects. Most often, as a result, each project that is not directly involved in generating or at least receiving revenue begins to invent quasi-financial indicators of its effectiveness. You can not even demand profitability from a particular project — even the general question "How will this affect the company's profit?" looks quite destructive. If the project is at least one step away from directly influencing this profit, the answer to this question becomes a compromise between the honesty of the project authors and the sanity of the author of the question.
In this connection, I recall a story that a professor of economics who gave us lectures at the institute told us about how a feasibility study was being prepared for the system of selling tickets for the Express train (the first version, which was launched in 1984-1985). Economists then faced a problem-it was not possible to prove the economic efficiency of implementing the system, since with the then shortage of tickets, increasing their sales did not make sense, and it was not possible to save on ticket cashiers — an experienced ticket cashier who had a selector connection with the dispatcher wrote out a ticket manually faster than with the help of automated control systems, and even if vice versa, the effect of reducing several percent of cashiers did not justify it in any way. We had to come up with an additional indicator "Reducing the waiting time for passengers in the queue" and derive the effect for the national economy from the fact that thousands of passengers will spend some time less buying tickets.
The next step of managers in general, each change in the project begins to be considered as a separate project and the same requirements for goals, deadlines and a positive impact on economic indicators begin to be imposed on it. And, although the idea of doing what is necessary and not doing what is not necessary seems to be correct and good, but after a certain stage of decomposing the project into very small components, the goals of these components are increasingly difficult to associate with the final effect. But they do not exist in an airless space and are influenced by other factors. This makes the application of the project approach even more of a game of conventions — " well, we will believe that this change affects sales in the end, although we do not know how."
Here, managers rub their hands and begin to apply a project-based approach to operational activities. True, they do not touch the most basic things like accounting, because they can not understand, everything is backward and there is a potential criminal liability, but now they are frolicking in HR and marketing.
For example, the question "What effect will we get from participating in the conference?"is asked. Since the effect of one conference is difficult to distinguish and the final deals are concluded by bizdev (and this is another project, another department, and in general a good bizdev at the conference does not sit on the stand and, even after receiving the lead at the conference, the deal is concluded after some time), it becomes almost impossible to prove the need for a stand.
I have seen the requirement to justify the need for a project to correct obvious errors that interfere with marketing-they say, well, it somehow works, but what will the correction give us, what market share will we get as a result?For some reason, when in response you are interested in what market share we will get as a result of refactoring the code or eliminating the dispersed layout on the main page, project managers begin to take offense and talk about extremes.
By the way, in such a type of operational activity as sales, managers with a project approach are rarely announced. And in this form, the revenue is the direct and virtually the only result of the activity. A coincidence? I don't think so!
Let's sum it up. First, the project approach should not be applied to the company's operating activities and standards, especially in small businesses. It is necessary to keep records, to be friends with journalists, to respond to letters politely and on time. And do not ask the questions "What will it give us?". We once used the concept of "hygienic minimum" at Yandex, which looked like " The product must be localized for the region in which we work, comply with the law, local customs, and communicate in the local language." If you think that the presence of the Ukrainian interface in Yandex mail in 2007 was an obvious task, then no, not for everyone. And the questions "What market share will the Ukrainian interface give us?" were asked everywhere. Just in case, let me remind you that it was 2007, when large sites with a Ukrainian interface could be counted on the fingers of your hands.
The division of project activities into smaller and smaller projects will sooner or later lead to the identification of a project that does not earn itself, but without which everything else does not work. And then there are angry questions " Who saved on the spellchecker / native editor?". So don't do that.
Moreover, such a division does not make practical sense, especially in small companies. Any decision, even the most subjective and voluntary, in projects at a level below the department of a small company will give better results, especially if you take into account the additional costs of all the near-project bureaucracy with regular meetings and presentations.
Finally, another real-life example of the collision of project managers with operational activities. I have dealt quite a lot with Odessa IT companies in recent years and observed, in particular, how the previous version of the IT cluster did not work. Self-confident project managers representing IT companies demanded that all issues be solved on a project-by-project basis, as a result, one of the projects was called "A trip of the cluster director to a conference". By what miracle the director still appeared at the conference, I did not understand.
Don't do that
