What can I say - I did many of them. I wondered how my conclusions were supported by the experience of non-RM: developers, analysts, testers.
In February 2021, I conducted a survey of members of the development teams in the offices of Ukraine and Russia. The survey asked to identify the most frequent and annoying moments when interacting with project managers.
The results of the survey - more precisely, the solidarity of the participants in the answers to some questions, and their correlation with my personal observations - surprised me.
Part one. Statistical
More than half of all participants noted that poor goal setting is the most common pain for development teams. The second and third places are shared by a small margin:
- Insufficient immersion of RM in the essence of the project, lack of understanding of the applied area. At the same time, many respondents indicated that they would gladly conduct onboarding to help their comrade-leader, but ... We do not often ask them about this. As one of the respondents aptly noted, misunderstanding of the project and lack of technical literacy often lead to planning errors.
- Ignoring questions and uncomfortable risks identified by the team, avoiding the problem. This topic, perhaps, deserves a separate article and, in my experience, this behavior is associated not only with the skills of risk management, but also with the leadership qualities of the manager.
Illustrations by the author of the article
As for setting goals, anti-rating is the most annoying and - alas! - while the most frequent mistakes of project managers are headed by empty or insufficient task descriptions. More than 70% of respondents noted this item.
At the same time, many are ready to forgive the manager for grammatical errors, typos, and incorrect use of terms, but not the lack of a clear statement of the essence of the problem. At the same time, more than half of the respondents admitted that a huge list of child and related tasks also hardly makes them happier or their work easier.
Part two. Reflective
Perhaps, here I will share only my own experience and will not pretend to absolute knowledge.
The task should be clear to the person who performs it and accepts it, its formulation should include the necessary context and links to the right sources, describe the implementation details and support the team's focus. After reading the problem, a person should realize what they want from him, why the project needs it, and imagine how he will achieve the result, at least in the first approximation. If there is no such understanding, we probably have a problem.
The second question is to what extent the project manager is responsible for this. Depending on the framework that the manager uses, different scenarios and degrees of development of self-organization in teams and different emphasis on the role of the PM, including his participation in the setting of tasks, are possible.
A great option is to involve a business analyst (BA) in this process. Its tasks include a detailed description of the requirements, the design of edge cases. At the same time, RM, and not BA, together with the team set tasks and plans.
In true Agile teams, the role of PM in the usual sense is leveled. Agile speaks of the value of a team that is able to organize itself, setting itself achievable and clear tasks on its own. Why does such a team need a leader who sets and controls tasks? At the same time, I do not see any contradictions.
It is not so important who technically described the task and set it, if the project manager monitored and organized the final result: he made sure that the team understands who should do what and why. Thus, any revision of tasks and their logical alignment is for me the area of responsibility of the RM.
Separately, I will say about project managers who bring tasks from above with minimal coordination with the team. What's wrong with this approach?
- The knowledge of one person is always limited. You can be a great RM, but your colleagues may have more experience in specific areas. Relying only on your knowledge, you can miss something or lead the team on a sub-optimal path.
- Assigning tasks from above without discussion excludes second opinion in the team, the opportunity to show initiative by other participants and can undermine the environmental friendliness of relations.
- Limit team growth. We grow not only when we take on difficult tasks, but also when we are responsible for them. Without giving the opportunity to manifest this responsibility, RM limits the development of the team.
RM is always the leader of a project and is ultimately responsible for delivering it. I really love the term ownership - it capaciously reflects my vision of responsibility.
