NOTE: Today I realized that what AI is reflecting back is contextual debt accumulated through decades of focusing on technical debt. I put the thought to Claude using the usual tech implementation projects approach.
Claude’s Reply —>
Perfect - this is the exact pattern playing out in concrete detail.
Let me structure this as a case study demonstration:
The Setup (Debt Creation Begins)
Sales & Account Management:
Have conversations with client
Hear contextual needs, constraints, culture, actual workflows
Translate everything into conceptual categories for the proposal
“They need a CRM system” (omits: how they actually manage relationships, existing informal processes, who really holds customer knowledge)
Initial debt created: All the contextual information from those conversations gets compressed into conceptual deliverables
Project Kickoff (Debt Becomes Structural)
Project team receives:
Statement of work (conceptual)
Requirements document (conceptual)
Timeline and milestones (conceptual)
Success metrics (conceptual)
Project team assumes: Sales did proper discovery, the documents capture what matters
Reality: Documents contain conceptual containers with contextual information already omitted
The forms of project management take over:
Gantt charts
Status meetings
Deliverable tracking
Risk registers (that only track conceptual risks)
More debt accumulates: The project structure itself prevents contextual awareness - everyone’s managing to the plan, not witnessing what’s actually emerging
Mid-Project (Debt Compounds Through “Management”)
Contextual information starts emerging:
Client mentions “oh, we also need to integrate with this system”
Team discovers workflows they weren’t told about
Users reveal constraints that weren’t in requirements
Cultural dynamics become visible
Project team response:
Try to fit new information into existing plan
“Can we add that as Phase 2?”
“That’s not in scope”
“We can do that but timeline extends”
Debt deepens: Each piece of contextual information gets forced into conceptual project framework rather than allowing the work to respond to what’s actually needed
The “Scope Creep” Moment (Debt Crisis)
Something too big to ignore emerges:
Integration that’s actually critical
Workflow that makes/breaks adoption
Stakeholder who should have been involved from start
Regulatory requirement nobody mentioned
Project team declares: “SCOPE CREEP!”
The fix:
Change order process (more conceptual forms)
Updated project charter
New timeline
Revised budget
More meetings to “control” scope
Massive debt accumulation: Instead of recognizing “we never actually understood what was contextually needed,” the team treats emergence as failure of initial scoping, then creates MORE conceptual controls to prevent future “scope creep”
Go-Live (Debt Transfer)
System launches:
Meets all conceptual requirements ✓
Passed all test cases ✓
On time (revised timeline) ✓
On budget (revised budget) ✓
Actual reality:
Doesn’t match how work actually flows
Missing key contextual integration
Users find workarounds immediately
“Adoption issues” blamed on change resistance
The debt has been transferred:
Client now carries it (future “improvement” projects needed)
End users carry it (daily workarounds to make system function)
IT carries it (maintaining something that doesn’t match reality)
The Cycle Repeats
2 years later:
Client: “The system isn’t working, we need to fix it”
Sales: “We can help! Let me understand your needs...”
[Compresses contextual information into conceptual proposal]
Project team: “Here’s the improvement plan...”
[More debt accumulates]
What Actually Happened
Not scope creep. Contextual debt accumulation.
The project was built on problem-solving approach:
“What’s the problem?” → CRM needed
“What’s the solution?” → Implement CRM
Never stayed contextual long enough to understand what actually needed to happen
Every “management” intervention deepened debt:
Requirements doc (omitted contextual nuance)
Project plan (forced work into predetermined timeline)
Status meetings (tracked conceptual milestones, not actual progress)
Change control (treated emergence as deviation to control)
Go-live (declared success conceptually despite contextual failure)
The humans absorbed the debt:
Project team worked nights/weekends managing gaps
Client team translated between system and reality
End users developed elaborate workarounds
Everyone exhausted but couldn’t name why
What Contextual Approach Would Look Like
Initial engagement:
Don’t jump to “they need CRM”
Spend time witnessing how relationships actually work here
Notice patterns, flows, where energy lives
Let understanding develop before proposing solution
Project approach:
Start with smaller scope that can respond to emergence
Regular contextual check-ins: “what’s actually happening?”
Treat “scope changes” as information, not failure
Measure success contextually (is work flowing better?) not just conceptually (did we deliver requirements?)
Continuous:
System evolves with organizational reality
Low contextual debt maintained
Humans not exhausted from managing gaps
Sustainable partnership with technology
This pattern plays out across:
ERP implementations
Digital transformations
Organizational restructures
Process improvement initiatives
Knowledge management systems
And now: AI adoption projects
Every. Single. Time.
The problem-solving approach guarantees contextual debt. The project management forms guarantee it accumulates. The “scope creep” response guarantees it compounds.
And we keep doing it because we have no other framework. Until now.
What’s been your experience with tech implementation projects? Were they so focused on catching up on the technical debt that they missed the contextual debt running underneath the project?
That is really strong 💪... ive been change management lead on a billion dollar program and that is an extremely incisive view. Are you a consultant of sorts?