Why Do Public Sector IT Projects Fail?

Why Do Public Sector IT Projects Fail?

To senior public sector managers an IT project implies staff numbers can be cut. Not correct. Just before we expand upon that let's deal quickly with some oft-given reasons why public sector I.T. projects fail:

1. Nobody is in charge. You'll usually find a committee at the top of public sector project organisation charts. Deadly. It means nobody is accountable. By contrast, private sector projects will have a Project Sponsor at the top who gets fired if the project fails.
2. Lack of continuity of personnel. It is not seen as important to have key players in place from start to finish. What incentive is there to get things right at the beginning of a project if you're not going to be there to suffer the consequences at the end? None. So early problems are swept under the carpet and scupper the project at the end.
3. Everything is wanted in one fell swoop. In the private sector money is limited: you get the functionality you can afford. In the public sector there is no commercial logic limiting project scope so everyone wants everything (and gold plated) and they demand it in the first delivery.
4. Projects are too long. I.T. projects planned to be 3 years or more long will probably fail. Few in the public sector understand this (and they still won't believe it even if you explain why it is).
5. People in charge of public sector IT projects have no project management experience and no understanding of IT. They simply don't know what they're doing. They believe general management experience is sufficient qualification. Unfortunately, project experience is not a requirement for promotion to high office in the public sector.
6. Loads of project management process, not enough project management. The chalk and cheese difference between process and management is not understood in the public sector. If you've got all the Prince2 paperwork in place you must be managing the project well. Rubbish. Authoritarian project managers do not exist in the public sector whereas the private sector thrives on them. (See: Why The Public Sector Breeds Administrators Not Managers.)

All true.

Why IT Projects Mean More Staff Not Fewer

The public sector loves outsourcing. You have a large IT project to do? Simple: outsource it to a company that does large IT projects. You form a committee of high-ranking civil servants to oversee the project, but otherwise you let the contractors get on with it. Oh dear, you've just doomed your project to failure.

Just how are these IT contractors supposed to know what the shiny new IT system should do? They aren't telepathic. Who can tell them what the new system should do - senior public sector managers? No. They may be able to write a one page statement of objectives (if you're very lucky) but they certainly can't write the 1000s of pages that define precisely the processes the new system will be required to automate.

So who can define those detailed processes? Only the people on the ground who are currently executing those processes.

Trouble is, those people are busy at the sharp end. But now we need to take significant numbers of them away and closet them with analysts who can tease from them precisely what the processes and associated data are. (For example: when the client rings we ask their NI Number (which must be two letters, 6 digits, one letter), then look it up in this table, then ask surname (maximum 25 characters) and address and... etc etc). And it won't be the front line's trainees who can do this work - it will be the brightest, the best and the most experienced who will be needed.

Often, the processes to be automated don't fully exist: the new system is being developed to enable their introduction. It really does take some very bright people to design these new processes and to say, from experience of the front line, what is and isn't practical in the real world and how the transition from old to new can be made. This user involvement is a lot more than just saying "that screen looks pretty and contains the right data". That's easy. It's all about ensuring the processes that will go on behind the screens are complete and correct. That's hard work.

However, simply taking people away from the front line could result in big problems for local services, and no manager is going to volunteer his people. We will at least need to hire extra staff to backfill for the front line people while they are away. We'll also need someone to negotiate with the relevant front line managers to agree who is going to be made available to the project and when.

This negotiator should be the person who will manage the people's project work: that way he has an incentive to get the right people for the project. And by the way this person is not from the IT contractor, he or she is very much one of us - a manager from the organisation for whom the project is being done. Someone with a vested interest in project success. Of course he must understand he will be held accountable for his work on the project, but in addition his part of the organisation should be one that will have to pick up the pieces if the system does not work properly.

Already we are seeing a need to increase staff and we've only just started the project. Without these front line staff to define precisely what the system is required to do, the requirements definition will be vague, incomplete and plumb wrong in places. And that means later in the project things will have to be changed. And then senior public sector managers will complain that change is costing them a fortune. Or sometimes the project simply ploughs on regardless, delivering useless stuff which will simply get thrown away when the problems become too obvious even for senior managers to ignore.

And what about the people who will be the end customers of this great new system (benefit claimants, tax payers, tax accountants, NHS patients, etc)? They may also have useful input: who is going to identify these people and co-ordinate their work?

Later in the project users will be asked to verify that the system design - the screens, webpages, validation checks, calculations and so on - do in fact meet the requirements and that the system will be useable. Later still, users will be involved in vetting changes to the design, and then in testing, user training and implementation.

So it's not only front line staff who must be made available to the project, it's also people to manage them: people with the authority to negotiate their availability; people with the authority to arbitrate amongst their differing views; people with authority to make detailed but nevertheless important decisions about what we actually want the IT guys to build for us. Senior managers can't do this, they neither have the time nor the detailed knowledge.

Even though we have outsourced the project we will need an appreciable increase in our own staff numbers. We should add to our list of reasons for project failure:
7. Failure to acquire extra staff and thus the inability adequately to involve users in the project. Particularly in the project's early stages.

Some weeks after implementation, when we've hand-managed the teething problems and the dust has settled, then we can begin to reduce staff numbers to below those of the status quo ante. But only then.

Whose Project Is It Anyway?

So we now have a whole client-side team: real users from each affected area; experts who are developing new processes; a person from each department acquiring and managing users from his department; and, because those departmental user reps will disagree with each other, we'll need an overall user manager to arbitrate amongst them and say: "We are going to have this yellow not pink" and tell the guys who wanted it pink they're overruled. And, most important (to stop the project growing out of control) to say "no, we are not going to have that facility on day 1, that will be in a later Release".

And somebody should be managing the IT supplier day to day and ensuring our team and the supplier team work together. That someone could be from the IT supplier but better still this overall project manager will be one of us. This is not some senior manager with a fancy title like "Project Director" presiding over the project part time: it is a full time person with project management experience running the project hands on day to day. And if this project manager is any good he will ensure there aren't two teams - client and supplier - working together, but a single project team that comprises people from our organisation and the supplier's organisation, particularly during the requirements analysis and design stages when a single-team approach is so vital.

Plus, of course, a senior manager from each affected department to: sit on the steering committee (aka project board) to oversee the project; ensure their department is adequately involved in the project; and ensure staff from their department are rewarded/punished for the quality (or otherwise) of their project work (has any public sector user or user manager ever been sanctioned for providing shoddy system requirements to IT?); and one (one) very senior manager to whom the project manager reports directly (for project purposes), who chairs the steering committee and who is accountable for the project's success.

Each member of this client-side team must feel, and must be held, just as accountable for project success as their contractor counterparts.

But this isn't the way it's done in the public sector. And look at the consequences.

How projects should be run in the public sector is covered in this free Project Management Book.

Project Management Articles:

Project Management in the Public Sector

The Tale of Three Project Managers

Risk Management

Quality Management in Software Development Projects

Towards a Project-Centric World

Project Management Proverbs, Saying, Laws and Jokes

So You Want To Be A Project Manager?

Free I.T. Project Management Book

Privacy Policy and Cookies