The “Yesterday” Problem: What I’ve learned from customers who challenged the traditional procurement timeline
By Jag Gattu, CEO, UptimeAI
This blog was originally published on LinkedIn.
I have this question I ask almost every operations leader I meet: when do you actually need this running? I ask it half out of curiosity and half because I already know the answer. Nine times out of ten, it’s some version of “yesterday.” Somebody’s losing sleep over a unit that keeps tripping, or a maintenance backlog that never shrinks, or a retirement that’s about to walk two decades of institutional memory out the door. There’s real urgency in the room.
And then, almost every time, that urgency hits a wall when it comes to the procurement process. First, they’re waiting on legal. Next, it’s IT. Someone has to find out who actually owns all the systems that need to be connected together. And by the time all of that has happened in sequence, the six months that everyone swore they didn’t have at the start of the project have quietly gone by.
I want to be careful here, because I don’t think the lesson is “move faster at all costs.” I’ve watched companies get burned by exactly that instinct — skipping a scoping session or waving off a data question can add more delays later. Whatever we build, it has to earn its way into a plant’s operations, and that takes real diligence. What I’ve learned instead, from watching a lot of these cycles up close, is that diligence doesn’t have to walk a straight line. Many procurement tasks can occur simultaneously; they just usually don’t because it’s not the way things have historically been done.
Here are a few of my favorite techniques that our customers have used to accelerate the value generation of their AI project by choosing not to wait on traditional timelines.
1. Be an advocate for imperfect data
I remember a call with an operations director at a cement plant who was clearly ready to move, but his team kept getting stuck arguing over whether they had “enough” and “good enough” data. Every week someone identified a new handful or tags, or a new sensor that would be “nice to have when trying to predict XYZ.” It could have gone on indefinitely.
At some point he just made a call: they’d agree on the handful of failure modes and the data around the assets that actually mattered for proving the case, then treat everything else as things that could be done in parallel once the solution was live. That one decision point—to accept that some things would be ready now, others would improve over time, and even more opportunities would be uncovered by their use of the technology—avoided weeks of delays in getting the software operational.
2. Know your scope, your systems, and your stakeholders
We worked with a project manager for deployment at a large refining client whose team showed up on day one with a clearly defined pilot scope, the KPIs they’d measure success on, the data they’d need to deliver successful results, and the people with the right access to the relevant systems to make it all happen.
This might sound trivial, but I saw another engagement get delayed by over a month because a new data source was added to the scope which lived at a different level of the enterprise architecture and had a different owner than our other refinery data sources. That owner wasn’t up to speed on our project, and we were fighting for their time with other priority projects that they’d known about for much longer.
3. Identify, and challenge, dependencies
One of our early power generation customers taught me something I hadn’t fully appreciated: a lot of the delay in these deals comes from waiting on others out of habit rather than requirement.
Their security and architecture review ran at the same time as the final commercial conversation, not after it, because somebody on their team asked “why would these two things need to happen in order?” and nobody had a good answer. Procurement and legal moved on a similar clock. Nothing about the actual approvals changed — same reviewers, same rigor. What changed was that they finished around the same time the contract did. That business was ready to execute the week they signed, instead of six or eight weeks later, which is close to how long that kind of review usually takes when everyone assumes it must come last.
What I want you to take away from these stories
None of these customers moved faster by cutting anything out. They moved faster because they stopped assuming that due diligence must happen in series. Confirming the use case, mapping the data, starting the security and legal review, building the onboarding plan — almost none of it actually depends on each other.
If your team is telling you they needed this yesterday, I’d take that seriously — not as a reason to skip anything, but as a reason to ask, honestly, which parts of the next few months are actually sequential out of requirement, and which ones are just habit and can be accelerated to help get them the solution they need, yesterday.
I’m grateful to the customers who have proved to me that it’s possible to go from demo to go-live in less than a quarter. We’re taking those learnings, applying them to every customer sale, and helping our new customers push to the frontier of adoption of AI reasoning agents for industrial operations.






