Mapping, measuring, and redesigning legal processes before selecting technology — applying Lean, BPR, and Six Sigma methodologies to eliminate waste and build workflows that scale.
## Process Before Technology
The highest-return investment in Legal Operations is getting the process right before selecting the technology. When a well-designed process is automated, the gains compound: speed, consistency, and scalability all improve simultaneously. This is why process mapping dramatically improves technology implementation success rates (industry surveys consistently cite process-fit as the leading predictor of implementation success). Organisations that invest in process design first consistently outperform those that lead with technology selection.
Process mapping must precede technology selection. The discipline is straightforward: before investing a dollar in any tool, whiteboard the current process, identify where value is created and where friction occurs, redesign the process, and only then determine what technology (if any) is needed to execute the redesigned workflow.
## Whiteboarding: Untangling the Mess
### The Discovery Exercise
Process mapping begins with discovery — and discovery begins with humility. The Legal Ops leader who assumes they understand how work actually flows through the legal department is almost certainly wrong. The documented process (if one exists) describes how work is supposed to flow. The actual process — shaped by workarounds, informal agreements, and years of accumulated exceptions — is often unrecognisable from the documented version.
**Step 1: Select the process.** Start with the highest-volume, highest-friction process. In most legal departments, this is the contract review and approval workflow. Other common candidates include legal intake (how the business submits requests to legal), matter opening, and regulatory approval.
**Step 2: Shadow the process.** Follow a real request through the actual workflow from submission to completion. Document every step, every handoff, every wait state, and every decision point. Talk to every person who touches the process — not just the lawyers, but the business requesters, paralegals, assistants, and anyone else involved.
**Step 3: Map the “as-is” state.** Whiteboard or digitally map the current process using a simple notation: rectangles for activities, diamonds for decisions, arrows for flow direction. Include wait states (the time between handoffs where nothing happens). In most legal processes, the total wait time exceeds the total work time by a factor of 3–5x.
**Step 4: Identify the friction points.** Mark every point in the process where:
- Work queues lack clear SLAs
- The same information is entered into multiple systems
- Approvals exist without clear substantive purpose
- The process branches based on tribal knowledge rather than documented criteria
- Handoffs occur via email rather than structured workflow
### The Redesign Principles
With the as-is map on the wall, apply five redesign principles:
**Eliminate.** Remove steps that consume resources without creating value. The most common candidates: approval layers that exist for political rather than substantive reasons, duplicative data entry, and review steps where the reviewer consistently approves without changes.
**Standardise.** Where multiple people perform the same activity in different ways, define a single standard approach. This is especially important for contract review, where different lawyers may apply inconsistent standards to the same clause types.
**Automate.** Identify steps that are rules-based, high-volume, and low-judgment. These are candidates for workflow automation (routing, notifications, escalations) or AI-assisted processing (clause extraction, risk scoring).
**Parallelise.** Where sequential steps have no genuine dependency, run them in parallel. A common example: commercial review and legal review of a contract can often happen simultaneously rather than sequentially — saving days from the cycle time.
**Measure.** Build measurement into the redesigned process from the start. Every process should have a defined cycle time target, a throughput metric, and a quality indicator. Without measurement, you cannot determine whether the redesign achieved its objectives.
### The Conversation is the Intervention
The most valuable output of a process mapping exercise is often not the improved process — it is the conversation. Getting business stakeholders, lawyers, and support staff in the same room to discuss how work actually flows (versus how everyone assumes it flows) produces insights that no technology tool can replicate. The whiteboard session itself is the intervention.
Participants typically have different mental models of the same process. The commercial team believes contracts are reviewed by lawyers within three days; the lawyers believe commercial approval is the bottleneck; the assistants know that requests spend two weeks in an email queue before anyone sees them. Only when these perspectives surface can the team identify the true friction points.
This is why process mapping should be a structured, visible exercise — not a behind-the-scenes analysis. The discipline of building the map together, labelling every step, and agreeing on the “as-is” reality is where the value lives.
## Process Engineering Methodologies
The redesign principles above provide a starting framework. For more systematic improvement, legal operations draws on three complementary methodologies, each suited to different improvement scenarios.
### Lean for Legal: Eliminating Waste
Lean methodology originated in manufacturing (Toyota Production System) but applies directly to knowledge work. The core principle: identify and eliminate *muda* (waste) — activities that consume resources without creating value from the customer’s perspective.
The eight types of waste, applied to legal workflows:
**1. Waiting.** A contract sits in an approval queue for three days. A lawyer waits for a business stakeholder to provide information. A paralegal waits for a reviewer to return feedback. In most legal processes, waiting time is 60–70% of total cycle time. Reducing wait states through parallel processing, clear SLAs, and escalation protocols has dramatic impact on cycle time.
**2. Overprocessing.** A contract undergoes five layers of review when two are sufficient. A legal intake request generates ten questions when three would suffice. A document is reformatted three times to meet different stakeholder preferences. Overprocessing consumes resources without creating corresponding value. Identify it by asking: “If we removed this step, would the end product be genuinely worse?”
**3. Defects.** Errors that require rework: a contract is reviewed twice because the first review missed a liability clause, documents are rejected because they don’t meet formatting standards, agreements are returned by the business because legal approval language was unclear. Defects drive rework cycles that consume 10–20% of legal team capacity in most departments.
**4. Movement.** Information moves from email to the intake system to the CLM tool to a spreadsheet tracker to another email. Each handoff is an opportunity for information loss or delay. Reducing movement means consolidating systems or automating handoffs.
**5. Inventory.** Open requests sitting in queues. Drafted documents awaiting approval. Approved templates waiting for use. Work-in-progress inventory ties up capacity and extends cycle time. Just-in-time processing (creating documents when they are immediately needed rather than in batches) reduces inventory.
**6. Non-utilised talent.** A paralegal who could screen 80% of contracts and escalate only complex ones instead processes all contracts the same way. A business stakeholder who could self-serve answers to routine questions instead emails lawyers. Failing to match task complexity to team member capability wastes human potential.
**7. Motion.** Unnecessary physical or digital movement. A lawyer has to navigate five menus to find the contract review checklist. A business user has to fill out the intake form twice (once in email, once in the system). Motion is the digital equivalent of unnecessary movement; it slows processes and increases error rates.
**8. Transportation.** Moving information between systems. Data entered into a web form is manually transcribed into a case management system. A contract template is downloaded from SharePoint, edited, and re-uploaded. Information that should flow automatically instead requires manual handling.
**Applying Lean to a Legal Process:**
1. **Map the current state,** identifying where each type of waste occurs. Use colour coding: red for high-impact waste, yellow for moderate waste.
2. **Prioritise the waste causing the longest cycle time or the most rework.** In most legal processes, waiting and defects account for 70% of total waste.
3. **Design the future state,** applying the five redesign principles to eliminate waste. A typical Lean redesign reduces cycle time by 30–50%.
4. **Implement incrementally,** testing the redesigned process with a pilot group before rolling out department-wide.
5. **Measure relentlessly.** Track cycle time, throughput, defect rate, and queue length weekly. Lean success is visible in data.
### Business Process Reengineering (BPR): Clean-Sheet Redesign
Business Process Reengineering is more radical than Lean. Where Lean optimises the current process (taking 10% out here, 15% out there), BPR asks: “If we were designing this process from scratch today, knowing what we know, what would it look like?”
BPR is appropriate when:
- The current process is fundamentally misaligned with business needs
- Incremental improvement has plateaued — you have already taken 20% out of cycle time and see diminishing returns
- Technology capabilities have changed dramatically, enabling new workflows that were not previously possible
- Market conditions have shifted, and the old process serves yesterday’s business model
The BPR question is not “How do we do this faster?” but “Why do we do this at all? What if we did it completely differently?”
**Example: Legal Intake Redesign via BPR**
A legal team currently manages intake through a complex workflow:
- Business user submits a request via email
- Intake coordinator routes to appropriate lawyer
- Lawyer reviews and decides whether legal involvement is needed
- If yes, lawyer sends a templated response with next steps
- If no, lawyer directs the business user to proceed without legal
This process takes 3–5 days (mostly waiting) and creates multiple back-and-forth emails.
A BPR redesign asks: “What if the business user self-triaged their request using a decision tree, and only lawyer-required requests entered the workflow?”
The redesigned process:
- Business user accesses a decision tree: “Is this a new customer contract?” → “What revenue is involved?” → “What jurisdiction?” → etc.
- Based on their answers, the system either (a) provides a standard approval template the user can proceed with, or (b) auto-routes to the appropriate lawyer with all context pre-filled
- Lawyers see only requests that genuinely require human judgment, not the 60% of routine queries that could be self-served
- Average intake handling time drops from 3–5 days to either “instant” (self-served) or 24 hours (lawyer-reviewed)
The BPR redesign fundamentally restructures the workflow, not incrementally optimising the old one.
**When to Choose BPR:**
BPR is appropriate when you are addressing one of these scenarios:
- A core process is broken and resists incremental fixes (legal intake that has too many channels, contract review that is fundamentally misaligned with contract types)
- Technology capabilities have evolved, enabling workflows that were previously impossible (AI-assisted clause extraction, workflow automation, RAG-based decision trees)
- Market conditions have shifted (rapid business growth requiring 5x capacity, shift from product to service delivery requiring different approval workflows)
- A process serves a business model you no longer operate
BPR is *not* appropriate for fine-tuning or routine optimisation. That is Lean territory.
### Six Sigma for Legal: Reducing Variation
Six Sigma originated in manufacturing and focuses on reducing process variation — the deviation between consistent performance and actual performance. While Lean asks “Where is the waste?”, Six Sigma asks “Why is our performance inconsistent?”
Six Sigma uses the DMAIC cycle:
**Define:** What is the problem? A contract review should take 5 business days, but it ranges from 1 day to 30 days. What are we trying to improve? Define the current state (baseline), the desired state (target), and the metric.
**Measure:** Collect data on the current process. Track cycle time for the past 50 contracts. Plot the distribution. Identify where the variance occurs: some contracts are reviewed in 1 day (why?), others take 30 days (why?). The measurement phase often reveals that different reviewers assess complexity differently, or that some requests get priority treatment while others wait.
**Analyse:** Why does the process have such high variance? Root cause analysis reveals: (1) there is no documented complexity assessment, so each reviewer makes their own judgment about priority; (2) approval workflows are undocumented, so handoffs are unpredictable; (3) there is no escalation trigger, so high-complexity contracts sometimes sit in a queue for weeks. The variation is driven by process design, not random factors.
**Improve:** Standardise the process to reduce variance. (1) Create a documented complexity rubric and assign all incoming contracts to a complexity tier; (2) Document approval workflows and assign ownership; (3) Implement escalation triggers so contracts stuck for more than 5 days are flagged. The goal is to bring all contracts within the 5-day target, eliminating the 30-day outliers.
**Control:** Implement control charts that track cycle time weekly. When a contract exceeds the 5-day target, investigate and adjust. This ongoing monitoring prevents regression.
**Six Sigma vs. Lean:**
- Lean eliminates waste and variability through simplification
- Six Sigma reduces variability while maintaining complexity
Six Sigma is useful when:
- A process is already reasonably well-designed but inconsistent (your contract review target is 5 days, and you often hit it, but sometimes it stretches to 20 days)
- Inconsistency is driving customer frustration or internal rework
- The process itself should be standardised (you want consistency across multiple offices or multiple teams)
Six Sigma is less useful when the process itself is broken (in which case Lean or BPR is more appropriate).
## Choosing Your Methodology: A Comparison
Use this table to select the right approach for your situation:
<table header-row="true">
<tr>
<td>Scenario</td>
<td>Methodology</td>
<td>Goal</td>
<td>Timeline</td>
<td>Effort</td>
</tr>
<tr>
<td>A process works but is slow. Incremental improvements have delivered results.</td>
<td>Lean</td>
<td>Reduce cycle time by 25–40% by eliminating waste</td>
<td>3–6 months</td>
<td>Moderate: mapping, pilot, measurement</td>
</tr>
<tr>
<td>A process is fundamentally broken or misaligned with business needs. Need radical redesign.</td>
<td>BPR</td>
<td>Redesign from first principles. Target: 50–70% cycle time reduction or 10x efficiency gain.</td>
<td>4–8 months</td>
<td>High: requires deep analysis, stakeholder alignment, significant change management</td>
</tr>
<tr>
<td>A process is reasonably designed but inconsistent. Performance varies wildly.</td>
<td>Six Sigma</td>
<td>Reduce variation in cycle time, quality, or cost. Goal: 95%+ of instances meet the target.</td>
<td>2–4 months</td>
<td>Moderate: data collection, root cause analysis, standardisation</td>
</tr>
<tr>
<td>You need quick wins while planning larger redesigns.</td>
<td>Lean</td>
<td>Early improvements build credibility and fund larger projects</td>
<td>1–3 months</td>
<td>Low to moderate</td>
</tr>
<tr>
<td>You need to scale a process across multiple teams or geographies.</td>
<td>Lean + Six Sigma</td>
<td>Remove waste, then standardise to ensure consistency across all instances</td>
<td>6–12 months</td>
<td>Moderate to high</td>
</tr>
</table>
## In the Trenches
**The Intake Process That Was Not a Process**
Tom Andersen, Legal Ops Manager at a New Zealand-based technology company, was asked to “digitise the legal intake process.” He assumed this meant building a web form to replace the email-based request system. Before committing to a solution, he decided to map the current process.
What he found was revealing. There was no single intake process. The sales team sent contract requests to the GC’s assistant via email. The product team submitted compliance questions through a Slack channel. The HR team called individual lawyers directly. The finance team forwarded vendor agreements by attaching them to calendar invitations for “quick review meetings.”
In total, there were seven distinct entry points into the legal department, none of which were tracked, measured, or documented. The legal team had no visibility into their own queue — they could not answer the basic question: “How many open requests do we currently have?”
Tom spent four weeks mapping each entry point, interviewing the stakeholders who used them, and understanding why each channel had evolved. In several cases, the workaround existed because a previous attempt to centralise intake had been too rigid or too slow, and users had found their own solutions.
This was an excellent candidate for BPR: the current process was broken (fragmented across seven channels), resisted incremental fixes (previous attempts at centralisation had failed), and required fundamental redesign.
His redesign consolidated all seven channels into a single intake portal built on Jira Service Management — but critically, he kept Slack as a supported submission channel (via a Jira integration) because the product team’s adoption of any non-Slack tool was near zero. He built a triage decision tree that categorised requests by type and urgency, auto-assigned them to the appropriate lawyer, and set SLA expectations with the requester.
Within three months, the legal team could see their complete queue for the first time. Average request response time dropped from “somewhere between 2 hours and 2 weeks” (Tom’s characterisation of the previous state) to a measurable 36-hour median.
Once the new intake process was stable, Tom applied Six Sigma principles to reduce variation. He created a complexity rubric so every request was consistently classified. He documented SLAs tied to complexity: routine requests were targeted at 24 hours, standard at 48 hours, complex at 5 business days. He implemented weekly control charts tracking performance against these targets. Variation in response time dropped from ±100% (unpredictable) to ±10% (predictable).
## Checklist
- **Pick your most painful process and shadow it.** Literally follow one real request from submission to completion, documenting every step and every wait state. Do not rely on anyone’s description of how the process works — observe it in action. This single exercise surfaces issues that months of meetings would miss.
- **Count your intake channels.** How many different ways does the business currently submit requests to the legal department? Email, Slack, phone calls, hallway conversations, calendar invitations — count them all. If the number exceeds two, you have a visibility problem that is likely sabotaging your cycle time.
- **Run a waste audit on your longest process.** Pick the process that consumes the most legal team hours (typically contract review, legal intake, or matter opening). Using the eight types of waste above, identify where each type occurs. Colour-code by impact: red for 20+ hours/month, yellow for 5–20 hours/month. Your biggest opportunity lies in the red items.
- **Measure your current state baseline.** Before you improve anything, establish the baseline: What is the current cycle time? What is the defect rate (percentage of work requiring rework)? What is the queue length? These three numbers are your control group. After redesign, these numbers tell you whether you actually improved.
- **Choose your methodology.** Is the process broken (BPR), slow but functional (Lean), or inconsistent (Six Sigma)? Your answer determines your approach. Applying BPR to a Lean problem is overkill; applying Lean to a fundamentally broken process will disappoint.
## Suggested Reading
- [ASQ - What is Six Sigma?](https://asq.org/quality-resources/six-sigma)
- [Lean Enterprise Institute - Lean Lexicon](https://www.lean.org/lexicon-terms/)
- [APQC - Process and Performance Management Resources](https://www.apqc.org/resource-library/resource-listing?f%5B0%5D=topic%3A73)
- [PMI Standards and Guides](https://www.pmi.org/pmbok-guide-standards)
- [NIST - Process Improvement and Quality Resources](https://www.nist.gov/topics/manufacturing/lean-six-sigma)