... why should we expect it to work for mega-IT projects?
James Governor posted a couple of weeks ago about the goings on on the UK government's massive National Health Service project. (Disclaimer: I have no inside knowledge on what's going on there... I don't even know if any of my colleagues in other teams are tangentially involved)
The problems of the omniscient, benevolent central planner are well understood in politics and economics. In anything other than trivial situations, it simply isn't possible for some entity to know all the information necessary to make a perfectly correct decision. You absolutely have to work on the basis that you don't know everything, that actions will have unintended consequences and that it is better to start small, iterate and learn from your mistakes. Whenever this lesson is ignored, failure occurs. Consider "planned" town centres versus ones that grew organically (I'd rather live in London than one of the UK's "planned" towns). Consider "planned" economies versus market economies. The Mythical Man Month is as much
So, what makes IT projects different? Of course, the answer is nothing. They are subject to all the same problems that every other top-down project faces.
This is why agile programming, iterative development techniques, extreme programming and all that good stuff has sprung up.
So, I guess I have two questions:
1) Is the NHS project as much of a disaster as the press suggest? (My take: I suspect it is running broadly to plan but that it is the objectives for the programme that are broken.... are huge swathes of it even needed?)
2) Do we have any good example of government (or other large-scale) projects where agile techniques have been used to prototype solutions, get participant buy-in and demonstrate value quickly? (My take: there are probably examples everywhere but I'm too lazy to dig them out :-p)
NHS Government jgovernor redmonk economics