Prioritizing your biggest issue

“Passion provides purpose, but data drives decisions” Andy Dunn founder of Bonobos

Every decision you make with your teams needs to have a basis in data. Without actionable data, you are making guesses. Whilst some great decisions have been made on gut, a lot of really bad ones have as well.

In the current world, we are surrounded by infinite data sources, and the collections sphere is no different. First up, you need to define the data which is most important to running your team (some suggestions can be found here Some thoughts on key performance indicators and collections). Once you know what you’re measuring, you need to start looking at the reasons you miss you metrics.

Understand drivers of behavior

So you missed DSO this month, why? The first step I take is to look for outliers on various cuts of the metric. Was it a specific product type? country? segment? or specific collections team.

Next ask if there is any reason you’re aware of an issue, and most importantly, ask the team owning it, what happened this month and why. Hopefully it’s an easy fix with one big customer paying a day late, but sometimes it’s a multitude of stories and this is where you need a methodology. My preferred is “Pareto” analysis.

Pareto aka the 80/20 rule

Named after the Italian economist Vilfredo Pareto, it is the concept that 80% of the effects in a system are caused by 20% of things. It can be applied to almost anything, the most common is on customer segmentation where 80% of revenue is typically derived from 20% of customers, if you can keep those 20% of customers happy, you have a fifth of the work, to deliver 80% of your target. Sounds like a much less stressful approach to sales to me. The added benefit of focusing this way is the rule flips typically, 80% of your issues come from 20% of customers, and guess what? they’re almost never in your top 20% of revenue producers.

It’s usually the case that your best customers are as reliant on you as you are on them, so they know your system, they want yo keep you happy as a partner, and they want to grow your business with them as you make them a lot of business too.

Applying pareto to issue analysis

So when you apply pareto to your reasons for missing target, there’s an interesting trend that comes out frequently. That is that 80% of your miss can be attributed to 20% of your issues, ie there’s a couple of specific things which if you fixed, you would deliver a disproportionate increase in performance.

In my case, when I launched collections, I asked my teams to feedback what was thepareto-diagram reason each late paying partner gave when chased. The results showed the number one reason was them not receiving invoices (A simple practice that will get customers to pay faster), and by implementing a simple change in process taking very little effort, we increased our collections within terms from 20% to 65% within a month.

A really important note on capturing data from a team. Give them a framework of answers, no more than 5-6 options and if your results show the biggest issue being “other” you’ve got the wrong reason codes. If you put too many reasons, people default to other as they can’t be bothered to figure out the specifics for every case, too little reasons and data doesn’t show any significant differences.

“Don’t boil the ocean”

The key here is to keep capturing the data, and each month to focus on fixing the number one item only, as one of my mentors put it “Don’t boil the ocean”. Your chances of addressing one thing really well are a lot higher than trying to address five things. The other reason for focusing on one thing is keeping the “science” clean.

What I mean by this is that unless you’ve got a huge team who can carry out multiple tests on distinct customer groups separately, it’s hard to see the impact of a change in isolation unless you restrict your changes to a single item. It’s easy to think you’re going to go faster by changing multiple things, but if you’re using pareto, you’re going to fix more with less, and you want to get those big fixes perfect.

Data in your DNA

It’s important to make sure that teams continue to exercise the practice of pareto every month and they make decisions on data. It’s typical to see hubris in successful teams who have delivered great results using the methodology to start believing they are the experts and can make decisions on the fly. That’s when an issue comes out of left field that’ll blow a hole in your numbers when nobody was looking.

I’ve made it a practice to send back any deck or proposal that doesn’t have a basis in data even when the concept is a good one. Teams quickly learn to ask “what’s the number” and know they’ll be successful if they can back up the talk with a robust dataset.

Test and learns

Many times the justification for “no data decks” is “it’s a test and learn”. Well first point here, how do you know what to test if you don’t have data to tell you something you need to test. Problems are framed because there is an issue showing in the data. If it ain’t broke , don’t fix it.

Conclusion

Use pareto analysis to focus on the single biggest issue you need to fix and stay focused on that until it’s no longer your biggest issue.

Never make a decision or change in process unless you have data to support the hypothesis, and tracking to show the impact.

Don’t try and boil the ocean, fix one problem at a time, starting with the biggest first to make it easy to track the impact of your changes, and to make sure you’re not run ragged chasing 20 issues at once. You’ll be more effective if you stay focused.

 

Comments

One comment on “Prioritizing your biggest issue”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s