The power of a problem series: Using simple measurements to bring focus
This is the fourth article of our six-part power of a problem series. Missed the last article? Read it here.
Last week, we shared tips on how to define a problem with a host of open-ended, descriptive questions designed to gather the facts you need to make others aware of the problem in order to build momentum for solving it. In this post, we introduce another tool you can use to define a problem: simple measurements. These are measurements we, as Lean specialists, often suggest that local governments gather before we embark on a process improvement project.
This week's scenario illustrates how simple, quantifiable data can help bring focus to the dimensions of the problem.
Now that Fatima, Wellsville's finance director, had a better understanding of the issues lurking in the accounts payable process, she was ready to discuss what she had learned with Ellen, the city manager.
Ellen was generally supportive of Fatima's efforts to improve the accounts payable system. However, she asked Fatima to provide her with some data before giving her the green light to improve the process.
Seeing Fatima's face fall as she anticipated a drawn-out analysis, Ellen reassured her: “There's no need to overthink this. What I need is high level: volume, cost, distribution and time. Let me help you understand what I'm looking for.”
Volume: What is the big picture?
First, focus on the general size and scope of the process where you've identified a problem, using just high-level data. For the accounts payable process, Fatima found:
Accounts payable cuts checks for vendors every Tuesday. On average, accounts payable sends 100 checks out each week. About a quarter of them are payments for the public works department. One accounting clerk spends about half of his time on paying invoices; the chief accountant and Fatima also spend some time each week on review and approval.
These answers cover the basics, giving a clearer picture of the scope of the problem and who touches the process. Once you dig into the process, you may want to ask more detailed questions, but this is all you need at this stage of defining the problem.
Cost: What is the problem costing your government?
Next, turn to readily available data that tells a clear, commonsense story about the breadth of the problem. You might think about both direct costs and potential future cost savings. Fatima learned that:
Because of Wellsville's history of late payments, one of the public works department's vendors closed the city's account and refuses to accept orders from the city. The accounting clerk said that the new vendor charges more for the same supplies, costing the city money.
Distribution: Can you quickly identify patterns?
Some initial data collection can help focus your efforts to spot patterns. It may help confirm or debunk any hunches you have about where the biggest problems lie.
Fatima set up a simple tally sheet where her staff could track the number of times they had to ask another department to clarify an invoice and the types of clarifications needed. She discovered three common issues:
The price quoted in the purchase order did not match the price on the invoice, the invoice lacked all required authorizing signatures, and inconsistent use of account codes. While all departments were asked some clarifying questions, public works was contacted for clarification most often.
One note of caution. When gathering data, be careful not to jump to conclusions, quick solutions or single out one department or person as the source of the problem.
Time: How is the work flowing?
Time can be one of the most important things to measure, but it can also be the most difficult to capture in an accurate and meaningful way. Although some software systems have built-in reports that can help you start to measure time, staff may not understand how to use report fields consistently or skip over them entirely. This could make canned reports unhelpful or even misleading. Fatima found:
The new finance system's analysis section had a report that suggested that the city was paying invoices 29 days after it received them. That made her a bit uncomfortable, so she wanted to learn more about what was happening. She set up a simple spreadsheet and asked her team to log invoices they received for payment for one month. She decided to capture four points in the process: the date the vendor issued the invoice, the date stamped “received by the city,” the date the invoice got back to finance, and the date the city issued the check.
Keep in mind that performance metrics are highly sensitive to volume. The fewer bills you pay each check run, the more variation a measure like “average time to pay invoice” will have. For example, one very late payment in a small batch of payments will have a large effect on the average and make your metric less meaningful.
Measurement: How many measures do you need?
Start by measuring what's available and easy to understand. Remember that measures based on facts—events and conditions that are directly observable—are much harder to argue with than measures that are subject to interpretation. Start with measures where something either happened or didn't—a yes or no measure. Measures that result in a percentage or number can be more time consuming than they are worth if you can't ensure everyone involved agrees with their meaning.
Here are some tips to keep in mind when using measurement to help define the problem.
- Focus on the data that is common and understandable. Look for measures based on information that all of your colleagues will recognize as relevant and reliable, not data they have never seen before and are likely to question.
- Collect data in simple and informal ways. Fatima's use of tally sheets and logs for a short period was helpful, particularly for confirming her hunch.
- Be transparent about where the data came from. Use reliable sources, but inform users of the data's limitations. If you identify that your data collection process is part of the problem, challenge colleagues to help you develop meaningful metrics to monitor performance going forward.
What if the problem just seems too big to tackle?
It's not uncommon to feel overwhelmed at this point. You've learned a lot about the problem, and it has likely grown tentacles—the more you know, the more you begin to see other related problems. Do you feel closer to the finish line? The answer may be “no” because your problem has grown, and that's ok! Next week, we'll explore how to break problems into manageable pieces.