A pragmatic Six Sigma approach to software.

Anyone who has worked with me knows one of my most frequently asked questions when a meeting gets bogged down in competing solutions: "What problem are we trying to solve, exactly?"

After years of asking that question, I've yet to see a group debating competing solutions give the same answer. That's usually the source of the disagreement! People are often optimizing for entirely different problems, each assuming everyone else shares their understanding of what needs to be solved.

If I’m fortunate enough to be involved from the beginning of a project, I establish a “define the problem, no solutions yet” approach from day one. The problems we identify become a living document throughout the project—not a requirements artifact that gets filed away once development begins, but the foundation we continually use to define success, evaluate decisions, and make sure the work remains focused on the business need. As we learn more, the problems and our understanding of them can evolve, but they remain the reference point for everything that follows.

When I join a project that has fallen behind or isn’t meeting the business need, I start with what has already been done and map it back to the DMAIC process. This helps me find the gaps in understanding, identify the questions that haven’t been asked, and bring the work back into alignment.

I usually do this behind the scenes, rebuilding enough structure for the team to move forward without turning the project into a formal process exercise. I’ve found that teams embrace the approach when it feels like problem-solving rather than process. Eventually, people start to recognize the pattern: the questions come first, the solutions follow.