UK Transportation Department IT failure: 'Stupendous incompetence'

The UK House of Commons attacked the Department for Transportation (DfT) for gross mismanagement of a shared services IT project. In a rather extraordinary comment, Edward Leigh MP, Chairman of the Committee of Public Accounts for the UK House of Commons, said:

The DfT planned and implemented its shared corporate services project with stupendous incompetence. This is one of the worst cases of project management seen by this Committee.

The DfT initially estimated the program would save £57 million ($85m) over ten years. Current forecasts show that program will result in a net loss £81 million ($121m). A House of Commons analysis concluded:

There are three ways in which implementation can fail: through delay in introducing planned developments; increased cost; or by providing poorer services. The Department for Transport (the Department) has suffered all three in implementing its shared services project. Yet, despite the extent of mismanagement in this case, no individuals have been dismissed or been properly held to account.

IBM ran the project, which was implementing SAP, with quality control services provided by Deloitte.

THE PROJECT FAILURES ANALYSIS

The House of Commons document, Shared services in the Department for Transport and its agencies, is required reading if you want to dive deeply into this case. In addition to analysis, the excellent document includes testimony transcripts so you can draw conclusions directly from the data itself.

I have annotated document conclusions with comments to provide broader context:

The Department's planning and management of this important project have been extremely poor. This case is one of the worst this Committee has seen and responsibility for these serious weaknesses rests firmly with some of its top officials.

Comment: Many IT projects suffer due to poor internal management. Although tempting to point fingers at either software vendors or external system integrators, the problem frequently lies with insufficient controls and oversight inside the contracting organization. You can call this "being asleep at the switch."

The Department's plans for implementing Shared Services were too optimistic and were imposed in the full knowledge of the risks, difficulties and slippage. The tight timetable led to the Department taking shortcuts which subsequently caused problems.

Comment: Call this poor judgment in the face of tremendous pressure. No one desires their project to fail, so the material issue becomes how participants manage the risks. Healthy environments encourage open disclosure of potential issues as they become known, enabling the team to accurately evaluate status on an ongoing basis.

Unfortunately, many project teams experience pressure to push forward in the face of evidence that success may be difficult or impossible to achieve. In effect, these teams push off the pain of failure into the future rather than address difficult issues in the present. However, many problems become worse over time, making the eventual outcome far more serious than it would have been, had core issues been handled earlier in the life of the project.

Two months after the project started, the Department knew that the initial assumptions were incorrect but did not deviate from its timetable.

Comment: Tunnel vision and denial are all too common. However, many environments are not receptive to hearing bad news about project delays and slippages. In such cases, project participants have little recourse than to push forward, despite knowing the project cannot meet planned schedule, budget, or scope goals.

Management is responsible for establishing a culture and environment where project participants can voice their concerns. Frequently, this deep-seated issue is difficult for an organization to change.

To save time the Department used an existing framework agreement for the development of the system, rather than competitive tendering, despite an initial cost estimate of £16 million. This choice contributed to poor specification of its requirements, the piecemeal placement of work and poor management of its suppliers.

Comment: Flawed requirements analysis is a common source of downstream project failure. For more background, see the following links.

• Related: Study: 68 percent of IT projects fail
• Related: Requirements and failure: Interview with CA's SVP of IT Governance

Requirements and upfront analysis should include all pre-implementation steps, including developing an RFP with multiple bidders, going through an initial evaluation phase with vendors, and creating contracts that include highly-specific goals and milestones. Wherever possible, the contract should specify clear vendor performance metrics.

To understand management's mindset, look at this small portion of the hearing transcript:

Q23 Mr Mitchell: You were predicting savings and then being sloppy about the planning of them. Why did you not have a competitive bid for it? Why was he work entrusted to IBM? Were you mates? Was there some kind of feeling of friendship for IBM? Admiration?

Mr Devereux: No. Let me come back to the point the Chairman has already identified. We deliberately set off on this with an ambitious timetable. It was our assessment that three things were true, one was that we were intending to build this on the systems which DVLA had already started on and they themselves were being supported by IBM; secondly, because we wanted to get on with it and we were being advised it was possible to do this in the space of a year, not in the space of two years. The fact that we already had a contract which had been won in competition by IBM, let us be clear and had the flexibility to do this, suggested to us that actually the alignment between business processes which had already been defined in the DVLA, and a contract and a contractor which had perfectly properly the ability to do this work, meant that we were able to deliver the one year target we originally set ourselves.

Q24 Mr Mitchell: You also thought you could trust them and you were wrong.

Mr Devereux: I do not believe in trusting suppliers.

I like this excerpt because it shows the inner thinking of the Department with respect to its relationship with IBM

The Department lacked sufficiently skilled or experienced project management staff.

Comment: One wonders the department embarked on a major business transformation initiative without properly trained or qualified staff. What else can you say?

The Shared Service Center is not meeting most of its performance targets and it is clear that some of them may not be met for some time.

Comment: Translation: this thing is so screwed up that it may never show results.

Many users do not trust the system due to the problems that they have experienced but the Department considers that some key performance indicators such as those for creating and maintaining customer details are not important.

Comment: Repeatedly, I see IT and technical folks who lack respect, and even show contempt, for users. Such attitudes reflect a profound misunderstanding of the relationship between and business groups and is a direct contributor to project failure. Even when a project is delivered on time and within budget, it must still be considered a failure if it does not meet user needs. The failure is more severe when users are unsatisfied and the project is also late and over-budget. That's what happened here.

The Department's excuses for failing to measure up to the performance of private sector organisations are that it does not have the economies of scale and it has to satisfy government reporting requirements.

Comment: This spurious argument reinforces the impression of management incompetence. The logic seems to imply that no outcome aside complete and total failure is possible on government projects. If so, then why are we bothering to analyze or discuss this at all? Such nonsense would be laughable if the stakes were not so high.

---------

Surveying the landscape of this project, one wonders how things can get so bad. Yet, this is no isolated case. Stayed tuned to this blog to read more hair-raising tales from the strange land of IT project failure.

[Transportation crash photo from udono.]