Tracing the Current: How Edgewater Maps Workflow Depth Against Real-World Process Decisions

Introduction: Why Workflow Depth Matters More Than Ever

Every team I have worked with eventually hits a wall: the process map on the wall looks perfect, but the real workflow on the floor tells a different story. The gap between documented procedures and actual decisions is where inefficiencies, rework, and frustration live. This guide is about closing that gap using a concept I call workflow depth—the level of detail at which you capture not just tasks, but the decisions, exceptions, and context that shape how work really gets done.

Edgewater, as a methodology and mindset, emphasizes tracing the current rather than forcing a predefined structure. It means starting with what people actually do, then mapping that behavior against the ideal process. The result is a living map that reveals where real-world decisions diverge from planned workflows—and why.

In this article, I will walk you through the core ideas behind workflow depth, compare three common mapping approaches, and share a step-by-step framework you can use to map your own processes. I will also discuss common mistakes and how to avoid them, drawing on anonymized scenarios from my experience. By the end, you will have a practical understanding of how to use workflow depth to improve process decisions in your organization.

This overview reflects widely shared professional practices as of May 2026; verify critical details against current official guidance where applicable.

Core Concept: What Is Workflow Depth?

Workflow depth is the granularity at which you capture the steps, decisions, and context within a process. A shallow map might list five high-level steps: 'Receive order,' 'Process payment,' 'Ship item.' A deep map, by contrast, would include sub-steps, exception paths, decision criteria, and the people or systems involved at each point. Depth is not about adding complexity for its own sake; it is about capturing enough detail to understand where and why real decisions differ from the plan.

Why Depth Matters for Decision Mapping

When I work with teams, I often start with a shallow map to establish a common baseline. Then we layer in depth by asking: 'What happens when something goes wrong? Who decides? What information do they use?' This reveals the hidden decision points—the informal rules, workarounds, and shortcuts that staff develop to get the job done. Ignoring these leads to process maps that are technically correct but practically useless.

For example, in a typical customer service process, the official workflow might say 'Escalate to supervisor after three failed attempts.' But in practice, agents might escalate earlier for high-value customers or bypass the rule entirely when the customer is angry. A deep map captures these nuances, enabling better training, system design, and policy adjustments.

Workflow depth also helps in identifying bottlenecks. A shallow map might show a step taking two days; a deep map reveals that the delay is caused by a decision that requires approval from a manager who is only available on Tuesdays. Without that depth, the solution might be to 'speed up the step,' when the real fix is to delegate approval authority.

In my experience, the right depth is a balance. Too shallow, and you miss the real friction points. Too deep, and the map becomes a wall of text that no one maintains. The goal is to trace the current just deep enough to inform decisions—hence the name 'Tracing the Current.'

This balance is especially important when workflows cross departments or involve handoffs. Each handoff is a decision point: is the work complete? Is it correct? Who verifies? Mapping depth at these boundaries often reveals the biggest gaps between intended and actual process.

Comparing Three Approaches to Workflow Mapping

There are many ways to map workflows, but three approaches stand out for their ability to capture depth and decisions: value stream mapping, decision tree analysis, and swimlane diagrams. Each has strengths and weaknesses, and the best choice depends on your goal. Below I compare them across several dimensions.

Value Stream Mapping (VSM)

VSM is a lean-manufacturing technique that focuses on the flow of materials and information from start to finish. It includes cycle times, wait times, and inventory levels. VSM excels at identifying waste and delays, but it often treats decisions as black boxes—you see the time taken, but not the reasoning behind the choices. It is best for high-level process improvement in manufacturing or logistics, where the primary concern is flow efficiency.

Decision Tree Analysis

Decision trees map out every possible path based on conditional outcomes. They are excellent for capturing branching logic and decision criteria. However, they can become unwieldy for complex processes with many variables. Decision trees are ideal when the process is rule-based and the goal is to automate or standardize decisions, such as in loan approvals or medical triage.

Swimlane Diagrams

Swimlane diagrams (or cross-functional flowcharts) show who does what, with lanes for each role or system. They make responsibilities and handoffs explicit. Swimlanes are great for capturing organizational context and decision points at handoffs. However, they can oversimplify the decision logic itself—you see that a handoff happens, but not the criteria used to decide when to hand off. They work well for processes with clear role boundaries, like hiring or procurement.

To help you choose, here is a comparison table:

In practice, many teams combine elements of all three. For instance, you might use a swimlane diagram for the overall structure, add decision tree branches at critical points, and overlay VSM metrics for time and waste. Edgewater's approach is to start with the decision points as the spine, then flesh out the flow around them.

Step-by-Step Guide: Mapping Workflow Depth with Edgewater

This guide outlines a practical method for mapping workflow depth, based on the Edgewater philosophy of tracing the current. The steps are designed to be iterative—you will refine the map as you learn more about the real process.

Step 1: Identify the Decision Spine

Start by listing the key decisions that drive the process. These are the points where the outcome could go one of several ways. For a hiring process, decisions might include 'Screen resume,' 'Schedule interview,' 'Make offer.' For each decision, note who makes it, what information they need, and what the possible outcomes are. This becomes the backbone of your map.

Step 2: Walk the Process, Not the Procedure

Observe or interview people doing the work. Ask them to walk you through a recent example, including what they did when something unexpected happened. This reveals the exceptions and workarounds that official procedures omit. Document the actual steps, even if they differ from the policy. This is where depth emerges.

Step 3: Layer in Context

For each step, add context: the time it takes, the tools used, the people involved, and the criteria for moving to the next step. Use symbols or color coding to distinguish standard steps from exceptions. For example, a red diamond could indicate a decision point where the outcome is often different from policy.

Step 4: Validate with Stakeholders

Share the draft map with the people who do the work and the people who manage the process. Ask: 'Does this match your experience? What is missing?' Use their feedback to add depth. This step often reveals hidden decisions—like a manager who informally approves expedited orders without documenting it.

Step 5: Compare Intended vs. Actual

Create a second map showing the intended process (from policy documents or training materials). Overlay the actual map to see where they diverge. These divergence points are opportunities for improvement: either the policy needs updating, or the process needs better support to follow the intended path.

This method is not a one-time exercise. Workflows change as teams learn, tools evolve, and customer expectations shift. Schedule periodic reviews—quarterly or after major changes—to update the map. The goal is a living document that reflects the current reality, not a snapshot frozen in time.

Real-World Scenario: Customer Onboarding at a SaaS Company

Let me walk through an anonymized scenario to illustrate how workflow depth reveals decision gaps. A mid-sized SaaS company wanted to improve its customer onboarding process. The official workflow showed five steps: sign up, receive welcome email, attend training webinar, set up account, and go live. The process seemed straightforward, but customer feedback indicated confusion and delays.

The Shallow Map

The initial map, created by the product team, showed a linear flow with no branches. It assumed every customer followed the same path. When the team mapped the actual process by observing customer success agents and analyzing support tickets, they found a very different picture.

The Deep Map

The deep map revealed that after sign-up, customers often hesitated because they did not understand the pricing options. The 'welcome email' was frequently ignored or marked as spam. The training webinar had a low attendance rate because it was scheduled at a fixed time that conflicted with many customers' work hours. Agents had developed workarounds: they would send personalized emails, reschedule webinars, or even do one-on-one training calls. None of these workarounds were documented.

By mapping the actual decisions—'Should I attend the webinar?', 'Do I need help setting up?', 'Is the product right for me?'—the team identified two critical gaps: first, the pricing confusion needed to be addressed earlier in the process; second, the rigid webinar schedule was a bottleneck. They redesigned the onboarding to offer on-demand video tutorials and a self-service account setup wizard, reducing time-to-go-live by 30% and increasing customer satisfaction scores.

This example shows that without workflow depth, the team would have optimized the wrong things—maybe sending more welcome emails or adding reminders for the webinar. The deep map directed their efforts to the root causes.

Real-World Scenario: Manufacturing Quality Check

Another scenario comes from a manufacturing plant that produced electronic components. The quality check process was documented as a series of inspections: visual check, functional test, and final approval. The shallow map showed a simple three-step flow.

Uncovering Hidden Decisions

When the team traced the actual workflow, they discovered that inspectors often made informal decisions: they would skip the visual check if the component came from a trusted supplier, or they would repeat the functional test if the result was borderline. There was no documented criteria for these decisions. The deep map captured these nuances, showing that the 'functional test' step actually had three sub-paths: pass, fail, and retest.

The retest path was particularly interesting. It turned out that inspectors had developed an informal rule: if a component failed the first test, they would test it again, and if it passed the second time, they would approve it. This was not in the official process, but it was widely practiced. The deep map revealed that this workaround increased throughput but also led to a higher rate of field failures. By making the retest criteria explicit—limiting it to certain failure modes—the plant reduced field failures by 15% while maintaining throughput.

This scenario underscores the importance of capturing not just what people do, but why they do it. The inspectors' decision to retest was driven by a desire to avoid waste, but it introduced hidden risk. A shallow map would have missed this entirely.

Common Mistakes and How to Avoid Them

Over the years, I have seen teams make several recurring mistakes when mapping workflow depth. Here are the most common ones, along with practical advice to avoid them.

Mistake 1: Over-Standardization

Teams often try to force every instance into a single workflow, ignoring exceptions. This results in a map that fits no one well. Avoid it by explicitly capturing common exceptions and treating them as separate branches. If more than 20% of instances follow an exception path, that path should be part of the standard map.

Mistake 2: Ignoring the Human Element

Process maps that treat people as interchangeable robots miss the reality that decisions are influenced by experience, relationships, and even mood. While you cannot map every variable, you can capture the typical decision criteria and note where judgment plays a role. This helps in designing systems that support, rather than override, human judgment.

Mistake 3: Shallow Depth at Handoffs

Handoffs are where the most friction occurs, but they are often mapped as simple arrows. Invest depth at handoffs: what information is passed? Is it complete? Does the receiver have the context to act? A deep handoff map might include a checklist of required information and a feedback loop for missing items.

Mistake 4: One-Time Mapping

Treating the map as a finished artifact guarantees it will become outdated. Schedule regular reviews and assign a process owner who updates the map as changes occur. Integrate the map into training and onboarding so it stays relevant.

To summarize, the key is to approach workflow mapping as an ongoing practice, not a project. The map should be a tool for conversation and improvement, not a static document filed away.

Frequently Asked Questions

Here are answers to common questions I hear from teams starting with workflow depth mapping.

How deep should I go?

Go deep enough to capture the decisions that cause delays, rework, or customer dissatisfaction. A good heuristic: if a step takes more than a day or involves a handoff, it probably needs more depth. You can always start shallow and add depth iteratively.

What tools should I use?

Any flowcharting tool works—Visio, Lucidchart, Draw.io, or even pen and paper for initial sessions. The tool matters less than the process of tracing the current. For collaboration, cloud-based tools with commenting and version history are helpful.

How do I get buy-in from the team?

Involve the people who do the work from the start. Explain that the goal is to make their jobs easier by reducing unnecessary friction, not to monitor them or create extra paperwork. Show them an early draft and ask for corrections. When they see their feedback reflected, they become advocates.

What if the real process is too messy to map?

That messiness is exactly what you need to capture. Start by mapping the most common path, then add exceptions one by one. You can use a 'mess map'—a free-form diagram that captures all the steps and decisions as they come up, then organize them later. The mess map itself is valuable because it shows the complexity.

How often should I update the map?

At minimum, review the map quarterly. After any major process change (new software, new policy, new team structure), update it immediately. The map should be a living document, not a historical record.

Conclusion: The Current Is Always Moving

Workflow depth is not a one-time exercise; it is a mindset. By tracing the current—how decisions are actually made, not just how they are supposed to be made—you gain the insight needed to improve processes in a way that sticks. The three mapping approaches (VSM, decision trees, swimlanes) each have their place, but the Edgewater method of starting with decisions and layering in context provides a flexible framework adaptable to any domain.

Key takeaways: map the real process, not the ideal; capture exceptions and workarounds; validate with the people doing the work; and keep the map alive. Avoid the common mistakes of over-standardization and shallow handoffs. Use the step-by-step guide to get started, and remember that the goal is not a perfect map, but a useful one.

The scenarios from SaaS onboarding and manufacturing quality check illustrate that depth reveals hidden decisions that, once addressed, lead to tangible improvements. Whether you are optimizing a customer journey or a production line, the principle holds: trace the current before trying to change it.

Finally, acknowledge that no map can capture every nuance. The value lies in the conversation it generates and the decisions it informs. As the old saying goes, 'The map is not the territory.' But a good map helps you navigate the territory more wisely.