I’ve been a bit hard criticising project managers—or project management as a discipline—especially harping on the fact that 70 to 80 per cent of project-managed projects fail—the larger the project, the higher the probability of failure. And ditto for PMs with more experience. This is intentionally polemic.
To be fair, I’ve been a professional statistician. And just like being a professional musician, I can’t just dismiss my past and say that I was a statistician or musician. These things tend to stay with you. I just don’t get paid for these things anymore.
My colleague of almost a decade pointed out to me that he has project-managed many successful projects. Off-hand, I suggested that he may have been among the 20 per cent of successes. Even Lotto with odds of 1 in 72,000,000 has winners. But that’s beside the point.
The bigger story here is the old reminder that correlation is not causation. That more experienced PMs fail at higher rates is likely a covariance to the fact that an experienced PM is more likely to be tasked on larger projects. And larger projects fail at higher rates owing to complexity, which scales geometrically rather than linearly.
As this has been written about time and again, I am not going to regurgitate details on why these larger projects fail. The usual suspects relate to hubris, unrealistic expectations, illusions of control, and outright bad faith. Incompetence and organisational impediments are also likely culprits.
This does not alter the perspective that there is no role for PMs in Agile. I’ve discussed this previously. In summary, a PM violates the concept of a self-organising team. If documentation and progress is a goal, a project would be better served with a scribe to document and perform administrative and reporting tasks, but planning and control would not be part of the role description.
The question of whether to use a project manager on a project depends on the nature of the project and the delivery approach. Project management is not appropriate for open-ended, creative, or experimental projects. On one hand, project management provides regimentation to a project, and it can keep resources on point; on the other hand, this comes at a cost, and a project administrator may be a better option. Consider costs and benefits of the function.
Also consider the intrusion of project management on resources. Similar to anthropology, this person can as soon disrupt a process than facilitate it. If this person is not self-sufficient, s/he is likely to burden otherwise productive resources with administrivia that creates task-switching and slows velocity. There is nothing inherently wrong with this. It’s like taking time to fasten your seat belt and adjusting your mirrors before embarking on a journey. But, let’s just say that I’ve been engaged on projects where the project manager exhibits borderline obsessive compulsive behaviour that may add 30 or 40 per cent more overhead to a project.
There are two more topics I’d like to address: value and adoption. The project manager is not ultimately responsible for the value of a delivered project. Generally, someone else has specified and design the project, and the PM just needs to deliver it. Where the PM becomes culpable is if they decide to descope features in order to hit a promised deadline. Deadlines are almost always arbitrarily determined, so the moving the deadline is typically the better option. Even so, this would count as a failed project. Descoping counts as a failed project, too, so the project manager needs to ensure both remain as originally promised.
Value ultimately hinges on adoption, whether by customers or users. If no one—or not enough—people use or consume the final project, commensurate value is realised. So whilst the value proposition of a project is not generated by a project manager, descoping feature functionality may neuter the value of a project. In some cases, speed to market is critical to the adoption of a project’s output, so excessive bureaucracy can serve to be late to market or on time without the critical mass of features. Of course, there are ancillary factors that come to mind for commercial projects that are out of the scope of control for a project manager, so in some ways a project manager can deflect responsibility on meta factors around a project, but then again we return to the question of the purpose of the project manager.