Monkey See, Monkey Do

BestPracticeApeManaging the implementation of enterprise software is an often daunting, humbling, and formidable task.  As I detailed in The PLM Trail, perhaps too much so, though it’s not limited to just Product Lifecycle Management (PLM).  Managing the technology, the organizational change management, the politics, the angry dinosaurs, it’s enough to generate the same fear that would take the heart of me.  The path forward is often obscure, replete with difficult decisions and imminent peril.   And so it is that many appointed with such a task, lacking a functioning palantír or other assorted prophetic magical crap, resort to a much more practical tactic.  Yes, the tried and true technique of when in doubt, ask your neighbor; otherwise known in business terms as customer references.  Such interactions are sure to provide a wealth of so-called best practice, and while some of it might be a little perplexing, at least all the kids at school are doing it!

The philosophy seems sound, at first.  Yoann Maingon in his Minerva Blog  succinctly writes to the advantages of customer references in an enterprise project:

” Ask multiple references, find out where they have had issues. We see customers who think they know exactly how their users are and how they work. You can have a lot of surprises, so ask references they’ll tell you what were their surprises.”

There is certainly much to learn by looking at someone else’s paragon of process, or conversely their flaming ruins.  Why wouldn’t you ask someone who’s been in a similar position how they managed to survive?  It’s for the very same reason we look for input on nearly everything we do, from where to eat to how we could save a bunch of money on our car insurance.  Sure, references have their purposes – it’s the best way to find out about all the available software options/technologies.  Trade some war stories, get some perspective, learn from the mistakes of others.  But there’s a hidden danger.  A sleepless malice.  A phantom menace.  Meesa think so.

That danger is when industry experiences are averaged into a single recommendation – a best practice.  Sounds great, except there is no such thing.

Sure there are thematic recommendations that ring true, because of their high level outlook.  Recommendations like:

  • Break down your project into manageable phases – i.e. “don’t eat the elephant”
  • Consider a pilot implementation (but not an implementation of pilots).
  • Test, test, test, test, test, test, and… Depl… er, I mean test.
  • Don’t punch the CEO in the stomach.  Seriously.

But such recommendations are general in nature – when it comes to the specifics of an implementation there is no such best practice.  Peter Schroer, President of Aras makes this point with respect to change management for example:

” These vendors will tell you their systems are based on “industry best practices”. The fact is there is no such thing as the best change process. The “best” really depends on the company, their customers, their product lines, their compliance mandates, etc.”

Regardless, many companies otherwise unable to really deal with the hard questions –should we do this or that– adopt a follower mentality (a sure warning sign) and flock towards the easy out.  The answer that someone else came up with: the best practice.  A planet where best practice evolved from men?  Regardless how emphatically such a practice might have been explained, the truth is that most of these practices are wholly centered around specific tool limitations or designs.  One of the thematic lessons to hold dear is that an enterprise strategy should be a reflection of the business and not the tools.  The technology should be evaluated on its own merits and not the mob opinion.

It’s important to recognize that businesses, like individuals, are wholly unique.  Best practice works to directly undermine this uniqueness which may otherwise be linked to the company’s competitive advantage (or secret sauce – whatever you want to call it).  But hey, all the kids at school are doing it.  So best practice gets invariably copied and followed blindly; monkey see monkey do.  And results aren’t so different from a dystopian ape future.

It’s a readily apparent trend.  Enterprise software in particular is submerged in a proliferation of best practice modules, templates, and frameworks that promise simple, quantified answers based on the experience of others.  While the underlying intention is generally positive and the best practice information quickly fills knowledge gaps for companies trying to tackle these difficult projects, ultimately such simplification is a disservice.

The greater challenge is developing malleable software frameworks that can bend -and not break- to match the uniqueness of a company without becoming ridiculously complex, dysfunctional and otherwise inaccessible.  It’s certainly not easy.  It’s a challenge yet to be met by the technology at hand.

  • Ross Bernheim

    Best practices should trigger questions. Just because everyone does it, does not make it right. Think lemmings headed for a cliff.

    If the software doesn’t fit, you must …

      • Ross Bernheim

        Due diligence is indeed difficult. A good part of the problem is that it is too easy to rely on the salesman from the vendors. Salesmen are of the see no, hear no, speak no evil clan when it comes to their software. The all singing, all dancing do all software that will do anything and everything you need and is so inexpensive that they almost pay you to use it.

        A more neutral source is of course the newsletters put out by groups that show the list of all the features that the various software programs have. Lists that make it easy for management to pick the most complete from the list. Never mind that the feature bloat does not mean that it solves your problem and that the user interface is horrid. The list is what counts.

        Been there, and had management choose on the basis of the list all too often.

  • Hi Ed,

    I fully agree with you mainly in PLM. I don’t promote best practices and Aras is definitely a solution pushing you to go beyond that. When I was talking about references I think I was more thinking about experiences, good or bad, just having a general understanding of why the solution has been well implemented, why it failed at some point all our projects have ups and downs and our customer are ok to discuss both sides of the projects. About 2 years ago, I went to a FailCon conference where speakers talk about failures in their company. That was clearly for startups but at that time I was hoping we could have one for PLM ( ). The aim of the article was really to talk about experience, not best practices. Our customers have very different project scopes so best practices wouldn’t make a lot of sense.

    Nice post though !

    • Yoann, I believe we’re on the same wavelength. Sampling the experiences is simply due diligence, a survey of the environment. But when a company takes that sampling as the primary source of direction, we know how that ends up.

      I really liked your FailCon article with respect to PLM. Anyone reading who hasn’t checked it out:
      Hrm, gives me an idea for another post.

  • Pingback: The Five Faces of Dr. PLM | E(E)()

  • Pingback: Locutus of PLM | E(E)()

  • Pingback: Turning Reinvented PLM Wheels into Rainbows | E(E)()

  • Pingback: The Legion of PLM Doom | E(E)()