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?

Lui

Do you currently have a methodology to assess how busy a programmer is? – Iolaiolande

Burn down and LOE averages are the only real metrics we've got for devs, but being a dev myself, I think they work well. – Lui

That's a metric which quantifies the programmer's deliverables, not a metric for how "busy" he is (i.e. for what percentage of his time is occupied). – Iolaiolande

Can I ask why you want to measure this? – Riva

@Lui - it is considered a good form on StakOverflow to pick the most helpful answer and choose it as "Accepted" answer. Cheers :) – Wycoff

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.

Wycoff

You deserve at least a comment, for linking to an "ancient trifle" that's "well-paft its expiration date". – Iolaiolande

Both the article and the Robert D. Austin book are as relevant today as the day as the day they were written. – Whisenhunt

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.

Riva

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.

Triturable

I'm not the original poster, but if I had to guess as to why he wanted to measure the amount of work of a project manager would be to allow for full utilization of said manager. Most project managers have multiple projects under their control at any given time. His company probably wants to know how many that should be: one? two? three? more? – Floribunda

Answer 4

I would suggest you use the same Burn Down and Level of Effort that you use for the developers. A PM's task in an Agile environment is a bit different (and from shop to shop it's different), but the PM should be able to provide a list of tasks, etc. I'm thinking positive and seeing it as your bosses approach to determining how much availability the PM has.

Belted

Answer 5

Most project managers equate responsibility with status, so a project manager who has spare capacity is quite likely to volunteer to take on a new responsibility, because it's in his/her own best interest. In all but the most functional organizations it's often better to be visibly overloaded, for that heroic look.

It's more likely to be in the organization's best interest to slightly under load its project managers, so that there is some spare capacity available should something start to go wrong. A project manager might well choose to apply his/her spare capacity in some constructive way in any case. Excessive politicking or other unconstructive activity is a good indicator of someone who could be more constructively deployed. Even on agile projects, workload tends to be uneven across a project cycle - e.g. delivery is often a management-intensive activity - somebody who is continuously heavily loaded probably has too much to do, and may be ignoring or hiding a serious problem.

If the next level of management conducts regular project reviews, pays attention to how many problems are being escalated, whether the project reports correlate with the news from the grapevine, and does some basic estimation on workload projections for each project manager, then the organization should be able to run a reasonably efficient system.

Managers tend to be political and psychological animals. Any methodology that doesn't take that into account is ignoring reality, so a good methodology for this problem is likely to be based more on observed behaviors than on hard numbers.

Whisenhunt

Answer 6

Excuse me if I am being to purist, but the tag and the question calls for Agile. What would be a project manager in Agile? You might either be trying to asses the work being done by a product owner or a scrum master?

In any case, both roles perform several tasks that are hard to measure, so probably your boss is looking at the wrong picture.

For instance, a scrum master is "The person responsible for supporting the development team, clearing organizational roadblocks, and keeping the agile process consistent". Basically is a coach and a facilitator. Blocking disruptive requests or distractions created by higher levels of management by negotiation or persuasion to follow scrum practices is one of the skills commonly used by scrum masters. Several of these soft skills are hard to measure as "work" since they do not involve working on a computer or producing a report.

I think a the metric that your boss would benefit most from is more related on how effective the team is and how a scrum master is described to facilitate the work of his team-mates. DVK then has a very valid point, the metrics you create can be "gamed", so it is best to trust that your managers are busy if your projects are progressing and your teams are happy and work as a team.

Asia