re: Why Do Big IT Projects Fail So Often?
It has been fascinating, being in IT leadership, to watch someone like a President get caught up in the maelstrom of a technology project. Despite what everyone not accountable for one of these projects might tell you, this stuff isn't easy most especially if you are dealing with changing requirements and lack of leadership. However, it is also extremely easy to Monday morning quarterback these projects even from those of us who should know better.
What I don't know is, and perhaps I missed this information in other articles, what the actual testing and roll-out plan looked like. Certainly the author of this article did an excellent job in detailing out all of the ways in which projects can fail. It seems so obvious in retrospect but rarely is that obvious within the moment. Can we say that there really were no PoC's and CRP's along the way to a final UAT? If these occurred, did any include some kind of load testing simulation? Were their appropriate test scripts such that people knew what "right" looked like?
It would be a great service to the project community if eventually a postmortem was done in the context of "open government" so that the charter, scope, risk ledger, WBS, and test plans can be analyzed. How many levels of decision makers were there, what was the issue escalation path, and what were the specific qualifications of the architectural team?
I certainly appreciate the author's points and again hard to argue with the logic. However, not all points are hard and fast rules and there are many ways in which to reach success. They clearly didn't reach success here and like all such projects that have launch problems everything looks like an incompetent debacle. The real answers will be something less black and white.