The Program That Ships vs. the Program That Slips

Nobody remembers the meeting where the program went off the rails, because there wasn't one. There never is.

Big delivery failures don't announce themselves. They accumulate. A slipped dependency here, a postponed demo there, a status report that says green for the ninth month running. Then one Tuesday somebody does the math and the launch date turns out to be fiction.

We've been called into a lot of these. The pattern is boringly consistent.

The tells

Watch the status decks. If the colors haven't changed in six months, that's not stability. That's a reporting culture where nobody wants to be the one holding the red marker.

A healthy program flickers. Things go amber, get fixed, go green, break again. A dashboard that never moves is measuring nothing.

Watch the demos. A shipping program shows you working software, ugly and half-finished, running against real data. A slipping program shows you slides about the software. If the demo is a screenshot in PowerPoint, the code is further away than anyone is saying out loud.

And watch the dependencies. Every slipping program we've ever untangled had a handful of critical items that everyone knew about and no one owned. The data feed from another division. The security sign-off. The contract stuck in legal. Ask who is personally on the hook for each one. If the answer is a team name, nobody is.

What shipping programs do instead

A program never slips in a meeting; it slips in the silence between meetings.

They deliver small and often, and they let the increments be honest. Two weeks of real progress beats a quarter of reported progress every time. A mid-size lender we worked with moved from quarterly releases to biweekly ones, and the interesting part wasn't the speed. It was that problems surfaced in week two instead of month five, while they were still cheap to fix.

They put one name on every promise. Not a committee, not a workstream, a person. That person can delegate the work but not the accountability, and everyone in the room knows whose calendar to find when the thing wobbles.

And they make bad news travel faster than good news. This is a leadership choice, not a process one. If the last person who flagged a slip got a lecture, you will not hear about the next slip until it's a crisis. If they got help, you'll hear about problems while they're still small enough to solve over lunch.

The uncomfortable part

None of this is sophisticated. There's no framework to buy, no certification to send people to. Which is exactly why it's rare. Small honest increments, single owners, fast bad news: each one requires a senior person willing to hear things they'd rather not hear, in front of people they'd rather impress.

So here's the test we run in the first week of any rescue engagement. Three questions. When did the status last change color? When did you last see the software actually run? And who, by name, owns the thing you're most worried about?

If the answers are never, the kickoff, and a shrug, you don't have a delivery problem yet. You have a truth problem, and the delivery problem is on its way.

Fix the truth problem first. The schedule usually follows.