Why do so many IT projects fail?

There are many reasons why many IT projects fail, however, some of the reasons lie within the areas of the key role-players and the basic methodology that are to be used on any project.

There are four key role-players on any project:

* The user, ie the party that will own and use the `thing` that is being built/changed.

* The designer, ie the party that has the necessary knowledge to define exactly, the `thing` that is to be built or the new form if something is to be changed. They listen to the user`s needs, provide advice and ideas, and define the requirements (eg, the architect who produces the plan).

* The builder, ie the party that translates the documented requirements into the end product.

* The project manager, who draws up the detailed plan, the resource and cost schedules, and manages all parties during a build phase to ensure that what the user requires is delivered on time and within budget.

With regard to the designer, builder and project manager, it helps significantly if they have had previous experience with similar projects.

With regard to the user, they need to know their business and the issues to be addressed by the project and must be prepared to invest time and effort in helping the designer to achieve a comprehensive understanding of their requirements, so that whatever it is they design, fully meets the user`s needs.

Ideally the designed `thing` should not only meet the user`s expectations, but should deliver added value as a consequence of the designer`s specialist skills and previous experience.

The basic methodology for any project is as follows:

* Define requirements, documenting to the right level of detail, what the new `thing` is. This should be done clearly enough to allow full planning and building with minimal requirement to interact with the designer.

* Plan the project, taking into account the current state. It should define all the tasks, resources and sequencing required to achieve the required state.

* Build, according to the defined plan, the `thing` as defined in the requirements.

* Review to confirm that what has been built matches the defined requirements.

* Change management, addressing other issues that are affected by the project, especially preparing users for the new way of working.

The engineering and construction industries are renowned for delivering complex and high cost projects on time and on budget. This is because they have usually done the projects before, they follow a tried and proven methodology, they recognise the roles required and use competent people to fulfil the roles. Road construction, buildings, mines are but a few examples.

An example of an engineering/construction project that did not go that well several years ago was the Mossgas project. Although it was successfully completed, it could be judged to have failed with regard to budget and time, as it was significantly over the planned budget and late in completion. This could be attributed to the fact that many of the players involved in delivering the project, in particular local suppliers and project managers, were inexperienced in offshore gas platform implementation.

In comparison, many IT and business re-engineering projects fail, many are delivered very late, often way over the original budget, and in some cases they are shelved.

The reasons projects are not successful is usually when the above methodology and role player factors are not followed:

* The project budgets are set too early. This often happens when, for example, a software development company contracts to develop a system before the requirements (typically system specifications) are fully defined. This is like a builder quoting to build a house before the architect has completed the plans. This invariably leads to the project cost and time overruns.

* Building starts before the requirements are defined. There are many examples where IT companies are doing development while systems are being specified. The justification often is that there is no time to do the specifications. This is similar to letting a builder start laying foundations before the house plans are completed. There is usually expensive re-work required, and often the user has to compromise on their requirements because of things that can no longer be changed. Some companies sometimes try to implement restructuring or process change project without the detailed requirements having been documented. The end result of such projects is that they are unpredictable with regard to costs, time and result, and have a high risk of failure.

* Incorrect resources used for the project roles. Very often the IT development company takes on the task of defining the requirements. This often results in a merging of the design/build tasks, with negative consequences. Also, there is often a perception that a good coder will make a good system designer, but would a builder be asked to design a house? In IT this happens all the time. We also often see companies using good process workers to write specifications for a system, ie the user doing the design function.

Another typical example of incorrect resources used for the project roles is where the development company also undertakes the project management role. It is very difficult for a project manager to be unbiased when it is resources from his own company that are not performing. Both answer to the same boss that interfaces with the client. This often leads to the project manager covering up and protecting the `builder` when he should actually be exposing the real issues and getting them corrected.

Some other factors that also affect project success are as follows:

* Contracts. It is essential that the contract that is signed between the builder/developer and the user company provides the project manager with adequate scope to effectively control the `builder`. It is extremely important that the contract be written with project control and risks in mind. Contracts need to link payments to milestones, as well as to the quality of the deliverables. There also must be escape clauses so that at any stage if a supplier is risking the project success, they can be ejected and replaced in good time.

* Change management. It is extremely important that the people, who will be affected by the project, are well prepared for the change in terms of training, as well as attitude. If people are not correctly skilled for something new, and are not positively aligned towards it, this can have a negative effect on the project success. Examples are new system implementations and re-engineering projects, where users are highly impacted and productivity suffers if their skills and attitude are not adequately addressed.