Describing IT project success

IT organizations have a problem when they talk about project success. That success is almost always described in terms of the project itself, yet the reason why the project was undertaken was a business reason. The business wanted to improve the outcomes that they received from one of their processes.

Project success is normally measured by:

• The project was completed on time.


• The project was completed within 10% of budget.

The real issue is: "did the business receive the value that they expected?" If the answer is no, then the project was a failure. If the business can't answer the question, then the project was a failure. Significant time and efort has been spent in the last 30 years to improve project success. All of it has been placed on success as measured by the project team, not by the business.

In this example, the project team considered the project a success. The business considered it an outright failure, because:

• The solution increased workload.
• The solution did not cater for exceptions.
• The job roles were changed. The staff were trained on the software, but not their changed roles.

The result? Negative productivity impact on the business.