Failure is not an *Error: Undefined*

Image courtesy despair.com.  Go buy a calendar.

Image courtesy despair.com. (Go buy a calendar)

Epic failure.  The source of all life.  No human, dog,  or software technology is immune to it; it is a great equalizer and also a great teacher.  Sometimes failure is entirely unexpected, wrecking havoc on the best laid plans and contingencies.  Other times you can clearly see failure, like Visigoths strolling over the seventh hill, fully three-fifths as angry as disaffected enterprise software users, determined to make the most unpleasant Wednesday in Rome ever.  Whenever someone, somewhere tries to stand on a bicycle, vote for competent government representation, or implement monolithic enterprise software solutions, failure is waiting just around the corner ready to deliver a friendly nudge back to planet reality.

So is failure a certainty?  No, of course not.  But to avoid it requires a thorough understanding of failure; you have to embrace failure.  Fortunately, the lesson doesn’t (usually) have to be your own failure, but the failure of others.  Failure by proxy.  This is how we build on the shoulders of giants to do great things.

Does enterprise software fail?  For example, does Enterprise Resource Planning (ERP) or Product Lifecycle Management (PLM) or even Computer Aided Design (CAD)  and Product Data Management (PDM) software fail?  Oh my, yes.  So why is it that failure in these markets are typically buried in the deepest, darkest recesses where no one will ever know or find out about?

Failure is taboo for a reason.  When it comes to business on the enterprise scale, blame can turn into liability on a dime.  A recent example is the State of California filing a lawsuit against SAP for spending $250 million on a payroll system with nothing to show for it short of a lingering burning sensation.

“After three years, and paying SAP approximately $50 million to integrate its own software into a new payroll and benefits system for the state of California, all the [state controller’s office] has to show for its investment is a system that could not get the payroll right even once over an eight-month period for a pilot group of only 1,500 employees.”

Great googly-moogly.  You could buy the Washington Post for that kind of coin.  Or your very own 787 along with 74 Ferraris.  Someone call Vin Diesel, I think we’ve figured out the plot for Fast and Furious XIV.  What was SAP’s response?  Predictable:

“We will say — as we have said consistently over the course of this engagement — that SAP software is not the culprit here, nor was SAP’s performance in implementing the software,” Kendzie said. “Our software works exactly as it is designed and we have successfully implemented the software with other clients.”

As yes, as-designed.  I find your thoughts intriguing to me and I wish to subscribe to your newsletter.  But to be fair, every enterprise implementation is a product of software, consultants, users, requirements, enterprise architects, company cultures and a variety of software products and integrations from multiple vendors.  So to blame a particular piece of software outright is unfair.  But claiming that any particular software is consequently faultless is similar fantasy.  The shared culpability is why this lawsuit (similar to a prior suit from Marin country) will probably not recover any significant money -except for the lawyers.

That’s great, but what about us chickens?  We still have this problem about ERP/PLM failure being swept under the rug instead of being constructively transformed into knowledge for success.  I.e. the opposite of failure.

An older post penned by Yoann Maingon has been stuck in my mind for some time and he reminded me of it recently.  In that post he suggested that PLM needs a FailCon, where failure can be openly talked about.  In that article, Yoann humbly observed:

“So I’m potentially wrong on that statement and If so please correct me but it feels like PLM conferences are like Alice in Wonderland. Sometimes there are some criticism but it’s never too strong on editors or integrators and we don’t see have more investigation on the root cause of the project’s failures.”

He’s exactly right.  That problem stems from a lack of sufficient independent voices in the market.  Most every PLM conference in particular are marketing engines either being directly hosted or heavily sponsored by the established vendors.  The truly independent take on PLM is notoriously weak.  And that’s a problem.

With the new year upon us, I propose a New Year’s resolution that has nothing to do with Jillian Michaels, quantities of bacon double-cheeseburgers, and/or jumping jacks.  Let’s fully embrace PLM/ERP/CAx failure, know it on a first name basis and admit that some things need serious correction.  Bring me your stories.  Then we can all move forward.

This blog post has committed an illegal operation and will be shut down.

  • Ross Bernheim

    Lawyers and stock brokers make money any time we play their game. Win or lose, the lawyers and stock brokers always win. Don’t feed them any more.

    As to failures, there are so many more ways to fail and it takes so much less effort and time to do than to struggle towards success. It requires a real deep and lasting commitment and understanding to succeed. And success is so fleeting as it is a moving target.

    The first and probably most prevalent problem is overreach. Promising or expecting far more than can reasonably be done at an unrealistic cost.

    For the vendor, it might be better to be more realistic and lose some sales than have the guaranteed failures and enmity down the road.

    For the customer, compare. Get performance goals in writing and contractual guarantees with real penalties.

    For PLM, start with the parts and get them right. Only then move on to bills of materials. Then go to the next step.

    For ERP start with the book keeping, Get the accounts right then populate vendors and customers. Then run the books in parallel with your current system for at least six months. Then start adding in the other modules once the books are running smoothly.