Skip to content
FM Consulting logoFM CONSULTINGSoftware Delivery Partner

FM Consulting

Release Governance Acceleration Initiative

Improved release predictability by standardizing readiness gates, ownership, and cross-team decision flow.

Gallery

Case study

The problem

Every release, regardless of size, required sequential sign-off from five stakeholder groups — security, QA, product, compliance, and operations — each reviewing after the previous one finished, with no shared deadline. A one-line configuration change went through the same approval chain as a customer-facing payment feature. Over a year, release frequency had quietly dropped by roughly half as the queue lengthened, while the actual criteria each reviewer was checking against were informal and inconsistent — two reviewers could each believe they were the last blocker. The heavier the process got, the less anyone could say what it was actually preventing.

The solution

Replaced serial sign-off with a single explicit readiness gate: one short list of objective, binary criteria — test coverage threshold met, rollback plan documented, no open Sev1/Sev2 issues, security scan clean — that a release owner certified against directly in the existing release ticket, reviewed in parallel rather than in sequence. A named release manager, rotating weekly rather than a fixed role, held sole go/no-go authority instead of requiring unanimous approval from every function. The highest-leverage change was tiering: low-risk releases (internal tooling, config-only changes) skipped the full gate entirely, while customer-facing and payment-related releases kept the complete review — most releases had been getting the same scrutiny as the riskiest ones by default, not by decision.

How it was built

The readiness checklist was built as required fields directly on the existing Jira release ticket template rather than a new tool or a new meeting, so certifying against it was part of the workflow a team already followed, not an added step. Serial email-thread approvals were replaced with a single parallel review window — every reviewer notified at once, a 24-hour SLA to flag a concern, with silence treated as consent rather than requiring an explicit yes from each function individually. Risk tiering was based on a short, concrete rubric (does it touch billing or auth, does it change customer-facing behavior, can it be rolled back in under five minutes) decided once per release at ticket creation, not litigated case by case. Within two quarters, release frequency recovered to roughly its historical baseline, and the release-linked incident rate did not increase — evidence that the heavier process had been buying latency, not safety.

More projects