It used to be that project success was based on one or more of three key project success determiners: on budget delivery, on-time delivery, and customer satisfaction (and sometimes quality, but that also factors into customer satisfaction).
What we are – and should be – concerned about more lately is how our projects are contributing to the overall strategy and goals for the organization. Are we fitting the needs of the end user? Are we falling in line with the business processes of the organization. When the project is over, is the solution usable long term in improving work and processes in the organization? How do we measure the project’s success or the final solution’s usefulness in the organization?
I led a proprietary software implementation project for a major US airline. The budget was originally $350k and that rose to $385k through change orders during the project. We went over budget and time on the project but neither were delivery issues. In the end we delivered a great working solution configured precisely to what the airline originally wanted and needed… or thought they needed.
But 60 days out from implementation I was touching base with this project customer and learning that no one was using it yet. It was very disappointing and the feelings of success faded fast. It sure felt like those two weeks onsite over Christmas with my team working through development and solution performance issues were a waste of time!
How could we avoid this? How could we better ensure that what we are creating and producing is going to be what the customer and their end users really want? For me, a few concepts come to mind…
Sometimes planning and executing a dog and pony show at rollout time will help ensure that the connect is secure between the delivery team, the end solution and the end user community. Hopefully any issues with requirements vs. expected end solution functionality have been ironed out during user acceptance testing (UAT) but there are no guarantees. Even with a signed off UAT there is no guarantee that the customer really knew exactly what they wanted, that you got everything “just right” and that it is performing 100% as expected.
A presentation of the final solution to a wider end-user community at – or just prior to – system rollout will further ensure that the customer is getting what they need. If any gaps remain, this is where they will be exposed, one or more change orders can be introduced and a final phase of add-on functionality can ensure 100% customer satisfaction and the proper fit to the organization strategy and goals.
Focus group discussion and end-user surveys
Keeping the focus on the end user community we can better understand if we are meeting their needs by allowing them to use the solution and run it through it’s paces. Does it perform as needed? Sometimes, these key roles and individuals were overlooked or not properly tied into the requirements definition phase of the project. Through using the solution, surveying the end user community and working to understand if or where any gaps still remain, we can be proactively responsive to the client’s true needs.
Keep in mind, if we are discovering gaps at the end of the project, the fix won’t be easy or cheap. Is it our fault as a delivery team. Was it the customer who missed requirements? That is going to be a determiner in any change order decisions because it will certainly have an effect on where any financial liability lies. But if it is missing critical functionality, then it will need to be resolved quickly.
Conducting lessons learned during the project or at the end of the project is a great way to understand how the customer feels about the project, the solution and the delivery team. Any issues or concerns should come out during this session. I recommend conducting lessons learned during the project – at key deliverable phases rather than at the end of the project when it’s difficult to regroup the team members that are on to other projects and the client who is busy with the new solution or on to other responsibilities.
By performing lessons learned at several key points throughout the project valuable information can be learned that will keep customer satisfaction high and allow the project team to take advantage of any feedback on the current project’s remaining phases as well as next projects.
Summary/call for input
The real issue here is… are we making our corporate life better with the project? Is it working as intended? Is it being used? Can we quantifiably measure it’s success, quality and usefulness? Yes, there are ways, but sometimes we have to be creative. On budget delivery does still matter. On time delivery still matters as well. Customer satisfaction will always matter whether the project customer is internal to the organization or external. But there is more to worry about… or at least there
Why traditional “on budget” and “on time” are no more relevant or enough…. need to know and measure how and how much you contribute to Overall strategy.