This article was born from a series of disputes with the leadership on whether the RP should or should not deeply understand the technical side of the projects he leads. In fact, it is a summary of my arguments on the topic that the project manager must thoroughly understand what his team is doing. It is desirable at the level of the ability to fully replace any of its participants.
A small preface: if you work in a large organization and manage multimillion-dollar, or even billion-dollar projects, then you clearly don’t have to read it, and you don’t agree with me, because The level of problems we have is different. And I understand perfectly well that my theses often go against the generally accepted practices of project management, but I personally can guarantee the success of a project only if I comply with them.

Team

The team that directly makes the project is the most important part of the project. Without a great relationship with her and an excellent understanding, you can immediately bury your project at the start. Only a great team and its attitude towards you can get a completely hopeless project out of complete ass.

1. We speak the same language with the team

If you do not understand what specific people are doing in your project, at some point you will not be able to communicate with them. And, most likely, it will be the most critical moment of your project. I noticed on my own: even the most intelligent, responsible, beautiful, etc. colleagues at a certain point, noting that you do not understand what they are talking about, are switching to the “Mom is an unreasonable child” communication style. Those. the developers are starting to say something like: “We cannot use the database in this project, because a-ta-ta will be bo-bo”. And you will not wait for a more logical explanation from them. Agree that this is not a good communication style, especially in a situation where you are for them some kind of leader.

2. Fire on the project - we burn together

If your project has reached some critical point at which the result should be shown here and now, otherwise shooting, the only way to motivate your colleagues for a labor feat is to “fall on the battlefield” with them. Those. if you have a deadline tomorrow and, if you do not fulfill obligations, there will be mass repressions from the customer and management, you should sit down with your employees and figure with them (or even more of them). You can only motivate your own example. If you get up exactly on a call and go home, because you still can’t help you, then rest assured no one will sit at night and plow on you (not counting a certain number of perfectionist madmen, but for now it’s not about them).
')

3. We work with the best

If management allows you to select a team for a specific project (and if it does not, then either you or your company are not “project oriented”), then you should recruit people who are ideally suited for this project. Of course, you can rely on the reviews and recommendations of other people, but they can be extremely erroneous. Example: there is a developer guru who is thrown into projects where the customer is ready to burn your office with napalm. The track record of such a developer - some failed projects, which are ashamed to recall. If you ask other RPs about the qualities of such a developer, they will not remember, because at that moment it was necessary to extinguish the fire, and not to think about personal qualities. And it is not known at all, they correct critical projects at the expense of this guru-developer or simply throw him with cannon fodder.

Therefore, if you understand exactly who of the existing pool of engineers is capable of, then you can put together an ideal configuration for the team that will do everything very smartly with minimal involvement in your problems. Well, the opposite situation, if you understand your team, and she will feel it, then the team itself will ask for your projects. True, partly sabotaging others, but I proceed only from selfish motives in my work.

Customer

1. We speak with the customer without a translator

Recently, on the part of customers, technicians (system administrators, internal developers, IT security personnel) are involved in all projects except business users, who like to attend meetings and ask pressing, and often uncomfortable questions. If you need to “clarify information in the office” to answer all these questions, you will look understandable how. Any solution to the problems will be delayed, because You will constantly run to consult with experts. And some problems are better solved here and now.

2. "Mr. Wolfe"

This item is derived from the previous one. If the customer sees that you are going somewhere to consult on all issues, and in the project, for the most part, perform the role of a mail server (even if this is not the case, the impression will still be formed), then at some point the customer’s specialists will start communicate with your team. You will remain somewhere behind the back of these negotiations, and some of the decisions will be brought to you post factum. I am sure that this is not the best position for a person who should manage everything. For a customer, you must be "Mr. Wolfe, who solves problems."

There is one more nuisance that can grow out of such communication. An employee who possesses the necessary communicative qualities, and in the soul trying on the role of the RP, can completely “squeeze” you out of the project and take control. And we remember about egoism?

3. Instant sale

Small item. Sometimes the customer can sell some extra. services immediately on site, until he perehotel. In this case, the more accurately you present the whole range of problems, and the better you can make an assessment, the more chances you will have for additional project money without subsequent bloody payback.

Other design buns

1. Project budget

Theoretically, all the problems described above are solved by involving specially trained people like those in the project. lead tim leads and so on. But the participation of any such specialist reduces the profit received from the project. And profit is one of the key indicators of project success. What is the point of independently cutting it down, using rather expensive resources in the project, without which you can definitely do without?

2. Project scope

You will be sure that the scope of work in the project will not change without your knowledge. Because the customer does not agree with the team behind your back; it will not push through some expensive “piece” into the project, which will show you a trifle (because of your ignorance), but in the end it will turn out to be a pain in the ass; the management will not impose on you an obviously impracticable project, taking advantage of your intellectual helplessness. And so on.

Manual

What will your leaders get from all the "side" knowledge that you will have? They will receive: a successful project, no need for constant monitoring of what is happening, a satisfied customer, a satisfied team, and a satisfied you with an overwhelming sense of ChSV :)

Cons of this approach

As much as I do not like this approach, there are, of course, disadvantages:

1. Danger of slipping into micro-management. If you are well versed in everything, then there is a chance that you will begin to control every developed line of code, every word written in TK. It is treated exclusively by increased self-control;
2. The need to simultaneously develop in two or three "positions." You should become better both as RP, and as a development engineer-analyst — who else is in your team. It will take too much time, so you have to look for a middle ground. Well, or spit on technical knowledge, and become a classic "stupid manager" (the word "stupid" in this place is not characterized by intelligence, but by the approach);
3. Lack of ability to lead the "construction sites of the century." Unfortunately, this approach does not work in them, because there are only 24 hours in a day, and in general, life is too short. If the opportunity to command something great looms on the horizon, and you also have a desire, then such an approach will have to be abandoned and overgrown with all sorts of helpers. But, I think, if you really have such an opportunity on the horizon, you do not need my advice.