Emphasise change management to boost chances of project success, experts advise
- Posted:
- 12:24 09 May 2005
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.