Best Practices for Developing Realistic Project Success Criteria
Updated: Oct 12, 2020
When starting a new project, it is important for all team members and executives to have a common set of criteria to determine project success. However, defining project success can be difficult as people’s definitions will differ based on their project experience and personal situation.
On several occasions, I have been a part of large transformation projects that resulted in significant technology leaps for the client. In most cases, these projects were considered successful by everybody involved, except a handful of end users in the field who were faced with change. Despite the change management efforts, the level of change (which was necessary for the overall organization) was difficult for some users to adopt and resulted in poor perceptions of the new system.
Therefore, given the variation in types and sizes of enterprise projects, as well as the experience of everybody involved, definitions of success will vary. It is quite possible (and likely inevitable) that no matter how hard you try or the amount of change management, some people will not be satisfied and deem the project a failure. My best advice for this situation (besides don’t take it personally) is to define “what constitutes success” upfront and reference the criteria throughout the project to manage expectations.
To help set realistic expectations, here are my general criteria for project success:
The project went live on the targeted date according to the original budget (which included contingency) without having to sacrifice the original scope.
The selected vendor met the majority of business requirements with minimal customizations; provided easy integration into the organization’s technical infrastructure; and was built on a scalable platform for future growth and integration.
The core users were trained and a support plan was in place to assist the users through an initial 3-month transition period.
There was no disruption to business operations (monthly close, payroll, etc.)
There was a manageable, prioritized list of post go-live tasks and a post go-live release schedule.
The project team was tired, but not completely burned out. Key knowledge was transferred from consulting resources and the organization was self-sufficient within three months of go-live.
The implemented system continues to provide a platform for enhancements, integration with other corporate systems and has the proper transactional data structure to support corporate reporting and reporting applications.