What makes big-ticket public sector IT projects so uniquely predisposed to fail?
Two new recent reports from the UK highlight political expediency and the constant state of flux within governments and government departments as sharing a big part of the blame.
For instance, during the 10 years from 1995 to 2004, UK central government departments endured on average 16 reorganizations a year, including (counted as only one each), Scottish and Welsh devolution.
And while it’s axiomatic that “events, dear boy, events” will change government policy, having large projects that spread across years only increase the chances of the project being affected by a change in Ministerial, governmental or a departmental reorganization, says Quocirca Principal Analyst Elaine Axby in a new opinion piece for Robin Bloor’s IT-Director.com.
Axby points to the very nature of the public sector to pinpoint some of the other leading causes of failure. Looking at the key project management criteria of time, performance and cost, she says people in the public sector are not very driven by time. With a culture that offers little pressure to get a project out of the door by Christmas, or before a competitor does, public servants find it hard to accurately assess how long things will take.
Performance, or what the project should deliver, is often derailed by hastily introduced policies, and the very wide array of stakeholders who need input into most public sector projects.
“Given that the estimates of time and performance are not very good, then is it surprising that cost estimates are often wildly inaccurate?” she asks.
Moreover government IT projects struggle with the concept of ownership, and frequently do a poor job of managing stakeholders, Axby says.
Axby repeats the tired old line about good project management not being rocket science, and goes on to suggest that really embedding it in the public sector would make a big difference, as would getting proper business ownership and being able to manage scope creep. She also says smaller projects can help.
But she says while all of these measures can ensure public sector IT projects do better, it is the very nature of the business that government organization and priorities will change.
“I can’t easily see any end to the stream of negative National Audit Office (NAO) reports – but really adhering to some of the basic principles of project management such as getting the business case right, clear ownership and better stakeholder management would be a big step forward,” she concludes.
Meanwhile Butler Group senior research analyst Mike Davis asks: “If you know that your new computer system, designed to process many millions of pounds for hundreds of thousands of people has 52 critical defects, 14 of which cannot obviously be fixed, and that of the 40 previous audits during the development period, 70 percent had identified serious concerns, would you deploy? Well, of course, it depends on the risks vs the expected benefits. For, if even with the faults it is better than the previous system, then there may be an advantage to deployment.
. . . However, what if three years later your staff have to use 600 manual ‘workarounds’ to the system to get their job done, and productivity has fallen? Then, in my opinion, it wasn’t fit for purpose.”
That’s not just Davis’ opinion, he says, but also that of the NAO in its report about the development and implementation of the systems for the UK Child Support Agency (CSA), released in June 2006. The CSA systems were developed by EDS during a three-year period, and went live in March 2003, after getting the “green light” from the UK Treasury’s “independent” Office of Government Commerce (OGC).
Davis says he is concerned by the apparent failing of the OGC to recommend the stopping of the project, and concludes it all demonstrates yet again that in public sector IT, project management disciplines are often rejected for political expediency.