Fellow Enterprise Irregular, Brian Sommer, is a superb blogger; everything he writes is noteworthy. In his latest missive, Brian’s Software Safari blog offers ten common ways that IT implementation project teams contribute to their own failure. From Brian’s post:
- No one in our firm can make a decision - the project died from paralysis
- Management operates in a decentralized fashion and we were idiots to think this centralized HR (or Finance) system could actually achieve some measure of standardization
- We didn’t realize that the consultants we hired actually believe this ERP software is their employment for life dream come true
- Everyone in our firm is intractable. No one seems able to put aside some of their ‘requirements’ for the greater good
- Oops - we forgot the sheer enormity of modifications we did to the last package - Putting all these changes into the new package blew out the budget
- We’re terrible at math and still don’t know why 28 half-time workers don’t work as effectively as 14 full-time team members
- Our project sponsor had no political power and the project was canceled the first time an important monetary or policy issue arose
- We have some users who sabotaged this implementation because they wanted this to fail and hope we’ll go back and buy the package they really wanted
- Our firm can’t keep anyone in one position for more than a few weeks. We’ve changed project leaders twice, executive sponsor three times and now our new CEO decided to kill the project.
- We’re screw-ups — If we ever succeeded with a big project like this, management would expect us to routinely perform miracles and we’re just not going to set up an expectation like that!
Seems like a tongue-in-cheek list, but is it really?
[via fellow Enterprise Irregular Jason Busch]
