Measuring Project Success

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.

In project evaluation, is success objective? 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 when examining a project that didn’t succeed. Let’s take a look at how lessons learned during and after a project can provide valuable insights into measuring project success.

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. 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. Looking at the numbers on that, it’s fairly easy to say that one failed. But more times than not, it will be a perception. 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.

The Project Management Institute’s Pulse of the Profession 2017 survey found only 14% of projects were deemed as failures, despite 49% of projects not finishing on time, 43% going over budget, and 31% not meeting their original project goals. Those three things align with the typical determiners of project success (on time, on budget, on spec), and yet many projects that did not meet those criteria were considered successful. 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 satisfied the customer is with the end result.

Determining where a project went wrong

Lessons learned sessions are great as a project manager – if you can stomach their truths – because you can learn a lot from everyone outside of yourself that had a stake in the project. Unfortunately, not all projects end up having a lessons learned session, whether its not part of the corporate project management methodology, no one had time as they were already working on other projects, or in some cases because the project failed miserably and nobody wanted to be reminded of this.

To truly understand what happened on your last project and set the stage for future wins, project post-mortems should be a top priority. Gather all the key stakeholders ‚Äì your delivery team, the customer sponsor and team, end users, subject matter experts and anyone else relevant who should be included. At the end of the project, if you sit down and discuss what went right and what went wrong, you’re likely to get some very good insight on what to keep doing and what to not do next time. The key here is to actually use the feedback you receive to improve your next projects, and create reusable systems going forward.

Lessons learned during a project

I’m a proponent of not only performing lessons learned sessions at the end of a project, but actually performing several throughout the current project engagement. Why? 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. 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.

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 and call for input

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 finally, 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.

Recommended Project Management Software

If you’re interested in learning more about top rated project management software, the editors at Project-Management.com actively recommend the following:


Brad Egeland

Brad Egeland is a Business Solution Designer, IT and project management consultant, and author. Brad is a contributor to GoSkills.com, an online learning platform that helps anyone learn business skills to reach their personal and professional goals.