Let us examine first what is wrong with Project Management. For brevity sake, we will only list a few points:
- Gantt Charts presume an organization form that doesn't work in practice
- Role Separation which presumably increases productivity when all it does is add waste
- Perverse incentives, such as rewarding testers for finding defects rather than stopping the root cause
- Watermelon Reporting, e.g. "we know we're Red, but report Green because that's what management expects"
In short, Project Managers spend a lot of time setting up a highly wasteful structure and then deceive themselves and the organization that they're doing the right thing.
The BadAgain, for brevity sake, let us examine briefly what causes the underlying problems in Project Management:
- The Plan: A project Manager gets paid to make and follow a plan. However, there is always some stuff you can't plan: The elements subject to exploration and/or unpredictable change.
- Complexity: People who fail to make the perfect plan aren't imbeciles, because the world is too complex, with a notion of unpredictability sprinkled in: Planning is good, flexibility is better.
- Detail: Project Manager must work on a certain level of abstraction. Unfortunately, "the devil is in the detail" - i.e. the tricky part can often only be decided by people who are lower in the hierarchy: Only by delegating critical decision authority into the team can a PM succeed.
As such, the PM role is inherently broken.
The GoodProject Managers do actually bring some skills to the table that are always needed to be successful in an organization. These are:
- - Organizing: Discipline and doing the right thing at the right time are important for success. Nobody has as much experience in organizaing stuff as the PM. Agile teams find a good organizer very helpful - as long as they don't organize things nobody asked for!
- - Breaking down work: Both backlog refinement and Sprint Planning are work breakdown activities - one on a strategic, the other on a tactical level. Poor work breakdown will result in missed goals and frustrated teams and customers. The only question remaining: How do you do it appropriately?
- - Creating transparency: Status reports are only one way to create transparency. However, the PM is used to creating an appropriate level of transparency. Once they rise beyond the non-valuable metrics, the PM will be very useful to help the team be better understood in the organization.
Whether the organization needs a PM or not - is not a question based on the role of the PM. The PM's skills are needed, while the activity a PM did do in the past are not. A PM may add value to the organization in the roles of Product Owner, Scrum Master / Agile coach or team member. However, the PM must unlearn certain prejudices, notices and abandon practices to rise into their new role. Likewise, they must learn agile practices and adopt a new mindset. A PM who is ready to leave their former title and old behaviours behind will be very valuable to an agile organizations.