Firstly, let me admit that I have never actually been a project manager. Coder, Architect, Team leader, bid team member, line manager, or some unholy combination of the above - yes. PM, no. But I'm going to claim that working quite closely with PM's in some of these various roles at least gives me an informed outsider's perspective. Feel free to disagree, but I will opine regardless 🙂.
The Agile angle here comes most directly from the Scrum guide. What does the Scrum guide mean when it says :
Scrum wraps around existing practices or renders them unnecessary. Scrum makes visible the relative efficacy of current management, environment, and work techniques, so that improvements can be made.
Is this an invitation to discard traditional Project Management ?
To start with, I'll just note a few observations. There are various canonical references for the duties and responsibilities of PM's, but I'm not going to dig into that, I'm not trying here to write a blog on 'How to be a PRINCE2 PM'.
Any business that's going to survive manages it's costs. Of course, there are variations on a theme when it comes to how exactly that is done from an accounting / budgeting perspective, but the key word here is 'manages'.
Management doesn't just happen, someone has to do it. It's an active process, not simply setting up a few spreadsheets, writing a Project Plan, and waiting for it all to work. In the case of the resources ( people, money, time, etc ) associated with a project, the person primarily concerned with this management is the PM.
In this context, 'management' is really a complex optimisation problem - the business wants to use as little resource as it can, whatever that resource is, and it wants to deliver product that it can make a profit from. The PM, together with other stakeholders, must make decisions ( frequently tradeoff's of one sort or another ) to help ensure that this is so.
One successful PM once confided in me that he didn't actually care all that much how long someone was going to take to deliver something, as long as they had actually done it by the time that period had expired.
The point he was making was that the bane of a PM's life, the thing that made PM a difficult problem, was not things that just took a long time ( that was a pain, but could be managed ), it was things that were not delivered on time. Being able to have confidence in an estimate was more valuable than reducing the effort by a few days.
What this led to was the realisation that a key part of the PM's role, at least for this PM, was simply to hold people accountable for their predictions. In this view, an 'estimate' was certainly being treated as a commitment, albeit in the sense of 'less than or equal to'.
Frequently the PM is the individual who represents the project as a whole ( not the Product - see below ) to senior management. This is both a technical skill ( involving an understanding of the business's budgeting and planning methods ), and a political one ( managing stakeholder expectations and reconciling the priorities of different stakeholders ). Having just one of these skills gives you half a PM. That's rarely what's needed.
This is a critical thing to note - the PM does not ( usually ) own the Product. This means a number of things.
The PM cannot prevent the product from changing, nor can they demand changes to the product.
What they can do is evaluate the resource impact ( or impacts - there may be several options ) of a change, which will often translate into a cost to some stakeholder(s). This evaluation can inform decisions taken by the stakeholders regarding future development.
Note that 'change to the product' includes the scenario where features are dropped to meet delivery deadlines - the PM does not take this decision. Usually they are expected to move heaven and earth to avoid this scenario, but regardless they do not own the product - if there is a tradeoff between feature complete and deadline met, this decision belongs to the product owner.
One interesting thing ( at least to me ) that I've noticed is that successful PM's are very rarely in firefighting mode. They are, for the most part, very calm people. What do I mean by 'firefighting mode' ? Essentially, I mean a situation in which normal working patterns are suspended in order to focus effort on an unexpected problem.
The ability of PM's to avoid these situations obviously depends on their personalities as well as management principles, but the common factor that I think I see is that these PM's have a crystal clear understanding of the roles and responsibilities of all the various teams and individuals in the project.
If the firefighting problem can be cast in terms of identifying the parties who need to act, and enabling them to do so, then this clear understanding of R+R combined with clear accountability can make the difference between 'panic stations' and 'management'.
What does all of this mean when thinking about PM in an Agile environment ?
It's very interesting to look at the structure of Scrum, because it directly touches on several of the things discussed above - clear roles and responsibilities, clear accountability, estimates, commitments, and reliable delivery of value.
However there are things that Scrum - in the sense of 'the Scrum Framework' - does not specify.
Since resource management and long(er) range planning are normally key PM functions, I think it's fair to say that the mere fact of 'doing Scrum' cannot be seen as a justification for dispensing with the role of PM.
However, saying that there is a role is not the same as saying that there is a unique individual associated with it. What this question usually boils down to is whether the Product Owner, in addition to the responsibilities as per Scrum, should also assume responsibility for resource management and long range planning, and hence in effect become the PM ?
Superficially, this may appear attractive. Who could be better placed to make decisions about resources and longer term plans than the Product Owner, who has all the information about the product at her fingertips ?
Well, if there is only the one Product Owner, dealing with one or two Scrum teams, and the number of external stakeholders is small, then maybe this approach stands a chance of working. Which is not to say that a sane Product Owner will be happy about it. Wearing two hats always cranks up the stress, and a stressed Product Owner is pretty much guaranteed to be a less effective Product Owner.
In more complex environments, with several Product Owners and multiple teams, this approach is just infeasible. I've also experienced an environment in which Product Owners were simply expected to act together, in the spirit of self-organisation, to resolve any resourcing and planning issues. Certainly, with multiple PO's, tradeoffs and agreements are required for resource and planning purposes. But the 'PO committee' approach risks having all the problems you might expect from a committee - tradeoffs and agreements become politics, and accountability is lost in the melee.
I'm strongly inclined to say that Agile development in general still benefits from having a singular PM, whose responsibilities are still closely aligned with those of PM's in non-Agile environments.
This PM is :
© Mark de Roussier 2022, all rights reserved.