Who a Project Manager in IT is, what they are responsible for, what skills are needed and how they help the team and client work without failures.
Reading time: 14 min. Is life easy for developers? It depends on the company. Let's look at how this can be assessed and how kt.team builds teams that are easy and enjoyable to work in.
If you're reading this article, you most likely know perfectly well what developers do.
Just to be clear: they build and maintain application software (websites, mobile apps, document recognition systems, BI systems, B2B business portals, and much more).
They usually work in teams rather than alone, since development is labor-intensive.
In some places there are only developers, while in others a support group joins them: project managers,
and systems analysts, quality mentors... In this article, we will look at how they strengthen the team and make developers' lives easier. To find out what kinds of developers there are, we will use Edward Hay's job evaluation method. Job evaluation factors according to Hay:
Required knowledge and experience (know-how) are the practical skills, theoretical knowledge, and experience needed to perform job duties.
Problem solving is the level of thinking process required for this position in terms of the complexity of the work.
Accountability — the employee's responsibility (for their personal and/or team work result).
On the job market there are both coders and engineers: both are in demand, just at different companies. But besides developers, there may be another very important person on the team - the project manager.
With their highly developed problem-solving skills, knowledge, experience, and high level of responsibility... Let's try to answer this question
The foundational philosophy in IT is Agile, flexible project management. Agile itself does not divide people by roles.
The team structure here is flat, and the entire team is responsible for the result. In Agile, there is a product owner (the client who makes business decisions and says how important a feature is when the task is set, and whether it delivered the expected effect after completion) and a team in which all members are equal.
There is no project manager role.
kt.team is a systems integrator, that is, a contractor that develops complex IT solutions for external clients. In an Agile integrator, the Agile principles are combined with the TQM paradigm (total quality management).
TQM rules: I don't make defects; I don't let defects through; I don't accept defects;
TQM rules can be represented as a pyramid, with quality responsibilities at each level.
A software engineer-level developer must think about all exceptions, including those not specified in the technical requirements - that is their quality standard.
That is, there are no developers in an Agile integrator who could be considered coders; in essence, everyone here is an engineer. For example, there is a task to build a simple registration form on a website with a single field - "Year of birth."
The developer must anticipate that a user might mistakenly enter the year 3000 or even letters, and handle all these exceptions.
This is the quality level of how the task is done.
The problem is that a task can be set incorrectly (you have surely run into this too).
A defective task is one that is poorly described and does not provide enough data to complete it. In our example with the registration form: if a person enters an age of five years, should that be treated as an error, or should registration be allowed?
Where is the upper cutoff limit: 65 years or 100 years?
To understand this, common sense alone is not enough - you need to learn the specifics of the client's business.
Another example: the client proposes implementing an excessive solution (for instance, new marketing features). Maybe the idea isn't the best, the implementation would reduce sales, or we'd spend too much time on it at the expense of more important tasks. Imagine if a developer or team lead had to analyze all of that?
They need to understand marketing, think about profitability, and worry not only about the quality of their own code but also about the project's overall business metrics.
How much time does it take to first learn this and then do it day after day?..
At this intermediate level between the product owner and the developer stands the project manager, who is the very "I don't let defects through" barrier at the level of setting and prioritizing tasks. He achieves high quality in setting the task (together with the client) and high quality in the finished product (together with the developers).
We cannot say:
That's why the project manager accepts any client wishes and brings them to a quality state:
For this we use the INVEST method (or SMART) and impact mapping: a way of describing tasks that lets you think a task through as deeply as possible from the standpoint of user value, and a methodology under which a specific task maps onto improving specific metrics. A task described with INVEST answers the questions: who (the role); where (the location); what to do; and why it's all needed.
An INVEST-based story must always include a business requirement (what exactly is needed and in what context).
If I want to paint the house blue, then the scenario should be: as the house owner, I want to see the exterior walls painted blue so that the house looks blue from outside.
The product owner is responsible for INVEST — this is the business-requirements level and the product owner's quality level (only they have the necessary data, and they will accept the finished result). And the project manager helps them arrive at the right wording.
Conclusion: A project manager saves developers and the team lead a huge amount of time by analyzing the task in depth, describing it with the INVEST method, and achieving high-quality task setup.
The work gets divided up, and developers can focus on code quality.
An important part of a project manager's responsibilities is communications management. Alexey Project Manager: "The project manager is responsible for communication with the client and, if any disputed situations arise, takes the heat. Only constructive feedback reaches the team: what is wrong, why, and how it should be done."
Project managers themselves call themselves translators from the client's language into developers' language and back. If you simply "throw" the development team together with the client, they will not understand each other because they speak different languages: technical details need to be explained to the client, and the team needs the client's request reformulated in a way they can understand.
This is convenient for the client: no need to spend hours finding a doer for the task or digging into details just to state it clearly. It also helps the developers: no need to beg and wait for the client to provide the required data or to hunt for someone who can supply it.
The project manager works out on their own which data they lack to define the task properly, requests that data, and when needed can set up automated data transfer, arrange integration, and refine the client's information system.
It is very difficult for the person doing the work to estimate correctly how much time a task will take.
This is a psychological trap - they will tend to give the client the shortest impossible deadline ("I'm a professional, this task is easy for me"
Or, on the contrary, to plan time mechanically by allocating an overly large, identical buffer to every task. An outside project manager can assess the required amount of time more objectively, which makes it easier for the team to avoid missing deadlines and at the same time prevent overspending the client's budget. At kt.team, the project manager requests time estimates for tasks from the team lead and the team and, based on those estimates and the client's available resources, provides the final plan.
On the one hand, the opinions of the team lead and the employee are always taken into account (there will be no impossible, ultra-tight deadlines), and on the other, the project manager can adjust priorities so the client gets their most important tasks completed faster.
Out of an eight-hour workday, a project manager spends about 4 hours communicating with the client!
The team is spared this - communication between the project manager and developers is usually limited to a short morning meeting (daily meeting). The project manager communicates with the client through many channels: email, phone, messengers; on some projects, they also have to track data in the client's software (for example, in Jira).
Sometimes project managers have to travel on business trips to the client's site, spending time and energy on flights.
The developer and the team lead deal only with Jira (our internal system).
Attending a long conference call with the client (for 1-2 hours) and extracting two paragraphs of valuable information from it is the project manager's job, while the team lead and the team receive that information in condensed form in five minutes. Can you imagine the time savings? The project manager works extensively with documents: checks the accuracy of work logs and sends itemized details to clients; records every call and every meeting with the client, and sends reports to all meeting participants.
This is necessary and very important, but team leads and developers would hardly enjoy it. The project manager spares them from it.
A project manager protects not only the team in front of the client, but also the client in front of the team.
When a task is done, the project manager accepts it first, analyzing and testing it from a business standpoint: did we achieve the business feature we wanted?
The client could say that the result does not satisfy them in a much less polite and much less timely way, so they should receive a result that is as close to ideal as possible. Conclusion: can the team lead do all of this?
After all, they have strong soft skills and are good at communicating.
Team leads talk with the client from time to time even when a project manager is present.
But without a project manager, the team lead would have to: spend at least half of his working time clarifying the client's business requirements; be interrupted every five minutes by incoming messages in messengers, emails and calls; think through all the project's business functionality; obtain the needed data from the client and arrange its regular delivery; keep minutes and reports and send them to all participants; demonstrate the finished product and defend it
to the client, proving that it fully meets all the client's requirements.
We strive to ensure that team leads and other developers handle only execution - carrying out the task.
It is more important for team leads to develop their leadership skills so they can mentor junior staff, pass on knowledge, and give the team high-quality feedback. In project groups, senior mentors review all mistakes made, and the team learns not to repeat them by studying examples of bad practice. Team leads have plenty to do!
In terms of project management there are two main methodologies: flexible (Agile); and requirements-driven development (waterfall).
For example, for a large corporation where a pre-agreed task needs to be completed, waterfall is a better fit. And if a project has a high degree of uncertainty, which is common in software development, Agile is usually chosen.
Alexey, Project Manager: "It's easier for a project manager to work with a clear technical specification, when requirements are known and fixed in advance.
But this does not always correlate with the result - it does not mean you will get a working product at the end, even if it formally meets all requirements, simply because some requirements are already outdated at the moment the technical specification is written, or the client's wishes were initially impossible for the client themselves to fulfill.
Downsides of the agile approach: it is hard to forecast the budget and completion dates for all the work. And every client always wants to know them in advance.
The advantages are a very fast launch of the first version (we have examples in a week) and the closest possible match to user needs, since users accept a product every one or two weeks and start using it right away.
monitors the timely start and progress of the work; runs daily meetings with the team; influences the team (or the team lead) so that the actual result matches the plan and meets the client's requirements; always keeps deadlines, budget and quality in focus and manages them wisely; maintains project documentation (project charters, mind maps, reports, etc.); takes part in demonstrating functionality to the client. Conclusion If you hand these functions to the team lead, they will take a lot of his energy and time.
And, as we've already said, the team lead has plenty of their own tasks.
Who else helps teams and makes life easier for team leads and developers? We share KT.Team's experience.
We are sometimes asked: "Why do you have so few testers?"
We really do not have them; instead, we have two quality mentors.
This fits the Agile paradigm: work happens in "flat" teams with no separate quality function.
We also keep TQM in mind here - every developer is responsible for the quality of task execution. Absent
If the team has testers, it changes the entire course of the work.
Developers may implicitly shift responsibility for the quality of their work onto them. The workflow becomes uneven - "I completed the task, and I checked it only superficially - the tester will do a better job."
The tester reviews the work and sends it back for debugging, and so on many times, many iterations. In the end the developer cannot dive deep into any single task, because a pool of old tasks keeps coming back to them.
Focus is lost, and work becomes less productive and more uneven. Present
That's why our quality mentors start testing the project only when the team cannot ensure high quality on its own.
The reason is simple - the deadlines are too tight, so compressed that extra help is needed (for example, launching an online store from scratch in three months, as we did for TVOE, and we literally lived in the client's office; that was several years ago, and we no longer take on projects with such extreme deadlines).
Our quality mentors don't just find a problem and reopen tasks — they deeply analyze the root causes of defects.
If a task was set up poorly, they find out why it happened and what can be changed so that defects no longer appear at that point. For example, a test environment is deployed but the database isn't kept up to date.
There are working issues that need to change, and mentors handle that. At the end of the month, every project undergoes a quality audit, and we send the results to both the team and the client.
The main function of a business analyst is to break down a request from the client into atomic sub-tasks in depth and clarify all nuances and behavior in edge cases. Sometimes this work is done by the project manager. A business analyst can also independently configure the product if part of the business requirements can be implemented through settings, or prepare a development specification on behalf of the client if needed.
On some projects, a systems analyst helps the team.
Often the tech lead (technical leader) performs these functions.
This specialist works deeply through the technical side of the task and can propose a fundamentally new approach to implementation.
What sets them apart from a business analyst and a project manager is this: a systems analyst has deeper technical knowledge and is focused on technical excellence more than on business tasks; a systems analyst does not hand work directly to developers and does not act as an intermediary between clients and the people doing the work.
In the quality paradigm, the project manager is responsible for the quality of task setup.
They don't have to know the technical details and don't need to be able to code.
Developers and project managers complement each other perfectly: each does what they do best.
Besides the project manager, other team members work alongside the developer and support him.
This is the team lead - the head of the working group; the tech lead, or systems analyst, who can work through the technical side of the task;
who will not only check code quality but also analyze why the task was set up incorrectly;
(often the same person as the project manager) who breaks the task down into the smallest subtasks and, when needed, helps the client draft the technical specification. Our company has five project managers, each running several projects. At the same time, every team lead heads just one team and works with a single project manager. As a result, team leads and developers don't spread themselves thin communicating with several project managers, yet still get the support they need.
