Interesting post by Jane Bozarth - The Myth of "Best Practices".
A "best practice" is best only in the precise, specific context in which it exists. …
What works in my marriage won't necessarily work in -- and may even damage -- yours.
Even if moved from one situation to another very close one, the odds of transfer being made with practice intact is nil.
How do we address those who pressure us to produce a list of, or abide by, "best" practices?
The comments are also interesting but focus primarily on the word "best" vs. "leading" or "better" … overall the suggestion was to be very careful about assuming because something works in one situation it will work in others.
So, the first thing I did was to quickly search my blog for any mention of "best practice" – whew, I don't use the term much. Dodged that bullet. :)
Patterns and Knowledge Work
I understand the concern that when you share best practices, you may come out with very different results. That said, I also understand exactly why people ask for "best practices" and why our organizations ask us to help "share best practices".
In Rethinking Knowledge Work, Kirby Wright describes Gary Klein's model of decision making:
Studies of health workers, executives, military, firefighters, pilots and others have found that sense making, pattern recognition and mental models are essential components of decision making.
As an individual encounters a situation he/she makes sense of the issue. Making sense generates cues and allows one to recognize patterns, both in the nature of the problem and response. Through pattern recognition, the problem solver identifies actions to address the issue. As one begins to act, they are also assessing, in real time, the potential impact of their actions. In particular, highly skilled workers demonstrate the ability to reflect-inaction (Schön, 1987), to conduct mental simulations as a way of imagining possible outcomes. As problem solvers do this, they adjust their actions on-the-fly.
This really rings true to me.
And this suggests that there is big value in providing knowledge workers with ways to assess a situation, to find the cues which link to possible approaches and actions. I think that we all somewhat inherently know this. It's why it's so great to go to sessions where you hear what other people have done when faced with similar situations.
Patterns Defined
While Klein uses the term "pattern", there is another definition of Patterns (or Design Patterns) which is a great example of the kind of information that we can produce which is valuable and maybe is not a "best practice" but is close. From the above definition, a Design Pattern is defined by:
- Pattern Name and Classification: A descriptive and unique name that helps in identifying and referring to the pattern.
- Intent: A description of the goal behind the pattern and the reason for using it.
- Also Known As: Other names for the pattern.
- Motivation (Forces): A scenario consisting of a problem and a context in which this pattern can be used.
- Applicability: Situations in which this pattern is usable; the context for the pattern.
- Structure: A graphical representation of the pattern.
- Participants: A listing of the classes and objects used in the pattern and their roles in the design.
- Collaboration: A description of how classes and objects used in the pattern interact with each other.
- Consequences: A description of the results, side effects, and trade offs caused by using the pattern.
- Implementation: A description of an implementation of the pattern; the solution part of the pattern.
- Sample Code: An illustration of how the pattern can be used in a programming language
- Known Uses: Examples of real usages of the pattern.
- Related Patterns: Other patterns that have some relationship with the pattern; discussion of the differences between the pattern and similar patterns.
I often use less formal patterns and you can see examples of patterns in Using SharePoint or at the WikiPatterns site. But the goal of these definitions is similar. Look across examples of practices and abstract out the common structure of solutions. Define where it might apply and what it is.
Going back to the "myth of best practices" … yes you still need to evaluate if this pattern will work for you, figure out how you might need to modify it. But what's the alternative – start from scratch each time? I don't think that's what is really meant, but I would claim that:
Patterns are extremely high value and we should look to produce patterns whenever we can.
Better Patterns
Taking this even further, in Data Driven (one of the few posts that uses the term "best practice") I talk about a model where we take data (e.g., customer satisfaction data) and provide knowledge workers (e.g., store managers) with specific possible actions that they can take to try to improve. We allow them to modify how they will apply these actions as we know that it often is best to have it modified to better fit the store. We also allow them to use alternatives.
This is something that certainly would be called sharing best practices in many organizations. I guess we could also say that it is Patterns that we have identified and we have tied them to specific situations based on metrics.
We have the added benefit in this case to measure the impact of applying these patterns to determine the impact. This means that we are able to determine better and worse performing patterns. While the organization involved used the term "best practice", I can understand an argument for not using that term. But, I do think that finding, distributing and helping to apply better patterns is an incredibly effective approach to performance improvement.
