Most project managers – and organizational leaders – will agree that there are really only a handful of true determiners of project success. You can state them several different ways, but it really comes down to four: On time delivery, on budget delivery, quality of the final solution, and customer satisfaction. And that last one is usually determined a lot by the project delivery team's success with the other three.
Learning lessons helps... but...
Is project success objective? Is it subjective? Is it quantifiable? Is it easy to pinpoint exactly where a failed or failing project went wrong? These are likely the types of questions that are going to come up on a project that didn't succeed if and when you conduct a lessons learned session post-mortum with the project customer. Lessons learned sessions are great – if you...the project manager... can stomach them – because you can learn a lot from everyone outside of yourself that had a stake in the project... all the key stakeholders. If you gather your delivery team, the customer sponsor and team, end users, subject matter experts and anyone else relevant to the project together at the end and sit down and discuss what went right and what went wrong on the project, you're likely to get some very good insight on what to keep doing and what to not do next time.
Unfortunately, not all projects end up having a lessons learned session for whatever reason... not part of the corporate PM methodology, no one had time as they were off to another project already or because the project failed miserably and it as avoided altogether. A few years ago I conducted a survey of several hundred project managers and team members and found that on 57% of projects (see #3 under the June 2010 survey on “Managing the Project”), lessons learned sessions were either never happening or only being conducted 10% of the time or less. That's a sad number because that is a lot of feedback that project managers and team members could be receiving but aren't and it could be used on the next project to help it succeed as well as the project just finished or avoid hitting the very same problems and issues that the last project just experienced.
So let's consider the questions I asked above...
Is project success objective or subjective? I'm going to go with subjective in most cases. Why? Because it's more of a perception than a hard measurable fact. At the end of the day, success or failure on a project is more about how you feel about how the project progressed and how the customer feels about it. Yes, there will be those projects that run way over budget – like a $250,000 project that hit $750,000 in actual costs with only $50,000 in change orders. That's not really a success, is it? And you can see numbers on that... it's fairly easy to say that one failed. But more times than not, it will be a perception. More subjective than objective. At least that has been my experience. The customer may have been uneasy due to failed communications during key points of the project or a bad user acceptance testing (UAT) experience that had to extend three times longer than expected due to bug fixes necessitated by poor quality in the delivery process.
Here's another example: If you reach the end of a project that had 12 deliverables and you only delivered 2 of them on time, then you'd be hard pressed to call that a successful project. Certain extenuating circumstances may have been the cause and the 10 late deliverables may have been the result of other vendor issues so sometimes those projects would be successes – especially if change orders were in place to cover the timeframe extensions. But, in most cases, this type of project would not be considered a success... correct?
Is project success quantifiable? In a way – and on some projects – the answer is yes. In the example of 10 late deliverables, that's quantifiable. In the example of $450,000 over budget after considering change orders, that's quantifiable. 10% budget overruns are usually going to be acceptable. 50% overruns are nearly impossible to correct. And – in my other example - when the project is over and you've gone over budget by $450k – which in this example means over by 1800% - you may actually be looking for a new project management job. Again, many times project success is neither quantifiable or very objective at all, but rather a perception... in many cases it just comes down to customer satisfaction.
Is it easy to pinpoint exactly where a failed or failing project went wrong? Probably not... Now, I'm a proponent of not only performing lessons learned sessions but actually performing several throughout the current project engagement. Why? Because learning lessons right away on a current project will help you either keep doing what's right and stay on the right path or possibly figure out something you are doing wrong and take corrective action now rather than end up with a failed project. If my project client is unhappy halfway through a project I want to know now, not at the end of the project when I can't fix anything and hopefully keep them as long term clients.
These in progress lessons learned are best scheduled into the project schedule as milestones and placed strategically at the time of, say, each major deliverable. That keeps the project on track and you can actually step back and look at the engagement more as a series of smaller projects focusing on each individual key deliverable... thus enabling you to use the lessons learned info to deliver even better on the next major deliverable on the CURRENT project. Win-win.
Summary / call for input and feedback
So, back to my original stance above... when you're trying to measure overall project success you can look at the key measuring sticks first. Was the project on budget? Was it on time? Was it a quality delivery – meaning did it match well with the requirements and scope and was it a usable solution when rolled out to the customer's end user community? And was the customer satisfied with the project and would they come back to you for a similar project? That last one – at least to me – is the real key and usually takes the other three into strong consideration. If the project is basically on budget, on time, and usable at the end of the day, the project customer will usually have a smile on their face.
Readers – do you agree? Do you consider this to be a fairly accurate depiction of real world project management success or failure? What is your experience or what would you change about this list? Please share your thoughts and discuss.
Learning lessons helps... but...
Is project success objective? Is it subjective? Is it quantifiable? Is it easy to pinpoint exactly where a failed or failing project went wrong? These are likely the types of questions that are going to come up on a project that didn't succeed if and when you conduct a lessons learned session post-mortum with the project customer. Lessons learned sessions are great – if you...the project manager... can stomach them – because you can learn a lot from everyone outside of yourself that had a stake in the project... all the key stakeholders. If you gather your delivery team, the customer sponsor and team, end users, subject matter experts and anyone else relevant to the project together at the end and sit down and discuss what went right and what went wrong on the project, you're likely to get some very good insight on what to keep doing and what to not do next time.
Unfortunately, not all projects end up having a lessons learned session for whatever reason... not part of the corporate PM methodology, no one had time as they were off to another project already or because the project failed miserably and it as avoided altogether. A few years ago I conducted a survey of several hundred project managers and team members and found that on 57% of projects (see #3 under the June 2010 survey on “Managing the Project”), lessons learned sessions were either never happening or only being conducted 10% of the time or less. That's a sad number because that is a lot of feedback that project managers and team members could be receiving but aren't and it could be used on the next project to help it succeed as well as the project just finished or avoid hitting the very same problems and issues that the last project just experienced.
So let's consider the questions I asked above...
Is project success objective or subjective? I'm going to go with subjective in most cases. Why? Because it's more of a perception than a hard measurable fact. At the end of the day, success or failure on a project is more about how you feel about how the project progressed and how the customer feels about it. Yes, there will be those projects that run way over budget – like a $250,000 project that hit $750,000 in actual costs with only $50,000 in change orders. That's not really a success, is it? And you can see numbers on that... it's fairly easy to say that one failed. But more times than not, it will be a perception. More subjective than objective. At least that has been my experience. The customer may have been uneasy due to failed communications during key points of the project or a bad user acceptance testing (UAT) experience that had to extend three times longer than expected due to bug fixes necessitated by poor quality in the delivery process.
Here's another example: If you reach the end of a project that had 12 deliverables and you only delivered 2 of them on time, then you'd be hard pressed to call that a successful project. Certain extenuating circumstances may have been the cause and the 10 late deliverables may have been the result of other vendor issues so sometimes those projects would be successes – especially if change orders were in place to cover the timeframe extensions. But, in most cases, this type of project would not be considered a success... correct?
Is project success quantifiable? In a way – and on some projects – the answer is yes. In the example of 10 late deliverables, that's quantifiable. In the example of $450,000 over budget after considering change orders, that's quantifiable. 10% budget overruns are usually going to be acceptable. 50% overruns are nearly impossible to correct. And – in my other example - when the project is over and you've gone over budget by $450k – which in this example means over by 1800% - you may actually be looking for a new project management job. Again, many times project success is neither quantifiable or very objective at all, but rather a perception... in many cases it just comes down to customer satisfaction.
Is it easy to pinpoint exactly where a failed or failing project went wrong? Probably not... Now, I'm a proponent of not only performing lessons learned sessions but actually performing several throughout the current project engagement. Why? Because learning lessons right away on a current project will help you either keep doing what's right and stay on the right path or possibly figure out something you are doing wrong and take corrective action now rather than end up with a failed project. If my project client is unhappy halfway through a project I want to know now, not at the end of the project when I can't fix anything and hopefully keep them as long term clients.
These in progress lessons learned are best scheduled into the project schedule as milestones and placed strategically at the time of, say, each major deliverable. That keeps the project on track and you can actually step back and look at the engagement more as a series of smaller projects focusing on each individual key deliverable... thus enabling you to use the lessons learned info to deliver even better on the next major deliverable on the CURRENT project. Win-win.
Summary / call for input and feedback
So, back to my original stance above... when you're trying to measure overall project success you can look at the key measuring sticks first. Was the project on budget? Was it on time? Was it a quality delivery – meaning did it match well with the requirements and scope and was it a usable solution when rolled out to the customer's end user community? And was the customer satisfied with the project and would they come back to you for a similar project? That last one – at least to me – is the real key and usually takes the other three into strong consideration. If the project is basically on budget, on time, and usable at the end of the day, the project customer will usually have a smile on their face.
Readers – do you agree? Do you consider this to be a fairly accurate depiction of real world project management success or failure? What is your experience or what would you change about this list? Please share your thoughts and discuss.
RSS Feed
