Best Practices Rarely Are That

This post originally appeared on BetterProjects.net on May 31, 2010.


Call it a pet peeve. Call it an annoyance. Call it B.S. Call it lying. Call it what you will, but in my career, a ‘best practice’ rarely lives up to its label. If there is one phrase I think needs to die, or at least needs to stop being so sorely abused, it is this one. It is not that there is no such thing as a best practice, but its how this phrase is used and who uses it that so frustrates me. What should have been an objective measure of the capability of a process has now been hijacked to be a marketing catch-phrase.

The Who (Not the Band)

The most egregious misusers of the term have to be sales and consulting teams. I can not remember a single demo I’ve been to where the phrase wasn’t used at least once during the discussion. I once considered making a drinking game out of how often I heard the phrase used, but that would only make a bad cliche worse.

Both of these groups are most often out to sell you something. Because they want your money, they will often 'extend the truth’ to help you view their product or service in a more favorable light. Their logic is that the better they look, the more likely you are to purchase what they are selling. It makes us, as the customers, feel better to believe that a lot of forethought and research went into the flow of a piece of software.

One of my favorite ways to put a stop to this type of nonsense is to ask to see their research. I ask for a survey or market review, conducted by a neutral party, that empirically shows the best process, that gives cost and efficiency measurements and then shows how the vendor’s application follows that best practice. It is at this point when the stuttering and blank looks start up from the vendor’ team.

After they recover from their shock of being called out, they’ll most likely rephrase themselves, saying what they really meant was that the process they’re referring to is something that evolved over many years by working with their many clients and customers. I can not stress enough that a single vendor’s belief in their own, biased experience is rarely worthy of the title 'best practice.’ They may have knowledge expertise in a specific domain which may translate into a better process than you could design on your own, but that does not mean it is the best.

Even if you give the vendor the benefit of the doubt, when you ask the vendor for their process documentation, they will likely not have anything to show you beyond useless whitepapers written by their own implementation teams or training material for the application. Only once in my 9 years as a business analyst, working with dozens of vendors, have I had a vendor that maintained process model information on which their application is based. Even that vendor was unable to explain how their processes, which were really good processes, were truly a best practice.

It is also a misuse of the phrase to equate a best practice with a specific software feature. A best practice can contain a software element, but is not, in my opinion, only a software element. If it is just software, then its a system workflow. I once had an implementation consultant try to tell me that a drill down and two additional navigation clicks for changing warranty dates on a product were a best practice for the industry. As I learned more about the application in question, it became obvious that this was a design limitation masquerading as a best practice. It was something that could be done with fewer steps and no drill-down, but it was easier for the consultant to tell me that it was a best practice than it was to fix their software to be more efficient.

Stakeholders, too!

But its not just sales or consulting teams who misuse this phrase; our business users can be nearly as bad. Usually when I hear a project stakeholder bring up this subject, they are doing so out of a desire to better understand what they should be doing in their business area. Its good to have a stakeholder who is trying to find ways to make their teams more effective in their duties, but asking a vendor this question only perpetuates the problems already mentioned. Its like asking the proverbial fox to watch the proverbial hen house. A vendor is only going to tell you how they do it right and build a case for why you should do it their way.

Another way stakeholders get into trouble by asking after best practice is to have a faulty assumption about what a best practice is. The question is asked in such a way as to lead to a specific, singular answer, but it is rarely that cut and dry. Consider if you will the concept of customer relationship management. How would you design a single best-practice for all companies? Or even for a single industry? What about a single market? This is an absurd question to ask because there frankly is no 'right’ way. Yes, some ways are better than others, but the 'best’ way depends upon not only who your customers are but on how you manage customers internally to your business. A 'best practice’ for one company could be diametrically opposed to a 'best practice’ for another company in the exact same industry.

A third failure stakeholders often face when confronting best practice is assuming that anyone can really tell them what it should be for their business. That’s not to say vendors can not help, they most definitely can help, but they are there to advise, not design for you. Stakeholders who don’t have well defined process and don’t want to take the time to map out what they need often look for a vendor who is willing, for a usually exorbitant amount of money, to do the work for the stakeholder. This frees up the stakeholder to focus on managing their current business without all the time and heavy thinking required to actually create a process that fits their needs.

So what really makes up a best practice? Check back soon for part 2 of this blog to find out that information!
Mastodon