The most expensive item in our IT backlog was also the cheapest one to fix. Nobody knew, because nobody had looked at it in years.
It was a regional electronics and appliance retailer, and our connection to our third-party logistics partner was held together with partial code pushes, EDI exchanges, a steady stream of emails, and a phone call every single day. We counted anything that needed a follow-up email or a call as an error. By that measure, four out of every ten exchanges with our 3PL failed. Every one of them was a delivery, an inventory update, or a customer waiting on somebody to pick up a phone.
The fix was on the list. It had been on the list since the day the 3PL went live, estimated at several hundred hours of development. And the development team was booked solid. Busy as bees, every one of them, closing tickets and hitting dates.
If you'd walked in to do diligence on that IT team, you would have checked the box. So would I.
The slide that's always green
You've seen this slide. It's in every operating review. IT utilization in the low 90s, projects on track, tickets closed inside SLA. It reads like a team at full capacity, and it is.
That's the problem. Don Reinertsen spent years showing what happens to work queues as utilization climbs: going from 80% to 90% roughly doubles the queue, and going from 90% to 95% doubles it again. A fully utilized team isn't a sign of health. It's a guarantee that the line of work nobody's getting to keeps growing.
A utilization report tells you how busy the team is. It can't tell you what the business has been waiting on, or what that wait costs every day. For that, you have to read the parking lot.
Read the parking lot
Ask for every request that was made and never started. Not the roadmap. The list. Each item needs three things attached: when it was requested, who asked for it, and when it was last estimated (or, failing that, last touched). If nobody can produce that list in a week, you've found your first problem.
Then take six readings.
- Years of backlog. Parked items divided by what the team delivers in a year. Anything over two means new requests never actually get in.
- Age profile. How many items are older than two years, and how many are older than four. The four-year-olds are the tell.
- Estimate age. How many estimates were written before your last major platform change. This is the one nobody measures, and it's the one that matters most. If items don't carry an estimate date, use the date each one was last touched.
- Orphan rate. How many items lost the person who asked for them. They left, got promoted, or stopped owning the problem.
- Re-ask rate. How many items got requested more than once, by different people or in different years. That's your real demand. The standard advice says good ideas come back on their own. These came back, and they still got parked.
- Leakage. The emails, the spreadsheets, the shadow IT, the unsanctioned AI tool somebody in finance is quietly paying for, all doing work that's sitting on the list. In our case, leakage was a standing daily phone call.
Put those readings together and most portfolio companies land in one of three places.
The Capacity Gap. A big backlog, low orphan rate, lots of re-asks. A good team, swamped, with keep-the-lights-on work eating everything. More capacity helps, and with AI-assisted delivery, for the first time it's cheap to add.
The Decision Gap. High orphan rate, old items, few re-asks. Nobody owns the call to kill an item, so everything gets parked forever. More capacity won't fix this one. Decision rights will.
The Bypass. High leakage. The business has already routed around IT. Get that work back under governance before it turns into a finding at exit.
Yes, some backlogs are just junk drawers. That's a Decision Gap too. A junk drawer is what a backlog becomes when nobody is allowed to throw anything away.
The thresholds for every reading are in the scorecard at the end of this issue.
What was sitting in ours
Our team didn't build the 3PL integration. An outside integrator built it, took it live, and handed it back to IT afterward. The backlog item came with it. That's when it became mine. Not long after, the complaints got loud enough that I went to look at what the 3PL could actually do.
The answer was attached to the backlog item itself. The original implementation documents showed the 3PL already ran a messaging pipeline on MQ that handled nearly all of its information exchange. And eighteen months earlier, we had moved our own systems to queue-based messaging.
Several hundred hours became five hours of configuration and twenty hours of testing. Measured exactly the same way as before, the error rate dropped from 40% to 2% overnight. The daily phone call went away. The value showed up on day one.
Nobody did anything wrong. The estimate was right the day it was written. It was wrong every day after that, and nobody went back. Every item in your parking lot is priced at what your company could do on the day it was parked. Change the capability and you've re-priced the whole lot, whether anyone notices or not.
Look at what it took to find it: a handoff, a complaint, and someone finally holding two documents side by side, the integrator's design notes and our own platform change. The full timeline just didn't live in any one head.
Why diligence misses it
That timeline is exactly what a deal team never sees.
Diligence runs on what the seller puts in the data room: an org chart, a systems map, a spend summary, a roadmap, and that green utilization slide. The parking lot isn't in there. To a seller, a list of things the business asked for and never got reads like deferred capex. If it exists in one place at all, it arrives curated. And even an honest management team can't tell you which old estimates went stale, because they don't know either. New capabilities come in through a platform upgrade, a vendor release, an integrator handoff, a new hire who knows a tool. There's no log entry for the day an old estimate stopped being true.
So you assemble the list yourself. Five requests do it.
- The raw ticket export, not the roadmap. Every open, deferred, on-hold, and "won't do" item from the ticketing or project system, with created date, requester, and last-modified date. Don't skip the won't-do items. That's where the good ideas that got killed by default are hiding.
- A capability timeline. Every major platform, integration, or vendor change in the last five years, with the date it went live. Lay it against the estimate dates. Every estimate written before a change on that timeline is a candidate for re-pricing. In our case, that one comparison was the whole fix.
- The handoff list. Every system or integration an outside party built and handed back to internal IT. Handoffs carry backlog nobody on the current team scoped, and they're where institutional knowledge falls off a cliff.
- Three interviews outside IT. Operations, finance, customer service. Ask one question: "What have you asked IT for that you're still waiting on?" Then a second: "What are you doing in the meantime?" The first answer is the parking lot management didn't send. The second is your leakage.
- The software spend IT doesn't own. Card and AP spend on software outside the IT budget. Every SaaS subscription and AI tool on a corporate card is a parking lot item somebody stopped waiting for.
Then compare what the business told you against the ticket export. The gap between the two is the most honest number you'll get in diligence.
Price it both ways. The parking lot is a liability: deferred work, workarounds that burn labor every day, and leakage that becomes a security or audit problem when you go to sell. It's also an asset: a list of improvements somebody already scoped, justified, and argued for. Most deal teams model neither. In the IC memo, that's a remediation reserve on one side and a value-creation line on the other. Both belong in the 100-day plan.
In a competitive process you won't get all five before the LOI. Put the ticket export and the capability timeline in the first data request. The interviews and the spend pull go in confirmatory diligence, or day one after close if that's what it takes.
Why the relook can't wait
Ours re-priced because of one infrastructure decision. AI is a capability change hitting every item on the list at the same time, and it isn't a one-time event. What a small team can build with AI-assisted delivery today is materially different from what it could build six months ago. An estimate from two years ago isn't a little stale. It was written for a different company. Work quoted at $50,000 a few years ago may be a $5,000 job today; Martin Alderson and Lunatech have both put numbers on that collapse.
Meanwhile, FTI Consulting's 2026 Private Equity AI Radar found only 7% of portfolio companies have scaled AI across the enterprise, and most of the rest are still hunting for use cases on a blank whiteboard. Your parking lot is that whiteboard, already filled in. It's just priced in the wrong year.
One caution. AI only pays off if someone points it at the parking lot on purpose, and keeps pointing it there as the tools change.
Pointing it on purpose takes a decision on every item. That's what Kill Park Blossom is for. Every item gets one of three calls. Kill: stop it, pull the resources, take it off the list. Park: defer it on purpose, with a reason and a date it comes back. Blossom: activate it now. Park was never supposed to mean forget. Our 3PL fix was a Park nobody ever came back to. A Park that never gets re-priced is just a slow Kill nobody had the nerve to make.
The Parking Lot Scorecard
Pull the list, then score each reading.
| Reading | How to measure | Low | Medium | High |
|---|---|---|---|---|
| 1. Years of backlog | Parked items divided by items delivered in the last 12 months | Under 1 | 1 to 2 | Over 2 |
| 2. Age profile | Share of items older than 2 years | Under 20% | 20% to 40% | Over 40%, or anything older than 4 years |
| 3. Estimate age | Share of estimates written before your last major platform change, or capability shift | Under 25% | 25% to 50% | Over 50% |
| 4. Orphan rate | Share of items whose requester left or no longer owns the problem | Under 25% | 25% to 50% | Over 50% |
| 5. Re-ask rate | Share of items requested more than once, by different people or in different years | Under 5% | 5% to 15% | Over 15% |
| 6. Leakage | Share of items someone is already working around: spreadsheets, standing calls, unsanctioned SaaS or AI | Under 5% | 5% to 10% | Over 10%, or any one touching customer orders or financials |
Save this scorecard: download the full-size image.
High is a warning on five of the six readings. On re-ask rate, High is the exception: it means the demand is real and the team just isn't getting to it.
Now find your profile. Check the Bypass first. It overrides the other two.
- The Bypass: Leakage High. Inventory every workaround and decide which ones IT takes back.
- The Decision Gap: Orphan rate High, age profile High, re-ask rate Low. Assign decision rights before you add a single person.
- The Capacity Gap: Years of backlog High, orphan rate Low, re-ask rate High. Add capacity, and point AI-assisted delivery at the oldest re-asked items first.
- No clean match: The list you were handed is probably incomplete. Go back to the interviews outside IT.
Estimate age doesn't pick your profile. It tells you how much money is hiding inside whichever one you're in. Run our 3PL story through the scorecard and we land in the Bypass: one standing call on customer deliveries is enough on its own. The Bypass told us something was wrong. Estimate age is what told us the fix was cheap. Over 50%, and re-pricing pays better than anything else on the list.
Pulling the data takes a day if the ticketing system is clean and a week if it isn't. The week is a reading too.
Start Monday
- Ask for the parking lot, not the utilization report. Operating partner or CEO asks; the CIO or IT lead produces it. At your next operating review, or in diligence on your next deal. Send the request this week. In diligence, that means the raw ticket export, the capability timeline, the handoff list, three conversations outside IT, and the software spend IT doesn't own.
- Run the scorecard. The IT lead pulls the data; finance or the operating partner does the scoring, so IT isn't grading its own backlog. The answer is one sentence for the board: we're a Bypass, a Decision Gap, or a Capacity Gap.
- Force a Kill Park Blossom call on everything older than two years. The CEO runs it with the business owners in the room, not IT alone. Every item gets a disposition and a named owner. Kill is a perfectly good answer. A Park gets a date when it comes back.
- Re-price the top ten at today's capabilities. Top ten by how often they've been asked for, then by who's asking. One senior engineer, using AI-assisted tools if you have them, does the re-estimate. Start with anything estimated before a change on your capability timeline, or more than six months ago. Some will drop by an order of magnitude. Ours did.
- Put parking lot age on the board scorecard. Share of items older than two years, right next to utilization. Then protect a fixed slice of capacity every quarter for pulling items off the list. Start at 10%.
The fix for our worst integration sat in the parking lot for years, already documented and already enabled by our own infrastructure. Nothing had to be invented. Somebody just had to put two documents side by side. Next issue is build vs. buy, and why the two numbers every one of those decisions gets made on are the least important ones in the room.