Reply to post:

There was once a relatively simple project rolling out replacement servers in the NHS trust where I was working. I was in charge of the servicedesk at the time.

Now, I could have done and managed this project. Hell, anybody could have done because it was so simple. I assumed that you'd do more or less this:-

day -1)Identify what's running on the server. Ensure all data is copied over to new server.

day zero) disconnect existing server and change config so that everybody works from the new server.

day +1) one member of staff stays on site to pick up the support problems that always occur.

So, the time required for the entire project could easily be calculated by number of days required for one site, multiplied by the number of sites, divided by the number of staff deployed. Simple, right?

Higher management had apparently decided that the job could be done in under half the time it was going to take to do it as outlined above with the level of resourcing. The first project manager left on the morning of his second day, presumably after doing the sums and having a meeting with management about it. The second PM left after 2? hours. The 3rd then proceeded with the project.

The project did a couple of sites with the obvious methodogy I outlined, before skipping stage 3. The servicedesk protested the absurdly huge number of calls swamping us that this generated, but management told us to deal with it. I ended up booking one of the my staff out for the day to pick up the bits. This was painful because we weren't exactly overstaffed, but what can you do?

The project team then accelerated their efforts to meet their deadlines by skipping stage 1 entirely, to another tidal wave of servicedesk calls caused by the obvious disasters exploding. The project was defacto halted by word getting around between site managers as to the rolling disaster, and local staff at each site started deploying their security staff against the project team, and when they started just saying "i'm from IT" anybody from the IT department they didn't recognise. The project leader was fired under a cloud of recriminations shortly afterwards and for some while afterwards getting IT staff into these places was shall we say exceptionally difficult if they weren't known to the local staff.

So, yeah. This is what happens with a relatively small internal project. Imagine what happens when you add an external company to the mix?

The problems are as follows:-

1) Systematic incompetence. Incompetent staff who are dangerous and might kill somebody would be fired in normal workplaces. Not so the NHS, they are prized. Before working in the NHS I used to be surprised and outraged by stories of people being killed by incompetent staff in the NHS. Now I just feel weary resignation and by surprise is only that there aren't more cases reported.

2) the problems at point 1 extend to the management, because of the (hopefully now ended?) program of recruiting managers direct from university. This gets the worst of what are effectively children with no leadership capability or management utility thrust into management positions where their incompetence is only matched by their inexperience, arrogance and level of qualification. Hence truly massive fuckups avoidable by anybody who has a couple of years of practical experience.

3) Suppliers send real quotes. However, they work to the spec provided. This is delivered precisely as requested, and it's then realised that this wasn't actually what was wanted by the Project Manager.

4) Testing (or user involvement) tends to cause rejection by the people who realise that the system is crap at an early stage, so avoiding this is preferred to avoid getting the project written off for as long as possible. This is why the favourite electronic management program for GP's is EMIS LV, which was written by a doctor and actually works. If a project is implemented and then just needs "fixing" or "feature enhancements" in order to be used then it's a "success" rather than a failed project, remember!

5) The NHS has to pay to fix problems with software they design because they generally just hire the developers on a per time basis rather than for doing a job. When the job they are given and the job that was wanted are divergent then you blame the developers and then pay them more to do some more work on it which is another reason why the NHS doesn't do development in house. Nobody to shift the blame to if you do that.

6) Privatisation is considered a great idea because a company run this way on a fixed budget would go out of business and a competitor would take over the work. This is why GP practices are generally considered to be the best part of the NHS, (ie not completely dysfunctional) as they are actually private for profit businesses and therefore can (and do!) go out of business if they are too highly incompetent.