How software should be run
Every company now runs on dozens or hundreds of apps. Most still manage them the way they did when there were ten: a central team, a spreadsheet, and hope.
We ran app governance by hand at two companies, first with a single spreadsheet and then with a 172-point scorecard for every app. Both worked, and both taught us the same things. Here are seven of them. They hold whether or not you ever use Collet.
1. Your team already owns its software. Admit it.
Nobody in IT chose your CRM. Marketing did. Finance chose the accounting system, Engineering chose a dozen developer tools, and someone in Sales signed up for the thing everyone now depends on.
That isn't a failure of governance. It's how modern companies work, and it's mostly good. The failure is pretending otherwise. When the org chart says IT owns all the software, the people who understand each tool have no reason to look after it, and IT can't look after all of it.
Start from reality. Write down who owns what.
2. Every app needs one name next to it.
Shared ownership sounds collaborative. In practice, everyone assumes someone else has it.
Apple put a single name next to every action item, the DRI, the directly responsible individual, for a reason. Do the same for every app. Others can help, administer, and advise. One person answers for it.
3. Set the bar centrally. Meet it locally.
Central teams are good at deciding what "good" looks like: sign-in through your identity provider, MFA enforced, departed people removed, renewal dates known. They're bad at doing it for 130 apps they don't use.
So split the job. IT, security, and compliance set the standard. Each DRI gets a short, specific list for their app and works through it on their own time, with no meetings and no tickets bouncing between teams.
A short list gets done. A policy document gets filed.
4. Enforcement is a trade-off. Choose it on purpose.
Blocking a renewal until SSO is on can be exactly right. It can also stall a team that depends on the tool, over a fix that would have happened anyway.
Neither "block everything" nor "block nothing" is a policy. Decide case by case. Know what you'll block before you block it, write down why, and name who can grant an exception.
Enforcement you've thought through earns trust. Enforcement by default earns workarounds.
5. Measure outcomes, not purchases.
The question is never "did we buy the right tool?" It's "can people sign in safely, do departed employees lose access, and do we know what this costs and when it renews?"
Grade your software on outcomes. A standard that can only be met by buying another product, or by upgrading to the plan that unlocks SSO, isn't a standard. It's a sales pitch.
6. The record should come from the work.
Every company has a software inventory that someone rewrote the week before the last audit. It was right that week.
When documentation is a separate task, it's always stale, because the work moves on and the document doesn't. Set things up so that doing the work updates the record: fixing a setting, naming a DRI, confirming that someone who left lost access. Then the inventory is true any day you look at it.
7. Make the state of things visible to everyone.
Most software problems last because nobody can see them. When every app's DRI, standard, and status are visible across the company, people fix things without being asked, and nobody is surprised at audit time.
Visibility isn't about blame. Show progress, not a wall of shame. But show it.
You can follow all seven with a spreadsheet and a lot of follow-up. We did, twice. Collet does the follow-up.