Are Best Practices Really Best?

Reader Question: Is the term “best practice” a misleading buzzword? A current process is normally referred to as “best practice” until analysis is done to identify a new “best practice.” So was the former process not the “best practice” at all and can you reach a point of diminishing returns on the analysis/improvements that could be implemented to a given process?

Kent’s response:

We hear the term “best practice” thrown around quite a bit, both in relation to the practices and techniques that business analysis practitioners use and the process we revise or create as a result.  I think the term came into common use during the benchmarking craze of the 1990’s, and the concept seems very appealing.  If your organization is experiencing some particular issue, take a look around and see what successful organizations are doing and copy what makes them successful.  There are at least two difficulties with “best.”  First, best implies a practice will work in all situations, which I have yet to find is the case.  Second, best implies that there are no better practices, which seems in conflict with the idea of continuous improvement.  I’ll discuss both challenges in turn.

Best Implies ‘in All Contexts’

Problems occur when people apply best practices without paying attention.   Many people see a practice working for another organization so they pick it up and apply it in the same way in their organization, and are often disappointed by the result.  What they fail to realize is that what works great in one situation may work lousy in another situation.  It depends on the context in which the practice is used.

To reinforce the idea that practices work best in particular situations, I avoid using the term “best practice” and instead use “appropriate practice.”  Sure, that doesn’t roll off the tongue as easily, but it does a better job of calling out that this practice is worth looking at, but buyer beware.

Of course, simply changing what you call something is not going to make a huge change in behavior. Once you have recognized that a particular practice has some merit and is worth looking into, the next thing to do is understand when that practice is good to use, and why.  This comes from understanding the context in which it has been used successfully and what characteristics of that situation lend to the practice being appropriate.  If your situation has many of the same characteristics, then great, you have a fit.  If most of the characteristics are different, you can either decide that this practice will not work for you, and look for something else, or you can put some thought into what changes you can make to the practice to fit your particular situation.

For example, many BAs consider use cases as a requirements best practice, to the point where every project they work on must have them.  Use cases are appropriate for describing an interaction between a user and a system, but they are not so helpful for describing what rules need to be followed to make a decision, or what information is needed for performing analytics.  There are other practices that are more appropriate in those situations (decision tables and data models for example), so trying to fit a use case into those situations often leads to extraneous work, frustration, and wasted time.  If you want to increase your value as a business analysis practitioner, learn about the different requirements models available, understand when they are most appropriate, and why and then apply that knowledge on your next project.

Best Is Not a Permanent Condition

Best practice will change over time as new information comes to light through analysis or improvements.  Teams will generally craft the best solution they can based on what they know at that time.  As they start using that solution, they will learn things which point to improvements, in effect heading towards the new best solution based on their new understanding of the situation.  That does not imply that the old solution was not best for that given situation, just that the characteristics of the situation have changed, and the solution may need to change with it.

As an example, consider the progress of transmitting health care claims between providers and insurance companies.  The best practice started as mailing paper, then faxing claims, and then transmitting a standard data set.  Throughout this cycle, the provider and insurance company sought to create a process that worked best given the situation at that time, but the truly successful ones did not let the fact that they were currently using a best practice stop them from revising the practice when new information came available – in other words, when the situation changed.

Is it possible to reach a point of diminishing returns in revising processes?  You bet. You can always perform another change to wring a few more dollars out of a process, but at some point, it will cost you more in terms of money and effort to get those incremental savings.  That time and effort may be better spent solving bigger issues on some other process.  One question I find helpful to ask when revising a process, or solving a problem: “Is it worth it to solve this problem right now?”

What Does This Mean For You?

The short answer is, “It depends.”  I like to joke that’s my consultant’s answer to just about every question.  Joking aside, it’s not far from the truth.  What “it depends” implies is that there is a lot riding on context.  As a business analysis practitioner, deciding which technique to use to describe a solution, or even what type of solution to pursue, learn from others, consider approaches that have worked before, but make sure you know under what conditions those approaches were successful, or not.

Would you like a starting point for approaching common business analyst work scenarios? Along with work samples so you can see what a typical requirements document looks like?

>>Check Out Some “Appropriate” Templates and Samples

Would you like a starting point for approaching common business analyst work scenarios? Along with work samples so you can see what a typical requirements document looks like?

Check out the Business Analyst Template Toolkit – all of the requirements templates are fully annotated and editable by you, giving you a great starting point for starting your first business analyst project or formalizing your work samples.

Click here to learn more about the BA Template Toolkit

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.

Comments

  1. Good article and good points, Kent.

    One minor bone of contention. You wrote, “simply changing what you call something is not going to make a huge change in behavior.” I disagree that changing what you call something would have little effect, since the original name already let the horse out of the barn. However, choosing a proper phrase from the start, such as “appropriate practice” or my preferred choice “good practice” would not encourage mis-use.

    And as you implied, a “practice” is relative, no matter how good it is. “Best” is absolute. So, “best practice” is an oxymoron.

  2. Michelle Swoboda says

    Kent, I enjoyed your article and your views on best practice. I hear this term almost daily as we are working with Oracle to implement one of their modules. The frustrating part is that we have gone through an entire cycle with them and I have still not seen ‘best practice’ as they define it.
    What I agree with is that best practice is different with every situation and every company. The term is too easily used by people who do not clearly understand what they are saying. While it is a good idea to learn from other business’s struggles – you have to clearly understand where you are coming from and where you want to get to.

  3. I couldn’t agree more! In fact, the gratuitous use of “best practice” in the business world as a shortcut to thinking about a problem bothers me to no end.

    As you wrote, when doing anything, it’s always useful to understand if someone has already solved the problem before you came along. That’s where the analysis usually stops when someone shouts “Best practice!” But the true value comes from saying, “Is this solution the right one for my version of the (same) problem?”

    That’s when you truly gain value.