The software services industry has always treated project management as an important role, and this has led a stream of senior programmers getting themselves certified as PMP (Project Management Professionals) from the PMI (Project Management Institute). This improves their employment opportunities, etc. After all, in India, the implicit expectation of almost all engineers is that they grow into management roles — we have trouble appreciating the value which a hands-on individual contributor with 20 years of software design and development experience can bring.
A discussion recently erupted in one meeting in our office: what exactly is a Project Manager responsible for? Some said that he needs to ensure that the project is on time and within budget. Very good. But what exactly does he do to ensure this? Some said that what he needs to do is run daily standup calls and ensure that his developers are busy writing code. Is that sufficient? So, some others added client relationship management, project closure, and so on. It became clear that we are not quite clear about the exact role of a project manager. We who run projects for our daily bread understand the role implicitly. Not explicitly.
So the discussion continued, and we landed up with a believable definition of everything he needs to do. A Project Manager in our industry has three areas of oversight.
Tasks and people
The PM needs to monitor tasks and ensure that his team is healthy. This includes a work breakdown structure (WBS) which forms the burndown chart in the task tracking system, the sprint planning, the daily standups, etc, etc. These are well studied and understood — these are the methods, techniques, and buzzwords that the project management courses will teach you.
The task tracking part of the work is often emphasized at the expense of the people angle. The PM needs to track his team members as individuals every day, not to just see if they’ve done their tasks, but to see how they’re operating. Are they confused? Stressed? Struggling to deliver? Helping others? Being distracted by incompetent team members too frequently? The core of any project team is people, not tasks. Many PMs we meet are not good at maintaining connections with their teams. Sure, they’ll have strong connects with a few team members who they like, but not with the rest.
Functional scope
The PM needs to know the functional features the software is supposed to be building. He does not need to have each field of each screen by heart, but he certainly needs to know the flow of tasks for a business process, or whether a particular process is expected to generate one kind of report or three.
This clarity in the functional domain is critical to track if the client is asking for spec changes midway, or is contradicting his earlier specifications. Yes, a PM rarely works alone, he has a business analyst (or analysts) to take care of this, but he needs to be in touch with his BAs to ensure that all changes, deviations, or new ambiguities are brought to his notice. There is a big gap between “Oh, I don’t really track functional details, our BA is superb”, and “I need to know the string-length and syntax of each field of each screen.” The PM needs to be in an appropriate midway point between these two extremes, else he’ll never be able to react to scope-creep, or back up his BAs when the client pushes them to change the spec.
Engineering quality
In the area of engineering, we are often told that someone “is a PM, he is not technical”. The truth is that a good PM does not need to know how to write code, but he needs to know how to ensure that the code his team is writing is of good quality. Therefore, a PM needs to monitor engineering quality, or code quality, using two tools: (a) adherence to processes and standards, and (b) monitoring of defects.
Process adherence for instance includes ensuring that code reviews are happening and observations are being diligently noted and then fixed. If a PM is not paying attention to code reviews at the pre-decided frequency, code reviews tend to fade away, evaporate. Everyone is “too busy”, so unfortunately “for the last 10-12 days, we haven’t gotten around to doing the reviews.” The PM also needs to ensure that static code analysers are a part of the automated build process, and the outputs from those analysers are actually being acted upon. To ensure this, he needs to sit with his technical lead engineers periodically and ask to see the analyser reports. Then he needs to grill his engineers to hear from them what exactly they did for each problem reported. He does not need to know coding to validate whether the actions taken are technically correct, he needs to ensure that the analyser reports are not being ignored.
Defect monitoring is a bit more complex. At one level, defects are the bug reports filed by his testing team. There is nothing to monitor — the bugs need to be fixed, and then cleared by the testing team. But at another level, the PM needs to observe the patterns of bugs, the frequencies of bugs from various modules or from various layers (Are the front-end bugs too numerous? Why?) and then get some senior techies to drill down to see why trends are emerging. One common problem which a careful PM can often spot is that the same sub-systems keep reporting bugs, or a fixing of a bug triggers new bugs in code which was previously stable.
So, even if a PM is not a coder, he can do a lot to ensure engineering quality, to the point where he can surface issues which would have missed other eyes in the melee of a high pressure project.
Client relationship management
It is usually said that one key deliverable of a PM is to manage client relationships. This is true, but needs to be understood carefully, in context. (This is why I started by saying that a PM’s role has three pillars, not four.)
A PM needs to maintain good relationships with the client, but not just by being pleasant to the client. His relationship must be based on building credibility and trust. He must be willing to speak truth to power, and must protect his team from disturbing demands from the client. His natural role demands that he be in a healthy adversarial relationship with the client. He builds credibility by delivering what he promises, not by sweet-talking. If he does his job well, very strong relations are built, and clients begin to say that the only person they trust in the company is the PM assigned to their project.
Project management is not easy, and I somehow don’t think that this sort of first-principles clarity comes from the various certification courses we see.
Leave a Reply