The very nature of Government projects, whether they are desktop rollouts; building restacks; or upgrades of tax systems, benefits delivery systems or whatever is that they’re big. They’re not necessarily the biggest global companies – after all, Walmart has about as many employees as the NHS and I can imagine that companies like GE have 400-500,000 or so (not that I could find out that number on the website – lesson one: if you don’t know where to find what you’re looking for on the web, you’ll almost never find it).
The consequence of often running such big projects is that even when dealing with small projects (and here, I put big in the hundreds of millions total life cost and small in the 5s and 10s of millions, UK pounds), there is an overwhelming tendency to throw additional requirements onto the list until it becomes as big as possible. This may be a result of the procurement processes that give you “one shot” at a given project, preceded by a lengthy buying/decision review; or it may be because public sector people are less directly engaged in a project during its implementation (the hand grenade over the wall syndrome). I guess it could be that public sector people inherently believe that the private sector will step up and deliver complex projects given the budget – although much recent evidence points to that not being the case.
One of the latest “small projects made big” is the whole content management / knowledge management / records management programme. People are looking for a killer, install-once, take care of the problem solution to run the department’s Intranet, the Internet site, internal records management, freedom of information accesses and, in some cases, the end to end paper publishing lifecycle (including leaflets, staff manuals, public policy documents and so on). The consequence of putting so many “related” things onto your do list is absolute, certain, guaranteed, cast-iron solid failure. A company bidding will be pulled in so many directions by so many stakeholders that prioritising what comes next will never be feasible. Such a project will never be meaningfully delivered – all that will result is a series of bodges as tools are stretched to do things that they weren’t supposed to do, and processes are shoehorned into routes that they were never meant to follow. Ugh.
I don’t know whether this is an apocryphal story or not, but it illustrates the point nicely. A year or so ago, I was doing some work in the NHS looking at how the National IT programme might be structured – the work I’d been asked to do was part of a review of progress so far. One of the people I talked to was a doctor from a regional hospital who talked me through how his people were going around a procurement for new IT services. They’d been instructed by the procurement people to think of everything that they might need in the future and include it in the requirements list – nothing was to be prioritised, it was just a long list. So this doctor had wondered for a while and decided that a useful thing to have would be a bed blanket temperature controller. He wanted to be able to set a specified temperature for a given patient as part of their treatment plan and then ensure that the blanket was kept at this temp through an automated monitoring process. I’m sure that’s a laudable aim, but can you imagine what it would cost to wire up every electric blanket to a system, keep track of which patient was there and ensure that the temp was right? Far better, surely, for the patient to carry a piece of cardboard with the temp setting she needs on it and have anyone who comes in the room to do something else check that it’s ok? Or, maybe, just put the temp control next to the patient and let him take care of it?
So, sometimes it seems to me that a bit of concentration on doing some small things well would make a lot of process towards getting the big things right – rather than trying to make a big thing work and ending up doing it badly. Even in a big project (and it’s undeniable that projects in NHS are going to be enormous), breaking them up into small enough parts and handling them individually with appropriate linking standards is likely to result in far better results.
Every time I think of this topic, I come back to research figures that the Standish Group quote: 45% of features in any given product are never, ever used; 19% are rarely used, 29% are often used, 7% are used all the time. Just getting the core 7% done for a defined scope would give payoff in record times and allow work to start on the 19% with money in the bank from productivity saves already underway.
So, a few little things well instead of some big things badly and I think we could make a difference. It will require people to think differently about how they structure their projects, it will require suppliers to work to persuade customers that they don’t need all that they’re asking for – some real points of conflict might arise there, but how else will we progress?
