Common Deployment Failures

How to read this catalog

Each entry has the same shape: name, symptoms, root cause, prevention, recovery. The most senior FDEs have seen most of these at least once and most of the rest from a colleague's deployment. Reading the catalog is cheaper than living through any single one of them.

Political failures

1. The disappearing sponsor

• Symptoms: Executive sponsor misses two monthly reviews. Stops responding to direct emails. Delegates a deputy who can't make decisions.
• Root cause: Sponsor's priorities shifted; internal reorg; the project lost board-level visibility; sponsor is exiting the company.
• Prevention: Cultivate at least one secondary sponsor early — usually one tier below the primary. Don't bet everything on a single relationship.
• Recovery: Escalate via your AE; if a real change happened, you may need to re-anchor on the secondary. If sponsor is exiting, find the inheritor of their portfolio fast.

2. The political stalemate

• Symptoms: Internal customer stakeholders disagree about what success means. Conversations loop. Working agreement keeps getting redrafted with no signoff.
• Root cause: Two senior stakeholders (procurement vs finance, procurement vs legal) want fundamentally different outcomes from the platform.
• Prevention: In discovery, surface the disagreement explicitly. Refuse to start work until it's resolved.
• Recovery: Escalate to your AE. They own the conversation about whose mandate prevails. Don't ship into stalemate.

3. The reorganization

• Symptoms: Customer announces a restructuring. Your sponsor's team moves under different leadership. New leader doesn't see the deployment's value.
• Root cause: Standard enterprise dynamics. Happens to most multi-quarter deployments.
• Prevention: Watch for leading indicators in the customer's industry news. Have artifacts ready to show new leadership: business outcomes, end-user quotes, ROI.
• Recovery: Schedule an introduction with the new leader within 30 days. Ship a one-page outcomes summary. Re-validate scope under the new mandate.

Scope failures

4. The scope creep that wasn't tracked

• Symptoms: By week six, you're delivering work you didn't agree to. Original timeline slips. Customer is happy but you're burning out.
• Root cause: Adjacent customer asks were absorbed without renegotiating timeline or scope. The "out of scope" section of the working agreement was vague.
• Prevention: Be ruthless about the out-of-scope list. When a new ask comes up, write it down explicitly: "this is in scope" or "this is a new scope conversation."
• Recovery: Re-anchor the working agreement. Name what's been added; renegotiate timeline. Honest is uncomfortable but recoverable.

5. The shrinking scope

• Symptoms: Customer keeps removing classes from scope. By week 8, you're delivering 30% of what was originally signed for.
• Root cause: Customer's situation changed; or the original scope was unrealistic; or extraction quality is below what they want and they're cutting losses.
• Prevention: Pre-flight data quality check in discovery. Set realistic SLAs against the real corpus.
• Recovery: Surface to your AE — shrinking scope often correlates with churn risk. Renegotiate the working agreement and the commercial terms together.

Data-reality failures

6. The customer's data is worse than they said

• Symptoms: OCR quality on a meaningful portion of the corpus is below threshold. Documents are scanned faxes. Amendments aren't linked to MSAs. Customer's "supplier master" has 4× the entries they claimed.
• Root cause: Customer didn't know. Or knew and didn't say. Either way, you have it now.
• Prevention: Pre-flight quality sample in discovery. Set the SLA expectations against what you saw, not what they described.
• Recovery: Bring the evidence to the customer. Reshape scope — narrow to the data that works. Negotiate carve-outs on the SLA.

7. The hidden document class

• Symptoms: Week six: customer mentions in passing that "we also have these 50,000 amendments separately." Wasn't in the original corpus walkthrough.
• Root cause: Discovery didn't go deep enough on the document inventory. Or different teams own different document classes and only one team was in the room.
• Prevention: Ask "what other contracts exist that you didn't think to mention?" in discovery, multiple times, to multiple stakeholders.
• Recovery: Treat it as a new scope conversation. Don't just absorb it. Renegotiate timeline.

Integration failures

8. The identity-IT bottleneck

• Symptoms: Week six and you still don't have SSO set up. SCIM provisioning ticket has been "in review" for a month. Service-account credentials require a security committee that meets monthly.
• Root cause: Identity tickets were filed late; or filed but not escalated when they sat. Customer's IT team has more work than capacity.
• Prevention: File identity tickets in week one. Escalate when they sit. Maintain a "what's blocked by IT" running list in your Friday status.
• Recovery: Escalate via your AE. Sometimes a sponsor needs to call IT directly. Identify a service-account workaround that gets you partial value while waiting.

9. The ERP that won't be touched

• Symptoms: Customer wanted ERP writeback. Two months in, the SAP team has not approved any integration. CAB reviews keep being deferred.
• Root cause: ERP writeback was scoped without IT/Finance team's actual buy-in. The political weight was underestimated.
• Prevention: Treat ERP writeback as a Phase 2 conversation. Defer until you've earned trust with warehouse-only delivery first.
• Recovery: Pivot scope to warehouse + BI only; reframe ERP integration as a Phase 2 expansion. Don't argue with the SAP team; absorb the constraint.

Operational failures

10. The quality-drift you didn't see

• Symptoms: Customer notices extracted renewal dates are wrong before you do. SLA dashboard hadn't fired because measurement sample was stale.
• Root cause: Eval cadence too slow; sample size too small; the dashboard you built wasn't actually being watched by anyone.
• Prevention: Daily eval against a rolling sample. Alert on any class trending toward SLA threshold. Confirm with the customer that they're checking the dashboard.
• Recovery: Apologize specifically — this is a trust hit. Diagnose, fix, ship a remediation plan, document the gap that let it slip. Tighten monitoring.

11. The status-doc decay

• Symptoms: Three weeks of identical "in flight" items. Customer stops reading the Friday status. Your manager doesn't know what's happening.
• Root cause: The deployment has gotten stuck and the status doc reflects it. The doc-writing habit decayed when the work got hard.
• Prevention: Never skip the Friday status doc. The week it gets hard to write honestly is the week you most need to write it.
• Recovery: Write the status doc honestly this Friday. Name what's stuck. Use the kill-decision worksheet if appropriate.

Meta-failures

12. The FDE who can't leave

• Symptoms: Day 90 came and went. You're still primary on-call. Runbooks were written but not tested. The customer's data team hasn't independently resolved an incident.
• Root cause: Handoff didn't start until the last week. Training didn't include real incidents. The customer wasn't pushed to take ownership.
• Prevention: Start handoff in week 6, not week 12. Write runbooks during deployment, not after. Bring the customer into incident response actively, not as observers.
• Recovery: Explicitly schedule a 30-day handoff sprint. Schedule pair sessions on real tasks. If a real incident happens, step back even if it feels uncomfortable. Let the customer drive.