The Institute for Government published a report today called "System+Error", which basically highlighted that government IT should be commoditised where possible, and IT projects should be run with an Agile approach.
(http://www.instituteforgovernment.org.uk/news/article/197/the-16-billion-question-whats-wrong-with-government-it)
I imagine that this will result in a raft of cash being spent on Agile training and people blathering on about how bad PRINCE2 is. The bottom line is that for successful IT, you have to understand the needs of the user. You have to accept that you also cannot fully know what the users want, but this isn't because you are an idiot - it's because the users do not know themselves.
It is obvious (to me, anyway) that IT projects should be run in an iteratively developed manner, with close attention to the user feedback. It totally makes sense - why deliver what isn't needed, requested or whatever, just because you think it's a good idea.
If you're sitting there in the private sector, thinking that this issue is just a public sector thing, you have to know this basic information:
IT spending accounts for over 50% of capital spending - worldwide.
IT is not usually user-driven.
IT projects usually fail (CHAOS/ComputerWeek)
IT projects focus on IT delivery and not organisational change. (HL Markus, 2007)
Late adopters usually spend less on IT, but get the same out of the process.
Project alignment is usually done badly. (Hartman and Skulmoski, 2000)
No-one observes lessons learned properly. (Sawyer, 2011)
So basically, what I'm saying is that almost ALL IT change comes as speculative change from within IT, not from the user community and that is utterly wrong.
To fix it, you need to go to the users, (not the user's managers) speak to them and really find out what they think they need. Then you go to the firm (and the internet) to see if there are any lessons learned or case studies out there to inform you. (Hint: there are loads) Then you give them the basics of a system and develop it (using COTS where possible) over a short period of time with a target group, honing the requirement as closely as possible. Once they're happy, you can roll it out further, but you have to realise that the listening and development needs to continue.
You also need to heed Markus' warnings that you need to embed the change within the organisation by ensuring that training, benefits and reward packages and generally 'the whole kit and caboodle' lines up to give the maximum chance of people actually using the system in the way it was intended.
I'm more than happy to discuss this, and please feel free to disagree!
