Many IT projects get off on the wrong foot through the very fact of being called "IT projects", when they are actually business change programmes.
This was a key conclusion from a BCS discussion involving senior people from user companies, IT suppliers, government and universities. The "thought leadership" debate, held under a rule of anonymity, found that the IT element of a project was low on the list of reasons for failure.
The much-publicised UK Passport Office project was not a technology failure but a management failure in business processes and change control. The health service IT project is not an IT project but a huge change programme.
Similarly, the NHS or any other big organisation is not necessarily a single entity running a unified business change programme with a unified objective and agreed scope. Indeed, an organisation is not a single entity but a group of disparate functions. This perception could be a starting point for major programmes: clarify the nature of the organisation and the programme, and emphasise business change rather than IT.
IT should not be too self-critical: programmes without IT as a central element have also failed in terms of missed schedules and budgets. For example, costs for the Channel Tunnel more than doubled to £10.9bn, and the Scottish Parliament building costs leapt from £40m to £374m.
A review of 1,000 projects by the Office of Government Commerce (OGC) found technology was one of the least likely reasons for failure. Programmes fail for management reasons, not technical reasons. The OGC said the main reasons for failure were:
Lack of leadership.
Lack of knowledge at the top of the organisation about what the technologists are trying to explain - and lack of knowledge among technologists about what business users want. This leads to a huge gulf between the two.
Poor risk management - not in program code accuracy, but in whether, for example, unions will accept the proposed changes.
Underestimation of the complexity of business process change and human change.
Inability to break down programmes into small chunks: projects taking 12-18 months are too long because things change - and people might not tell the project that things have changed.
Major programmes often involve firsts. A lot of firsts indicate the project could be high-risk, and the budget and schedule should take this into account. Firsts need to be thought about early on. Is this the first time the team has worked together? Is it the first time the activity has been computerised? Is it the first change programme for this function? Is it the first time the project team has had to identify stakeholders and get them committed?
Although IT projects might be renamed "business change programmes", the IT industry must take responsibility for some factors. Bad practices in drawing up IT contracts have become established. For example, lowest-cost bidding is prevalent.
Many suppliers bid low, knowing they can recover the costs on scope changes and overruns. So accepted practice gives incentives to fail, because that is the only way IT suppliers feel they can make money.
Another factor is that IT projects often lack requirements - unlike big civil engineering programmes such as bridge building, which have more precise specifications. This lack of precision can again give suppliers way to make money on their lowest-cost bids.