Every IT organization with a persistent ticket backlog treats the backlog as the problem and measures progress by reducing it. This is the wrong frame. A ticket backlog is the visible manifestation of a supply-demand imbalance in IT support capacity — the result of a problem, not the problem itself. Treating the backlog as the target produces solutions that attack the symptom: hiring more helpdesk staff, implementing triage automation to move tickets faster, setting SLA targets that create pressure to close tickets quickly. None of these address why the tickets were created in the first place.

The four-year PC refresh cycle that became standard in enterprise IT during the 2010s was a budget optimization made under specific conditions: hardware improvements were incremental, Windows 7 was stable, and the marginal productivity gain from newer hardware was not large enough to justify more frequent refresh. Those conditions no longer hold. The PC refresh cycle at many organizations has stretched to five, six, and in some cases seven years without a corresponding assessment of whether the extended cycle is actually saving money.

The security vendor community has done something impressive with the Zero Trust concept: it has taken a principled architectural framework that requires organizational discipline, policy definition, and sustained implementation effort, and repackaged it as a product category that can be purchased and deployed. The repackaging is commercially effective. It is also misleading in a way that causes organizations to believe they have implemented Zero Trust when they have purchased a tool.

The average organization with 500 to 1,000 employees is running between 100 and 200 SaaS applications. A fraction of those are managed by IT. The rest were procured by individual departments, teams, and employees using corporate credit cards, expense reports, and in some cases personal cards that get reimbursed. The finance team knows about the ones with purchase orders. The IT team knows about the ones that went through the security review queue. Nobody knows about all of them.

Enterprise software procurement moves at a pace that the software it is trying to purchase has long since left behind. The average procurement cycle for a mid-market enterprise software purchase — from initial vendor identification to signed contract — runs between four and nine months. The software category the procurement team is evaluating will have shipped multiple major releases during that period. The requirements documentation that anchored the evaluation will have drifted from what the business actually needs. The vendor selected may have been acquired.