I’m sitting here, on a Friday night, watching old episodes of “Yes Minister”. Tonight’s episode, first broadcast in February 1980, is on a “big brother” project to build a single database that would store all citizen’s details: health records, tax records and so on. The conversation goes back and forth about why you can and can’t do a project like this. The exact project doesn’t make a lot of difference, says “Jim Hacker” – the issues usually boil down to the same: legal, technical and administrative. The follow-up episode talks about open government and reductions in civil service headcount. Great fun, hugely prescient and wonderfully warming that so much that has gone before is coming again! There’s a little note at the front of each episode that says something about taking the stories after reviewing contents of the Parliamentary Library; wonder how close that is to the truth?
Public sector IT project failures have been in the news recently … Simon Moores commented on the recent NHS e-mail system procurement, Michael Cross published a piece in Computing, Steve Ranger in Computing and this week’s Economist carries a piece on NHS IT, prodded by Richard Granger starting work as head of IT there (you won’t be able to get this last piece unless you are a subscriber).
I’ve heard comparisons between public and private sector before, along with appropriate cautionary tales about them not being directly comparable. Maybe that’s to … but not completely. Private sector projects fail, fail dramatically and fail often – you need only look at the 98% of dotcom companies that have gone under or the telcomms companies that have failed for examples. Public sector projects are significantly more heavily scrutinised than private sector ones – if a project is late, over-budget and under original specification it is audited at least three times in the public sector (local audit, the National Audit Office and the Parliamentary Advisory Committee), each of which is likely to make their results public – and often within the same year that the issue occured. When was the last time you saw a CEO stand up and apologise to his shareholders for spending, say, 50% more than expected on a project? The answer to that is, of course, only in a bear market – by which time the old CEO is gone and the new CEO finds it in his best interest to surface all the issues that he/she can so that there is a clean slate to start with. All issues are blamed on previous incumbents. The list of these is legion: Enron, Worldcom, Tyco etc. If you want to include CEOs that have been given a hard time because their strategy was not working, then the list grows longer (C&W, Vivendi and so on). Steve Case at AOL does not tell us exactly how much AOL v8 has cost to develop; nor does Bill Gates tell us how much the latest release of Windows has cost (versus how much it was expected to cost). There is a big shortage of obvious data for private sector failures.
Turning (at last I hear you say) to the public sector: the fundamental issue is a lack of skills in the civil service. Project management is not a highly valued skill, project delivery is even less valued. Large numbers of what today we’d call “intelligent customers” have been outsourced to suppliers over the last few years as the public sector has, rightly, tried to focus on what it does (policy and government) versus what it doesn’t (IT). In the absence of these smart people, requirements are not buttoned down at the beginning, stakeholders are not consulted fully and often enough, technical issues are not explored and opened up early in the process and suppliers are used for market intelligence and decision processes rather than in-house resource … so projects kick off, get into difficulty and have few choices but to carry on in the hope that they can sort themselves out. Sometimes they do, mostly they don’t.
Projects need full weekly reviews, sometimes daily reviews – with all participants. In government, project boards meet monthly, have papers a week in advance and do not usually consist of “intelligent customers” either so are unable to get into the detail of an issue (how could they? Project boards are made up of people several steps away from the specifics of the project). Project boards are there to give direction – to decide what the scope should be, to make choices between several courses of action; to cover issues that are not absolutely time critical. But if a decision needs to be made TODAY about whether something should be in or out, a project board meeting is just too far away; the issues are too complex and the attendees unlikely to have grasp of the day to day detail. In the private sector, the team is likely to be able to take the decision and tell the board what has happened so that they know.
Public sector techniques are improving here – Peter Gershon’s OGC Gateway reviews are a big part of the improvement. But there is a need for more … questions need to be asked in a couple of ways “is this the right thing?” and “are we doing it right?”; bad projects can be killed off early with the right controls. Resource can be focused on the “right things”.
The second issue relates to “intelligent suppliers”. There are few suppliers that are able to manage their client, especially when the client is as complex and difficult as government. Despite the transfer of resource, the middle tier of managers at the supplier end are not good enough at spotting the issues above either; not good at managing risks and putting in place the right mitigation or dealing with more than one issue at a time. So, both sides bumble on with issues buried at the coder level, deep in the technical architecture or just in plain bad requirements – and they are not realised until it’s too late. Typically, we have relied on a “prime” supplier to manage the dependencies between companies. What this has resulted in is prime suppliers that struggle to integrate a range of different providers, add layers of cost on the initial quotes and reduce the transparency available to the project management team.
The third issue is one of scale. Few private sector projects touch quite the same number of people as the average public sector project. Many private sector companies have reached equivalent scale – eventually. But not so many have to launch on day one catering for benefit payments for 10 million, 20 million or more. Scale delivery requires a different mind set when it comes to building systems and, especially, testing them. There is limited specialist testing capability in government – people that can really think through the end to end issues, simulate the scenarious, figure out what the right result should be – all with a vast set of circumstances to consider.
So … what to do?
– The public sector needs to make “delivery” a firm competency that is rewarded – both financially and organisationally. Projects should not be the poor relation to policy. The solution is not to dump more Prince2 documentation on people or provide more training. It is to establish a career structure for technically competent project staff where they are rewarded and even incentivised directly for successful delivery.
– “Intelligent customers” need to be recruited from around government and deployed on the most significant projects. These are going to be specialist people who will move around from department to department. They will manage big programmes for two to three years at the very most and then move on. They will also be deployed into failing projects (because some will always still be on the critical list) for short periods to put them back on track. A solid career structure will be needed if these folks are to be civil servants, else the departments will forever have to rely on capable contract staff recruited at high rates for short term roles with minimal skills transfer involved.
– Suppliers should be encouraged to move away from the traditional “prime contractor” process where issues are hidden several layers down. Instead they work in a “top table” fashion – all represented on the project team and equally able to identify, raise and resolve issues. Suppliers will need to work in new ways with the new types of project managers that government needs – the old way of hiding issues, negotiating from a position of strength (after all, who else is government going to choose?), blaming scope changes on the department and not on inflexible methodologies and poor discipline … all of those have to go.
– OGC Gate reviews are already well entrenched. Their scope should be expanded to include not only “is the project doing things right” to “is this the right project to do”; i.e. does it really make sense to do this project, or can we use something that has been done elsewhere, perhaps with minimal customisation, to deliver faster. Departments should not replicate what has been done elsewhere.
– Departments should be focused on deploying technology as it is, not with making endless tweaks and changes to a system so that it fits their process. Changing large systems is more expensive – probably by an order of magnitude – than changing business process to match a system.
– Finally and, I think most importantly, the lesson from “Yes Minister” is that there is not a single lesson to be learned that government has not already learned. Since the time when Cromwell signed himself above the Monarchy, projects have started and stopped, succeeded and failed … and government has, somewhere in its files, the details of them all. Those lessons need to be easier to find, widely reviewed, embedded in training, kept up to date and checked up on over and over. If you, as a project manager, can stare at the history of all those who have gone before you and can see what they did wrong, you are unlikely (unless you are very stupid) to make the same mistakes. Suppliers, of course, will get to see the same lessons, whichever supplier was responsible. Without true open-ness here, we will never emerge from the swamp we are in (for we are already neck deep in aligators). We can but hope.
