86% of ERP projects fail, yet 95% of the companies approach the evaluation process with essentially the same methodology....trend....correlation. ..coincidence?
I'm seeking horror stories to include in the upcoming eBook "ERP - Huge Mistake or Horrible Idea?" If you have a tale of an implementation gone wrong, a client problem out of control or an ERP vendor/reseller who's careless antics created hilarious hi-jinx, write it up in the comments section below or forward to email@example.com. Pay is minimal ($0), but if selected, you will get attribution and can claim you're an ePublished author - client confidentiality is the sole responsibility of submitting authors - please change the names to protect the innocent.
The book is not an effort to slam the software industry, inept clients or daft consultants - but after decades in the industry - I studied the 300+ clients who've software evaluations I've participated in - - often as an account exec, sometimes as evaluation consultant, sometimes as a purchasing manager - I wanted to know, which clients were successful, who failed?
You've all read the statistics, some 80-86% of all ERP projects, (depending on who's number you're examining) will fail as measured by time to go-live, budget, or feature expectation.
And it would be easy to blame overzealous salespeople, overpromising pre-sales magicians, overblown marketing spin - but I think there's more.
A few months back, I pulled out all the old client folders - deals I'd won, deals I'd lost. I went back and printed out client notes from my 'Dead' file and my "Customers' files. Customers from the days with Sage, MAS500, Lawson, Ross Enterprise, Navision, Great Plains, Epicor (a lot of the resellers I've worked with ended up with a lot of product lines in the mergers between growing from very local to nationwide scope).
Anyway, I'm sitting there surrounded by stacks of files and mounds of memories flooding back from files I hadn't seen in years.
I'm putting them into stacks of winners, like the companies who implemented ERP and made back the $500k software cost within months - - and then the stacks of losers, some of which threw up their hands half-way through the implementation and gave up, content with expensive shelf-ware. In many cases, the same consultant installed the winner and the loser. Regardless of software, there were good implementations and poorer outcomes.
In most cases, I've been lucky enough to work with some pretty good companies with fairly solid consulting crews - and I learned very early in my career that it's better to walk away from a deal if you can't pull off what the customer requires - either in software feature or consulting experience - so I've been able to buck the industry average so far - knock on wood.
So, there I was, surrounded by files, I'm digging in, really trying to isolate factors that separate the winners and the losers...and the phone rings.
It's my biz dev guy, calling to say we just received a 120-page 1,800-question RFP from VegCo, and VegCo's ERP consultant says "Don't bother answering the RFP unless you're willing to make the response a contractually binding part of the End User Licensing Agreement (EULA)."
First question, "Which RFP form is it?" When a business consultant is trying to pass themselves off as an ERP consultant, It's common knowledge that there are about half a dozen websites to download generic RFP questions - (and we have canned answers having received the same questions dozens of times a year).
Anyway, second red flag - if you've ever sold software, you know there's a point right before the deal closes where you go through the legal review - the client attorney scrutinizes the EULA, generally has a cow over about 22 items - our attorneys review their changes, has the corresponding vendor cow over 11 of the proposed changes and we spend about a week going over compromises of the last 10 or so elements of the contract - and at the end, generally have a single paragraph that serves as a contract addendum - both sets of lawyers are happy, both bill 10 or 20k to the respective client companies - and life goes on.
So that being the case, can you imagine two sets of lawyers trying to agree on word-by-word phrasing of 120 pages of non-legalese RFP-blather to attach to a legally binding contract? Never seen it happen. Couldn't imagine the legal fees needed to get something like that done. But whatever. Here we go again.
Then it suddenly hits me.
I've been through this a million times. Why am I going through this same kabuki-dance-of-a-software-evaluation when it has an 86% of ending up in a failed ERP implementation?
I don't want to just sell software (OK maybe a little bit) - seriously - what I really want is a successful client - I want success stories that will sell software for me with referrals, word of mouth, testimonials - I want someone that's going to do so well, my job gets easy.
And this is not just a slam on RFP's (I have a whole chapter in the book designed to do just that) - What I'm talking about is the whole process - RFP's, two-day cattle call demos, rooms of bored execs answering email on their blackberries while software companies explain how cool SaaS really is...it's really amazing how similar most companies approach software evaluation.
And then I looked at my stack of successful ERP implementations - and I started going back to how they approached the project - from the beginning - even before they started evaluation of software vendors and partners - and began to pull some similarities out...and that's what this book is really all about.
We're in a pretty humorless industry that tends to take itself very seriously, so it's a better than even chance the book title "ERP Huge Mistake or Horrible Idea" will blow up in my face career-wise - but I think the point is valid - companies need a better approach to ERP evaluation than the current system with it's 86% fail rate. And life's too short to work with humorless ..um.. guys.
So the final chapter will be a primer on how to do it right - how the companies that excel at ERP implementation beat the odds, and methodologies to adopt those theories to the real world.
And if your client stories are selected for inclusion, you'll have a nifty handbook to give your prospects a roadmap to success. Not to mention the credibility of buying software from a contributing author.
You may want named attribution or a more generic "Jason represents Oracle Accounts Payable modules in the Southeastern US"
Again, protect your client confidentiality - change the names and identifiable circumstances (If it's a supply chain story of the worlds' largest PC maker suddenly getting out of the consumer business, it's pretty obvious you're writing about HP). Submission will be considered copyright release and all future rights of publication will be waived - don't make me get a lawyer to write all this up. All warranties implied or inferred are hereby void and no promises are guaranteed. And no, Tom Cruise will not play you in the movie version. Editorial control rests with the publishing author and editors.
Good luck and good writing - "ERP Huge Mistake or Horrible Idea" is planned for release within the next 60 days, but it's a time and materials project, so go-live might get pushed back, of course, due solely to scope creep that cannot be foreseen nor controlled by the consulting expertise of yours truly.
You can contact Gene via GH@GeneHammons.com.
Trends Fads Bubbles and Bashing. Take a couple hundred Geeks and give them typewriters, you'll never get Shakespeare, but what you will get is the Technology Press - here's where we sort it all out to see if there's any 'there' there.