Home
Learning center
Project Management
Project Management

Remediation phases keep moving on assumptions, not on confirmed work

A remediation project can log every hour and still have no record of when a phase actually closed

JM
Juan Manjarrés
Marketing Manager
October 15, 2026
Reading time:
#
minutes
Remediation phase scheduling

When the next phase starts on assumption

Moving to the next phase depends on the right steps happening in the right order. A completed task and a closed phase are not the same thing. Regulatory sign-off on a remedial design has to happen before well installation starts. Confirmation sampling has to come back from the lab before the next grid gets excavated. A phase closes when those specific steps are done, in that order, not when the crew moves on because the schedule says it's time.

Most projects don't have anything written down that draws that line. Building a phase structure or a project log that holds up under a handoff isn't part of environmental science or engineering training; the training covers characterizing contamination, running the sampling protocol, reading the results correctly. Many firms plan a project the way the last one was planned, frequently the same spreadsheet with new dates, so the phases on paper rarely reflect what this specific site actually requires.

By the time work is underway, a plan exists, but nothing in it answers a plain question: did the right steps happen in the right order, or did the work just move forward?

Where the assumption costs you

A phase structure and a project log built for this specific project, thought through at planning instead of copied from the last one, is what turns "did the right steps happen" from a guess into a fact anyone can check. Without that groundwork, a guess that turns out wrong doesn't just cost time; it costs rework, a stalled regulatory review, or a crew standing on site with nothing they can actually do. That shows up in three places on every project.

Capacity and project timing don't always move together

A phase's staffing need gets estimated at planning. What rarely gets checked against it is what the team is already committed to on other active work. A quote goes out based on what a phase requires, not on what capacity actually remains once existing commitments are accounted for. The gap surfaces later, at execution, when the team assigned to a phase turns out to already be running at capacity somewhere else.

The mismatch traces back to planning. Checking demand against what's already committed before the work is quoted is the step that was never part of the process; the gap only becomes visible later, once the team is already needed. A phase scheduled against a team that was never actually confirmed available was scheduled on the same kind of assumption the opening already named, just one level earlier, before the work even started.

Situations that show up after the work already started

A project's site can turn out different from what the plan assumed: contamination extending further than the original characterization showed, groundwater behaving differently than expected, a utility conflict or an access issue changing what was assumed possible. None of this is a planning error; a site can only be characterized as well as the information available at the time allowed.

The real question is whether the project is built to handle it if it happens. A changed condition usually means a changed approach, sometimes one that needs regulatory review before the project can continue. When the phase structure and its tasks were only ever built for the original plan, there's nothing to update; the project keeps running against a plan the site has already outgrown. Built to be adjusted instead, the new steps are just as clear and confirmable as the ones the project opened with.

What happens when the project log can't back up what you're claiming

The first two situations are about whether the right steps happened at all. This one is different: whether you can prove they did, even when they did.

Regulatory review depends on proof that specific steps happened before the next phase started, not just a summary of what the project accomplished overall. A project log that only shows a phase marked complete, without the specific steps that were supposed to happen before that mark was made, has nothing to answer that kind of question with. A gap like that can mean a request for more documentation, a delay while it gets assembled, or worse, depending on what's actually missing and how the reviewing agency treats it.

The work itself may have been done correctly, in the right order, by people who know the science. What a regulator needs is different: proof, something specific enough to check against, not a description of how well the work went. A project log that ties specific steps to specific phase closures is what turns "we did this correctly" into something that can be shown, not just stated.

What the project log actually needs to hold

Marking a task complete takes one click. What that click confirms is that something happened, not how it happened, or whether it was the specific step a phase closure actually depended on. The task's title is where that gap starts, "sampling" instead of "confirmation sampling, north excavation boundary, per remedial design section 4," but it doesn't end there. A description that explains what the task actually verified, a comment noting a condition found along the way, a document attached to the step it belongs to, all carry the same weight, and all get skipped just as often.

That gap rarely comes from carelessness. Writing a full sentence about what a task actually confirmed isn't the habit most work moves in anymore, on-site or off. But a phase closure, or a regulator's request for proof, can't run on memory. The person who knew what "sampling" meant that day is the only proof that exists, and that proof leaves when they do, or just fades faster than the project needs it to.

Using that capacity, titles specific enough to mean something later, descriptions that explain what was actually verified, and documents attached where they belong is what separates a task that's done from a phase that's confirmed closed. EVX Software's task and phase tracking is built to hold that distinction, not to replace judgment with automation, but to give the project a record specific enough that closing a phase is a documented decision, not a guess that happened to be right.

See how EVX Software keeps every remediation phase tied to the tasks that actually closed it
Task and phase tracking built for remediation work, not a spreadsheet.
Task management
Environmental consulting
Risk management
Get the next one in your inbox
Practical project-management notes, every week. No fluff.
Thank you! You have been successfully subscribed to the EVX Software Learning Center.
Oops! Something went wrong while submitting the form.