5 Go/No-Go Mistakes Executives Make on Enterprise Software Programs
Five specific go/no-go mistakes enterprise software executives make when estimation patterns are screaming the wrong answer. A concise corrective for portfolio leaders.
Five expensive go/no-go reflexes — and what to do instead
Most enterprise software no-go decisions arrive six months too late and cost ten times what an earlier conversation would have cost.
Enterprise software programs accumulate enough sunk cost by gate three that executives systematically tilt toward go decisions. The estimation pattern — forecasts wrong in the same direction — is most expensive when an executive layer doesn't see it clearly enough to halt a program that's drifted past viability. The five mistakes below are the most common reflexes that produce that outcome.
Each is paired with a corrective short enough to use at the next gate.
- Mistake 1Treating the gate as a yes-or-no when conditional-go is the right answerBinary gates encourage teams to over-promise to clear them. Conditional-go with named conditions and a re-review date produces honesty. Corrective: replace 'go/no-go' with 'go / conditional-go / no-go' as the standard option set.
- Mistake 2Discounting the team's own confidence intervalsWhen the team gives a range, executives anchor on the optimistic end. Corrective: gate decisions on the worst-case end of the team's range, not the best-case. If the program isn't viable on the worst case, the gate is a no-go.
- Mistake 3Greenlighting on momentum, not on dataOnce a program has cleared two gates, the third gate is treated as a formality. Corrective: every gate has the same evidence requirement as gate one. If the team can't produce that evidence at gate three, that's the answer.
- Mistake 4Ignoring the parallel program competing for the same engineering capacitySoftware gates are made program by program; resource conflicts are made portfolio by portfolio. Corrective: every gate decision shows the engineering capacity assumption in writing, sourced from the engineering org, not the program team.
- Mistake 5Not pre-defining what would change a go to a no-goWithout a tripwire, every program continues until it's obviously failed — at which point the cost of stopping has dwarfed the cost of an earlier pause. Corrective: every go decision documents one or two specific tripwires that would convert it to no-go. The tripwires are reviewed at the next gate.
Three-decision discipline at every gate
0 / 5- Is the option set 'go / conditional-go / no-go' rather than binary?
- Are we evaluating the worst case of the team's range, not the best case?
- Are we reviewing fresh evidence rather than relying on prior gate decisions?
- Is the engineering capacity assumption sourced from the engineering org?
- Have we documented at least one tripwire that would convert today's decision?
| Mistake | What it produces | The corrective |
|---|---|---|
| Treating go/no-go as a milestone, not a decision | Calendar drives the gate | Re-pose the question: "what would make us not ship?" |
| Silent stakeholder absent from gate | Late veto | Pre-gate conversation with veto-holders, in writing |
| No reversibility plan | Ship-or-die mindset | Pre-document what a controlled rollback looks like |
| Estimation pad burned by Q3 | Final approvals are unsafe | Reset the pad mid-project, not at the gate |
| Conflating "ready" with "complete" | Half-built features ship | Define ready as the smallest releasable scope |
These five corrections are not difficult, and they don't require a heavier gate process. They require an executive willing to apply discipline that the program team cannot apply for them. The corrective intervention here is short — five mental checks before voting at the next gate.
For the same pattern viewed at greenlight rather than mid-gate, see the preventive greenlight question; for the annual retrospective that builds the data behind these checks, see the retrospective playbook.