4 Warning Signs a Project Is Heading Toward a Claim (That Show Up in Documentation First)

Most claims aren’t surprises.

The signs may be visible for weeks before anything is officially filed. Unfortunately, most people aren’t looking in the correct places at the time, and on the bulk of public works projects, they won’t show up in the schedule.

Let me walk you through what I mean. Picture a bridge project with creek work bounded by permit deadlines. The contractor’s baseline schedule is tight but workable. Two weeks in, they still haven’t turned in their SWPPP — which the team needs before pulling a WDID number from the Regional Water Quality Control Board, which is what allows them to start work. So, they take an extra week to submit and the team uses the full review period (3 weeks, contractually). And by the time the WDID is in hand and work can start, a month of float is gone.

The questioning begins:

❓ Has the contract been violated? No.

❓ Has anyone been late on a contractually-defined deliverable? Technically, no.

❓ Does the contractor have any documented basis for a claim? None.

But here’s what just happened:

The contractor consumed weeks of their own float without anyone tracking it. Three weeks from now, a nesting bird is going to cause a real delay. And that delay is going to come with a claim — for the time they’ve already burned through on something else.

This is what most PMs already feel and can’t quite put their finger on. They know something is off because the contractor isn’t formally behind and there’s no claim on the table. But your gut is telling you a problem is coming.

That feeling is usually right. The trick is knowing where to look to confirm it — and how best to document that confirmation, before the legitimate-looking issue lands and the deflection starts.

Learn about the four patterns I watch for below. ⬇️

1. Work is happening, but not on the critical path.

The contractor’s crews are out there. Daily reports show activity. Productivity looks fine. The monthly schedule update may even show them on track.

But the work isn’t on the items driving contract time.

This is the most important warning sign because it sets up every other problem downstream. When a contractor works the easy items first and lets the critical path lag, they’re eating their own float — quietly, without violating anything in the contract. Until something legitimately gray comes up months later, i.e., a differing site condition, a design clarification, or a real RFI-worthy ambiguity. By the time that happens, the float is gone, and the gray issue becomes cover for a delay the contractor already created. You end up on the defensive trying to disprove that a late issue caused a delay that was actually months in the making.

Most contractors and PMs on sub-$100M projects aren’t actively managing critical path. The schedule is a contract deliverable, not a real-time tool. So you can’t rely on a schedule update to flag this for you. You have to read the daily reports against the contractor’s stated critical path activities yourself, every couple of weeks. When you see a gap — crews working items that aren’t driving contract time — put it in writing.

• Meeting minutes.

• Weekly statement of working days.

• A direct email asking the contractor to explain how they’re tracking against critical path.

• You’re not picking a fight. You’re creating the record that prevents a future deflection.
  
  

2. Long lead items aren’t reflected in the contractor’s schedule — and nobody’s asking the right questions about them.

This one is a planning failure dressed up as a procurement problem, and the contractor often isn’t hiding it. They just haven’t thought about it.

Submittals tell you what the contractor knows about their own supply chain. The schedule tells you what they’ve actually planned for. When those two don’t match, somebody is going to be surprised — and it’s usually the owner.

Example: The contractor’s baseline schedule shows switchgear installation in week 22. The long lead procurement submittal (when it eventually comes in) shows 16 weeks for delivery. There’s no order date in the schedule, no fabrication window, no shipping window — the procurement is invisible. The 16 weeks have been quietly absorbed into general construction time. If anything goes sideways with that procurement (and on public works it almost always does — supplier delays, factory inspection failures, shipping holdups), the contractor will frame it as an owner-caused delay because there’s no contract artifact saying they were responsible for managing it.

Same dynamic on environmental sign-offs, utility coordination, permit modifications, and any agency review with a multi-week external dependency. Anything that isn’t visibly tracked in the schedule is a future claim waiting for a hook.

The fix is in two places — one upfront, one ongoing.

At the preconstruction meeting, ask the contractor what they consider long lead items on the project. Don’t tell them — make them name them. You already know some of the obvious ones (switchgear, traffic signal equipment, structural steel, specialty pumps) and you can prompt with those if they miss them. But the goal is to put on the record what they think requires planning. That conversation, captured in meeting minutes, is the foundation for every later discussion about who was supposed to be tracking what.

At every weekly meeting, look 3–4 weeks ahead in the baseline schedule or the contractor’s order of work. Ask: what submittals or shop drawings do we not have yet that we’re going to need? Don’t wait until you’re a week out from a steel pour to discover the shop drawings haven’t been submitted, hear “oh yeah, here they are,” and find yourself already behind. The contractor isn’t necessarily hiding this — they often just haven’t planned it. Your job is to ask the question early enough that the answer still has options.

3. The RFI log is telling you something — read it as a system, not as individual questions.

Most claims on public works projects don’t start with one bad RFI. They start with a pattern in how the RFI process is being used.

The most common version is timing. Contractors usually submit RFIs when they’re already looking at the work, not weeks ahead when there’d be time for the designer to research and respond before it affects production. Even when the design team responds well within the contractual window, the project is already losing time — because the work was queued up behind an answer that hadn’t been asked for early enough. You can run a clean RFI log on response times and still be bleeding schedule.

When you see this pattern — RFIs arriving the week the work starts, every time — it’s worth a direct conversation at a weekly meeting. Ask the contractor to look 3–4 weeks ahead at upcoming work and identify questions early. Document that conversation. If RFIs continue to come in late, you’ve established that the contractor was given the opportunity to plan ahead and didn’t.

The other pattern to watch is volume. When a contractor starts submitting a steady stream of small RFIs — items that individually don’t seem to warrant much attention, none of them on the critical path, none of them about anything urgent — that’s not a design problem. That’s a contractor building a record. They’re demonstrating a “pattern of design issues” they can point to later as the basis for a broader claim about plan ambiguity, coordination problems, or impact to their work. By the time you realize what the volume adds up to, the record is already there.

The fix in both cases is the same: don’t process RFIs transactionally. Look at the log every two weeks as a whole. Are RFIs arriving with enough lead time to be answered without impact? Is the volume in line with what a project of this complexity should generate? Are they clustering in spec sections or work areas? Patterns that would never show up on any one RFI become obvious when you look at the log as a connected document.

One more thing worth saying about RFI response times that doesn’t get said often enough: most project teams try to respond faster than the contract requires, which is a good practice. But every now and then, an RFI is going to need more time than the contract allows — the designer needs to research it, run a calculation, get a design change executed. That’s reality, and it’s not always avoidable. The thing to do in those situations is to get the contractor on record, in writing, that the RFI in question isn’t on the critical path. Then make sure your baseline schedule and updates actually back that up. If the schedule shows the activity is on critical path, the contractor’s email doesn’t protect you — that’s not a clarification anymore, that’s a claim. You don’t always have to be on time. But when it counts, you do — and when it doesn’t, make sure you’re not the only one saying so.

4. Meeting minutes have unresolved items with no owner, no action, or no deadline.

Meeting minutes are the cleanest leading indicator we have on a project, and almost nobody uses them that way.

Here’s the standard for a usable meeting minute item: every open issue should have an action, an owner, and a date. Not “follow up.” Not “TBD.” Not “ongoing.” A specific action, a specific person responsible, and a specific date by which a response is expected. That standard applies regardless of which side of the table the action sits on:

• The contractor asked a question and needs to formalize it: “Contractor’s PM to submit RFI on conduit conflict by EOD tomorrow.”
• The CM team owes a response: “Resident Engineer to call the materials testing lab and get the weld sample test results back by end of week.”
• The owner has the action: “City PM to coordinate with Traffic Engineer on lane closure approval for new pattern, due by end of this week.”

When meeting minutes consistently produce items in this structure, two things happen. First, things actually move. Second — and this is the part most teams miss — when something doesn’t move, the failure is documented. You can see it. You can address it.

The warning sign is when meeting minute items don’t have all three components. Items show up as descriptions of problems with no action attached. Or actions get assigned to “the team” instead of a person. Or there’s no date — just an open status that quietly rolls forward week after week.

When an item rolls forward like that, you lose two things you can’t get back. You won’t be able to identify whether it’s stuck, who’s responsible for moving it, or when it should have been resolved. And you won’t have the documented record showing the team made reasonable efforts to resolve it before it became an issue.

Here’s a real example: On a recent project, the owner had been asking the contractor for a makeup schedule for over two months — the work was clearly slipping, the original baseline schedule was no longer realistic, and the team needed to see how the contractor planned to recover. The request showed up week after week in meeting minutes. The contractor never produced one. Eventually, the contractor turned around and claimed time and cost impacts on the project. The problem with that claim — beyond the contractor never having demonstrated the ability to manage their own schedule in the first place — is that the documented record of the owner asking for a recovery plan, repeatedly and over months, was right there in the meeting minutes the whole time. The pattern itself was the defense.

That’s the part most teams underuse. The recurrence of an unresolved item in meeting minutes isn’t just a tracking failure. It’s a documented pattern. When a claim arrives, that pattern is one of the strongest pieces of evidence the team has — but only if you can pull it together when you need it.

The fix is upstream of the meeting minutes themselves. Insist on the structure — action, owner, date — for every open item, every meeting. When an item rolls into a third set of minutes without resolution despite having all three components, escalate it out of the weekly meeting cycle. Put a decision deadline on it. Get it on a project executive agenda. Send it up the chain with a written summary of what’s been tried and where it’s stuck.

One more thing worth saying about meeting minutes specifically. They’re the only project document where the contractor’s silence is captured alongside the team’s. If an item is open for six weeks and the contractor never raises it as an impact during that window, that absence is in the record too. It cuts both ways — but most of the time, on a well-run project, it cuts in the owner’s favor.

Closing

None of these signals require special tools to spot. They require a PM with the time to read the documentation as a connected whole rather than processing it transactionally — and that’s the part that’s hard on a real project. The volume of paper coming at you on any one day makes it tough to step back and look for patterns across weeks.

But the patterns are the warning. By the time you’re responding to a formal claim, the documented record either supports your position or undermines it. The work that will support you happens in the weeks before anyone uses the word “claim” — when nothing official is wrong yet, but your gut is telling you something is.

One last thing — a brief note about what we built. On the makeup schedule example earlier in this piece, the project team obviously knew the contractor wasn’t producing one. They didn’t need a tool to tell them that. What they needed, when the claim eventually landed, was a fast way to assemble exactly how many times the owner had asked, what dates the contractor had committed to, and where each commitment had fallen short — across months of meeting minutes, RFIs, correspondence, and daily reports. That’s most of what we use BridgeDoc InSite for: to put language and structure to what experienced PMs already know — fast enough to matter when a claim response is on a clock.

And, every once in a while it does catch an existing problem. A pattern across documents that wasn’t obvious to anyone watching a single thread. A recurrence the team had stopped seeing because it had become background noise. We don’t lead with that, because the more honest claim is the assembly one — but if you’ve been in this work long enough, you know how often the project record holds something nobody quite put together until someone went looking. That’s the work InSite does fastest.

Want to see BridgeDoc InSite in action?

Book your FREE demo with Kelly HERE!

"I’ve managed construction on public works projects for over 25 years, including federally funded infrastructure in California. At BridgeDoc, we’ve built daily report workflows around the documentation practices that hold up under scrutiny — RE review, structured field logging, photo management, working day tracking, and built-in prompts that make thorough reporting achievable in the field. If you’d like to see how it works, I’d be happy to show you."- Kelly Wheeler, BridgeDoc CEO & Founder