In the quest for efficient resourcing and cost cut-down, I noticed the same question getting repeated over and over again:
“Why do we need a Project Manager for an Agile project?”
In a functional Agile environment, the team is or should be, empowered to deliver, to decide how to implement the features. Agile ensures issues are addressed, blockers are removed, the risk of requirements is reduced, and scope can be shifted according to the business needs.
Is this all that’s needed to deliver success?
As trusted suppliers, we share similar goals with our clients: delivering efficiently, maximising the business value and creating a strategic, long-term partnership. Agile works very well at a tactical level, however, when it comes to aligning strategy and direction with day-to-day delivery, other roles need to step in.
The client organizations are usually large, with complex hierarchy and stakeholders with different, sometimes conflicting interests. Information gets exchanged, and sometimes lost on the way, risks which are not necessarily delivery-related can appear and will need to be owned and mitigated. In complex environments, with multiple teams working on the same feature-set or with mixed horizontal and vertical teams, aligning the work and making sure waste is minimized and delivery is efficient requires even more effort, not to mention cross-team dependencies, risks that go beyond each project’s boundary and again communication. Someone needs to step in at project level, someone able to understand the context and navigate the complex conditions, with good communication and influencing skills and with the main focus to keep everything balanced: the client, the team, the project margin and the business value for the client.
So, why can’t the team do this?
The main focus of the team is delivering, right? For this, they need to constantly ensure their work is clear, predictable and high-quality. This requires juggling a lot of details and maintaining a structured approach on the commitment. They also need to ensure the technical decisions are sustainable and aligned with any practices and processes the client might have. Adding strategical, project or account level goals on top of this is too much to handle. Moving these entirely to a senior management role is also not entirely feasible, sometimes due to the amount of information that needs to be managed and also due to the level of exposure to details.
On top of that, other aspects necessary for delivery such as; resource allocation, billability, team morale, balancing the structure of the team to keep the right mix of skills, keeping an eye on the margin at the same time, following up on opportunities, and internal risks, etc. Expecting the team or team/technical lead to juggling all this would be an inefficient use of their skills and time.
I was once working as a PM on a project as part of a major account: 200+ people in delivery. At some point, the decision was taken to remove all local management, in order to maximise the development capacity. It was considered that those expenses will be allocated to additional development and will help the teams deliver faster and meet an aggressive timeline to get in front of the competition in a year or so. The teams were already working together for more than a year, they knew the product and the dependencies and had a fair amount of business knowledge. Why keep the PMs?
Seemed like a common sense decision at that point, until disaster stroke. With no one to act as a barrier and communication facilitator between the client and the teams, the pressure on delivery got too high. People started leaving the project; team morale dropped, no one was pushing back consistently on unclear or unfair demands and deadlines or excessive scope change. Some of this responsibility passed naturally to the team leads and scrum masters, who got overwhelmed by the added communication and the overhead of managing risks they hadn’t been exposed to previously and significantly dropped their involvement in delivery and in coordinating the technical decisions vital to progress. Dependencies started to slip, as there was no longer an active eye on aligning the plans and prioritizing the work across the streams. Delivery slowed down due to blockers piling up, etc., etc. You get the picture.
The story has a happy ending, though, as the initial decision was reconsidered and things slowly got back on track, with the somewhat painful realization that having Project Managers who seem to have little to nothing to do is actually a good indication of success.