In these long, hot (and wet! At least in the Northeast) days of summer, while people are off on vacation and doing other summer-type stuff, I’ve decided to use the “down” time to do something new. I’m working on a Lean Six Sigma Black Belt project around increasing the effectiveness of resource allocations on analytic projects.

Unfortunately, I have to be vague about the specific project I’m working on, but I can tell you a little bit about Lean Six Sigma (LSS) – it’s the beautiful marriage of two improvement methodologies. Lean is designed to improve process efficiency, while the goal of Six Sigma is to reduce defects. The combined methodology provides a fantastic framework for evaluating transactional business processes. Like any methodology, it comes with a wide set of tools that practitioners can use to hone in on a specific business issue and come up with ways of assessing and evaluating the problem.

LSS provides a strong framework for problem ideation (the D in the Six Sigma “DMAIC” – Define, Measure, Analyze, Improve, Control phases of a project). As I began to go through the rigors of the define phase, I rapidly realized how poor a job we do (as business leaders or project managers) on project definition. We all know that a poorly defined project is not likely to meet business needs, and are often scuttled because they take too long or don’t realize business value. I’ve seen this pain so often in business intelligence and analytic projects: The end state and objectives are so poorly defined that true value is never really reached (because nobody bothered to figure out what “value” meant). In my own particular project, I started with a big lofty goal, and then I started to get nervous. I quickly realized that I was “boiling the ocean” and that my target objective wasn’t realistic. Fortunately, everything in LSS has to be actionable, and to get to that point, you have to use data. Wow – sounds like business intelligence and analytics to me! Another huge differentiator for LSS is that everything is from the customer perspective – which is also a huge mind change. Here are my steps:

1. I mapped out the process flow for the problem I was trying to solve. It’s a big, complex process that spans multiple functional areas. The process flow diagram illustrated the overall complexity of what I was trying to solve for and allowed me to select a subsection of the process that I could reasonably act on. But then I had an “aha!” moment: I mapped the process from an internal perspective, and that didn’t necessarily reflect what the customer wanted or expected out of the process. I overlaid the customer process and looked for areas that weren’t aligned.
2. That’s fine – but everything within a LSS initiative is quantified…EVERYTHING. Fortunately, I was able to find customer survey data and I created a decision tree in JMP. Lo and behold – I now had quantifiable proof that I was tackling the right issue and that it was manageable and meaningful to the customer. In LSS, you should not seek to address more than two customer requirements per LSS project. My tree results gave me two highly correlated variables that aligned to my project focus area. I stopped panicking, because the data gave me direction.
3. My project ideation still isn’t refined enough, so I conferred with my Master Black Belt mentor, who reminded me that continued analysis of data helps refine the problem statement. I’m off next week to uncover additional data that will drive my next steps. Imagine, letting data guide your decisions!

The point here is that regardless of the initiative you’re embarking on, exploring and analyzing data is an excellent way to define your next steps. It will help you objectively make better decisions and drive accountability. Even though you might not be working on a process improvement project, applying the LSS define methodology can work well for creating manageable project scope and critical success factors. And, oh yeah…it’s all about the customer.

Tell me how you're spending your summer!