June 15, 2015 at 08:51Can PM manage what it does not understand?
This article was born out of a series of disputes with management on the topic of whether the RP should or should not deeply understand the technical side of the projects that it manages. In fact, it is a summary of my arguments about the fact that the project manager should thoroughly understand what his team is doing. It is desirable, at the level of ability to fully replace any of its participants.
A short introduction: if you work in a large organization and manage multimillion-dollar or even billion-dollar projects, then this is clearly not worth reading to you, and you will not agree with me, because the level of problems we have is different. And I perfectly understand that my theses often go against the generally accepted practices of project management, but I personally can guarantee the success of the project only if I follow them.
The team that directly makes the project is the most important part of the project. Without a great relationship with her and excellent mutual understanding, you can immediately bury your project at the start. Only an excellent team and its attitude towards you can pull an absolutely hopeless project out of its full ass.
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, this will be the most critical moment of your project. I noticed by myself: even the most intelligent, responsible, beautiful, etc. colleagues at a certain moment, noticing that you do not understand what they are talking about, switch to the communication style “Mom is an unreasonable child”. Those. the developers start telling you something like: "We cannot use the database in this project, because a-ta-ta will be more." And you will not get a more logical explanation from them. You must admit that this is not a good style of communication, especially in a situation where you are a leader for them.
If your project has reached some critical point at which the result must 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 your obligations, there will be massive repressions on the part of the customer and management, you should sit next to your employees and figure along with them (or even more of them). You can only motivate yourself by example. If you get up exactly on the call and go home, because you still can’t help with anything, then be sure that no one will sit at night and plow at you (apart from a certain number of crazy perfectionists, but for now it's not about them).
If the management allows you to select a team for a specific project (and if it does not allow it, then either you or your company are not "project oriented"), then you should recruit people who are ideally suited for this particular project. Of course, you can rely on the reviews and recommendations of other people, but they can be extremely wrong. Example: there is a developer guru who is thrown into those projects where the customer is ready to burn your entire office with a napalm. The track record of such a developer is some failed projects, about which it’s a shame to recall. If you ask other RP about the qualities of such a developer, they will not remember, because at that moment it was necessary to extinguish the fire, and not think about personal qualities. And it’s not known at all whether critical projects are being straightened out at the expense of this development guru or just throwing him cannon fodder.
Therefore, if you precisely understand which of the existing pool of engineers is capable of what, then you can put together the ideal configuration of the team, which will do everything very smartly with minimal involvement of you 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 strangers, but I proceed only from selfish motives in work.
Recently, technicians (system administrators, internal developers, IT security personnel) have been attracted by customers to all projects except business users, who like to attend meetings and ask urgent, and often also uncomfortable, questions. If you need to “clarify information in the office” to answer all these questions, then you will understand how. Any solution to the problems will be delayed. You will constantly run away to consult with specialists. But it’s better to solve some problems here and now.
This item follows from the previous one. If the customer sees that you are going to consult somewhere on all issues, and in the project, for the most part, you play the role of a mail server (even if it’s not, the impression is still there), then at some point the customer’s specialists will start directly chat with your team. You will remain somewhere behind the back of these negotiations, and part of the decisions will be brought to you in general post-factum. I am sure this is not the best position for a person who must just manage everything. For the customer, you must be "Mr. Wulf who solves the problems."
There is one more nuisance that can grow out of such communication. An employee who has the necessary communicative qualities, and in his soul trying on the role of RP, can completely “squeeze” you out of the project and take control. Do we remember about egoism?
Small item. Sometimes the customer can sell some extra. the services are immediately in place until he wants to. In this case, the more accurately you present the whole range of problems, and the better you can make an assessment, the more chances there are for additional project money without a subsequent bloody reckoning.
Theoretically, all the problems described above are solved by attracting specially trained people like those to 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 trimming it yourself, using quite expensive resources in the project that you can definitely do without?
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; some expensive “thing” will not be crammed into the project, which will show you a real trifle (due to your ignorance), but in the end it will turn out to be a pain in the ass; management will not impose on you a deliberately impossible project, taking advantage of your intellectual helplessness. Etc.
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 CSW :)
No matter how I like this approach, there are, of course, disadvantages in it:
A short introduction: if you work in a large organization and manage multimillion-dollar or even billion-dollar projects, then this is clearly not worth reading to you, and you will not agree with me, because the level of problems we have is different. And I perfectly understand that my theses often go against the generally accepted practices of project management, but I personally can guarantee the success of the project only if I follow them.
Command
The team that directly makes the project is the most important part of the project. Without a great relationship with her and excellent mutual understanding, you can immediately bury your project at the start. Only an excellent team and its attitude towards you can pull an absolutely hopeless project out of its full 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, this will be the most critical moment of your project. I noticed by myself: even the most intelligent, responsible, beautiful, etc. colleagues at a certain moment, noticing that you do not understand what they are talking about, switch to the communication style “Mom is an unreasonable child”. Those. the developers start telling you something like: "We cannot use the database in this project, because a-ta-ta will be more." And you will not get a more logical explanation from them. You must admit that this is not a good style of communication, especially in a situation where you are a leader for them.
2. Fire on the project - we burn together
If your project has reached some critical point at which the result must 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 your obligations, there will be massive repressions on the part of the customer and management, you should sit next to your employees and figure along with them (or even more of them). You can only motivate yourself by example. If you get up exactly on the call and go home, because you still can’t help with anything, then be sure that no one will sit at night and plow at you (apart from a certain number of crazy perfectionists, but for now it's not about them).
3. We work with the best
If the management allows you to select a team for a specific project (and if it does not allow it, then either you or your company are not "project oriented"), then you should recruit people who are ideally suited for this particular project. Of course, you can rely on the reviews and recommendations of other people, but they can be extremely wrong. Example: there is a developer guru who is thrown into those projects where the customer is ready to burn your entire office with a napalm. The track record of such a developer is some failed projects, about which it’s a shame to recall. If you ask other RP about the qualities of such a developer, they will not remember, because at that moment it was necessary to extinguish the fire, and not think about personal qualities. And it’s not known at all whether critical projects are being straightened out at the expense of this development guru or just throwing him cannon fodder.
Therefore, if you precisely understand which of the existing pool of engineers is capable of what, then you can put together the ideal configuration of the team, which will do everything very smartly with minimal involvement of you 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 strangers, but I proceed only from selfish motives in work.
Customer
1. We speak with the customer without an interpreter
Recently, technicians (system administrators, internal developers, IT security personnel) have been attracted by customers to all projects except business users, who like to attend meetings and ask urgent, and often also uncomfortable, questions. If you need to “clarify information in the office” to answer all these questions, then you will understand how. Any solution to the problems will be delayed. You will constantly run away to consult with specialists. But it’s better to solve some problems here and now.
2. “Mr. Wolf”
This item follows from the previous one. If the customer sees that you are going to consult somewhere on all issues, and in the project, for the most part, you play the role of a mail server (even if it’s not, the impression is still there), then at some point the customer’s specialists will start directly chat with your team. You will remain somewhere behind the back of these negotiations, and part of the decisions will be brought to you in general post-factum. I am sure this is not the best position for a person who must just manage everything. For the customer, you must be "Mr. Wulf who solves the problems."
There is one more nuisance that can grow out of such communication. An employee who has the necessary communicative qualities, and in his soul trying on the role of RP, can completely “squeeze” you out of the project and take control. Do we remember about egoism?
3. Instant sale
Small item. Sometimes the customer can sell some extra. the services are immediately in place until he wants to. In this case, the more accurately you present the whole range of problems, and the better you can make an assessment, the more chances there are for additional project money without a subsequent bloody reckoning.
Other design buns
1. Project budget
Theoretically, all the problems described above are solved by attracting specially trained people like those to 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 trimming it yourself, using quite expensive resources in the project that 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; some expensive “thing” will not be crammed into the project, which will show you a real trifle (due to your ignorance), but in the end it will turn out to be a pain in the ass; management will not impose on you a deliberately impossible project, taking advantage of your intellectual helplessness. Etc.
Guide
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 CSW :)
Cons of this approach
No matter how I like this approach, there are, of course, disadvantages in it:
- 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 with increased self-control;
- The need to develop in parallel in two or three “posts”. You should become better both as an RP and as a developer-engineer-analyst-who else is in your team. This 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 does not characterize intelligence, but the approach);
- The inability to lead the "construction of the century." Unfortunately, this approach does not work in them, because there is only 24 hours in a day, and indeed - life is too short. If the opportunity looms on the horizon with something great, and you also have a desire, then such an approach will have to be abandoned and overgrown with all kinds of helpers. But, I think, if you really have such an opportunity on the horizon, then you do not need my advice.