One of the terms that I like least in the business lexicon (apart from “solutionizing,” but that’s a completely different rant) is “best practices.” The idea of best practices is one that is reified in improving organizations, particularly by consultants who charge ridiculous amounts for pointing them out to you.
The conventional wisdom (such that it is) is that if you are making change, improving practices, optimizing service delivery or enhancing how you manage your projects, you had better be sure that you are adopting best practices.
So let’s break down my issues with the concept (and there are actually several). To do so, it actually helps a little bit to go back to first principles to understand just what we are theoretically talking about. According to Wikipedia, best practices represent practices that are “generally accepted as superior to any alternatives; that produce results that are superior to those achieved by other means.”
There’s a lot to theoretically like in that definition, if it were possible. But frankly, there is a great deal more to find problematic. For starters, there is an implicit assumption that one, single way exists to that is substantially and materially better. Behind that assumption is a much larger one that there is (and should be) only one optimal way to solve a problem.
A slightly more helpful qualification, and a telling one, is the idea that best practices have “become a standard way of doing things.” In other words, they are very often simply accepted as the manner by which you accomplish something. Critical here is that all judgement of appropriateness, relevance and impact has gone away. What we’re left is simply what has become the default. It is, quite literally, the process equivalent of ‘no one ever got fired for buying IBM.’
My essential problem with the idea of best practices is that there is a lot of emphasis on the process, without any real consideration of how that process gets used. Or whether it should get used at all. The process is how the doing of something is codified. It’s how we write it down, make it simple and structured, and explain it to people. In doing that, there is always an abstraction. We are often taking something that is relatively intuitive and fluid, and we are giving it hard and explicit structure.
What gets left in most process definitions is the instruction of what to do, how to do it, and the results that should be produced at the end. What gets lost, however, is an understanding of the choices that led to that structure. The thinking process goes away, and the structured results are what is left over.
The perfect illustration of this lies in the origin story of modern project management. While numerous authors make the argument that we have been managing projects for thousands of years (see, for example, the pyramids, the library at Alexandria or the great wall of China) the reality is that modern project management as we know and practice it today has only been around for a number of decades.
The history of project management actually begins in the 1950s. The critical path method emerged at the DuPont Corporation as a means of managing complex plant turnarounds, and many other practices (including the Program Evaluation and Review Technique) were developed to support the complexity of managing the development of the Polaris nuclear missile platform in the United States Navy. What we know as ‘best practice’ in project management largely originates in these projects.
What gets missed is how these techniques were developed. In collaboration with several large consulting firms, both organizations went through a prolonged course of experimentation and development. They tried many different approaches and adaptations, some of which were more successful than others. What worked, they kept. What didn’t work, they evolved or discarded. What was left is now the essentials of what you learn in a modern project management course.
The challenge is that, while many of the aspects of project management has now attained the status of ‘best practice’ in the “standard way of doing things” meaning of the term, that is not in any way to say that what is defined is best, or superior, or superlative to any other alternatives. Certainly, what has been developed is arguably a great way to manage a large scale industrial or military development project in the 1950s, but that is not our context or our current reality.
The tools of project management are in fact designed to support management in traditional, hierarchical, top-down and power-driven structures. Many of them are about rigour, oversight and control. Project management principles are designed to structure, delegate and scrutinize work, ensure accountability and provide a healthy amount of cover-your-ass documentation in case anything goes wrong. These approaches are not inappropriate in traditionally operated mid-20th-century corporate environments. They are also occasionally appropriate in some larger and more traditional corporate entities that still exist today. But they are no longer (if they ever were) universally applicable.
That leads us back to the challenge of best practices. Going back to the earlier definition, there is an important qualification that will no doubt make some ardent process fans squirm. Specifically, there is an explicit acknowledgement that sometimes a “best practice” is not applicable or appropriate for a particular organization’s needs. In other words, what is labelled ‘best’ may not, in actual fact, be ‘best.’ It may be completely or wholly impractical and unusable in specific contexts.
The largest challenge is knowing just what those contexts are. Processes don’t (although they arguably should) come with disclaimers that say “best used in these particular contexts; entirely inappropriate in these.”) Making this determination is left to the expertise—and particularly the judgement—of the process designer or organizational change agent responsible for introducing a new order of things.
This is where, unfortunately, genuine organizational needs often collide headlong with traditional expectations, view points and perceptions of “best practice.” There is a known way of doing things, there is a presumption that is they way things should be done, and if we are adopting a new approach than we should arguably align with what is (theoretically) tested and proven.
Except that, in many instances, processes and standards that get marketed under the label of being best practices often are entirely untested and unproven. They are frequently developed anecdotally and often by committee. As a result, they represent the lowest common denominator definition of the practices that participants can live with. Processes and standards are far less often based upon research, empirical evidence or an analysis of what approaches effectively produce results in which contexts.
For example, I know of absolutely know one that fully complies with the prescriptions and bromides of the Project Management Body of Knowledge, which is far too often labelled a “best practice,” particularly in a North American context. If they did, they would be producing a minimum of fifteen separate and distinct management plans spanning hundreds of pages of paper, simply to get a project started. The standard says that you should. We don’t. If we did, we would bury projects in far more bureaucracy, administration and red tape than they are already arguably subjected to.
For someone working to implement an appropriate, effective and reasonable process in their organization, they have a challenge on their hands. They need to consider what is actually contextually relevant and appropriate, which may genuinely fly in the face of conventional wisdom, traditional practice or what is considered appropriate.
It would arguably be far easy to go with best practice and be done with it. Who, after all, could argue? It’s proven! It’s published! Other organizations use it! Why, it’s a best practice! But it would be wrong.
The significant challenge for any process designer is responding to the unique qualities of their organization. What gets defined and implemented needs to fit the culture, the structure and the environment of the organization. It needs to be appropriate to the magnitude of the work being managed, and the formality of process that is accepted and considered useful. Building—or adapting—contextually relevant process is hard work. It is, sadly, made harder by the mythical presumptions that underlie the existence of best practices.
The true test of any process—in any context—is that it is used, and it is used in the manner that was intended and that it produces results. That’s a high bar to clear. Implementing new approaches and ways of working require not just designing effective processes, but also managing and supporting their introduction. And the only way a new way of operating will be successful is if the people that will use the process see themselves as being more successful in the new way of operating than they are today.
Best practices need not apply. But effective, relevant and appropriate ones that work for people are more than welcome.