I do not know whether I am reinventing the wheel, but I have never come across the following reporting method.

I imagine that if I was to choose a single metric to report to upper management about a project, it would be the risk of the project not delivering something of the intended value, on time. I imagine that this metric could be used on something like a project webpage.

In the beginning of a project, I would, as as project manager, set it to a conservative 50%. The goal of the group is to to reduce the risk of failure. I imagine that on such a project page, there would be a deeper description of why it is set to its current value. This could be: Risk of misunderstanding between senior management and project manager, risk that a larger project in a different part of the organization will make this project obsolete, risk of not having the needed critical resources available throughout the project.

The reason why I believe that this is the single most important metric, is because it will quickly give senior management the one metric, which is important when deciding whether to use their capacities on the project, either by stopping it, redefining it, adding resources or something else.

Is this just old theory, or is it new?


The problem with this is that it lacks a formal definition of the actual value you will give.

If you have a clear partitioning of your project into tasks, together with a task planning, then you can use a derivative of the value at risk. It means that you ensure that "with confidence X% we will fulfill at least Y% of the planned tasks of the next period".

If you are interested, there is a nice entry for the value at risk on Wikipedia : http://en.wikipedia.org/wiki/Value_at_risk

| improve this answer | |

Here's the problem I have with this concept - as the PM your job is to reduce, mitigate, or eliminate the risks. You're supposed to come up with a plan that will ensure the success of the project before you even start it. The reporting metric and examples you've used avoid all of this and imply that there's only a 50% chance of success before you even start.

"risk of misunderstanding between senior mgmt and PM" - if this is a risk, then it needs to be addressed and resolved BEFORE you start the project. I'm really struggling with the idea that you would start a project with possible misunderstanding still being a stated 'risk'.

"risk that a larger project in a different part of the organization will make this project obsolete" - then there's either not a strong enough reason for this project, or someone's not paying attention to what's going on. Either way, it calls into question the value of the project before it even starts.

"risk of not having the needed critical resources available throughout the project" - again, this should be done and assured before the project starts.

I guess the real problem I have with this idea is this - all projects face one primary risk - the risk of failure. It's the job of the PM to navigate the project through that primary risk to success. But the way you're looking at it is you're setting up excuses for why it may not succeed, before it even starts.

Now it may be that I've misread it and these are just examples. If I have, you can disregard my responses to the specific items. The idea of risk management still holds though.

The other issue is the idea of a single metric for success. There is no ONE metric that is most important. Mgmt will want to know if it's on schedule, on budget, and providing the expected outcome with the defined qualities.

| improve this answer | |
  • 1
    actually the PMs job is to manage risk, sometimes that means accepting it. Unless it's a very short timeline, throughout the project it is a good idea to run periodic risk identification sessions to because things change and new risks will show up and current risks will disappear. – Perry Wilson Jun 2 '11 at 16:56
  • Agreed. Not including acceptance was a miss on my part. Thanks for catching that. My bigger concern was the idea of 'probability of success' being the primary reporting metric, and having that be only 50% at the start due to 'potential' risks. – Trevor K. Nelson Jun 2 '11 at 17:18

All good answers, but I think the main flaw is trying to report one metric. Only providing this one dimension is dangerous because it can look like you are hiding something when issues arise. Keeping it too simple for the executive view isn't providing them with what they want to know.

My advice is to try to make a dashboard that can be reviewed quickly. For example, use the traffic light mode for status and then a one or two point about issues that are currently happening or recently resolves and risks that are emerging.

| improve this answer | |

It sounds like you may be trying to reinvent Earned Value Management.

EVM can provide meaningful metrics on the overall value of the work performed, encapsulated into one or more numbers.

| improve this answer | |

Your Answer

