Starting With The Actual Work
I keep seeing this question come up on forums and in Slack threads, usually from people who just got handed a mess of symptoms and no clear direction on what to do next. The short answer is that it's a structured decision-mapping process, but the long answer is that it only works if you actually do the steps in order and don't skip ahead because you think you already know the problem. The method breaks down into three distinct phases: identifying the current state through evidence, narrowing the gap between where you are and where you need to be, then mapping executable steps to close that gap. Most people conflate the first two phases and jump straight to action, which is why it fails so often in practice. I ran into this exact problem last year with a client who had been trying to reduce their cloud spend for three quarters. They'd already decided on a "cloud optimization initiative" before doing any real diagnosis. Their charts showed cost reduction targets and vendor negotiations, but the actual data told a different story. The primary waste wasn't in active compute — it was in abandoned storage volumes and forgotten snapshot commitments sitting idle. By starting with the diagnosis chart first, we mapped the real flow of spend across the environment. That took us two days instead of six months of failed initiatives.
The Diagnosis Phase
This is where most teams get sloppy. You need to document the current state using measurable indicators, not opinions. Write down what you can observe and verify. If you can't point to a specific number, location, or timestamp, it's not yet diagnosis — it's speculation dressed up as data. Collect evidence across at least three independent sources. One source tells a story. Three sources tell you the truth. I use a combination of system logs, direct observation, and stakeholder interviews. System logs show what's happening. Direct observation shows what's actually being done versus what the documentation says is being done. Stakeholder interviews reveal the assumptions people are operating under. The gap between those three datasets is usually where the real problem lives.
Mapping The Gap
Once you have a clear diagnosis, define the target state with the same rigor. Not a vague aspiration. A specific, observable condition. Then you chart the distance between the two — both the measurable gap and the structural reasons it exists. This second layer matters more than people realize. The measurable gap is the symptom. The structural reason is the cause. Here's something beginners almost never catch: the gap isn't always linear. Sometimes closing 60% of the measurable distance requires 80% of the effort because you're running into a structural constraint that wasn't visible in the diagnosis. I spent weeks on a logistics routing project where the diagnosis was clean — clearly inefficient paths on paper — but the gap mapping revealed that the constraint wasn't the routes themselves, it was the loading bay scheduling that made the theoretical shortest paths impossible in practice. No amount of route optimization would fix that. You have to map the constraint before you map the solution.
Get the Full Details
Building The Action Chart
Actions should flow directly from the gap analysis, not from a generic best-practices list. Each step needs to address a specific identified constraint and produce a verifiable change. The easiest way to check if an action is properly derived is to ask what gap it closes. If you can't answer that, it's not part of the chart. I structure mine as a sequence with dependencies clearly marked. This means identifying which actions must happen before others can start, and where parallel paths are possible. The dependency mapping is where this method actually earns its keep. Without it, you're just making a to-do list. With it, you're seeing the critical path and the slack between tasks. One thing I've found that nobody talks about: these charts degrade fast in dynamic environments. A chart built for a stable system might still be useful after two weeks. A chart built for a system that changes weekly needs to be treated as a living document, not a one-time exercise. I set up a biweekly review cadence where we invalidate any action whose underlying assumption has shifted. It sounds heavy but it takes maybe twenty minutes and saves you from executing dead steps.
Where This Breaks Down
It doesn't work when the problem is purely political. If the real blockers are people protecting their budgets or turf, no amount of diagnostic rigor will surface them — those constraints hide behind organizational structure, not operational data. In those cases, you need a stakeholder mapping exercise before you even start this process, or you'll build a perfectly logical chart that gets shelved for reasons you never anticipated. It also breaks down when you lack access to accurate baseline data. If you're diagnosing a system you didn't build and the documentation is unreliable, you can end up spending more time reconstructing the current state than you would have spent just running an experiment or building a small prototype. In those situations, I sometimes pivot to a minimal viable test instead of a full chart, gather real data from the test, and then apply this method to the cleaned-up picture.
Practical Details
For the charting itself, I use a simple matrix format with four columns: observed condition, identified constraint, proposed action, and expected outcome metric. The column discipline matters more than the tool. I've seen people spend days setting up elaborate flowcharts in Visio or Lucidchart with no more insight than what fit in a spreadsheet. The structure does the work, not the software. If you want a template to start with, I keep a basic version in Google Sheets that most people can copy in under a minute. It's not fancy. It has the four columns, a dependency column, and a status tracker. The status tracker is the part people skip and then regret — without it, you lose track of which actions are still active versus which you've invalidated during reviews. The real takeaway here is that the diagnosis-to-action link is the fragile part. It's easy to produce a long list of actions that feel productive but have no clear connection to the actual gaps you identified. I've learned to check that link by reversing the process: starting from each action and asking whether it addresses a constraint that was actually proven during diagnosis. If it doesn't trace back, it doesn't belong in the chart.
