Project Manager in IT. Duties without powers
How did the idea to write an article come about?
I wanted to comprehend my experience and the systemic problems that I encountered while working as a project manager (PMA) in IT. Almost always I saw a similar picture – the head of the company wanted to transfer part of the responsibility to line management in order to free himself for more strategic tasks. Since work in IT is most often a project, finding a PMA seems the most logical. They are looking for a person who is not afraid to take responsibility for the entire project. At the same time, other processes in the company (project initiation, contract signing) practically do not change and remain tied to top management. As a result, the project comes to the PM at the stage when everything has already been decided: the team is defined, the customer’s expectations, the project goal, and the budget are lined up. And then the PM works with what is, without having the authority to change the composition of the team, the budget of the project, the customer.
But without delegation of authority, the problem of top management workload is not solved. An interesting situation occurs when there is a person “responsible” for the project, but all decisions are made by top management. The problem becomes less visible, because the PM is “guilty” of all the decisions made. PM, as a rule, is a responsible person, then he stubbornly searches for the reasons for failures in himself. Beautiful words can be heard in the company about the fact that everyone can influence the situation, we have Lean, Agile and that’s it. But this only makes it difficult to see the discrepancy between duties and powers.
Here one could put an end to the article and say that everything is decided by job descriptions, descriptions of roles, but this is boring. And all the skill lies not in the tools, but in how to apply them in a real situation. And in order to apply them, you must first see what is happening in general. What I will write about.
By the way, I heard that things are better with PMs in construction. I would be glad if someone share in the comments.
In the case of roles, it is very important to find a suitable name for the role and its purpose. This choice has its consequences:
Published resume with this title
Vasya, who has taken courses in project management, will respond to him. In these courses, he was told that he was responsible for the execution of the contract (project triangle: schedule, budget, scope of work), work with the team, stakeholders.
Vasya will be assigned as a PM for project X. And inside the company, everyone will have an expectation that now Vasya is responsible for project X. He controls it, whatever that means.
If a problem appears on the project, then everyone will look at Vasya and wait for him to solve it.
Let’s take a look at the names. I’ve often been called the PM, but what would the role be called according to its powers?
It happens that top management wants to give the PM the function of controlling the timing and budget. In fact, it looks like the PM collects reports on team performance and budget spending. A lot of mechanistic work, in which, again, there is no decision making, but sending reports to the top management and informing the team that we are working according to the plan or behind it. Since the PM cannot influence the composition of the team, he can only hope for the prudence of each participant, conduct motivational conversations or escalate the problem higher, finding people in the company who care about the project for which he is responsible. Here he can develop into the role of a consultant.
If the PM is lucky with his skills, environment and his influence, then he becomes a consultant. That is, again, due to the lack of authority, he cannot do anything with his own hands, but he can do it with the hands of other people. In fact, this is what consultants do. This is neither bad nor good. It’s just that a consultant cannot be responsible for the implementation of the project’s goals, he can only be responsible for informing all participants in the process about the problems and risks.
When a PMA has expertise in agile methodologies, then from the role of a simple consultant, he can become a consultant on Scrum, Agile, Lean. Here another inconsistency appears, because there is no project manager in the Agile philosophy. When I got into this situation, I usually used the “internal product owner” crutch role, since I was not only the process custodian, but also communicated priorities to the team.
A responsible PM often plugs all the gaps between business and engineers. One such gap is working with requirements and translating business requirements into technical tasks. In this case, the PM becomes not only the bearer of expertise in building production processes, but also an expert in the domain area of the project. Here he becomes a direct participant in the production of the product both at the stage of setting the task and at the stage of validating the results.
What powers does it make sense to delegate to the PM
I will write about the two powers that have been most prominent in my experience and that, in my understanding, make a Consultant into a Project Manager.
Validation and control of agreements
There were times when I was not involved in drafting the contract and initiating the project. The client negotiates all the terms of the contract with one person, and implements it with another. In IT, I came across this both from the side of the contractor and from the side of the customer. Introducing additional layers of communication in IT is considered the norm.
Sometimes a client encounters such a chain:
Sales->Account Manager->Solution Architect->PM from presale-> Production PM -> team
Transferring information and context between different roles is a complex task. At the start of the project, the expectations of all stakeholders are formed, a common vision and trust are created. As a rule, many nuances in expectations and agreements remain verbal. In the case of outsourcing companies, the situation is aggravated by the fact that there is a task to “sell” ourselves, to promise the maximum of what we can do. The conflict between sales and production is textbook and requires the creation of additional links between people working in sales and production.
The sooner the PM and the team are engaged in communication, the more in sync they will be with the project goals. As a rule, after the start, everyone has the feeling that everything has already been discussed and asking “stupid” questions seems not comme il faut.
Advice to PMs who have already received a signed contract: arrange a “honeymoon” for yourself with all the stakeholders. Do not be afraid to seem stupid, understand what you signed up for here and how, in your opinion, it is realistic to comply with these agreements, is it possible now, with current resources, to solve a problem of such complexity?
The most common and costly mistakes come from the fact that people diligently pretend that they understand each other.
Determining and changing the composition of the team
People in IT are the main resource, the main risk and, accordingly, the factor determining the productivity, marginality and success of the project. It is logical to assume that the PMA should have the power to change the composition of the team, but this is far from always the case. I met a situation where there was a separate role – a resource manager. This person makes sure that all engineers are busy and tries to balance “busyness” with the interests of the projects. This role has a focus on the percentage of the bench, the overall margin of the company, but does not focus on the goals of individual projects. This leads to averaging of project results and constant rotations. Plus, competition for resources between project managers is added – the most convincing one or the one who has a good contact with the resource manager wins.
Also, I had experience when I myself opened vacancies, interviewed engineers and built a team – in this case, I managed to make an effective team where there is trust, good group dynamics and a resource for solving complex problems.
Delegation of authority VS propaganda of influence
Delegation of authority is a change / creation of such business processes in which the PM has the opportunity to make a decision and has the resources to implement it.
Influence propaganda is the words that we are Lean, Agile, that everyone can influence the process. But without the appropriate business process and resources needed to make that impact.
As long as meetings to discuss the composition of the team take place without the PMA and contracts are agreed without the participation of the PMA, no Agile-Lean practices will make the work of this role effective.
Self-management and self-organization
In my understanding, a good manager is one who was able to build a structure that works independently, without his participation. The evolutionary goal of the PMA, which resonates with me, is to make sure that the role of the PMA is no longer needed. The path to self-government is long and thorny, I do not have enough expertise and experience here to describe it in its entirety. Nevertheless, the revision of the organizational structure and roles plays an important role in this way. I want to believe that this article can help with this process as well. In the case of self-management, the delegation of authority may be carried out not by an individual, but by the entire project team. The role of the PMA may not exist, but instead, for example, a business analyst can be added and the meeting facilitator role can be made transitional. One can glean specific implementations of such organizational structures from the Sociocracy 3.0 community of practice. The international community regularly hosts webinars where companies share their successful experience and the rake they have collected.