Shadow Process
The actual operations process includes steps, judgments, and exception paths that are not in any SOP. Automating the SOP automates an incomplete picture. The automation works on paper. It fails when the real process runs.
SOLUTIONS
Operations and delivery automation built on how work actually flows, not how it is supposed to.
Operations and delivery functions run on a combination of documented procedures and institutional knowledge that exists nowhere in writing. The people who know how to handle exceptions, manage escalations, and navigate cross-functional handoffs carry that knowledge with them. When they leave, or when automation is applied before that knowledge is surfaced, the result is a system that handles the standard case and fails on everything else.
THE PATTERN
The documented process and the real process are not the same thing.
Operations functions accumulate Shadow Processes over time: the workarounds, informal escalation paths, and exception-handling routines that have never been written down because they evolved organically. When automation is applied to the documented process, it executes against a process that does not fully reflect reality. The automation works in testing. It breaks in production.
Fragmented Processes
Delivery workflows span project management, resource management, client communication, billing, and handoff to support. Automating one segment without mapping the full chain produces visible efficiency and invisible gaps.
Rules Undocumented
Escalation criteria, exception authority, and client accommodation policies exist as institutional judgment, not documented rules. They cannot be automated until they are written. And they almost never get written until an automation project forces the question.
THE APPROACH
Process First Automation in operations and delivery.
Operational Truth mapping in delivery functions means shadowing the actual process, not reviewing the SOP. It means identifying where the documented process diverges from execution, where informal judgment governs escalation, and where handoffs between teams create the delays that compound into delivery risk. The Process Readiness Score then determines which operational workflows are ready for automation, which need standardization first, and which exception paths must remain under human judgment.
Shadow Process mapping
We surface the real process: the workarounds, informal escalation paths, and tribal knowledge that live outside documentation. Automation is scoped against reality, not the SOP.
Handoff analysis
Cross-functional handoffs are mapped as discrete transfer points with defined inputs, outputs, and failure modes. Most delivery delays originate at handoffs, not within tasks.
Exception path design
Exception handling is explicitly documented and classified before automation is built. Automation absorbs the deterministic cases. Human judgment is preserved for the cases that require it.
Delivery governance layer
Every approved automation in the delivery cycle carries success criteria tied to a delivery driver: cycle time, error rate, client satisfaction score, or utilization rate.
PROCESS EXAMPLES
What this looks like in practice.
These are illustrative examples based on common patterns in mid-market operations and delivery functions. They are not client case studies.
Client onboarding workflow
Client onboarding was a 22-step process documented in a project management template. In practice, onboarding ran in parallel with a separate internal checklist maintained in a shared spreadsheet that had grown to include 37 steps. The template was the official process. The spreadsheet was how onboarding actually happened. An automation initiative targeting the template would have accelerated a process nobody used.
DRIFT pattern identified:Shadow ProcessRules Undocumented
Path taken:Redesign
The two processes were reconciled into a single documented workflow. Automation was applied to 14 of the 31 consolidated steps. Onboarding time decreased by 28%.
Freight exception handling
The operations team had automated freight status updates to customers. When a shipment encountered an exception, damaged goods, missed pickup, customs delay, the automation continued to send standard status updates because exception classification was a manual step that had not been included in the automation scope. Customers were receiving "on schedule" notifications for shipments that were not on schedule.
DRIFT pattern identified:Invisible ExecutionFragmented Processes
Path taken:Redesign, then Automate
Exception classification was added to the automation logic. Customers now receive exception-specific notifications with resolution timelines rather than generic status updates.
Project resource allocation
Resource allocation was managed manually by two delivery managers. When a new project was sold, resource availability was checked via a spreadsheet maintained separately from the PSA. Allocation conflicts were discovered at kickoff rather than at sale. The company had evaluated three different resource management tools. Each evaluation stalled when it became clear the underlying allocation logic was inconsistent between the two delivery managers.
DRIFT pattern identified:Rules UndocumentedFragmented Processes
Path taken:Redesign
Allocation rules were documented and agreed upon before any tool was re-evaluated. A single source of resource data was established. The third tool evaluation succeeded.
Case handoff between intake and processing
Cases were routed from intake to processing via an automated workflow. Average processing time was 6.3 days against a 4-day target. Analysis revealed that 40% of cases arrived at processing with incomplete data fields, requiring a manual outreach step back to intake before processing could begin. The handoff automation was operating correctly. The problem was that intake did not have a validation step before submitting cases.
DRIFT pattern identified:Fragmented Processes
Path taken:Instrument, then Automate
A validation gate was added at intake submission. Cases arriving at processing with complete data increased from 60% to 94%. Average processing time dropped to 4.1 days.
SCOPE
Operations and delivery processes we evaluate.
The following represent common processes in this function that organizations bring to a PFA Diagnostic. This is not an exhaustive list. The Diagnostic begins with your specific situation.
Client onboarding and project initiation
Resource allocation and capacity planning
Project status reporting and escalation
Delivery handoff between teams or functions
Exception identification and routing
Scope change and change order workflow
Quality review and approval routing
Client communication and update delivery
Milestone tracking and completion confirmation
Vendor coordination and subcontractor management
Project closeout and documentation
Post-delivery support handoff
Utilization and capacity reporting
SLA monitoring and breach notification
ILLUSTRATED EXAMPLES
How the process plays out.
These are detailed walkthroughs using fictional companies. Each follows a real diagnostic pattern, from the initial problem through the DRIFT diagnosis, the Four Paths decision, and the outcome. They are here to show the work, not to replace case studies.
FICTIONAL COMPANIES. REAL PATTERNS.
COMPANY
Clearpath Consulting Group
Professional services · 260 employees
DRIFT PATTERN
Shadow ProcessRules Undocumented
PROCESS EVALUATED
A 22-step onboarding template that had not been used in two years, while a 37-step spreadsheet ran the actual process.
Clearpath's operations team was proud of their onboarding template. It was detailed, well-formatted, and kept current in their project management platform. What they had not noticed was that the delivery team had quietly built a parallel process. The shared spreadsheet started as a supplement to fill a few gaps. Over eighteen months it became the actual workflow, expanded by team members who added steps to handle situations the template did not cover. When the automation project started, the vendor asked to review the onboarding process documentation. The team shared the template. The spreadsheet was never mentioned. The automation was scoped against a 22-step process that the delivery team had stopped following two years earlier.
PATH TAKEN
Read the walkthroughRedesign
KEY OUTCOME28%reduction in onboarding time after the two processes were reconciled and automation applied to the real workflow.
COMPANY
Meridian Freight Solutions
Logistics provider · 720 employees
DRIFT PATTERN
Invisible ExecutionFragmented Processes
PROCESS EVALUATED
Customer notifications were automated. Nobody automated the step that determined whether a shipment was actually on schedule.
Meridian had invested significantly in customer communication automation. Status updates went out on schedule. Notifications were well-designed and consistently delivered. The automation was technically working. What it was working on was a single data field, shipment status as recorded in the TMS, without any logic to check whether that status was current or whether an exception had been flagged elsewhere in the system. When exceptions were identified by the operations team, they were logged in a separate exception tracking tool that the notification system had no visibility into. Customers with shipments in active exception states continued receiving standard "on schedule" updates. The operations team knew about the exceptions. The customers did not.
PATH TAKEN
Read the walkthroughRedesign, then Automate
KEY OUTCOME100%of exception cases now trigger exception-specific customer notifications. Generic status updates on exception shipments eliminated.
COMPANY
Vantara Technology Services
IT services · 440 employees
DRIFT PATTERN
Rules UndocumentedFragmented Processes
PROCESS EVALUATED
Three tool evaluations. Three stalled implementations. The allocation logic was the problem, not the platform.
Vantara had been trying to solve their resource allocation problem for four years. They had evaluated and partially implemented three different resource management platforms. Each project followed the same arc: initial enthusiasm, a successful pilot with one delivery team, and then a stall when the tool was rolled out more broadly. The stall point was always the same: the platform's allocation logic required defined rules, and the two delivery managers who ran allocation did not apply the same rules. Each had developed their own approach over years of experience, shaped by different client relationships and different priorities. Neither approach was wrong. They were just different. And different enough that any single rule set the tool enforced would override one manager's judgment in ways they would not accept.
PATH TAKEN
Read the walkthroughRedesign
KEY OUTCOME4 yrsof stalled implementations resolved after allocation rules were documented and agreed upon. Fourth tool evaluation succeeded.
COMPANY
Ascendant Health Administration
Healthcare administration services · 580 employees
DRIFT PATTERN
Fragmented Processes
PROCESS EVALUATED
The handoff automation was working correctly. The bottleneck was a step that happened before the handoff, and nobody had looked upstream.
Ascendant's operations leadership knew their case processing times were above target. They had invested in improving the handoff workflow between intake and processing: better routing logic, faster notifications, cleaner status tracking. The improvements shipped on schedule and ran cleanly. Processing times did not improve. The Operational Truth mapping session traced the bottleneck to what happened before the handoff, not during it. Forty percent of cases arriving at processing were missing required data fields. The processing team was performing a manual outreach step back to intake to collect the missing information before they could begin. That step was not visible in any workflow report because it happened outside the automated system, via email. The handoff was fast. The processing team spent their time waiting for intake to respond.
PATH TAKEN
Read the walkthroughInstrument, then Automate
KEY OUTCOME4.1 daysaverage processing time, down from 6.3, after validation gate added at intake. Complete case rate at processing: 94%.
GET STARTED
Not sure which part of your delivery process is the real constraint?
The DRIFT Self-Assessment identifies which failure patterns are active in your operations environment. Shadow Process and fragmented handoffs are the most common patterns in delivery functions.