This post was inspired by today’s Dilbert cartoon:
“Best practices” usually means copying the mechanics of what successful companies do, and trying to shoehorn them into your processes and culture.
For example, lots of companies “benchmarked” Toyota for decades, and never really gained understanding of the underlying culture and thinking.
Other companies, even today, struggle to try to find working examples of improvements applied to their exact industry and circumstances.
This is an especially deadly combination when they have a culture where experts (or their bosses) provide the solutions, and they simply have to carry them out. Where creative thinking has been effectively stamped out (at least around how the business is run), it is hard to get people to quickly embrace what “empowerment” really means.
Dogbert is selling a quick fix that doesn’t require the client to engage in struggle, hard work, or learning to think for himself. (In the case of THIS client, that is probably appropriate. 
)
I’m going to resist the temptation to add a lot more to this one right now.
Happy New Year.
Well put. I’m always interested in observing the people I am taking a benchmarking trip with. What are they things they are grasping onto and want to bring back to their organization?
The people I would classify more as micro-managers or poor leaders seem to grasp onto very specific, tangible things. They want to bring those back and implement them into their work environment.
The people that I consider great leaders don’t latch onto the specific tool, they are much more interested in the process that spawned the creation of that tool. They understand that the specific tool they have seen likely won’t have the same benefit in their area but the process that created the idea for the tool likely will.
As I’ve done more benchmarking trips I’ve found the best things to observe are the processes that encourage learning and discovery. Those tend to be much more applicable than the specific idea that came from those processes.
I also Agree, Well stated Brian
I do utilize best practices when proposing a project plan which share how several successful organizations had responded to a common requirement (Customer Imposed, FDA, ISO, ITIL GxP…).
The goal is to align the business model with requirements, addressing gaps, limiting risk while gathering the data necessary for long term success / process monitoring.
It also is a logical time to challenge the current state, demonstrate continuous improvements while planning for the future state of requirements or marketing to an expanding market for a business.
The best lessons learned are those that are shared.
Happy New Year to All
Derick
Best Practices are useful for simple problems where clear boundaries exist and where cause and effect are deterministic, things are clearly linear. However when the gap between cause and effect varies, things get complicated, best practices start to break down and they start to cause new issues and things are less linear, you start to need expert advice to analyses and expose possible actions that deal with the now less deterministic effect.
Beyond this, things get complex and the cause and effect can be so intertwined that you can only understand what’s happening only after it has happened through the clarity of hindsight and each time the cause and effect is different and beyond that we are in a chaotic system.
Why am I telling you this?, well because Best Practices, like COBIT, ISO, NIST etc… just like all process based best practice do not work in the real world once things leave the simple and go into the complicated realm of cause and effect. Your world has far less boundaries than you care to admit, that’s why when the S#*T goes down, the processes designed for the simple world we thought existed don’t work, and we end up needing a room of people to think emergently on how to deal with the unanticipated and generally unknown effect.