Software Governance Fails at the Handoff, Not in the Policy
Most organizations that struggle with software governance do not lack a policy. They have an acceptable use document, an approval workflow, a procurement checklist and a renewal calendar. When something goes wrong, such as an unapproved install, a renewal nobody noticed or a contract that outlived its product, the post-mortem rarely finds a rule that was missing. It finds a rule that was written down and then dropped when the work passed from one team to another.
This post argues that software governance is mostly an ownership problem at the seams between functions. If you want fewer surprises, adding policy coverage is the slow route. Naming an owner for each handoff, and attaching evidence that the owner exists, is the fast one.
Policy coverage is rarely the gap
Policies describe what should happen inside one function. Procurement knows its approval thresholds. IT operations knows its deployment standards. Finance knows its coding rules. Each document is reasonable on its own terms. The trouble is that a software product moves through all of them, and every transition is a place where context, authority and accountability can fall away.
A useful test is to pick one product from your estate and trace it from first request to retirement. At every step, ask who held it, what they knew and what they passed on. In most estates the trail goes cold at the same places: the request that was approved by someone who never saw the contract terms, the purchase that finance paid and nobody tied to a deployment, the renewal that sat with a person who had left. None of those is a policy gap. All of them are handoffs where the next owner was assumed rather than named.
This is also why governance reviews that add more policy tend to disappoint. The new rule lands on the same seams, with the same ambiguity about who carries it. The pattern is close to the one in the hidden cost of interpretation work in software asset management: when the picture has to be pieced together by hand across teams, someone is always doing unrecorded translation, and the work disappears when they do.
The five handoffs where ownership drops
Every software product passes through the same five handoffs. The table shows where each one sits, what tends to be lost and what an owner would need to produce to show the handoff worked.
| Handoff | Between | What gets dropped | Evidence that proves an owner |
|---|---|---|---|
| Request | The business and IT | Why it is needed, how many users, which license metric applies | A request record with a named sponsor, a user count and the metric assumed |
| Purchase | IT and procurement | The terms the requester assumed; who will deploy it | Contract on file, entitlement recorded, deployment owner named at signature |
| Deploy | Procurement and IT operations | The entitlement limit; where it may be installed | Installs matched to an entitlement record before go-live |
| Renew | IT operations, finance and the business | Usage data; the notice date; who can say no | Renewal date, notice period and decision owner held on the contract record |
| Retire | The business and IT | Cancellation, uninstall, data export, support end date | Closure ticket linked to contract and install records |
The columns on the right matter more than the ones on the left. A handoff without evidence is a conversation, and conversations do not survive staff changes. Evidence is what lets a new person, or an auditor, see that the handoff happened and who held it.
What goes wrong at each handoff
Request. The requester describes a need, and the approver says yes or no on cost alone. Neither records the license metric, so the quantity approved may not match the quantity the vendor will count. Approval is treated as the end of governance when it should be the start of an entitlement record.
Purchase. Procurement negotiates price and signs. The requester assumes the terms match what they asked for, and nobody checks. Often the contract is stored where only procurement can find it, and IT operations deploys against an informal understanding. The gap is in the structured knowledge of what was bought, a theme that runs through the bus factor in vendor licensing knowledge: if the answer lives in one head, the handoff has not happened.
Deploy. Installation is usually gated by technical readiness, not by entitlement. Teams install what they were told they could, and the count drifts above or below what was bought. Nobody notices until a renewal or an audit, because deployment and entitlement are held by different functions with different tools.
Renew. This is where handoff failures become expensive. The renewal date is on a calendar, but the people who know what is used, what is needed and what could be dropped are different people, and none of them owns the decision. The approach in triaging software renewals by risk works because it forces a named decision owner early. Without one, the vendor sets the timetable.
Retire. Nobody is rewarded for turning something off. The business stops using a tool, the project closes and the contract rolls over. The retirement handoff has no natural owner because the people who cared are gone, which is why orphaned contracts and unused installs outlast the products they supported.
How to assign an owner for each handoff
An owner is not a committee, a team alias or a role that may be vacant. For each handoff, name one person, state what they are accountable for and say what evidence they will leave. The structure below is enough for a first pass.
- Name the person, not the function. If the answer is a team, pick the individual who is accountable when the team is wrong. Record their name and a deputy.
- Write the obligation as a sentence. For example: before go-live, the deployment owner confirms the install count against the entitlement record and attaches the result.
- Define the evidence in advance. A field on a record, a linked ticket or an attached contract. Anything that can be checked later without asking the person.
- Set a trigger and a deadline. A handoff with no trigger starts only when someone remembers. Tie it to the approval, the signature, the go-live date or the notice period.
- Say what happens if the owner is absent. The deputy takes over, and the change is recorded. A vacant owner is itself a finding.
The evidence requirement is what separates this from an org chart exercise. It also connects governance to a record that others can read. When contracts, entitlements and deployments sit in one place, the evidence for most handoffs is a field rather than a document hunt, and a tool such as the License Contract Manager can carry the renewal date, the notice period and the decision owner on the contract itself, so the renew handoff leaves a trace by default.
Run a one-hour handoff audit
You do not need a program to find out where your handoffs are weak. Pick one vendor that matters and work through this list with the people who touch it.
- List the product's five handoffs from request to retirement as they actually happened, not as the process says they should.
- For each, write down who held the product before and after, and what they were told.
- Mark each handoff as evidenced, assumed or unknown. Be strict: if the proof is a person's memory, it is assumed.
- For every assumed or unknown handoff, name one owner and one piece of evidence, and set a date to produce it.
- Repeat for the next two vendors by renewal date, then compare. The weak handoffs are usually the same ones.
- Bring the pattern, not the individual cases, to the people who own the process, and ask who should hold the handoffs that no one does.
The first audit will show that most gaps cluster at two or three seams, usually purchase to deploy and renewal. Those are the places to fix first. Policy can stay as it is for now, because the thing it was missing was never a clause. It was a name.
