Will I spoil KM if I tell people “best practices” don’t exist?

Twice in the last week, I came across important internal guidance documents which mentioned the term “best practices” and the need for the organization to use them.

I was wondering, would  it be Scroogelike of me to tell them that just like with Santa, there isn’t really any such things as best practices.

(Aside: someone tweeted to me that they also have a problem with the term “practices” let alone “best practices”. I’m not going to take that on here – for me a practice is rather broad term for the sum total of the methodology, approach, set of actions and pattern of behaviours that we use in our work to tackle a particular problem – in other words it’s what we do at work. What is important is what we actually do “in practice” rather than whatever theory or idea we use to rationalize it).

So what’s my problem with the term “best practices”?

1. It implies we actually know the best way of doing something. In most cases we don’t. We might have developed some principles and good approaches based on experience – but this doesn’t necessarily mean that this is THE best way of tackling a particular issue. In some areas there might be a well established set of procedures, but these are usually best expressed in the form of guidance (and see my earlier critique of guidance). In practice though I’ve often seen the term used for practices about which there is relatively limited evidence or only a very few document examples of the practice being used. Often organizations (and individuals) are under pressure to quickly scale up successful approaches and this creates a risk of  over generalizing from a few successful examples. Also people who run successful programmes can overestimate how generalizable they are which leads us to:

2. We don’t always know WHY something works, even if it was successful. This is important because if we don’t know which parts of an approach are key to making it successful, then it can be hard to replicate into other contexts. Indeed it might be that certain elements of an approach can fairly easily be adapted from one circumstance to another while others are very context specific. If the context specific parts are also critical to its success then it can be extremely difficult to successfully transplant an approach from one context to another.

3. Use of this term can discourage us to look for ways of improving how we do things. All we need to do is follow the instructions, and so we don’t need to think too much about whether the approach makes sense in our current context. In fact we are led to the assumption that if things are not working then it is probably because we didn’t follow the practice properly rather than that the practice itself didn’t really work.

4. The description of a practice is not the same thing as the practice itself. However we document it and whatever evidence we collect, it represents only a summary of what happened and will most likely miss out important “tacit” elements of what made a practice successful, especially issues such as personal rapport between those involved, cultural sensitivities, the skills and instincts of those involved, as well as the importance of personal commitment to succeed (It is easy to include the need for personal commitment and ownership when documenting an approach – it is wholly another thing to reliably recreate it).

Despite these limitations I believe there is a value in documenting experiences and sharing them. To tackle this, in our work we have developed a set of three types of practices (and note the careful wording) to describe experiences that are promising (i.e. there may be elements that might potentially be replicated, or that important programming lessons can be gleaned from them for use in the future and in other situations):

Innovation – these are summaries of a programmatic or operational innovations that have or are being implemented under our mandate. These innovations may be pilot projects or new approaches to a standard programming model that can demonstrate initial results, and may generate potential learning for other situations.

Lesson learned – these are more detailed reflections (rather than just a description) on a particular programme or operation and extraction of lessons learned through its implementation. These lessons may be positive (successes) or negative (failures); both are valuable and encouraged. Lessons learned have undergone more of a review process than innovations, require some evidence to support them and generally have been implemented over a longer time frame.

Good practice – these are well documented and assessed programming practices that provide evidence of success/impact and which are valuable for replication, scaling up and further study. Documentation of good practices require more time and effort because of the need for assessment or evaluation results. The more evidence the better, as these practices should add value to development programming in a particular sector or region.

---

 

 

Each level requires a little more in the way of evidence of success and replicability (in fact we have more detailed descriptions of each including an indication of suitable information sources, and how these should be documented). In the case of “good practices”, of which we identify relatively few, we generally look to see if the same or similar approaches have been used in different countries and contexts, and how the results vary to help better understand what is “good” about the practices. Some colleagues had requested that we give detailed how-to guidance on the process for collecting these – but perhaps unsurprisingly we’ve resisted and rather chosen to share information on different methods that different offices have used, so they can see what works best for them.

A few important features of how these practices are defined and intended to be used:

1. They are not “final” but can and should evolve and be further developed overtime as we gain additional experience. What is a good practice now might be thought sub-par in future when we identify better ways of working, or the practice itself may be refined and improved over time.

2. They are not considered “definitive”. They are an example of a good approach not THE best approach. There may be several different good practices or approaches to dealing with the same issue. And different aspects of each of the practices might be combined or mashed-up to suit a particular situation.

3. They are intended to be used for inspiration, not for cloning. The idea is that those developing programmes can review the experiences of others and use them as a basis, or as a potential idea source for ways of tackling new programmes – but they should adapt them to their own circumstances, or choose to only adopt them in part or not at all based on their own judgement of the situation they are dealing with.

4. We recognize that the documented experience only captures part of the actual experience,  and that there is a lot of tacit knowledge in the heads of those people who worked on it from our side and the counterpart and partners side. We therefore encourage people to follow up and contact those involved in the original project to get greater insight into an experience they find promising and interested to replicate. In a sense the documented practice is intended to be the beginning of a process of thinking and consultation rather than the end of it.

This is not a perfect system, and we are constantly trying to improve it. We’re also trying to hold the middle ground by   explaining it to those who still think we need centrally validated “best practices”, and to those who think there is no benefit in documenting  practices at all.