Intelvision
Book a diagnostic
Book a diagnostic

Field notes

Notes from engineering interventions

Delivery, architecture, leadership, and operating systems. Written from the projects, not for the algorithm.

Delivery

Software Project Rescue: How to Know Whether a Project Can Be Saved

Six factors determine whether a failing software project is worth rescuing — and why the people closest to it are structurally unable to give you an honest answer.18 min read →Leadership

Why rescues fail: the firefighting layer

The most common failure mode in troubled projects is not technical. It is the leadership team becoming the coordination layer.5 min →Business Cases

The €220k a month nobody was counting

How a healthy-looking delivery pipeline quietly leaked a fifth of a million euros a month, and why no dashboard showed it.6 min →Business Cases

Best Software Project Rescue Companies: What Each One Can Actually Prove

Four questions applied identically to eleven rescue firms: who is named on the page, what are they qualified to do, do the case studies carry numbers, is a duration published?15 min →Delivery

12 Warning Signs Your Software Project Needs Rescue

The warning signs that predict a project will not self-correct cluster into three categories — operational, technical, and stakeholder — and how they combine matters more than how many you count.18 min →Delivery

The First 72 Hours of a Software Project Rescue

Six moves in a deliberate order — access, evidence, critical path, production risk, decision rights, and stakeholder communication — that determine whether a rescue stabilizes or makes things worse.15 min →Delivery

Software Project Rescue vs Rebuild: How to Decide

The rescue-vs-rebuild question is usually the wrong frame. There are four real paths — stabilize, modernize, rebuild selectively, restart — and the right one is determined by evidence, not instinct.16 min →