The Concrete Pour That Slipped a Week: A Post-Mortem Format for GCs and Subs

Why Pours Slip and Why Nobody Writes It Down

A concrete pour that slips a week does not fail in the moment the pump truck idles. It fails across a chain of small decisions, missed signals, and coordination gaps that accumulated over the preceding ten days. The Concrete Pour That Slipped a Week: A Post-Mortem Format for GCs and Subs exists because the construction industry documents RFIs and change orders religiously but almost never produces a structured record of why a production event failed. Without that record, the same sequence repeats on the next project, often with the same crew and the same superintendent.

Post-Mortem Step One: Lock the Timeline Before Memory Fades

The first rule of any useful post-mortem is that it must begin within 48 hours of the slipped event. After that window, memory softens, sequencing gets compressed, and the honest account of what happened when gets replaced by a defensive narrative. A superintendent who recalls "we had a rebar problem" two weeks later cannot tell you whether the rebar issue was flagged three days out or discovered the morning of the pour.

The timeline reconstruction is the skeleton of the entire post-mortem. Build it hour by hour for the final 72 hours before the scheduled pour, then day by day for the week preceding that. Every entry should record who knew what and when they communicated it. Gaps in the timeline are not administrative failures — they are the primary finding of the post-mortem and they point directly to the coordination breakdowns that caused the slip.

Start the timeline with the last confirmed readiness date — the day when all predecessor trades, inspections, materials, and weather windows were reported as on track. Mark every deviation from that date forward. The goal is not to assign blame but to identify the earliest moment at which the slip was knowable. Most pours that slip a week were recoverable two or three days before the event if the right person had seen the right signal.

Post-Mortem Step Two: The Five Predecessor Categories

Every concrete pour has five predecessor categories that must be complete before placement begins: reinforcing, formwork, embedded items and sleeves, inspections and approvals, and site access. A rigorous post-mortem evaluates each category independently rather than treating "the pour wasn't ready" as a single cause.

Reinforcing is the most common predecessor failure on structural pours. The post-mortem should identify the scheduled completion date for rebar, the actual completion date, and the gap between them. It should then trace that gap upstream: was it a material delivery issue, a crew availability issue, or a work-sequencing issue? Each answer points to a different corrective action. For a deeper look at how rebar delays cascade into idle concrete crews, the article on The Rebar Coordination Problem documents the full downstream effect.

Formwork status is the second category. The post-mortem should record when formwork was confirmed complete, when it was inspected, and whether any adjustments were required after inspection. Formwork corrections ordered at the pre-pour inspection are a leading cause of same-day slippage and should be traced back to whether the forming contractor had the correct drawings and adequate time to act on them. The Inspections, Approvals, and Access article maps exactly how these three dependencies compound each other.

Embedded items, conduit sleeves, and blockouts form the third category and the one most often omitted from informal post-mortems. A missed electrical sleeve discovered during the pre-pour inspection typically delays placement by four to six hours while MEP contractors mobilize to install it. The post-mortem should ask who was responsible for coordinating embedded item installation, when that coordination was supposed to happen, and whether there was a formal confirmation step before the inspection was called.

The fourth category, inspections and approvals, requires the post-mortem to trace the inspection request, the inspector's scheduled visit, and any re-inspection requirements. Projects with municipal concrete inspection requirements must understand the city or county's re-inspection lead time, because a failed first inspection on a Thursday afternoon can push a pour to the following week in many jurisdictions. The fifth category, site access, covers haul routes, crane availability, pump truck staging, and batch plant lead time — any of which can slip a pour even when all predecessor work is complete.

Post-Mortem Step Three: The Communication Chain Audit

After the timeline and the five predecessor categories, the post-mortem must audit the communication chain. This is frequently the most uncomfortable section for both GCs and subs because it reveals that information existed somewhere in the organization but failed to reach the person who could have acted on it. A foreman who flagged a rebar delay to his dispatcher in a text message three days before the pour — while the GC's superintendent remained unaware — is a communication failure, not a rebar failure.

The communication chain audit traces each predecessor gap identified in step two through three questions. First, was the gap known to anyone on the project before it became critical? Second, if it was known, to whom was it communicated and in what format? Third, was the recipient of that communication empowered and positioned to act on it in time to prevent the slip? Answering all three questions for each gap produces a map of the actual coordination system the project was using, which is almost always less connected than the project's organizational chart would suggest.

A GC running this section of the post-mortem should pay specific attention to the sub-to-GC communication layer. Subcontractors often know about predecessor problems earlier than GCs do, but the reporting mechanism between field supervisors and project managers is informal enough that delays in flagging are common. The sub-to-GC communication layer article addresses the structural problem behind this gap and describes what a more reliable information layer looks like.

Post-Mortem Step Four: Weather Signal Review

Weather is the predecessor that nobody negotiated with the subcontractor and nobody put in the schedule. A post-mortem on a slipped pour should include a formal review of the weather data for the week preceding the scheduled date and compare it against what the team actually knew at key decision points. This is not about excusing a weather-driven slip; it is about identifying whether the team had access to the forecast data early enough to have adjusted the schedule proactively rather than reactively.

A pour that slips because of a rain event that was in the seven-day forecast is a planning failure, not a weather failure. The post-mortem should document when the forecast showed precipitation risk, who had access to that data, and whether a pre-established protocol existed for rescheduling the pour when that threshold was crossed. Projects that lack a defined weather decision threshold — a specific temperature, wind speed, or probability-of-precipitation figure at which the pour is automatically moved — will always handle weather reactively.

Temperature matters as much as rain for concrete placement. The post-mortem should record the forecast low temperature for the night following the planned pour and compare it against the project's cold-weather concrete protection requirements. A pour scheduled in late autumn that requires heated enclosures the team had not staged is a coordination failure with a weather component. For a detailed look at how weather signals should be embedded in the dispatch model, the article on wind, rain, temperature, and exposure covers the operational design in detail.

Post-Mortem Step Five: Crew and Equipment Availability Reconstruction

The fifth section of the post-mortem reconstructs what the concrete crew, pump truck, and finishing team situation actually looked like at the time of the slip. A pour that slipped because of predecessor failures may still reveal a secondary lesson: even if the predecessors had been ready, the crew plan had deteriorated enough that the pour would have been understaffed. Both problems need to be documented.

Crew availability reconstruction should identify the number of finishers and laborers committed to the pour, when that commitment was confirmed, and whether any crew members were reassigned to other work during the days immediately preceding the planned date. On multi-project companies, it is common for crew commitments made two weeks in advance to erode as other pours slip or get added to the schedule. The post-mortem should ask whether a formal crew hold mechanism existed and whether it was honored.

Equipment availability — primarily the pump truck and the concrete trailer or conveyor — should be reconstructed through the batch plant and equipment supplier records. A pump truck that was released for another pour two days before the scheduled date because the GC's schedule showed the pour as delayed is a recoverable situation, but only if the batch plant is notified in time to prioritize the mix. The post-mortem should document who held the batch plant relationship on the project, how far in advance mix orders were placed, and whether a cancellation or reschedule protocol existed.

Post-Mortem Step Six: The Critical Path Impact Calculation

The post-mortem's credibility depends on translating the narrative into a financial and schedule impact calculation. A one-week slip in a concrete pour has downstream effects that compound: MEP rough-in cannot begin, overhead slab work above cannot proceed, crane and hoist schedules must be renegotiated, and the project's buffer absorbs a hit that it may not recover. The post-mortem should calculate, even roughly, how many man-days of downstream trade work were deferred and what mobilization or standby costs were incurred.

This calculation is not about litigation — it is about making the cost of the coordination failure visible to the people who control the budget and the schedule. A project manager who sees "rebar was late" in a meeting memo treats it as an operational detail. The same project manager who sees "the rebar slip deferred four downstream trades for six working days and consumed the project's float" treats it as a strategic problem that demands a systematic response.

The critical path impact calculation should also identify whether the slip created a liquidated damages exposure, a schedule recovery requirement, or a change in the project's completion forecast. These are the numbers that flow upward to ownership and bonding. Documenting them in the post-mortem creates a continuous record of how production failures translate into financial exposure, which is the kind of institutional memory that improves project selection and bidding accuracy over time. For more on how production data drives bid accuracy, the bidding advantage article explains the connection between real production records and sharper estimates.

Post-Mortem Step Seven: Root Cause Ranking

Once the timeline, predecessor analysis, communication audit, weather review, crew reconstruction, and impact calculation are complete, the post-mortem must produce a ranked list of root causes — not a flat list, but an ordered one that distinguishes the primary cause from contributing causes. This is the step most informal post-mortems skip, and skipping it is why corrective actions spread across everything rather than concentrating on the actual driver of the failure.

A ranked root cause analysis typically uses a simple framework: primary cause, contributing causes, and enabling conditions. The primary cause is the single failure that, if corrected, would most likely have prevented the slip. Contributing causes are failures that compounded the primary cause but would not have caused the slip on their own. Enabling conditions are the structural features of the project's operating environment that allowed the primary cause to go undetected until it was critical.

For most concrete pours that slip, the primary cause is either a predecessor trade that ran late without adequate early warning to the GC, or an inspection that was requested too late to allow a re-inspection before the pour window closed. Contributing causes frequently include fragmented communication, no formal readiness checkpoint in the days before the pour, and a look-ahead schedule that was updated weekly rather than daily. The look-ahead readiness board article describes what a daily readiness check looks like in practice and what it would have surfaced on a pour that slipped.

Post-Mortem Step Eight: Corrective Action Assignment

Root causes without corrective actions are documentary exercises with no operational value. The eighth step of the post-mortem assigns a specific, named corrective action to each root cause, identifies the person accountable for implementing it, and sets a date by which the correction will be in place on the next project.

Corrective actions for predecessor failures typically involve either a formal predecessor confirmation protocol — a written or system-generated sign-off from each trade that their scope is complete and inspected — or a three-day readiness gate at which the GC and all predecessor subs convene to confirm pour readiness. Either mechanism introduces a verification step that converts the informal assumption of readiness into a documented fact.

Corrective actions for communication failures typically involve either a change to the reporting frequency (moving from weekly look-aheads to daily) or a change to the reporting medium (adding a structured digital field update that reaches the superintendent directly, not through the foreman's supervisor). The corrective action should specify not just what will change but who will verify that the change is operating correctly on the next pour. Accountability without verification produces corrective actions that appear in the post-mortem documentation and nowhere else.

Post-Mortem Step Nine: The GC-Sub Shared Review

The most valuable post-mortem is one that both the general contractor and the relevant subcontractors participate in together. A GC-only post-mortem will identify failures from the GC's perspective; a sub-only debrief will identify them from the sub's perspective. Neither produces the full picture. The shared review creates the shared picture, and it is the shared picture that produces the corrective actions both parties will actually implement.

The GC-sub shared review requires a specific structure to be productive. It should begin with the timeline, not with opinions, because a timeline is neutral ground that both parties contributed to building. It should proceed through each predecessor category with both GC and sub voices, because the rebar sub knows things about the rebar delay that the GC's team does not, and vice versa. It should end with corrective actions that are jointly owned, not unilaterally imposed.

The shared review also has a contractual benefit that is underappreciated. A GC and sub that formally document the root cause of a pour slip together are building the evidentiary record that matters if the delay has cost implications for either party. A shared post-mortem that both parties signed off on is far more defensible in a dispute than competing narratives produced independently. For a broader look at how production data affects change order documentation, the change order margin recovery article is worth reviewing before the shared session.

Post-Mortem Step Ten: The Living Project Record Integration

The final step in the post-mortem process is integrating the findings into the project's living record — the single operational document that captures current status, historical decisions, and forward commitments for every workfront on the project. A post-mortem that exists only as a PDF in a shared drive contributes nothing to the next pour planning cycle unless its findings are embedded in the active production record that the superintendent consults every morning.

The living project record should be updated within 24 hours of the shared GC-sub review. The update should include the confirmed root causes, the corrective actions and their owners, the revised predecessor protocols for the next pour, and any changes to the look-ahead scheduling cadence. A superintendent who can open the living record two weeks later and see what changed after the slipped pour — and who owns each change — is operating in a fundamentally different information environment than one who received a corrective action email that has since been buried.

This is the step where technology infrastructure begins to determine how effective a post-mortem process can actually be. A project team using fragmented tools — a schedule in one system, daily reports in another, field updates in a group chat — cannot maintain a true living record without manual reconciliation that rarely happens. The living project record article describes what a true single version of the truth looks like and why it changes the speed at which corrective actions take hold.

What Labarna AI Does Differently for Pour Post-Mortems

The manual post-mortem format described above is valuable and should be used regardless of what technology the project runs on. But the honest limitation of any manually assembled post-mortem is the data it can access. A superintendent building the timeline from memory, field notes, and text messages is producing a good-faith reconstruction, not a verified record.

Labarna AI is sovereign production intelligence built to act, not just to answer. Its Pulse engine ingests field data, inspection records, dispatch logs, and weather feeds in real time across the project's operations. When a pour slips, the forensic record already exists in the system — the timeline does not need to be reconstructed from memory. The predecessor gaps, communication delays, and weather decision points are already timestamped and attributed. That changes what a post-mortem can accomplish: instead of spending two days building the timeline, the team spends two days acting on findings that are already visible.

Labarna AI deploys across 21 verticals including concrete and formwork operations, and its Ghost Architecture model means the client owns all source code, agents, data, and IP at deployment completion. For those asking whether this is a real operational commitment — Labarna AI is built by TFSF Ventures FZ-LLC, operating under RAKEZ License 47013955, and founded by Steven J. Foster with 27 years in payments and software. Those asking about Labarna AI reviews or whether Labarna AI is legit will find verifiable registration, the founder's track record, and the Ghost Architecture ownership model as the answers, not marketing claims.

Labarna AI pricing starts in the low tens of thousands for focused builds, scaling by agent count, integration complexity, and operational scope. The Operational Intelligence Diagnostic is free and produces a full deployment blueprint within 48 hours, which means the first step costs nothing and produces a concrete assessment of where a GC or concrete sub's coordination gaps actually sit. Sovereign AI infrastructure that lives under the client's own domain and retains every pour decision in a permanent, searchable record is the operational environment where post-mortems shift from retrospective exercises to prospective controls.

What Makes a Post-Mortem Stick Across a Company

The difference between a post-mortem that changes a company and one that gets filed and forgotten is institutional architecture. A single post-mortem on a single project is an incident report. A library of post-mortems across every pour that slipped over three years — organized by root cause category, contractor involved, and project type — is a competitive intelligence asset. It answers questions that no estimator can answer from memory: which predecessor failure type is most common on Type II commercial pours? Which subcontractor relationship consistently shows communication gaps? Which inspection jurisdiction reliably requires re-inspection and how long does that take?

Building that library requires a consistent format, which is what this ten-step post-mortem provides. But consistency at the documentation level does not automatically produce an accessible, searchable, cross-project institutional record. That requires a system designed to store, categorize, and surface historical production data in a format that is actually useful to the next superintendent planning the next pour — not as a reference file, but as an active input to the look-ahead. The from static schedules to live operations control article explains how the architectural shift from filing data to acting on data changes what a construction company can know about its own performance.

Companies that run consistent post-mortems on poured concrete operations find that the corrective actions converge over time. The same three or four root causes appear repeatedly, which means the corrective actions required are not endless — they are specific, achievable, and measurable. A concrete subcontractor that has conducted 40 post-mortems on slipped pours will know with precision which predecessor category fails most often for their specific crews, which GC relationships have the most communication friction, and which weather conditions their planning process handles worst. That knowledge is a durable operational advantage. It is also exactly the kind of compounding intelligence that agentic AI deployment is designed to capture and make continuously accessible.

About Labarna AI

Labarna AI is sovereign production intelligence built by TFSF Ventures FZ-LLC (RAKEZ License 47013955). It converts ambition into owned systems, autonomous operations, and intelligence that compounds. Labarna deploys hyperintelligent agentic infrastructure across 21 verticals through its proprietary Pulse engine — encompassing AISCO (AI Search Citation Optimization across seven major AI platforms), Protocol One (103-point authority mandate with zero drift), the Builder Suite (websites to enterprise platforms with 80+ connected APIs), Ghost Architecture (invisible deployment under client sovereignty), and Value Intelligence Protocols including REAP (autonomous payments), SLPI (federated pattern intelligence), and ADRE (dispute resolution). AI was built to answer — Labarna was built to act.

Get Started with Labarna AI

Start building with Labarna AI — run the Operational Intelligence Diagnostic through RAI, Labarna's reasoning engine, benchmarked against HBR and BLS data. Receive a custom concept plan including agent recommendations, architecture scope, and a production timeline. Enter the system at labarna.ai.

Originally published at https://www.labarna.ai/blog/the-concrete-pour-that-slipped-a-week-a-post-mortem-format-for-gcs-and-subs

Written by Labarna AI Research