Week 21: Old CI Tools Still Work. Here's What's Actually Obsolete.
Old CI Tools Still Work. Here's What's Actually Obsolete.
I was at a conference last year where a speaker — young, confident, good slides — told the audience that fishbone diagrams were outdated. Relics of the 1960s. No longer relevant in a world of AI and predictive analytics.
The audience nodded. A few people tweeted approvingly.
I sat in the back and thought about the fishbone diagram I'd used three weeks earlier to help a drilling crew in the North Sea solve a recurring equipment failure that had been baffling their engineering team for four months. The fishbone didn't just help us find the root cause. It helped the crew — the people who actually operated the equipment — structure their knowledge in a way that made the invisible visible. Two hours on a whiteboard. Problem solved. Equipment running.
But sure. Outdated.
Here's what I've noticed over twenty years of doing this work. There's a pattern in how people dismiss tools. And the pattern almost always reveals more about the person than the tool.
The people who call fishbone diagrams outdated have usually never used one properly. They've seen the template. They've read about it in a textbook. Maybe they've filled one in during a training exercise. But they've never stood in front of a team of operators on the floor, drawn the fish on a whiteboard, and worked through the structured thinking that the tool demands.
The people who call 5 Whys simplistic have usually never gone beyond the third why with a team that knows the process. Because the truth is, getting to the fifth why — the real fifth why, not the textbook version — requires the kind of disciplined thinking that most teams find genuinely challenging. It's not simple. It's elegant. And there's a difference.
The people who dismiss PDCA as "too basic" have usually never maintained the discipline of actually completing all four steps. Plan, Do, Check, Act. Most organisations get through Plan and Do, skip Check entirely, and never get to Act. The tool isn't basic. The organisation's application of it is incomplete.
I've spent my career using tools that Kaoru Ishikawa developed in the 1960s, that Walter Shewhart developed in the 1920s, that Taiichi Ohno refined in the 1950s. And they work. They work in 2026 exactly as effectively as they worked when they were created.
Gravity is from the 1600s. Nobody suggests we stop using it.
Now, I'm not a luddite. I'm not arguing that nothing has changed. The world is different. Data availability is different. Technology is different. The speed at which organisations need to make decisions is different. And some tools genuinely do need updating.
So let me give you my honest assessment, built from twenty years, forty-plus organisations, and deployments at Shell, Johnson Controls, KCA Deutag, and Petrogenium. What's essential. What needs updating. And what's actually dead.
Still essential. No debate.
The fishbone diagram. Ishikawa's cause-and-effect diagram. The visual structuring of potential causes around a problem statement. This tool is essential because it does something that no software can replicate: it organises team thinking. It forces a group to be systematic about brainstorming. It prevents the team from jumping to the first plausible cause — which, in my experience, is wrong about seventy percent of the time. At Shell, fishbone diagrams were a standard part of every problem-solving session I facilitated across thirteen years. They worked in refineries. They worked in shared services. They worked in drilling. They'll work in your organisation too.
PDCA. Plan, Do, Check, Act. The foundational cycle of improvement. Deming popularised it, Shewhart designed it, and every effective improvement programme I've ever seen is built on it. The temptation is to see PDCA as too simple. It isn't. It's the operating system. Everything else is an application running on top of it. You can change the applications. You can't change the operating system.
Process mapping. Whether you call it value stream mapping, swimlane diagramming, or just "drawing the process on the wall," this is non-negotiable. I wrote about this recently in detail. The act of mapping a process — current state, as-is, no aspirations — reveals waste that no data system will ever surface. Because data tells you what's happening. The map tells you why.
Standard work. The documentation of the current best-known way to perform a task. Not the procedure manual that sits in a binder. The living, visual, regularly-updated document that the person doing the work actually references. Standard work is the foundation of stability, and stability is the foundation of improvement. Without it, every improvement is temporary.
5 Whys. When done properly — and that's the critical qualifier — 5 Whys is one of the most powerful root cause tools in existence. The problem is that most people do it badly. They ask shallow whys. They accept vague answers. They stop at the symptom level and call it a root cause. Properly facilitated, with data backing each answer, 5 Whys cuts through organisational noise faster than any statistical tool I know. I've used it at every level from shopfloor to boardroom.
Needs updating. Still valuable, but the application has evolved.
Control charts. Shewhart's statistical process control. The concept is timeless — understanding variation, distinguishing signal from noise, knowing when a process has genuinely changed versus when it's just fluctuating within normal bounds. But the manual plotting of control charts on paper is, yes, outdated. AI and real-time dashboards can generate control charts continuously, flag special causes automatically, and do it across hundreds of parameters simultaneously. The tool isn't obsolete. The manual application of it is. Understand the theory. Use the technology.
SIPOC. Suppliers, Inputs, Process, Outputs, Customers. A high-level process overview tool. Still useful for scoping, still useful for getting a team aligned on boundaries. But in an era where processes cross multiple systems and geographies, SIPOC needs to be more dynamic. A static SIPOC on a wall is a starting point, not an endpoint. Combine it with digital process mapping tools that can be updated in real time and shared across teams.
A3 thinking. The A3 report as a paper document has limitations. The A3 as a thinking framework — problem statement, current condition, analysis, target condition, countermeasures, follow-up — is as powerful as ever. I'd argue it's more important now than it was ten years ago, because AI can generate plausible-looking analysis that hasn't actually gone through the disciplined thinking the A3 demands. The format can evolve. The thinking must not.
Pareto analysis. The 80/20 principle. Still fundamentally valid. But with modern data tools, Pareto analysis should be dynamic, real-time, and multidimensional. Static Pareto charts based on last month's data are being replaced by live dashboards that show you the current distribution of defects, delays, or costs. The principle endures. The static chart is becoming a limitation.
Actually obsolete. Let them go.
Manual data collection sheets. Paper-based tick sheets for collecting defect data, cycle times, or production counts. In 2026, if your data collection still involves someone with a clipboard and a pencil, you have a technology problem, not a methodology problem. Automated data capture isn't a luxury. It's a prerequisite for effective CI. Every minute someone spends collecting data manually is a minute they're not spending analysing or acting on it.
Lengthy certification-focused belt training without practical application. The four-week classroom Black Belt course where people learn statistical tools they'll never use on a case study that bears no resemblance to their work. This model is dying, and it should. Belt training needs to be embedded in real projects, with real data, solving real problems. The certification should come from demonstrated capability, not from surviving a training programme.
The "CI department" as a standalone island. Having a central CI team that operates separately from the business, runs its own projects, and reports its own savings is a model that I've seen fail far more often than it succeeds. CI needs to be embedded in operations, owned by line leaders, and supported — not directed — by a centre of excellence. The department model creates dependency. The embedded model creates capability.
Here's what frustrates me about the "old tools are dead" narrative.
It lets people off the hook.
If fishbone diagrams are outdated, you don't have to learn to facilitate one properly. If 5 Whys is simplistic, you don't have to develop the skill of asking genuinely penetrating questions. If PDCA is too basic, you don't have to confront the uncomfortable reality that your organisation can't even complete all four steps of the most fundamental improvement cycle ever designed.
Dismissing old tools is easy. Mastering them is hard. And mastering them is what separates organisations that improve from organisations that just talk about improving.
At Shell, we didn't succeed because we had the newest tools. We succeeded because we had disciplined application of proven tools, combined with relentless leadership cadence and a culture that valued going to the Gemba. The tools from the 1960s worked because the people using them understood the principles behind them.
That's always been the differentiator. Not the tool. The understanding.
So here's my challenge.
Before you dismiss a CI tool as outdated, ask yourself: have I ever used it properly? Not seen it in a training deck. Used it. On the floor. With a team. On a real problem.
If the answer is no, you're not qualified to declare it dead. And you might be surprised at what it can do when applied with discipline, purpose, and genuine understanding of what it was designed to achieve.
The oldest tools in CI are like the oldest tools in mathematics. They're old because they're fundamental. And fundamental things don't go out of date.
If you want a professional-grade set of proven CI tools — including fishbone templates, A3 formats, PDCA trackers, and process mapping frameworks that you can deploy immediately — the CI Mastery Toolkit gives you twenty-five ready-to-use templates. Find it at stormholt.org/products/ci-mastery-toolkit.
New to Stormholt? Start here — it locates your stage in minutes.
Building capability? Stage III — Skill — the tools, the courses, the simulations.