Judge Software Governance Maturity by How Exceptions Get Resolved
Ask a team how mature its software governance is and you often hear about documents: the policy library, the approval workflow, the standards for procurement and deployment. These are worth having. They are also a poor measure of maturity, because they describe intent. A policy that nobody can enforce and no one is asked to follow can look identical on paper to one that works.
A better measure is what happens when reality departs from the policy. Every estate produces exceptions: an install nobody approved, a deployment above its entitlement, support that lapsed, a contract no one can account for. How those exceptions are surfaced, owned and closed tells you far more than the length of the rulebook. This post sets out a way to judge software governance maturity by exceptions, with four metrics and a table you can use to place yourself.
Why exceptions tell you more than policy does
Policy coverage is a one-time effort. Exception handling is an ongoing behavior, and behavior is what auditors, vendors and finance teams meet. When a vendor asks for a deployment report, the question is not whether you had a rule against over-deployment. It is how long the over-deployment existed, who knew and what was done.
Exceptions are also unavoidable. Mature governance does not mean few of them. It means they appear early, reach someone who can act and end with a recorded outcome. An organization with many visible, quickly closed exceptions is usually in better shape than one with very few that are all stale. The first has a working loop. The second may simply not be looking, which is the risk a register of unknowns is designed to expose.
There is a link to ownership as well. An exception that no one owns does not close, however good the policy. As argued in why software governance fails at the handoff and not in the policy, most exceptions stall at a seam between teams. Measuring them shows you which seam.
The exceptions worth tracking
Start with the ones that carry money or risk and that every estate has. Four categories are enough to begin.
- Unapproved installs. Software present that no request or entitlement explains.
- Over-deployment. Installed or used quantity above what the contract allows.
- Expired or expiring support. Products running without vendor support, or support ending without a decision.
- Orphaned contracts. Active agreements with no named business owner, or no matching usage.
Each exception is a record with a type, a product, a date it was first seen, an owner and a closure. If your tooling cannot produce that record yet, a shared list is a fair start. What matters is that the same fields are filled in every time, because the metrics below depend on them.
Four metrics that show whether the loop works
You do not need a dashboard of thirty measures. Four timings and one ratio describe the loop. Every one of them can be computed from the exception record.
| Metric | What it measures | How to calculate it | What a poor result suggests |
|---|---|---|---|
| Time to surface | How long an exception exists before anyone records it | Date recorded minus the date it began, where known, else the date of the first evidence | Discovery runs too rarely, or exceptions are found only at audit and renewal |
| Time to owner | How long before a named person accepts responsibility | Date owner assigned minus date recorded | Unclear handoffs; exceptions wait in a shared queue |
| Time to close | How long from owner to a recorded outcome | Date closed minus date owner assigned | Owner lacks authority or the fix needs another team |
| Repeat rate | How often a closed exception returns | Closed exceptions that reappear within a set period, divided by all closed | Fixes address the instance, not the cause |
Read them in order. A long time to surface says the problem is visibility. A long time to owner says it is accountability. A long time to close says it is authority or capacity. A high repeat rate says closures are cosmetic, and is the most telling of the four: it separates teams that clean up from teams that fix.
Pick your own thresholds, because estates differ. A company with a quarterly renewal cycle may accept a month to close a support exception. One with monthly true-ups may not. The numbers matter less than the direction of travel and the shape across the four.
Here is an illustrative case. A team finds a database product running on twelve more hosts than it holds licenses for. At a low level of maturity, the finding sits in an email thread, someone is asked to look into it, and it resurfaces eight months later in a vendor request. At a higher level, the finding is recorded the day the scan shows it, the infrastructure lead accepts it within two days, the hosts are either removed or covered by a purchase within the month, and the cause, a cloning template with the product preinstalled, is fixed so the case does not return. The policy was identical in both versions. The behavior was not.
Notice that in the second version the closure includes the cause. That detail is what the repeat rate checks, and it is the quiet difference between a team that clears a backlog and one that stops refilling it.
A software governance maturity table
Use this as a self-assessment. It describes behavior on exceptions, not the existence of documents. Place each of the four categories separately, because most estates are further along in one than another.
| Level | How exceptions are handled | Typical signal |
|---|---|---|
| 1. Unseen | Found by audit, vendor letter or invoice surprise | Time to surface is measured in quarters, if known at all |
| 2. Reactive | Recorded when found, handled by whoever is available | Owners assigned by chasing; no closure standard |
| 3. Owned | Every exception has a named owner within a set time | Time to owner is short and tracked; closure varies |
| 4. Managed | Exceptions surface from routine checks and close against a standard | All four metrics tracked; repeat rate known |
| 5. Preventive | Repeat causes are removed at the handoff where they start | Repeat rate falls; exceptions are mostly new kinds |
Most teams will find themselves at level two or three, and that is a normal place to be. The move from three to four is the hardest, because it needs routine checks and an agreed closure standard. It depends on comparing what was bought, deployed and used on a regular cycle rather than once a year, which is where the License Contract Manager and a current entitlement record help: the comparison stops being a project and the exceptions arrive with the contract context attached.
What to do in the next month
Maturity is a direction, so choose a small first move and measure it.
- Pick one exception category, for example support that has lapsed or is about to.
- List every current case and record a first-seen date, even if approximate.
- Assign one owner per case and write down the date they accepted it.
- Agree what closed means: removed, renewed, accepted as a known risk with an expiry date, or contract ended.
- After 30 days, calculate time to owner and time to close for the cases you closed.
- Review the closed cases for causes. If three came from the same handoff, fix the handoff.
A related point on reporting: leadership rarely needs the whole exception list. It needs the four metrics, the oldest open items and a view of what is likely to hit a renewal. That is the kind of output described in decision-ready software intelligence, where the value is a position someone can act on. Report the trend, name the owners and let the maturity table tell the story over a few quarters.
