Governance Models That Look Good on Slides but Fail in Delivery

[Abhijeet Upadh2]

Governance in ServiceNow rarely fails because it is absent. More often, it fails because it is designed in isolation from delivery reality.

I’ve seen governance models that look excellent in steering committee decks: multiple review forums, formal design authorities, mandatory artefacts, and layered approvals. On paper, they promise control, consistency, and risk management. In delivery, they often achieve the opposite. Decisions slow down, teams feel blocked, and pressure builds to “just get things done.”

When governance becomes too heavy, people don’t stop delivering—they stop following the process. Architecture decisions get made informally, exceptions are granted verbally, and documentation is backfilled (if at all). The official governance still exists, but it has lost credibility. At that point, risk hasn’t been reduced; it has simply become invisible.

The most effective governance models I’ve worked with were intentionally lightweight. They focused on a small number of non-negotiable principles, clear decision rights, and fast escalation paths. Instead of trying to prevent every bad decision, they made trade-offs explicit and recorded why certain risks were accepted.

Good governance respects time pressure. It recognises that delivery teams operate under constraints and that delayed decisions are decisions in themselves. Rather than blocking progress, effective governance channels it.

If your governance only works when timelines are generous and priorities are stable, it isn’t fit for purpose. Governance succeeds not when it controls delivery, but when it guides delivery without suffocating it.