Can We Recognize Project Success or Failure?

What defines whether a project is a success or failure?

As I reviewed published materials on the state of the IT industry’s ability to deliver projects successfully, it struck me that project success and failure have different meanings to different people.

Two of the more recent studies that I reviewed were from the Project Management Institute and the Standish Group. (For more information from these studies, refer to the following articles: “This is Why So Many IT Projects Fail: A People First Companion to the PMBOK” and “This is Why So Many IT Projects Fail: A Wrap-up”.) 

Both studies indicate a bleak rate of success in our industry’s ability to deliver software projects on time, within budget, and that meet the client organization’s objectives. Regardless of how one measures success or failure, fewer than half of IT projects were deemed successful.

But how do we measure project success and/or failure? I evaluated several projects that I worked on during my career and realized that I do not have a good answer. At least not one that would probably match the definitions provided in the studies that I reviewed.

The following real-world scenarios show the challenges in definitively labelling a project a success or a failure (or somewhere in between).

I offer my opinions. Feel free to comment with your own at the end of this article.

  • Project scenario 1: I have shared this example in other articles. A colleague was providing consulting services to a large overseas (from the U.S.) government department. In discussion with the CIO, she asked how the department’s latest system implementation went. The CIO replied that the project met the timelines, budget, and end-user objectives. However, they would never work with that IT provider again.

Project success? I believe it was, both from the department’s and the provider’s perspective. However, I would consider it a project management failure on the part of the provider.

  • Project scenario 2: The IT provider completed the project on time, within budget, and met the end-user objectives. However, in doing so, the Project Manager invoked the proverbial “death march”. Staff worked 60 to 80 hours a week for several months. After the project was delivered, several developers resigned from the firm. Some went into different careers.

Project success? Probably so, but possibly another project management failure.

  • Project scenario 3: Like scenario 2, the project was delivered on time, within budget, and met end-user objectives. However, to do so the developers took many shortcuts. As a result, the maintenance and operation (M&O) of the implemented system became a major challenge. Unstructured code, “spaghetti logic”, unnormalized data, incomplete or erroneous documentation, and other such issues contributed to a difficult transition to M&O.

Project success? Partially, if measured by timeliness, budget, and delivered functionality. However, the lack of quality became an ongoing burden for the client organization to keep the system operational. From that perspective, it was a failure.

  • Project scenario 4: The proposal team “low-bid” the procurement to win the job. Predictably, the project was delivered late and over budget. It did, however, deliver the expected user functionality.

Project success? Partially. Depending on how critical the system was to the client organization’s mission, the client may have been able to absorb the delay. As long as the client was not required to cover the budget overrun, the project was delivered functionally complete. However, the loss of reputation and the hit to profitability was a failure point for the IT provider. Not necessarily a project management failure, but certainly a project failure due to the low bid.

  • Project scenario 5: The IT provider completed the project on time, within budget, and delivered the required functionality. However, upon implementation the end-users refused to use the new system. They complained that it was clunky, not intuitive, and took longer than their manual processes.

Project success? From a pure definition of meeting scope, schedule, budget, and quality, one could argue that it was a success – at least a project management success. However, from a usability standpoint, it failed.

  • Project scenario 6: The project was delivered several months late and was 50% over budget. The client absorbed the overage, taking responsibility for a myriad of scope changes. Upon implementation, the end-users raved about the new system’s utility and how it changed their ability to service their customers.

Project success? From a pure definition of meeting scope, schedule, budget, and quality, one could argue that it was not. However, given the client-initiated scope changes and the delight of the end-users, I would say that it was successful.

  • Project scenario 7: The project team struggled to code and test the functional requirements. They were challenged by the system architecture. It seemed that the processing hardware that the client had selected for its new system was designed for short, bite-sized transactions (think airline reservation transactions). The system being designed and built was processing intensive (think massive data manipulation and calculations). While the IT provider envisioned many lucrative change requests to come, the client finally cancelled the project.

Project success? From a pure definition, not at all. From the IT provider’s perspective, absolutely not. From the client’s perspective, it was partially successful. Although both client and provider should have done a better job of defining the solution as early as the development of the project charter, the client had the good sense of “pulling the plug” and not sending good money after bad.

  • Project scenario 8: In the middle of project execution, a major external event disrupted the schedule. Eventually the project was completed, though well over budget, several months late, and with several of the less critical functions de-scoped.

Project success? I have not provided all the facts, so this one could be a toss-up. The provider and client agreed on how to recover from the disaster situation, and still deliver significant functionality, suggests it was a success. On the other hand, if the IT provider had no disaster recovery plan or risk management plan in place that could have mitigated much of the cost and schedule overrun, then this might be deemed only a partial success.

Project delivery is not always 100% successful or 100% failure. As these eight scenarios indicate, there are many moving parts that a Project Manager must be able to handle quickly and definitively. Considering these scenarios, all (with the possible exception of scenario 7) dealt with the people aspects of project management.

It’s the people aspects, the human factors, that require as much focus as process and technology.

*** Photo by Michal Chmurski /

Get Your Free Guidebook

Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.