Lean Six Sigma Project Metric – Common Pitfalls and Best Practices
Selecting the right Project Metric is crucial for Lean Six Sigma projects. In this post, I will talk about how to correctly identify, scope and define the Project Metric for your LSS Project. And most importantly, how NOT to. This is based on the insights drawn from a plethora of projects that I have led, mentored and/or reviewed. Happy reading.
When you pick up a lean Six Sigma project, it is about improving a particular process. This improvement has to be measurable. And hence, we tend to pick a Metric that we define, baseline and then track for improvement till we reach the defined target. Your project is deemed complete, and successful, only when this defined target for this defined metric is reached. Hence, a lot depends on what metric you choose for your project and how you define it.
Scope of the project metric
The scope of your project plays an important part in choosing the right metric for your Lean Six Sigma project. You need to ensure that the Project metric that you chose is within your control and that you can control majority of the levers / drivers that impact your project metric. Lets understand this with an example.
People familiar with Accounts Payable function will agree that Paid On Time, or POT, is one of the critical, business level metric. It measures the percentage of invoices that an organization pay within the due date. The base is all invoices that the organization pays in that particular time period.
The best case scenario is to pay each and every invoice exactly on the due date, neither late nor early. However, due to certain internal process designs and payment run schedules, some invoices do get paid before the due date. We will still consider them as paid on time. But invoices which do not get paid on or before the due date cause dissatisfaction for the vendor. And also increases the volume of help-desk queries raised by the vendor for invoice status update, increasing cost for the organization. There might be late payment penalties involved as well. And the organization might be losing on early payment discounts.
Download my latest eBook – Lean Six Sigma Acronyms
Contains 220+ LSS acronyms and abbreviations, a handy reference guide for all LSS Practitioners. And its FREE!
Paid on Time as a Project Metric
At the onset, its seems like POT is a good metric to pick up for improvement as your Lean Six Sigma Project Metric. You can define it, measure it, baseline it and track improvement as well. And its important for the organisations leadership as well, which is a very good thing.
However, there are lot of sub processes and other metrics which impact POT. Paid on Time depends on;
- The vendor submitting the invoice on time for payment. Do the vendor submit it on time? Or after the due date is passed? And this actually happens by the way.
- The speed of scanning / converting the invoice to soft copy and feeding into the invoice processing workflow or ERP.
- Invoice processing cycle time of the invoice processing teams.
- Exception approval process, the time it takes and number of approvals needed based on the exception type.
- The frequency of the payment runs.
- The payment terms agreed between the organization and the vendors.
- And multiple such things.
Now, lets say, you are from the invoice processing team and wish to pick up a Lean Six Sigma project. Will Paid On Time be a good project metric to pick up? To answer this, you will need to evaluate your control on all the above aspects. From invoice receipt to payment process. More often than not, you will not be able to control all of them. The only thing that you will have in your control is to reduce the invoice processing time of your team. That does have an impact on POT but will be marginal. And it will not do justice to all the efforts and resources that you put into the project. It might also happen that POT %age drops although your team processes the invoices faster. Just because, some other driver fell apart.
So what Project Metric to pick?
Answer is simple. If you are part of the Invoice processing team, concentrate on your scope. Identify the driver from within your scope which impacts Paid On Time. Pick that driver and define a metric around it.
You surely can control the invoice processing cycle time and can work towards reducing it. You can also influence exception approval process. Hence you can look at reducing exception approval lead time. If you pick these metrics, the improvement in these metrics will be proportional to the efforts that you put in. The metric movement will show the true quantum of improvement based on your efforts. Both of these project metric will eventually have a positive impact on Paid on Time as well.
However, if you belong to the CFO organization of the company and / or are part of the leadership team overseeing Procure to Pay, Source to Pay or Accounts Payable function, it becomes a different story. In such case, you will be able to influence the end to end process. Right from influencing the vendors to taking decisions to alter payment run schedules. In such case, it would make sense to pick POT as your project metric.
Download my latest eBook – Lean Six Sigma Acronyms
Standalone Vs Relative Project Metric
Metric, in general, can be a standalone metric or a relative metric. Lets understand what it means.
Lets take a simple example of Accuracy. Accuracy by definition is number of transactions processed correctly divided by the number of total transactions processed. Here we are looking at the proportion of correctly processed transactions relative to the total transactions processed. Hence, its a relative metric.
If you look at Number of overdue invoices as a metric, it is a standalone metric. We are not comparing it with anything as such. When we convert this into percentage of overdue invoices with total unpaid invoices as the base, it becomes a relative metric.
Standalone Metrics as Lean Six Sigma Project Metric
As a practice, you should never chose a standalone metric as your Lean Six Sigma project metric.
Lets say instead of picking % overdue invoices as a project metric, you pick number of overdue invoices and start your project. Your baseline, lets say, was 15,000 invoices which were overdue when you started your project. Your target was to reduce this number to 5,000. You gather all the required data, do your data analysis and hypothesis testing. You arrive at critical drivers, root causes, identify solutions and implement those solutions as well. And you start seeing a drop in number of overdue invoices month on month or week on week.
However, this drop can either be attributed to your efforts and improvements that you did. Or, it might just be the result of drop in total invoice that you receive. During your baseline, you had 100,000 invoices coming in each month. Something changed in the business or just because of seasonality, now you get just 50,000 invoices per month. This will surely reduce the proportion of overdue invoices as well by approximately 50% showing movement in your project metric. But then, its not because of improvements in the process. The process is still the same. The input has changed.
And what happens if the number of invoices that you receive goes up. Instead of 100,000 invoices, you start getting 200,000 invoices. Logically, your overdue invoices will jump from 15,000 to 30,000 per month. Even after all the efforts and improvements, you will never be able to meet the target of 5,000 overdue invoices in such a scenario. And for no fault of yours.
Relative Metric as Lean Six Sigma Project Metric
All of the above can be avoided it you convert the standalone metric to a relative metric. Lets see what happens if you chose % overdue invoices instead of number of invoices.
Your project metric will always be a proportion of total invoices. In business as usual state, without doing any improvements, it will not change outside a specific range. (This range is the normal variation that you have in your incoming volume, click here to read about variation in your process and how to identify it, opens in a new tab). Even with increase or decrease in incoming invoices, your overdue invoice percentage will remain more or less the same.
Your project metric baseline now is 15% (15,000 overdue invoices on the base on 100,000 total invoices). Your target now is 5% (5,000 overdue on 100,000 invoices). If the incoming invoices increase from 100,000 to 200,000, the overdue invoices will also increase by the same proportion and your metric will still be at 15%. Now if you have done some process improvements and fixed the gaps, this will lead to lower invoices getting overdue. And will reflect in this proportion. So even with increase in incoming invoices to 200,000 and with 5,000 overdue invoices, your project metric will be at 5%. This can now be attributed only to your project and efforts. And you will be able to close the project successfully.
Related Post : What are the measures of Variation?
The same holds true if the volume decreases to 50,000. Natural reduction in overdue invoices will be to 7,500. Still at 15%. Only your improvements will further reduce the overdue invoices to 2,500 to achieve the target of 5% overdue invoices.
Download my latest eBook – Lean Six Sigma Acronyms
Dollar Value as a Project Metric
A lot of Lean Six Sigma project owners these days, specially in the service industry, tend to use dollar values as their Project Metrics. They define the goal as “reduce cost by $5 Million” or “Increase revenue by XX Million dollars” or “Reduce open and aged debit balance from $1,000,000 to $100,000. This is outright incorrect. And I will tell you why?
The Lean Six Sigma project methodology is not the correct methodology to directly reduce cost or increase revenue. The methodology is the make your processes better, faster, cheaper, leaner thereby reducing cost, improving customer / vendor satisfaction which results in increased revenue. The goal of a Six Sigma project is to Process Improvement. The benefit that you get because you fixed the process or transformed it using Lean and Six Sigma tools is the dollar value. So we should clearly be able to differentiate between what a project metric is and what the benefit is. And not tend to treat them as same.
The project metric should always be defined at a unit level where each unit can be tracked flowing through the process. When an invoice flows through the system right from receipt and scanning till its posted for payment and finally paid, it doesn’t matter what the value of that invoice is. Its the invoice that experiences the process and its flaws / gaps. When we try to improve a process, we look at what the invoice goes through and how it’s flow can be improved. Once the flow is fixed, the next invoices will go through the improved flow irrespective of what the invoice value is. Seems common sense, but a lot of project owners fall pray to this error.
First, pick up a project metric that you have end to end control on. You should be able to influence all key drivers impacting the metric. Else, revisit the project metric.
Second, always built a relative metric, never a standalone metric.
Third, never have dollar values as your project metric. It should always be the unit that flows through the process.
Thank you for reading. Do let me know what you think about this post or if you have any questions / suggestions in the comment section below. Happy to hear from you.
Do take time and go through the post on 12 important and essential things to do in Define phase of a Lean Six Sigma DMAIC project (opens in a new tab).