01 · IT Project Recovery
Project lost momentum. Vendor unresponsive. Budget draining without visible progress. Before you fire the team, rebuild from scratch, or write off the spend — a structured recovery with a clear plan for what comes next.
↓ Expand a section to read more
Why you can trust me
Acting CEO of TreximAI · 8 years BA across AI products, logistics, fintech, B2B SaaS
Cases on this site are illustrative patterns drawn from 8 years inside IT — not invented for the page. No published clients yet.
Each starts looking like a different problem but ends with the same need: someone reads the situation honestly and proposes a workable plan.
Calls get rescheduled. Updates come less often. The Slack channel where work used to happen has slowly gone silent. Maybe the team is overloaded; maybe your project lost priority; maybe a key developer left. Either way — response is slower than you need, and the spend keeps running. First job: honestly figure out whether the relationship can be repaired, or whether it should end cleanly.
Started at $40K. Now at $80K with the original feature list still incomplete. Every change request lands with another "this will need two more weeks." You can't tell whether it's legitimate re-scope or just stretching the project. First job: separate real scope changes from padding, re-paper the agreement on transparent terms, restore progress against milestones.
People are engaged. Standups happen. Sprint reviews show movement. But the actual shipping has halted — and nobody inside the team can name why. First job: read the situation from outside the politics — process, scope, technical assumptions — and surface the real blocker without damaging the relationship.
Work runs in phases. Each one ends with a concrete decision you can make based on real data.
Read the codebase, the vendor contract, the comms history; interview the team. Identify what's actually broken versus what's just symptomatic. End-of-phase artifact: a one-page recovery plan you can show co-founders, investors, or board.
Either re-paper the vendor agreement on transparent terms, or close it cleanly. Restore weekly delivery cadence. Triage technical debt — what we fix, what we live with, what we plan around. End-of-phase: predictable shipping resumed, financial bleed stopped.
One of two paths. Either the project is stable with the existing team and I step out, leaving documentation and a clear next step. Or we transition to a vetted team from the network with structured handover. Either way, the project runs without me in the room.
The end value isn't the plan itself — it's what the plan unlocks:
A new team solves "who writes the code." Recovery solves "what actually needs doing, and why isn't the project moving." Often the first step reveals the team isn't the problem — scope, agreement, or process is. In that case a new team will just repeat the same situation 3 months later.
That's an honest answer, and I'll give it directly. Then work shifts to: cleanly closing current agreements with minimal losses; salvaging what's worth keeping (data, parts of the codebase, market learnings); and a plan for what to do with the remaining budget. Better to make that call in week 5 than spend another 4 months on something that won't fly.
First useful effect — end of phase 1 (week 2): you have a plan and an honest picture. Real delivery stabilization — phase 2 (weeks 3-8), depending on the depth of the problem. Deeply distressed projects take longer; an honest forecast comes after diagnostic.