The Hidden Cost of Project Change Follow-Up in Construction and Engineering

Project changes rarely arrive in one clean place.

A drawing gets revised. A specification changes. An RFI response clarifies scope. An addendum updates a requirement. A vendor sends a deadline risk by email. A client commitment gets made in a meeting and then buried in a thread.

Each update may look small on its own. The real problem is what has to happen next.

Someone has to notice the change. Someone has to compare it against what the team already knew. Someone has to decide who it affects. Someone has to route it to the right owner. Someone has to confirm the owner reviewed it. Then the team has to know whether pricing, schedule, scope, compliance, or coordination changed because of it.

That is the hidden work behind project change follow-up.

The issue is not just missed information

Construction and engineering teams are not usually short on information.

They have drawings, specs, RFIs, submittals, addenda, meeting notes, emails, portal updates, schedules, vendor updates, and client commitments. The problem is that important changes move through all of those channels at once.

A team may receive the update and still miss the action.

A coordinator may forward the revised file but not know who owns the follow-up. An estimator may see the addendum but not realize a specific drawing changed. A project manager may remember that a client asked for something, but not have it tied to a deadline, owner, or source. A vendor may warn that a delivery date is slipping, but the risk does not reach the person who needs to adjust the plan.

The information exists. The follow-up breaks.

That is why project change review is not only a document management problem. It is an ownership problem.

The hours add up quickly

PlanGrid and FMI estimated that non-optimal construction activities, including fixing mistakes, looking for project data, and managing conflict resolution, accounted for $177.5 billion in U.S. labor costs in 2018. The same research estimated that rework caused by miscommunication and inaccurate or inaccessible information cost the U.S. construction industry more than $31 billion in 2018.[1]

The report also found that construction professionals spend 35% of their time, or more than 14 hours per week, on non-optimal activities such as looking for project information, conflict resolution, and dealing with mistakes and rework.[1]

For a construction or engineering team, that time often shows up as small moments:

• Five minutes checking whether a drawing revision matters.
• Ten minutes searching for the latest response.
• Fifteen minutes confirming whether someone reviewed the change.
• A half hour resolving confusion caused by two people working from different assumptions.
• One missed handoff that leads to rework later.

Individually, these moments feel normal. Across active projects, they become expensive.

RFIs show how costly review loops can become

An RFI is not just a question. It is a review loop. It has to be logged, interpreted, routed, answered, tracked, and sometimes reflected in drawings, specifications, cost, schedule, or field coordination.

Navigant Construction Forum research summarized by the American Society of Concrete Management Association of America and Navigant found that the average RFI takes about 8 hours and costs $1,080 to review and respond to.[3]

That does not mean every RFI is waste. Many are necessary. But it shows how expensive project clarification becomes when review, routing, and response are manual and fragmented.

The same pattern appears outside RFIs:

• A revised drawing needs review.
• A spec change needs review.
• An addendum needs review.
• A vendor update needs review.
• A client commitment needs review.
• A compliance deadline needs review.

The recurring question is the same: did the right person see the right change, understand the impact, and take ownership before it slipped?

Document storage is not enough

Most teams already have shared drives, inboxes, construction management platforms, project folders, spreadsheets, and messaging tools. Those systems are useful. They create places where project information can live.

But storing a document is not the same as closing the loop.

A shared folder can hold the latest drawing. It does not guarantee the estimator reviewed the changed section. An inbox can receive the vendor warning. It does not guarantee the project lead saw the deadline risk. A project platform can contain the RFI response. It does not guarantee the downstream owner understood what changed.

The work is not only finding the document. It is turning the change inside that document into a clear, owned action.

Project changes need a review workflow

A better process starts by treating project changes as follow-up work, not just information.

When something changes, the team needs to know:

• What changed?
• Where did it come from?
• Why might it matter?
• Who owns the review?
• What evidence supports it?
• What action is needed?
• Has the owner acknowledged it?
• Is anything still unresolved?

Not every update needs the same level of response. Some changes are minor. Some affect pricing. Some affect schedule. Some affect compliance. Some affect design coordination. Some only matter if a specific person sees them before a deadline.

The goal is not to create more alerts.

The goal is to turn important changes into review-ready actions with source evidence, ownership, and follow-through.

What better project change follow-up looks like

The answer is not to give project teams another inbox, another dashboard, or another place where updates can sit untouched.

A better workflow turns every important project change into a clear review loop.

Change capture

Project changes should be captured from the places they already appear: drawings, specs, addenda, RFIs, emails, vendor updates, client notes, and internal decisions.

The first step is not asking someone to remember to check another system. It is making sure important changes are noticed when they enter the project environment.

Impact review

A change is only useful if the team understands why it matters.

A revised drawing might affect quantity takeoff. A spec update might affect material pricing. An RFI response might change field coordination. A vendor email might threaten a schedule commitment. A client note might create a promise that needs an owner.

The workflow should help separate routine updates from changes that may affect:

• Scope
• Pricing
• Schedule
• Compliance
• Coordination
• Owner/client commitments
• Vendor or subcontractor risk

Owner routing

Once the impact is clear, the next question is ownership.

Who needs to review it? Who needs to respond? Who needs to adjust pricing, schedule, drawings, documentation, or field coordination?

The right reviewer should receive the change with the source evidence attached, not just a vague note saying “please review.”

Closeout proof

The loop is not closed when someone sees the update. It is closed when the team knows what happened next and can point back to the source.

That means keeping a record of:

• What changed
• Where it came from
• Who reviewed it
• What action was taken
• What is still unresolved
• What evidence supports the decision

That record matters because project teams should not have to reconstruct critical decisions from scattered emails, file names, and meeting notes after the fact.

Where Pertava fits

Pertava is built around this loop: capture the change, review the impact, route the owner, follow up, and preserve source-backed proof.

It catches important changes across project documents, emails, and workflows. It identifies what changed, why it may matter, and who needs to review it. Then it routes follow-up to the right owner with the source evidence attached.

It tracks whether the review was acknowledged or remains unresolved, while keeping proof of what changed, who reviewed it, and what action was taken.

Addenda are one concrete starting point because the pain is deadline-driven and easy to recognize. But the same loop applies across the broader project environment: RFIs, drawing revisions, spec changes, vendor updates, client commitments, compliance deadlines, and internal decisions.

The point is not to replace judgment.

The point is to make review, routing, follow-up, and source-backed proof dependable.