I am well aware that I’ve ranted about “best practices” in the past. That is as much for semantic reasons as it is for pragmatic ones. Quite simply, best practices usually aren’t. Best practices assume a world where there is right and wrong, and there is a clear answer to how to proceed in a given situation. If there is one thing that I’m entirely certain of, it’s that we don’t live in that world.
As I’ve discussed before, best practices only apply in the domain of simple problems, where there are clear answers as to how to do something. They are most appropriate as a reflection of “if-then” thinking, where we can operate on a checklist of “if this occurs, then do this.”
Once things get even the slightest bit fuzzy, best practices break down. There is no one, best way to proceed. There are alternatives, each of which have pros and cons. There are options and opportunities, and there are risks and complications. In these situations, expertise can make a difference. That’s not because there is a more refined use of “if-then” so much as expertise can offer a broad array of choices and possibilities, and some guidance on how they may play out in a given situation.
Despite that, there is a tendency to cling to the possibility that best practices can exist. In my experience, this tends to be for a couple of reasons. Ironically, those reasons have very little to do with an objective assessment of the situation, or of identifying a preferred response. Instead, they’re more often rooted in the personal wants and preferences of the person using the phrase.
The first reason we hang on to a professed love of best practices is about control, and imposing a way of doing something on others. The thinking is that by labelling something a “best practice,” that expectation is unassailable. A not-so-subtle implication behind the assertion is that you’d have to be an idiot not to do it that way.
A notable examples of this occurred when I was engaged to deliver a keynote presentation for an organization. While speaking isn’t my full-time job, I do get those sorts of invitations once in awhile. And I speak frequently enough to have developed and honed a presentation approach that works well for me. What the client contact wanted, however, was for me to adopt a very different approach, using their ‘standard’ presentation template because the template was built around presentation “best practices.”
And what, you might ask, were those best practices? In essence, it was your very typical PowerPoint presentation, using a very large font, that demanded three to five bullets per slide of preferably less than seven words each. Now, that’s not a wrong approach to build slides, necessarily, although it is a very boring one. I can point to many guidebooks and training courses that recommend exactly that method to presentation development. And I can point to as many resources that will argue that PowerPoint in general is a horrible way to deliver presentations.
Now, I’ve made my peace with PowerPoint (after a fashion). I do usually have slides when I present. But they’re pretty meaningless without me actually speaking alongside them, injecting them with meaning and context. In many instances, my slides don’t even have words. Or they might have a very, very few words that have been chosen for very specific reasons. The slides play a supporting role, but they aren’t front and centre to how I speak. Particularly because they are intended to support, not dominate, I spend a lot of time on how they look and what they say. And it was very obvious that the template that this client wanted me to use was going to be pretty unworkable.
This should have been an easy conversation to have. It was a surprisingly difficult one. The client contact was very stuck on the idea that their template structure was based on ‘best practice’ and that I should use it. What became fascinating to me was the recognition that this insistence really became a passive aggressive way of trying to impose a specific approach. The relevance or merit of what was being asked was not even a factor. “Best practice” was basically code for “this is what I want you to do and how I want you to do it.”
The other reason that best practices get clung to fiercely tends to be a fervent wish that “best practices” as an idea could actually be true. Specifically, it’s a product of wanting the certainty that there can be a one, single, best possible way to get things done.
In large part this is the same driver that we had in school to get perfect on our tests, or to get an “A” on our assignments. We want there to be a right answer. We want there to be a best approach. We want there to be a clear diagnosis, and a definitive prescription of what to do. The degree to which this is a personal driver has a lot to do with personal tolerances for ambiguity and uncertainty. The more that “it depends” is an unacceptable answer, the greater the belief in best practices as mantra.
One of the clearest examples of observing this occurred when helping to develop an estimation capability for a client organization. Now, estimates have their own complex relationships with uncertainty. Estimate, after all, is simply a three syllable word for “guess.” But we want our estimates to be educated guesses. We want them to be informed by knowledge, by experience, by some level of insight of how things might play out and what is going to be required to do the work. In fact, this is an excellent illustration of how expertise helps to mitigate uncertainty when things get complicated. The more we know, the more informed our estimates can be.
Now, developing an estimation capability for an organization is its own challenge. There is a process, of sorts. I’ve worked to develop a good dozen or so over my career, and each has followed a similar pattern. You need to understand the projects being estimated, develop meaningful measures of how big they are, how complex they are and how different situations can influence cost and schedule. You need to develop models of previous project performance, and use these to extrapolate how to develop future estimates. All of this is pinned to a common project process that reflects the standard stages and activities by which a client does their project work.
While this is easy to define in the abstract, doing it in real life is inevitably complex, difficult and messy work. In this particular case, there were varying degrees of history available. There was no common process, or even agreed upon stages. Every project manager that developed estimates did so using their own rules of thumb, many of which were deeply intuitive and defied attempts to get them to explain how they arrived at the numbers that they did. And there was no agreed upon way of objectively defining how big a given project was, or what drove its complexity. All of this to say that there were a lot of moving parts that need to be sorted and organized if meaningful answers were going to be possible.
The irony is that meaningful answers were possible, it was just going to require a lot of meandering and exploration to figure them out. The challenge was that the sponsor of the project wanted to know how the work was going to be done, and in particular how long it would take and how much it would cost. And my repeated answers were distinctly unsatisfying, in that while I could identify with great clarity the work of the next two or three or four weeks, everything beyond that was maddeningly vague. I could discuss the key stages of work that still had to occur, and provide ballpark ideas of schedule and cost, but that was truly the limit of what was possible to know.
That’s not to say that I was being deliberately vague or obtuse. It’s not because I didn’t want to get pinned down. I wasn’t resisting accountability. The nature of the project was such that the work was an on-going process of learning. What we learned in the immediate weeks would shape and define what was possible to happen from there. The more we learned, the more we could plot next steps and determine what needed to happen afterwards. But the learning had to happen, the process needed to be allowed to unfold, and results couldn’t be forced.
The tension between a sponsor that wanted clear answers and a project that defied giving them created understandable conflict. From the sponsor’s perspective, the answers should be clear, straightforward and above all reliable. His presumption was that this was known work that the organization had done before, successfully, and so defining and codifying it shouldn’t be hard. And “best practices” of project management (which is in his eyes why they were hiring me) should tell them how to get the work done. All of which completely ignored the fact that previous estimation success was entirely the product of intuition and personal experience of individual project managers, and in no way representative of an organizational capability.
What’s important to note about both of these examples is that the holding on to “best practices” as a touchstone has nothing to do with objective reality. There is nothing in either of these examples that suggest that there are external, knowable, single ways to do things. There are many ways to tell stories and deliver presentations. There are multitudinous approaches to managing projects, to developing strategy and to navigating change. There are choices, and in different circumstances different alternatives will be more or less preferable. But there is no single path, and no objective truth.
The desire for that objective truth doesn’t come from outside, however. It comes from within. It’s a product of personal preferences and viewpoints that are deeply uncomfortable with uncertainty, complexity and ambiguity. It’s a result of feeling vulnerable and exposed, and wanting to impose control. Above all, it is an attempt to impose order and certainty on the world, despite our living in a world that pretty much defies every effort to do so. Whether as a weapon or as a crutch, those are most likely to cling to “best practices” do so because they fear the world is as messy, awkward and difficult as it actually is.
Although, if we’re truly honest about it, it’s the messy and difficult situations that are the most interesting, the most challenging and provide the greatest opportunity to make a difference. They’re just not amenable to clear, simple and straightforward answers of how to go about doing it.