Time to blow up best practices myths

Blowing up the best practices myth. It's about time to skewer this enterprise rug rat.
Written by Dennis Howlett, Contributor

I'm not sure if this is a trend but I am noticing the term 'best practices' turning up in many a presentation. It kinda goes like this: 'We know your implementation is failing but if you follow these best practices, then hey presto, good karma will be magically restored to all.' The polite way of characterizing this is 'piffle.' The less polite way is per this Tweet:

@ The term 'best practice' is - Grade A BS. A best practice might exist for 1,2 co's rarely if ever for everyone

This Tweet prompted SAP consultant Nathan Genez to get up on his hind legs on the SAP Community Netowrk and lay into the expression. He starts:

Best Practices are merely a guide or process that is believed to be more effective than an alternative processes.  Note that they are not *the* solution even though most everyone in the industry equates one with the other.  When interpreted from this more moderate (realistic?) viewpoint, they serve as a good reference point for SAP customers.  Considering the large number of SAP projects that fail to live up to pre-implementation expectations and deliver sub-optimal solutions, it would seem that the industry would be falling over itself to continually refine these best practices.  Part of that process would be to correctly interpret the phrase from the get-go but the industry doesn't seem to care about that.

Michael Krigsman would likely characterize this as representative of what happens in the Devils' Triangle. for those not familiar with Michael's position:

The Devil’s Triangle describes a basic set of dysfunctional relationships that push many projects toward failure.

It's not a bad starting point but one that I critique on the back of the narrowness of its argument. However, the dysfunctional label is well applied in this case. By that I mean the psychopathy of laziness fueled by gluttony. There is a reason that enterprise is attractive to consultants of all stripes. The money. Customers have been fed a diet of luxury promise but been delivered scraps. When there are large amounts of money sloshing around, it is almost inevitable that waste sets in. Time and again we see projects where the promised talent turned out to be some wet behind the ears, freshly 'certified' grad school student who would be doing well if they could program 'Hello World' in ABAP let alone assemble SAP/Oracle/...you name it financials for a national roll out. But I digress.

On the one hand we hear that every business is different. On the other hand we're encouraged to go for vanilla implementations. Best practice is supposed to kind of sit at the vanilla end of the spectrum. And therein lies an essential tension.

My friend and colleague Vinnie Mirchandani regularly berates the industry for its continuing failure. Paraphrased: after 35 years of implementing ERP isn't it time that we knew the basics? The answer is yes but then we get slammed with 'every one is different.' Let's think about this for a moment.

The basis upon which most enterprise ERP systems is based has not changed in 600 years. That was about the time Pacioli invented double entry book-keeping, the principles of which inform all accounting applications. Accounting is the backbone of ERP and to the best of my knowledge, debits and credits are still where I was taught they sit over 40 years ago. So why can't we assemble a financial system without there being some mega cock up?

If life was that simple I'd have nothing to write about but it isn't. Each business comes to the table differently and most commonly in my experience, that starts in the billing process. There are plenty of good reasons why billing should be different from one industry to another but I am never easily convinced that once you get over that hurdle then whatever might be construed as best practice can be easily applied to all businesses within a sector. But then in comes the consultants. As Nathan describes:

I dislike the phrase because I routinely see consultants using it as a shield.  By that, I mean that they use the phrase "its best practice" as a way to justify what is, in fact, just their opinion.  This seems to come mostly from people who can't justify their answer on their own.  They can't explain the rationale behind why their solution is better / easier / quicker / more stable / etc.  Either they don't fully understand the functionality or process in question, or they aren't aware of all of the alternative solutions that are available, and therefore can't justify their answer based on merit.  They take the easy way out...  they recommend a course of action based on the little that they know and then append "its best practice" to it as if this will legitimze the inaccuracies of their answer.  Then they sweat bullets as they pray that the other party won't press them on the issue.

Nathan's argument takes us to a level I believe is sorely under-estimated. When you look at the footprint that an ERP covers it may, and I say may, reach 30-45% of required functionality. It should therefore be obvious that what masquerades as a claimed best practice needs careful examination. Too often, customers are blinded by Jar-Gon and then wonder what went wrong.

Eric Kimberling offers a pragmatic approach to the problem arguing that:

For example, accounting and general ledger are overhead functions that generally do not provide a sustainable competitive advantage. In these cases, it would be inefficient and overly costly to build functionality from scratch. Our experience with ERP implementations is that companies can expect to leverage best practices or pre-configurations that apply to approximately 60-75% of a businesses functions in these areas. The remaining portion will still need to be configured to meet your specific needs.

We can argue the 60-75% depending on context but you see where he is going. The one point where I will argue is on what constitutes a best practice. What do you do if a process is being automated that has worked well but not as efficiently as the business would like? Do you get the software to fit or fit the organization to the software? It's not an easy question to answer. And as Eric correctly points out, the more advanced the process, the less likely you are to find an optimal answer. But then customers get sold on the mythical 'best practices' meme and then what do you do?

My advice in these circumstances is to be prepared to experiment if time and budget allow. Run fast track development to assess whether automating existing is enough or whether more radical action is required. The problem is that those options are almost never offered in the pre-sales and sales processes. It inevitably means time delays and has cost implications. Those however should be outweighed by the end result benefits - assuming of course those are measured. If you are really lucky, you'll come across a consultant who 'gets' what best practice implementation really means. Here's an example from another colleague Frank Scavo.

He told me a story about a competitive bid where his team turned up for interview with the board of a potential new client. The interviewer pressed them on best practice on a particular topic but Frank's team refused to be drawn in the direction the interviewer wished to go. The impression created was that Frank's team were not willing to implement or recommend best practice as sold to the company. Frank's answer was pragmatic: the best practice being sold might be something that has been seen in this industry but it would not fit as described to the circumstances of that particular customer. Therefore while there was a best practice that could be implemented, it wasn't the answer the company was expecting.

ERP is not the only place where the best practices myth is asserted. Naomi Bloom talks about what happens in HR:

Of the many reasons cited for outsourcing one or more HRM business processes as well as for making investments in HRM software, none is more susceptible to marketing hype than that outsourcing providers and software vendors deliver "best" practices in HRM.  The best HRM software, "out of the box," may certainly deliver some good practices in business event workflow, data edits, regulatory reporting, and even considerable guidance and content around the strategic HRM processes (but only a few software vendors actually do this to any extent).  But no software, "out of the box," can deliver "best" HRM practices in those areas that really matter, e.g. proposing both the KSAOC profiles and related assessment tools that will produce a better fit hire for a specific role in your organization or proposing the design of an incentive compensation plan which will motivate your sales force to greater productivity and revenue generation.

It doesn't get much blunter than that.

The bottom line:

  • Beware software vendors/consultants selling you best practices.
  • Understand what a best practice means
  • Test the knowledge of those selling best practices. If you can't do this on your own then hire people who can.
  • Be prepared to trade off assumed optimal best practices for what will work while providing the least disruption.
  • Think about experimentation but under controlled circumstances.

Editorial standards