• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

The Difference Between IT Success and Project Success

The recent well publicized problems with the Health Care web site, to support the Affordable Care Act (ACA), when it was launched in late October drove home a very important point to me: There is a fundamental difference between the success of a project (business or government initiative) as whole and the performance of the IT team on the same project.

When business or government embarks on an IT development effort to support some profit or policy objective, there are four possible outcomes.

  1. The business objective is achieved and the IT development effort is also successful.

This is the best case scenario.  Business executes on their initiatives and IT delivers the functionality needed to support the business activities and the objectives defined for the project as a whole are achieved.  Everyone goes home happy.

  1. The business objective is achieved but the IT development effort is a whole or partial failure.

This happens when the business achieves its objectives even though the related IT project failed.  For example, a company that has both retail and online sales may hit their sales targets for the year even if an IT driven online improvement project failed.  This could be because the retail stores had an uptick in sales due to the marketing effort supporting the whole project.  The company might have done even better if the IT project had succeeded but the whole initiative was not a failure.

  1. The business objective is not achieved but the IT development effort is successful.

This happens when IT delivers all the functionality needed to achieve a business objective but the financial targets are not reached due to failures in other parts of the company.  If there are problems with the product, manufacturing, quality, sales, marketing or any of the other functional areas of the company involved in the project, the whole effort might fail even if all the functionality needed from IT is delivered on time and under budget.

  1. The business objective is not achieved and the IT development effort is also a whole or partial failure.

This is the worst of all possible scenarios when there is a total failure with neither business nor IT being able to deliver the desired outcomes.

It becomes clear from the above that IT success and project success, defined by hitting the business objectives, can be mutually exclusive of each other.  While IT can play a key role in the success of an overall effort, it cannot guarantee success.  For projects that are heavily dependent on IT deliverables like the ACA, the failure of IT to deliver the needed functionality can (and did in fact) jeopardize the program as a whole.  If people cannot access the ACA web site to research and purchase health insurance policies online, then the whole program is in danger of failing.

However, even if the ACA web site delivered all the needed functionality on day one and was a total success, there is no guarantee that the overall initiative will automatically succeed.  There are many other complex factors that determine whether or not sufficient numbers of people sign up for health insurance nationwide that are totally out of the control of the IT team.

This critical distinction between overall success and IT success must be understood by management and analysts alike.  When measuring overall project success, common sense and logic must be applied when ascribing causality to the measured outcomes.  Calling an IT project a success just because the business objectives were achieved is simplistic at best and dangerous at worst.  Likewise, it is equally foolish to declare an IT project a failure just because the overall business objectives were not achieved.

Measurable business objectives are not meant to be used to make blanket determinations of success or failure of individual departments of an organization like IT, Marketing, Sales, Manufacturing and so on.  Rather, they should be the starting point of a detailed retrospective assessment, to truly understand the causes of success (or failure) so that corrective action can be taken.  The contribution of all the functional areas involved in a project must be assessed once final project success measurements are made.

Leave a Reply

Your email address will not be published. Required fields are marked *