Assessment of a project manager's volume of work - what is a good methodology? [closed]

Question

Currently, my company utilizes agile as its development principal. I was approached by my boss to determine some methodology for determining the amount of work a project manger does on a given project in flight. To be honest, I can't really think of anything fool proof.

I guess the best question is how do we assess how busy, on a day to day basis, a project manager is?

Answer 1

Remember that ANY metrics you can come up with is most likely going to be gamed.

[ Do I get a badge for on-topic link to Joel On Software? :) ]

Having said that, you can try a union of the following approaches:

• Developer feedback!!! (e.g. a good PM's feedback would be "I had problems X, Y and Z and he made them disappear"). Not so good for measuring how "busy" a PM is but really good for measuring how effective he/she is.

• Volume and rated clarity of project plans (easily gamed)

• Rate of change of project plans (easily gamed)

• Amount of meetings/meeting time (easily gamed)

• Success rates of projects (on timeliness vs. % of features delivered vs. customer satisfaction). Not easily gamed but devil's own work to normalize this across projects.

Answer 2

Timesheets will measure the amount of work in one sense (you can see how their day breaks down and so on) but not I think in the sense you want.

Ultimately I don't believe there is a useful metric for Project Managers in this sense, but I don't think that's an issue.

I think ultimately you should measure project success rather than "busy-ness". After all, why do you care how busy the PM is if they deliver successful projects?

One PM may spend half a day putting together a risk log and mitigation plan which contains 20 risks, another may spend 2 days putting together one which only has 5 risks but none of those numbers are any more useful as a metric than lines of code. The key thing is not how long you spent doing it, how many risks you identified, how big your mitigation plans are, but whether you actually managed risk on the project successfully.

You're better off looking at what a Project Manager is meant to do, which is to deliver projects on-time, to budget and to customer satisfaction (which I'd use as the ultimate measure of quality rather than defects).

After all, do you measure how "busy" the CEO is? Or is he just judged on the profit the company makes?

To do this:

• Time - The only way it can really be gamed is by massively padding estimates and plans and this can be minimised by reviewing the plans and estimates and having all relevant parties agree them (developers, PM, client). The other side of this is that the PM must agree to the plan rather than have the implementation date foisted on him or her. You might want to measure this on either the overall implementation or each milestone.

• Budget - Measurable but gameble. For most development projects the key thing her is honest timesheets from the developers and the best way to ensure this is to make it so the PM is the PM but not their line manager. That way the developers have someone to fight their corner (a technical director for instance) if they're being pressured to fill in timesheets to keep the budget down. Again the PM should agree the budget, it's not reasonable to expect him to deliver on something he's told you is unreasonable.

• Customer satisfaction - Hard to measure so I'd suggest that you keep it simple and go with a straight forward post project review with the account manager and marks out of 10 for communication, delivery and whatever else is important. It is subjective but ultimately so is customer satisfaction.

But a lot of it depends on the company culture. For some organisations the key thing will be billable hours, others developer satisfaction will be part of the mix.

Answer 3

I am trying to understand WHY you have been asked to estimate the amount of work that a project manager does on a project. At best it is just a request for a rule of thumb, otherwise it indicates that your boss just don't know the first thing about running a project. Even when projects looks very similar there will always be something unique about a project:

• The team is not identical (teaching the new guy the ropes takes time)
• The spec might vary just a tiny bit (and that tiny bit might double the workload)
• Even the season might influence the outcome
• and so on and so forth

Each and every condition on the project might change the workload of the project manager, so it will always be a subjective assessment.