Most retrospectives on a stalled programme start in the wrong place: was the platform right, was the vendor right, was the architecture sound. Usually all three check out fine, and the programme still didn't deliver what the business case promised.
The pattern shows up often enough to name: somewhere between 70 and 80% of digital transformation programmes fail to deliver the value in their business case, and the reasons rarely trace back to the software itself.
Four gaps do most of the damage, and none of them are technical. The first is starting without an honest baseline — nobody actually measured where capability stood before the programme kicked off, so "improvement" is unmeasurable and disputes over whether things got better become a matter of opinion. The second is mistaking the system going live for the organisation being capable of running it: the tool ships, the team's ability to own and operate it never actually develops, and six months later everyone's back to the old workarounds. The third is a governance vacuum, where decisions get made, or more often don't get made, with nobody clearly accountable for the outcome either way. The fourth is the capability cliff itself, the moment the programme team disbands at go-live and walks out the door with the only people who understood how any of it actually works.
Worth doing this week even without a full review: pick one of the four and ask honestly whether your current programme has evidence against it, or just an assumption that it's fine. Most teams find at least one they can't actually answer cleanly, and that gap is usually the real one worth tracking.
Curious which of the four shows up most in other people's experience here — is it usually the baseline, the governance, or the handover at the end?