A recent and massive ERP software project failure ($1 Billion US) made me wonder…what issues may there have been for the Business Analyst organizations involved? For the the software requirements definition process?
I posted my questions, and a link to “What went wrong? U.S. Airforce blows $1 billion on failed enterprise software”, to the IIBA LinkedIn Group.
61 thoughtful and insightful comments later, I’ve learned a lot from the BAs who participated. If you’re not a member of this LinkedIn Group I’d encourage you to join! Once you do, scroll down to “Massive fail on ERP – of (painful) interest to BAs” to read the full, vibrant discussion.
Some hypotheses regarding this software project failure, from some of the comments (anonymized), include:
POOR BUSINESS REQUIREMENTS
“I’d be really interested to know what *problem* the USAF were trying to solve by implementing this new software, and the $ benefit they predicted they would derive from solving it. I’d also be interested to know whether they projected the financial implication of “doing nothing” to see whether it would be favorable to implementing a new IT system.”
“Unfortunately, I’ve seen multiple examples where organisations fall for the ‘solution illusion’. A sponsor who is charismatic or powerful enough falls in love with a particular software package because it’s ‘flavour of the month’. You then end up with projects initiated with an objective of ‘Implement system xyz” and success criteria of ‘xyz system is implemented’, and there’s no real relation to any particular business problem.”
LACK OF TRUST
“Great inputs from everyone and based on reading the article, I can only surmise that key failure factor is the lack of trust from every player. If you read lack of cooperation from players and stakeholders of a project, you immediately know you have a problem.”
ENTERPRISE PROJECT MANAGEMENT ISSUES
“Studies have repeatedly shown that organizational challenges rise dramatically with the increased size of teams. The challenge with large project like this is distributing the work in a meaningful way that allows each smaller team the flexibility to develop their portion of the program without having an overly cumbersome coordination effort.”
“Companies often have the mindset that you could have a baby in 9 months if only you could get 9 mothers involved. The real world doesn’t spin like that. Dividing work and [coordinating] large projects is perhaps a bigger challenge for software development that the great Agile vs Waterfall vs Whatever debate.”
POORLY MANAGED SCOPE
“[M]any of us no doubt have seen this as well: poorly managed scope and timelines at the project delivery level, coupled with willful ignorance and a determination to ‘meet milestones’ at all costs at the governance level – with definition of said milestones (often conveniently vague) shaped to suit whatever reality exists on the day.”
Learn more:
“What went wrong? U.S. Airforce blows $1 billion on failed enterprise software”
2010 GAO report on the management of ECSS and its eight ERP subprojects
“As of December 2009, DoD had invested over $5.8 billion in ERPs and will invest additional billions before the ERPs are fully implemented. Most of these programs are over budget, behind schedule, and have not met performance expectations.” From “Assessment of DoD Enterprise Resource Planning Business Systems” (opens a PDF).
