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:
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.
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
Why Do Public Sector IT Projects Fail? https://www.hraconsulting-ltd.co.uk/why-do-public-sector-it-projects-fail.htm Copyright M Harding Roberts 2011
Project Management in the Public Sector
The Tale of Three Project Managers
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
The public sector does not understand the involvement their people must have in IT projects
and it does not have the strong, authoritative project managers who might lead by example and change the culture.
Being an authoritative, even authoritarian, project manager is not how you get on in the public sector.
Why Do Public Sector IT Projects Fail?
Home Sitemap Contact Us Project Management Articles Project Management Book IT Project Management Course