The public sector has a bad reputation when it comes to IT. Frequent project failures have led to central government being lambasted in the press, and yet with the emphasis now on driving efficiency in government, tightening up public sector IT becomes more important than ever. The Gershon Review, carried out last year to identify opportunities for increasing efficiency in government, argues that back-office functions including IT, human resources and finance have much room for improvement. But in a recent report for its FiReControl project, which is designed to consolidate emergency contact centres for the Fire services, the Office of the Deputy Prime Minister admitted that only 50 per cent of government IT projects succeed.
Clearly much needs to be done. But what is causing the problem?
One of the reasons public sector IT projects fail is because public sector culture leads to the abdication of responsibility, especially with large projects, according to Paul Renucci, MD of Damavo UK, a telecommunications and contact centre services company that sells heavily into the public sector.
"With these mega-projects, no one wants to get too close to them in case something bad sticks to them, so they create a process in which the process itself is a decision maker," he explains. "That's something that is different from the private sector, in which there are clearly identifiable people who have to be responsible for things."
But it isn't all down to individual cowardice or unwillingness to make a decision, says Nigel Watson, COO of project management software company Aspiren. The procurement cycles for many public sector projects are simply too long, leading to projects which can often fail to meet changing conditions.
"What this tends to do is shift focus away from what the organisation is trying to achieve and the outcome it wants to get," he says. "All of the brave creative thought that may have been there is stripped out." If the procurement phase of a project takes up too much time, the benefits can be eroded.
One reason procurement can take so long is that public sector bodies are bound to follow certain rules if the project meets selected criteria. For example, if the project value falls above a certain level, it must be put out to tender through the Official Journal of the European Commission (OJEC). "You had to advertise to the whole European Community, going through various rounds of responses," explains Aspiren's Watson. After a lengthy period of consulting with potential suppliers through this process, you finally get to negotiate contracts.
But even when the contract negotiation phases reached, mistakes are made, claims Rob Killick, CEO for IT consultancy CScape. Government negotiators were always forced to take the cheapest price in the past, and although this has changed slightly (the emphasis is now on 'best value'), a culture of cheapness still exists within the public sector, he says.
Aspiren's Watson agrees. Many companies will bid low to get the business but will then define the project requirements so strictly that any minor change requires more investment by the public sector customer. Because projects almost always change, this can introduce extra costs and complexity into the project as it develops.
None of this is helped by the fact that many public sector IT projects are driven by politics, says Andrew Smith of Mercury Interactive. "Public sector projects are driven by political cycles and so artificial deadlines are often set," he says. "They are driven by politicians, which creates a framework that isn't helpful." If politicians are driving the project, sometimes for overtly political reasons, it becomes difficult to set the projected benefits and deadlines of the project to benefit the real-world users at the sharp end.
What can be done to stop the rot? Because these cultural and procedural elements carry a great deal of inertia, it is often necessary to work around them rather than try to change them. Aspiren's Watson recommends a better focus on managing the scope of the project early on. "Rather than trying to build the whole thing at once, it's about taking manageable, bite-sized chunks," he warns. "So, get the early benefits and grow on the back of that." This also makes your project more flexible because you can adapt future requirements as political conditions change.
Using pilot projects can also help you to fly at least part of the project under the OJEC radar, keeping you within spending limits that do not require a huge European Commission-wide tender.
Mercury's Smith warns public sector bodies tend to focus on the post-deployment service cycle, as well as the design and build cycle. "Our experience is that many people run service lines as ad hoc items," he says. "You don't just want to know whether the application is alive and running or not." Identifying things like service levels and response times for your deployed IT service is also important. This will require a structured budget in advance.
But perhaps the biggest recommendations come from the Gershon Review itself - such as the sharing of services. This will be particularly important among local government bodies, which face restrictions on how much capital they can borrow to complete an IT project. Many local government bodies are now clubbing together to form consortia for e-government related projects.
The Gershon Report also highlights outsourcing as a potential method of increasing efficiency in back-office operations. With the drive to outsourcing also prevalent in the private sector, it seems as though government organisations have much to learn from their commercial counterparts.
Autor: Danny Bradbury
Quelle: Silicon, 14.03.2005
