Reliable Project Delivery was introduced in 2005/6 against a background of failure (actual and perceived) of major public sector ICT projects and specifically in response to the media attacks on those projects.
Reliable Project Delivery research carried out during 2006, together with work done jointly with the NAO on its report on Successful IT Projects, showed that:
- the public sector failure rate was no worse than private sector but the failures were more “public”
- Organisations with successful project delivery track records:
- Initiated the “right” projects in the first place and challenged/stop the “wrong” ones (the use of portfolio management being a common thread)
- Applied robust control and governance to those projects they do take forward, throughout their lifecycles
- Public sector organisations were over reliant on OGC (and other) best practice rather than taking ownership of and managing the problems themselves
- Issues specific to ICT-enabled business change were not being addressed
In working for a number of central government departments over the last seven years, it has become apparent to me that whilst they “talk the talk, they do not walk the walk”.
With the OGC Gateway process, we have a world-class tool for monitoring – and where necessary correcting – the progress of IT-enabled change programmes. However, this is all too often paid lip-service to, or worst still completely ignored. Unless it rates as Mission-Critical or is over a certain lifetime cost, the OGC often doesn’t even get to hear of it. Time and again, the same avoidable mistakes are repeated and lessons are not learnt due to poor central monitoring.
You only have to submit FOI requests to departments and separately to the OGC to see that their records are completely out of synch. The OGC Gateway process is mandatory for all government acqusitions over a certain value that use IT but generally anything over 1 millions pounds but under 10 million pounds does not get the scrutiny it deserves.
Lots of good stuff comes out of the OGC (think PRINCE2, ITIL) but unless departments are (a) made to use it; (b) not left to waste time creating their own delivery methodologies (c) place experienced professionals in charge of delivery (doing a PRINCE2 course makes you a project manager in name only) – we will be damned to repeat the same mistakes time and again.
The public sector failure rate IS WORSE than the private sector because tax payers lose money when a public sector project gets delayed.
The problem is not over reliance on OGC (or other) best practices, the problem is not having enough accountability on projects so those same individuals or public sector organisations have no way of hiding from their responsibilities on a project.
One of the things we need is a central government Project Register, available online for everyone to see, with a list of all government projects stating:
=> Project Methodology Used
=> Initial Cost
=> Start Date
=> Estimated End Date
=> Key Persons and Government Contractors responsible for success of project (Project Executive, Project Manager, Supplier X, etc)
=> End Date
=> Final Cost
Then we’d get away from the usual grey blame game of “it’s the government’s fault” (Labour or Conservative).
Oh brother, don’t get me started.
For a start, public sector project fail far more than private.
Why?
1. They are too big.
2. They have no clear leadership structure and no clear roles & responsibilities.
3. There is zero accountability amongst government stakeholders.
4. The end users are absent from any involvement.
5. The requirements are set by committee.
6. There is no concept of defining the core requirements of the solution and then baselining these against contract.
7. There is no effective solution development lifecycle mandated.
8. There is appallingly low levels of risk and change management and zero impacting against the requirements or solution.
9. Political expediency is absolute over the correct process of developing solutions.
Nine reasons from someone with far too many public sector IT projects under their belt.
Mike,
I agree with some of your points, but let me tell you agreeing requirements by a committee is better than letting a senior manager, with no IT experience, dictate that it “has to be blue and interact with the database thingy”.
At least us public sector IT bods get a say when we are on a committee and stop some of the, frankly, madcap requirements from ever making it onto the Project Initiation Document (you see, I have been on a course
).
agree pretty much with Mike Thomas above, the public sector has a poor understanding of how to fix a requirement and get a supplier to deliver against it. The requirements process tends to be committee driven and runs on into the delivery project, a behaviour that is now well known to suppliers who can bid below what they think the project might actually cost and then make up the difference and more as the changes to requirements inevitably appear. the whole thing is probably a function of the size of some govt departments, and the networks of interests they contain.
99% of IT is saying *no* to new projects and dramatic changes in favour of gradual evolution. The other 1% is saying yes to the right big changes. Government seems to spend all its time trying to make every project a “1% big project’
Devolve the decision making power to the departments and hold them accountable for their results. That will produce a lot more small, innovative and efficiently operated low risk projects for change.
Devolving them also engages the users of the systems and lets the make a real difference which produces feedback, commitment and real benefits.
Send the civil servants on system theory courses not just IT ones. Worrying about computing so much is like teaching someone to run a garage by teaching them about spark plugs -both are mostly about business sense and people.
The simple way to offset failure, and to increase the viability of a public sector projects. Is to decrease the size of the singular unit of the project.
For an example if an implementation of a specific project requires 10,000 staff. Do not make that into a single unit with a top down structure. Split it into 10 units of 1000 staff.
Its just the nature of how people work, a unit of 1000 staff is much more manageable and such the hierarchy of such a unit is more approachable by the staff when issues arise. So although the initial outlay is more expensive, the efficiency of the output from smaller project units is much higher. Which in turn, reduces people hours and communication through the hierarchy is more efficient and adaptive. Thus avoiding some of the main pit falls of many public sector projects.
If a lawyer makes a huge mistake they get struck off.
If a doctor kills a patient they get struck off.
If one of the IT consultancies working on a UK government IT project makes a mistake, runs over cost or simply doesn’t deliver they get … well they get another contract to deliver something new.
Whilst part of the problem lies in the public sector themselves, with specifications set by politicians as well as end users the companies implementing them are never held to account when things go wrong. Witness the current NHS work, or the myriad of MOD projects right now.
Until the companies concerned are held to account, and failure is no longer rewarded there is no incentive to deliver something on time and to budget. Unfortunately I can’t see this changing, even under a new government – as somehow the large consultancies are seen as less of a risk, and there’s only a few of those.
Having worked on a FOI project for a very large “consultancy” – supplying amongst others; Downing Street and DCMS, the attitude in that company was to hard code everything. That way whenever the project got rolled out to another department, the company would make lots of extra money in change management.
There is very little incentive in these big companies to make things reusable and the standard of code even in some of these big organisations leaves lots to be desired.
The government needs to hire more of it’s own programmers who can then be involved in these projects at an implementation/technical level and be able to say when the code smells…
Small contractors should also be encouraged but to bring their standards of code up, make more use of the British Computer Society (BCS) or similar as part of the recruitment process. Typically, a good contractor will work out much cheaper than a large consultancy company that sends in their best programmers for the initial client meetings then uses junior programmers behind the scenes for the rest of the time (have seen it happen).
Bring more code in-house – it means you can understand what you have ordered better and fix it cheaper!
Every public sector project should have a rigorously enforced break cause based on a pilot phase and clear criteria for failure.
If the project meets the failure test it should be canned, not subjected to further refinement of the base case