Scoping a benchmarking project is the first step

I’m often asked what the first step should be once you decide you need to benchmark. I’m assuming that you have already done the vital steps of understanding the value this benchmarking effort will bring to your organization, aligned it with a current strategy or business issue, and have common agreement within your organization that you should, in fact, execute a benchmarking project.

After these key steps of gaining buy-in and ensuring alignment, you have to nail the scope of your benchmarking project.

Simple scopes are the best

You will inevitably be faced with figuring out how broad vs. how deep to focus your benchmarking effort. You don’t want to attempt a benchmarking effort that will “solve world hunger,” but you also don’t want to narrow your focus too specifically that you risk not getting enough answers to your problems. I will tell you this is an art and a balancing act, but I have learned a pretty simple approach to scoping a project that works more than 90 percent of the time.

Four bullets with four sub-bullets

This is the rule I use. If you can explain the scope of the project in an outline consisting of four bullets with four sub-bullets, you have the correct balance of breadth and depth. I’m sure this will create a lot of discussion within most organizations, and you’ll find numerous ways to “cheat” this system.

For example, the bullets should contain a few words of description. But, I have worked with organizations that have crammed a paragraph of text into each of their sub-bullets. This “work around” usually works out positively, though. The discussions to determine what is (and isn’t) included in the paragraphs help you gain great clarity on the focus of your benchmarking efforts. It also helps the organizations you will approach as benchmarking partners for the project understand exactly what will be asked of them.

The other added benefit of this type of well-documented and (relatively) simple scope is that it helps translate jargon and terms. For example, if you just approached an organization and requested to benchmark their procurement process, you might run into the following issues.

• They don’t know what you mean because they call it “purchasing” not “procurement”.
• You include specific activities from finance and accounting into your definition of “procurement” whereas they do not.
• You show up at their facility for a site visit and realize you have different meanings for “procurement” and they don’t have the right people available for your conversation.

The scope is critical in making sure you and your organization are clear on what you will include in the benchmarking examination, but it also helps you communicate clearly what you expect from your benchmarking partners. This makes for a lot smoother of an effort for everyone.