This morning the TImes has yet another article on Government IT failures. Last week I sat in on yet another discussion on how to avoid yet another generation of big public sector IT fiascos. I will not repeat my “why do we never learn” message. Instead I will boil it down to six questions.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
1) Can you understand the proposal?
2) Does it have clear objectives?
3) Have those backing the proposal delivered anything similar?
4) Are they committed to staying in post until it is operational?
5) Have the target audience been consulted?
6) Have those who will do the front line delivery been consulted?
Unless the answer is an unequivocal “yes” to at least three of the above questions – run away.
The proposal being put to you is as doomed as the DSS Operational Strategy, Child Support Agency, Farm Payments or National Plan for IT – whatever the commitment of your political leader or the claimed competence of the contractor(s).
If the answer is “yes” to some but not all, tell them to come back when the answer to all of them is “yes”:
Meanwhile read my little “why do they never learn” paper, the Public Accounts Committe report “Delivering Successful IT-enabled change” and “The Challenges of Complex lT projects” by the Royal Academy of Engineering and the British Ccomputer Society” .
When they come back ask the 14 questions on page 37 of the BCS – RAE report and ask them to put the answers in writing and sign them in blood, to accompany the press release – over their names.
Now you might have a winner.
By comparison limiting the size of contracts, mandating the use of open source software or tested methodologies, products and services, or whatever other nostrum of the day, while limiting exposure to multi-billion pound fiascos, does little to improve the chances of success. Nor do calls to use Internet mash-ups.
Size, time and changing requirements are not the only risks.
The past is littered with dead projects where the technology was cheap and/or worked but no-one had considered the scaling or people processes. One of the most expensive failures in terms of deaths and suffering, but not actual cash, was the 1992 London Ambulance fiasco .