Many books and blogs (including this one) share best practices for Digital Transformation efforts and Software implementations. And many of them, including this one, don’t say this enough: Best Practices for One Company may not work for your Company.

It doesn’t mean that you should ignore the experiences of others. I’m not advocating that you approach every significant change effort with a blank sheet of paper. Ok, so what do you want? You should be prescriptive (when appropriate) – so many failures could have been avoided if the consultant or the Company had listened to previous learnings. At the same time, you need to be flexible when recognizing the “square peg in a round hole” phenomenon and the need to adjust. Most folks don’t understand that best practices and prescriptive approaches only go so far. “The devil is in the details,” as it were, and Best Practices often stop short of addressing those details.

Why Best Practices are Often Fraught

1. Best Practices, like the word “Truth,” have gotten obscured because although there are still commonly accepted Best Practices (and Truths, for that matter), there is an increase in skepticism about what is a Best Practice and what is not. The core of the issue is around Trust – but, inherently, as we still battle whether the Earth is round, we are faced with increased cross-winds when trying to implement “Best Practices.” In other words, what was once accepted as a Best Practice is now more complicated to convey and often faces very vocal resistance where there was none several years ago.
2. Similarly, Prescription – bringing solutions that have worked in the past – are often problematic. The cartoon above, it’s both humorous and spot-on accurate. What worked for one Company does not necessarily work with the next. For example, when working with customers, they’ll ask how their competitors solved a problem. And without revealing too much, they would listen and immediately dismiss it as not working for them – for various reasons. Usually, the reasons relate more to pride than to actual reasons.
3. The best Best Practices are often shared by folks that don’t know “The How.” They don’t have the depth they require to acknowledge and support the nuances in each Company. And every Company has its nuance. The guy who coded the 4D program to help timesheets ten years ago and then embedded himself and a small team to support and maintain (adding to your technical debt and operational headcount) is unique to you. Likewise, the aggressive infighting and political one-upmanship that make almost every internal project fail are unique to you. But the stories continue, and the details matter in shaping “The How” for you.

Again, I’m not advocating for a first-time, never-been-done-before approach every time you implement Enterprise Software. However, I do feel that it is common for many to have unrealistic expectations about how much technical, political, and cultural debt impacts what can and can’t be done and how fast the change can be successfully implemented. So, yes, best practices should guide you. Still, you should also be prepared for the journey – which will most certainly be different (especially when considering your Company’s nuances) from other Companies.

Supporting Music

Burn the Witch by London Cello Quartet with Ruth Corey (Cover)

Painkiller by Turin Brakes

Burning by Yeah Yeah Yeahs