Throughout my career I’ve worked with various types of PMs (Project Managers) and I too have managed many projects over the years. I’ve often pondered about whether PMs do indeed add value to projects or not. The simple answer is that I think PMs can indeed indeed add value to a project, but in my experience 90% of the time they just simply don’t. If anything they probably make the project go slower and bring about unnecessary complexity. Having said that, I don’t believe it’s any fault of their own. Personally I think this is caused by upper management assigning the project managers for the wrong reasons or there are other corporate politics in play that prevent PMs from adding value to projects.

So let’s start with a list of very wrong but very common reasons why a PM gets assigned to a project and how they end up adding little to no value:

• Promoting the weakest link: Suppose there’s a guy on a software team called John and suppose that John has limited technical skills. This could be because he doesn’t have any talent for coding, or he’s lazy, or he isn’t analytical enough, or he writes horrible code, or maybe he simply doesn’t care enough about the company or project. When it comes to employees like John, upper management will have tried to place him in various roles in the hope that there’s something that he’s good. Unfortunately, John cannot code to save his life, and when given the opportunity to code, he creates more problems than solutions. They’ve tried putting John into an analyst role to gather and document requirements, but because of his limited technical skills he cannot translate functional requirements into technical requirements. Worse yet he doesn’t have any eye for detail, and misses a lot of important information when relaying information between the customer and the development team, which in turn can cause havoc on a project. They’ve tried putting him in a support role, but he ends up escalating almost all the issues to the developers without ever learning anything in the process. As ugly as it may sound the bottom line is that John is pretty much useless. So, what do you do with a guy like that when you’ve tried everything to increase his technical skills and the only thing that he seems to be half decent at is talking to people. Well, what often happens is that upper management will assign him as a PM on the next project. Their reasoning is that in their minds, project management is only about managing the customer, so John will definitely not be able to screw it up. Even if John does screw it up, project management can cause the least amount of collateral damage i.e. the developers will continue with their development and the project can still be a success.
• Maximising billable hours: In software consulting companies it’s all about resources (people) and time. The more hours the company bills the more money it makes. Suppose you have two developers on a project and they communicate with the customers directly: any time spent attending meetings, phone calls and emails is often ignored i.e. it’s a loss to the company. Even if that time is actually billed for, you’ll only have those two people billing time. Therefore what many software companies do is to add as many people on the project as possible i.e. instead of having only having two resources on a project let’s add a PM into the mix so that he too can bill hours for attending meetings and drawing Gantt charts. This is the oldest trick in the book by any company that makes money through selling services. Lawyers often apply the same tactics: instead of getting one lawyer that can do everything, they will tell you that one lawyer specialises in one side of the law while another will specialises in something else, and you’ll need another to take notes, another to do research, and another to supervise the whole circus. In the software industry, it often happens that a PM gets assigned purely to increase the amount of billable hours instead of to actually manage the project.
• Specialised project managers: many software companies hire PMs that have some sort of formal project management course under their belt and they assign these people purely into PM roles without any technical responsibility i.e. they’ll never do any analysis, design, development, or support work etc. The problem with this approach is that these PMs have no technical skills or engineering experience whatsoever. So if they ask developers for time estimates, they will take whatever the developer tells them because they don’t have any hands on experience to tell right from wrong. Worse yet, they might not even ask for estimates from the developers, and instead simply thumb suck the schedules and timelines. When deadlines are not met being met, the PM passes the buck by blaming the developers. Furthermore, when the developers try to explain a technical issue they’re struggling with, the PM cannot articulate those issues to the customer.
• Glorified secretaries as project managers: many software companies are run by non-technical business people. For this reason, these business people often do not understand the work that the developers do, nor can they measure their developers’ progress. They’re often also not interested in the technical details regarding issues the developers are facing. What the business people do understand though are numbers. So what they often do is assign a PM for the simple purpose of capturing, keeping track and reporting back on costs and timelines throughout the project. At the same time, the PM is given limited authority. So when it comes to the technical staff not performing, missing deadlines and dealing with unhappy customers, this PM has virtually no power to do anything about it i.e. they might have the word “manager” in their job title but none of the technical staff report to them. In cases like this the PM is in fact nothing more than a glorified secretary that schedules weekly meetings to ask for progress updates, accepting anything the developers say without questioning anything. Thereafter the PM will update the Gantt chart and spreadsheets and forward them to the real manager who is not even involved in the project. This is a recipe for disaster because these kind of PMs end up being nothing more than shock absorbers for the developers thereby fostering  laziness i.e. the developers never have to face a screaming customer because their glorified secretary of a PM will take the hit, while at the same time the PM is not able reprimand them for non-performance.

For all the above reasons I believe that PMs add little to no value in most cases. However, I do believe that PMs can indeed add an incredible amount value under different circumstances.

Here are a few very good reasons for assigning a PM on a project and some strategies for maximising the value that they can add:

• Reduce communication channels: the most important reason for assigning a PM to a project is reduce the number of communication channels between stakeholders. This really comes down to Fred Brooks’ famous quote, “What one programmer can do in one month, two programmers can do in two months.” The simple logic behind this statement is that the more people you add on a project the more these people spend talking instead of working. If you only have a single person on a project, then this person has no one else to talk to and therefore spends all their time working. If you have two people, they will spend a considerable amount of time talking to each other and consequently establish a single communication channel amongst themselves. Having three people means you have three communication channels between them. Having four people results in six communication channels. Hence, increasing the amount of people on a project increases the communication channels exponentially, which in turn reduces productivity. This is rule is known as Combinatorial Explosion and the formula for determining the number of communication channels is as follows: l = n(n -1) / 2 where n is the number of people on the project and l is the number of communication channels. Using the formula we can calculate the number of communication channels on a team of 10 people to be 45 i.e. 10(10 -1) / 2 = (10 x 9) / 2. As you might expect, in such a team, the 10 people will spend all their time talking instead of working. This being the reason why so many corporate environments have endless meetings without ever getting anything done. Smaller companies on the other hand tend to be a lot quicker and more productive. It’s in cases like these that PMs can be added to reduce the communication channels. By adding a PM in the centre of a 10 people team it will reduce the communication channels from 45 to 10 i.e. instead of each team member talking to every other team member, the communication becomes centralised by them talking only to a single PM.
• Assign a PM with strong technical skills: adding a PM to reduce the communication channels is all good and great, but it will prove to be futile if the PM has insufficient technical skills to hold a discussion with the developers. For this reason it’s important to ensure that a PM has a strong technical background as well as people skills to communicate not only with the developers but also to manage the customers and/or business people. The result of having a weak project manager is that the developers will simply resort to sidestepping the PM by talking directly to the customer as well as manage the project amongst themselves. Evidently this defeats the object of assigning a PM in the first place.
• Increase the PM’s authority: If a PM is going be assigned to a project, the PM then needs to be given absolute authority over the project. Even if some team members do not directly report to the PM within the company, within the context of the project, they should be reporting to the PM. Higher level management should explicitly make it clear to the team that they report to the PM and failure to do so comes with consequences.
• Do one project at a time: Even if absolute authority is given to the PM on a given project, the developers for example may be working on multiple projects at a time reporting to multiple PMs simultaneously. The problem with this scenario is that the developers can use one project as an excuse for non-performance on another project. For example, a developer could say to PM 1 that they haven’t made any progress on project A because they’ve been busy on project B. They could then turn around and tell PM 2 that they haven’t made any progress on project B because they’ve been busy on project A. Meanwhile back at ranch, the developer hasn’t made any progress on either of the two projects, but the two PMs will be none the wiser. Amongst many other pitfalls of running concurrent projects is that it undermines the PMs’ authority thereby enabling the developers to run amok.
• Global authority: In many companies it’s simply not possible to run a single project at a time. This could be for financial reasons where customers cannot be held off for several months in waiting for resource availability. In such cases, it’s best to assign a single PM to manage all concurrent projects, thereby granting the PM complete authority across all projects. The goal being that a single developer should report to more than one project manager at any given time. By doing so the developers will never be able to deceive the PM by using one project as an excuse for non-performance on another project.