Managing 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.