Diving into the world of process improvement, I’m thrilled to sit down with Marco Gaietti, a veteran in management consulting with decades of experience in business management. Marco’s expertise spans strategic management, operations, and customer relations, making him a trusted voice in uncovering the hidden causes of recurring problems. Today, we’ll explore how root cause analysis (RCA) transforms challenges into opportunities for lasting improvement, delving into practical tools, real-world applications, and strategies for bridging team perspectives. From the simplicity of the 5 Whys to the structured depth of fishbone diagrams and beyond, Marco will share stories and insights that bring these methods to life.
How have you seen root cause analysis reveal deeper systemic issues in a real project, and can you walk us through a specific case where you uncovered multiple layers to find a lasting solution?
Thanks for asking. I remember a project with a mid-sized manufacturing firm where equipment breakdowns were a constant headache, halting production almost weekly. On the surface, it looked like a simple fix—replace the broken parts and move on. But when we applied RCA, we started peeling back the layers. First, we found that maintenance schedules were being skipped, which led to premature wear. Digging deeper, we discovered that the maintenance team was understaffed due to budget cuts, and those cuts stemmed from a company-wide focus on short-term cost savings over long-term reliability. It was a classic case of systemic priorities clashing with operational needs. We addressed this by restructuring the budget to prioritize staffing and implementing a strict maintenance checklist with accountability measures. Seeing the production line run smoothly for months afterward was incredibly satisfying—it felt like we’d finally fixed the foundation, not just patched a crack.
Can you share a story of using the 5 Whys method on a straightforward issue, walking us through each ‘why’ question and revealing what surprising root cause emerged?
Absolutely, the 5 Whys is a favorite for its simplicity. I recall working with a small factory where a critical machine stopped during a peak production run. We started with the problem: the machine isn’t working. Why? The motor burned out. Why? It overheated. Why? There was no proper cooling system check. Why? Maintenance logs showed the checks were skipped. Why? The operator wasn’t trained on the new protocol after a system update. That final ‘why’ was the eye-opener—training gaps were the root, not just a bad motor. We could’ve stopped at replacing the part, but getting to that training issue meant we rolled out a refresher course for all operators. I still remember the relief on the floor manager’s face when downtime dropped significantly. It’s a small victory, but those add up when you fix the real problem.
When tackling complex problems with a fishbone diagram, how do you approach categorizing causes, and can you describe a time this tool led to actionable fixes?
The fishbone diagram, or Ishikawa, is fantastic for complex issues because it forces you to think broadly. I approach it by gathering the team and brainstorming causes under key categories like people, process, equipment, materials, environment, and management. A memorable case was with a logistics company struggling with delayed deliveries. We drew the fishbone and started filling it in: under ‘people,’ we noted inconsistent driver training; under ‘process,’ unclear scheduling protocols; under ‘equipment,’ aging delivery vans; and under ‘management,’ a lack of accountability metrics. Categorizing like this helped us see the interplay—poor training compounded bad scheduling, and old vans made it worse. We prioritized fixes like a driver training program and a van replacement schedule, while management introduced weekly performance reviews. I can still picture the team huddled around that diagram, lightbulbs going off as we connected the dots. Within a quarter, delays dropped by nearly half, and the structure of the tool made everyone feel heard.
Using Pareto analysis and the 80/20 rule, how do you decide which causes to prioritize, and can you share an example with specific metrics where focusing on the ‘vital few’ made a difference?
Pareto analysis is all about focusing on what matters most, and I prioritize based on impact—whichever causes drive the majority of the problem get tackled first. I worked with a retail chain once where customer complaints were piling up, affecting their reputation. We listed all complaint sources and measured their frequency. Turns out, about 80% of complaints came from just two issues: late shipments and poor in-store service. Out of 500 monthly complaints, 400 were tied to these ‘vital few.’ We didn’t have the resources to fix everything at once, so we zeroed in on streamlining the supply chain for shipments and training staff on customer interaction. Within two months, complaints dropped to under 200 a month, and customer satisfaction scores climbed. I’ll never forget the store manager’s grin when he showed me the feedback forms—it felt like we’d turned the tide by not spreading ourselves too thin.
How have you applied Failure Mode and Effects Analysis (FMEA) in a high-risk setting, and what was the impact of identifying potential failures before they occurred?
FMEA is a lifesaver in high-risk environments because it’s proactive. I used it in a healthcare project focused on a hospital’s medication dispensing process. We walked through every step—prescription entry, pharmacist review, dispensing—and brainstormed how each could fail. We identified risks like misread prescriptions due to handwriting or system errors during data entry, rating their severity and likelihood. One study we referenced found 90 failure modes in a similar process, so we knew the stakes were high. We implemented safeguards like mandatory double-checks and barcode scanning for verification. The impact was immediate—error reports dropped by over 30% in the first six months. The challenge was pushback from overworked staff who saw it as extra steps, but seeing patient safety improve made it worth the effort. I still feel a sense of pride walking into that hospital knowing we prevented harm before it happened.
What’s your perspective on using the 8D problem-solving method for cross-functional collaboration, and can you recount a time you led such an effort with lasting results?
The 8D method is ideal for cross-functional issues because it brings everyone to the table with a clear structure. I see it as a roadmap for collaboration, ensuring no voice is missed. I led an 8D effort for an automotive supplier dealing with recurring defects in a component that affected multiple departments—design, production, and quality control. We formed a team, defined the problem as inconsistent weld strength, contained it by pulling defective batches, and dug into root causes like equipment calibration drift. Each step, from planning corrections to verifying results, involved input from all teams, and I mediated debates to keep us focused. Ensuring the solution stuck meant setting up automated calibration checks and quarterly cross-team reviews. I remember the tension in those early meetings melting into camaraderie as we saw defects vanish. Years later, I heard they still use those protocols—it’s rewarding to know the collaboration we built had legs.
How has a platform like monday work management helped streamline your RCA investigations, and can you share a specific incident where automation or centralization made a tangible difference?
Platforms like monday work management are game-changers for RCA because they keep everything in one place and cut manual grunt work. I used it during a project with a service company facing recurring billing errors that frustrated customers. We centralized all data—customer complaints, transaction logs, staff notes—on the platform, so no one was chasing emails or spreadsheets. Automation was key; we set up triggers to notify the team when new errors were logged and scheduled follow-ups to verify fixes. This saved us hours of coordination and caught patterns, like a glitch in one billing module, faster than we would have manually. The result was a 40% drop in billing issues within a month, and the team felt less overwhelmed without the constant back-and-forth. I can still recall the relief of seeing real-time updates on my dashboard—it was like having an extra team member keeping us on track.
With perception gaps in teams, such as 92% of senior leaders feeling ownership is fostered versus 76% of individual contributors, how do you bridge differing perspectives during RCA, and can you share a story of its impact?
Bridging perception gaps in RCA is critical because everyone sees the problem through their own lens. I focus on creating space for all voices, from frontline staff to executives, through structured discussions and anonymous feedback if needed. In a tech firm I consulted for, system outages were blamed on user error by management, but operators insisted it was software glitches. We held workshops to map the issue together, using data like error logs and staff surveys to ground opinions in fact. Hearing a junior tech describe frustration with unclear error messages shifted leadership’s view, and we found the root was inadequate user training on updates. The solution—a tailored training rollout—cut outages by 25%, but more importantly, the team felt united. I still remember the room’s energy shift when people realized they were finally being heard; it turned skepticism into trust.
What’s your experience with barrier analysis in critical safety incidents, and can you walk me through a case where identifying failed safeguards led to stronger controls?
Barrier analysis is invaluable for safety-critical situations because it focuses on what should’ve stopped the problem. I applied it after a warehouse incident where a worker was injured by a falling pallet. We mapped out the safeguards—stacking protocols, equipment checks, safety training—and found multiple failures: stacks exceeded height limits, forklifts weren’t inspected regularly, and training was outdated. Identifying these gaps was sobering; it felt like walking through a house of cards that had collapsed. We strengthened controls with strict height guidelines, mandatory daily equipment logs, and refresher safety courses. Post-implementation, near-misses dropped noticeably, and the warehouse manager told me workers felt safer just knowing the rules were enforced. That visceral sense of preventing harm sticks with me—it’s why I’m passionate about getting barriers right.
How do you decide when to combine RCA methods like fishbone and 5 Whys for a thorough investigation, and can you describe a time mixing approaches led to a better fix?
I decide to combine RCA methods when a problem’s complexity demands both breadth and depth. Fishbone diagrams give me the big picture by mapping multiple causes, while 5 Whys drills down into specific chains. I used this mix for a client in food processing where product contamination kept recurring. We started with a fishbone to brainstorm causes across categories—people (hygiene practices), equipment (cleaning tools), and process (sanitation schedules). Then, we picked the most likely cause, inadequate cleaning, and applied 5 Whys: why wasn’t equipment cleaned properly? Because schedules were rushed. Why? Staff were overworked. Why? No backup team during peak times. Combining methods revealed both systemic staffing issues and specific process flaws, leading us to hire temporary staff and adjust cleaning protocols. Contamination incidents virtually disappeared, and I can still taste the relief—pun intended—when the client passed their next audit. It proved to me that blending tools often uncovers fixes a single method might miss.
Do you have any advice for our readers who are looking to implement root cause analysis in their own organizations?
My advice is to start small but think big. Pick a recurring issue that’s manageable and use a simple method like 5 Whys to build confidence in the process—don’t jump into complex tools without practice. Involve your team from the get-go; their insights are gold, and buy-in makes solutions stick. Remember to document everything, not just for compliance but to learn and improve over time. And don’t rush—thorough analysis upfront saves endless firefighting later. I’ve seen too many leaders push for quick fixes only to face the same problem months down the line, and there’s nothing more frustrating than spinning your wheels. Trust the process, and you’ll see workflows strengthen in ways you didn’t expect.
