What Project Success Criteria Should You Use?

Traditionally, project performance measurement methods fall into two groups: economic and pragmatic. These are what we normally use as project success criteria. 

Economic measurement models are based on financial metrics and consider whether or not a project has achieved the expected financial value. Examples of economic measurement criteria are: 

• Return on Investment (ROI) 
• Return on Capital Employed (ROCE) 
• The Use of Balanced Scorecards​

The challenge with these metrics is that they are all retrospective. You can forecast what you predict the ROI for your project will be (in fact you should: this will help inform the business case). However, the true cost and the true return is going to be clear once the project is complete. In many cases, only several months after project completion. In complex projects operating in an environment with a fluid internal political landscape, things change fast. If ROI is a key measure you could potentially spend a lot of time recalculating your forecast in response to a fluctuating organizational environment. 

Pragmatic measurement models consider elements outside of economic returns. These look at whether or not a project has delivered against specified success criteria. If you are like me, these success criteria will be defined at the beginning of the project, and when the project is in the closure phrase, you'll pull them out from a forgotten file and look at them again-perhaps for the first time in months. That's what you use to compare what you thought you'd do against the actual achievements of the project. Again, this is not practical for complex projects that may have their requirements tweaked as they progress. Things change, especially on projects that are complex, or that run over a long period of time. 

Measures for projects' success 

You can use Post-Implementation Review (PIR) as the vehicle to measure the project against the success criteria. Here are some examples that you can use on your project:

• Earned value management metrics-worked out from the project tracking
• Number of submitted scope changes-worked out from the change management process
• Cumulative project slip-worked out from the project baselines and the information from your Seavus Project Viewer schedule or whatever project management scheduling tool you use
• Effort overruns-worked out from timesheets and statistics gathered about tasks
• Overtime worked-also from timesheets or payroll information
• Quality control statistics-worked out from your quality audit data and from control reports.​

I'm sure you can think of others.  

The downside of these metrics is that they tend to relate almost entirely to issues which have a negative effect on the lives of your project stakeholders and they are almost always yesterday's news. You can't do anything about schedule slippage or budget overruns at this point, not on this project, anyway. It's important to make sure that the learning from this project is carried over on to other projects. 

Including stakeholder satisfaction as a success criteria of a project  

I would strongly recommend including stakeholder satisfaction as one of the key success criteria, if not the most important one. After all, even if your project comes in on time and on budget, what's the point if the project customer (the main stakeholder) is unhappy and will moan about it all the time? That will reflect badly on you and the team.

The downside of measuring stakeholder satisfaction is that people often think that it's about how quickly we are answering their calls and whether we are taking action to mitigate your risks effectively. Internal customers expect that. They hire a project manager to do this stuff, so in my mind those type of customer satisfaction results don't count. 

Measurement of service quality in both project and operational environments is in limitation to the performance of processes that the customer has a right to expect as standard. No project sponsor begins the project expecting that the measures of time, cost and quality will be ignored (the classic triple constraint of project management) or that tolerance levels will be exceeded. There is the understanding that change could create a situation where time, cost and quality would need to be revisited. With hiring a competent project manager there is the expectation that these measures will be achieved. This is the hygiene factor for projects; the basic levels of service that project customers expect as standard from their project teams. We should not expect to get credit for what our internal customers take for granted. This isn't a success criteria-it's what we are paid to do. 

Summary

What is important is that stakeholders feel engagement and that you act on the result of their feedback promptly. You can include a stakeholder/customer satisfaction measure in your success criteria list that will cover off that feeling. 

Do you routinely gather stakeholder satisfaction data as part of your post-implementation review or success criteria? If not, why? If so, what feedback have you had from your stakeholders?