Project Recovery

Half the projects I step into are projects someone started but couldn’t deliver. The typical picture: a company spent 8 months and 70% of budget, and only login and a couple of reference books work. The development team is burned out, the client has lost trust, and the project manager is writing progress reports that describe progress that doesn’t exist.

A characteristic case: a large company was implementing a CRM system through a well-known vendor. After 10 months — not a single working business process. The cause turned out to be not in the technology: requirements were gathered formally, architecture was drawn beautifully, but nobody figured out how the business actually works. The system was designed for an ideal process that didn’t exist in the company. My diagnosis took 10 days. We identified 3 critical processes out of 15, redesigned them, and launched the first module to production in 6 weeks.

The root cause is almost never the technology. In 80% of cases it’s one of three things: unclear requirements, absence of an owner with authority to make decisions, or a gap between what the business wants and what the team is building. Diagnosis isn’t a code audit. It’s conversations with people: the client, the team, the users. It’s in these conversations that you see where and when the project went wrong.

Honesty is the main tool. I won’t say “we’ll fix everything” — I’ll say what can be saved, what needs rebuilding, and what should be thrown out. Sometimes the best advice is to stop the project and start over with the right foundation. That’s painful, but cheaper than another six months working in a dead end.