What do PM’s actually do?

Replace “physicist” with “project manager” in the following exchange from the 1988 movie “Young Einstein”: does this pretty much sum up most people’s impression of the PM role?

 “Dad, I want to be a physicist project manager”

“What do they grow son?”

“They don’t grow anything”

“Well what’s the use of them then?”

We live in a knowledge economy where the old ways of working no longer create a competitive advantage. Imposing unrealistic tasks and quotas from above means that effort is wasted or, at best, misdirected, resulting in crappy, rather than snappy, products. Read the literature and you will find that, time and again, the self-directing, autonomous team is the only kind that produces results with the capacity to delight customers. Your people know what they are doing so you should leave them alone to figure out the best course of action in response to a particular set of requirements. You can tell people what to do but you can’t tell them what to think. But if micromanagement and detailed plan setting are taken away, is there actually anything left for the project manager to do other than make the tea and colour in the status reports? At first glance, in this brave new world it would seem that there isn’t.

However, as Stephen Denning writes in the Leader’s Guide to Radical Management, referring to the start of the Agile movement (Jeff Sutherland et al) in the early 90s:

“The role of management was not to manipulate the people doing the work; it was to set direction, eliminate anything that was preventing the team from performing at an extraordinary level, and then get out of the way”

Certain roles, such as the “solution developer” (ie the person who actually creates the new system or builds the house extension) will always be required, whichever methodology is adopted (notwithstanding the fact that the name is likely to vary depending on the type of work undertaken). But this role alone isn’t enough to get the job done. In IT-enabled business change projects, for example, the temptation is to build a team of techies who create the new system with no more than a nodding acquaintance to how the system is going to be used. This is not good. If people don’t use the product that you create, you can forget those attractive status reports – your project has failed. So, is a redesign of the way the business works with the new product a responsibility that the project manager can assimilate? Unfortunately not. The person with the requisite skills, and indeed remit, to build this new business process is actually the business analyst, or what I like to call the “business developer”; the solution developer creates the code and the business developer creates the process to use the code.

A new role?

So should the PM hang up his Gantt chat and call it a day? Thankfully (for project managers at least), I would suggest not. Take, for example, the three threads of an “Atern” agile project: i) business, ii) solution, and iii) management. We have considered the first two already, which just leaves the area of management, which I will take to mean looking after the project process. In my view, this is the primary (and perhaps only) responsibility of the project manager, as if we consider her job to be that of the “management (or process) developer”, owning the project process, this leads to the following responsibilities:

• Management of risks and issues (the process is breaking);
• Protecting the team from unreasonable interference (the process is interrupted);
• Installation of a retrospectives process each iteration (the process could be better);
• Motivating and training the team (process optimisation).

Not only does this thinking lead to a clear demarcation of duties (where the project manager is less likely to meddle in the actual doing), but it also leads to a much less stressful life for the project manager who until this point has taken on her shoulders full responsibility for all of the ills and travails of the endeavour. Under the new regime, If the code isn’t working then it’s up to the solution developer and tester to fix it; if the proposed invoicing procedure doesn’t work for everyone then it’s up to the business analyst (with the business representative) to come up with alternatives. All the project manager has to do is ensure the project process is running smoothly and efficiently.

And think of the beautiful status reports that could be produced with all this extra time (if only anyone ever looked at them, but that’s for a future post)….

HOME