Friday, December 2, 2011

Capturing project success

Project success is something hard to capture. One person can find a project successful while another person finds it a failure. A project could be on time, on budget and on scope (so it was a success) but in the end the organization didn't use it (so it was a failure). Or maybe the final costs were hugely over budget (so it was a failure) but 10 years after the return on investment was huge as well (so it was a success). Or maybe although it was late (and so a failure) everyone that uses its results is very happy about it (and so it was a success). The combinations seem endless... So how do you capture project success?

Putting success in context
Project Management has 3 dimensions to it (please check "Stress Free Project Managers" for some more detail on this):
  • Deliverables: and their cost, the time it took to deliver them, their scope and quality
  • People: how happy were your stakeholders with what you delivered? How happy were they with you? How motivated was your team? How well did you negotiate the resources?
  • Organizations: did they use the project's deliverables? Did they add business value to the organization?
These names for the dimensions may not be the best ones but they have a great virtue: it's hard to mistaken them. That is, if you think about time, budget and scope you are definitely on the "deliverables" dimension; and if you think about the organization use of the project's outcome you are definitely on the "organizations" dimension.

So you get metrics
It seems that finding metrics for each of these dimensions would do the job and allow you to have a global measure of project success. But this is now all that linear: if you think so, then the Sydney Opera House must be considered a failure (in short, it was delivered 10 years late and 15 times over budget but check Wkipedia for more details) - but somehow this doesn't seem right, does it? Sometimes, and in particular in big, lengthy or breakthrough projects, you have to add a time dimension because what you measure when the project is just finished is different in 2 or 5 years.
I also have to add that sometime ago, on the Beginners Guide to Project Management, I stated that "you’re a successful Project Manager if your main stakeholders are happy with your project and its outputs". This definition of project success has all the 3 dimensions included:
  • Main stakeholders - people dimension
  • Project - deliverables dimension
  • Outputs (in the sense of something new available in the organization) - organizations dimension
Bottom line is you need metrics on each of these dimensions to capture a project success. Any other way will be either perspective dependent, too narrow or just subjective.

There's not one recipe for project success
If you include all the metrics necessary to capture these 4 dimensions you probably end up with so much stuff to measure that any small or medium project will have its costs and schedule increased significantly just so you can measure what you need. On the other hand, if you ignore the time dimension you have to consider the Sydney Opera House a failure. This looks like a trap...
The best way out of this is to have different sets of metrics for different types of projects. It does seem reasonable to me if you think of highly dynamic projects such as marketing projects and very predictable ones such as construction projects (at least in general terms). If the projects in your organization vary mainly in size and degree of expected change, why not capture that in your metrics? Small projects with little expected change would have a set of metrics, small projects with many expected changes would have another set, big projects with many expected changes would have yet another set of metrics and so on.
What do you lose? Mainly the ability to compare projects in different categories. But then again, comparing a marketing project to a construction project will not be all that useful. It looks to me that what you lose is largely compensated. But then again, this is just my own experience and I'd really appreciate if you could provide a different perspective.

What about baselines?
In principle, you can only get good metrics if you use the last baseline for comparison. If the scope changed so much from the beginning of the project to what was actual delivered, it doesn't make much sense to compare your actual figures at the end of the project with the ones in your initial plan. But... if you rebaseline your project just before closing it, all your metrics will probably look very, very good. The only way out is to allow a new baseline on any given project only when things change so much that no one can raise the question "why a new baseline?".

Project success in 4 steps
In short, to capture success, all you have to do is:
  1. Determine what types of projects are done in your organization.
  2. Build simple rules to determine which projects go into which category (budget amount, length, risk exposure, complexity,...)
  3. Get metrics for the 3 (or 4) dimensions for each category of projects in your organization.
  4. Provide for whatever is needed to get these metrics (what data, in what format, where,...)
And now you can say if a project is a success and, better yet, how much of a success it was! It may seem easy when put this way but... why don't you try it for real?

Pictures taken from

Posted by

No comments: