Change Without Cover: Tracing RFIs, PCOs, Change Orders and Claims in PMWEB

Change is where an unbalanced bid pays out, where a design error is quietly passed to the owner, and where a claim-oriented contractor earns its margin. Every one of those outcomes depends on a chain of documents. When the chain is linked in one system, the pattern becomes visible.

Part 3 ended with a contractor that won a piling package with an unbalanced bid, knowing the pile design would change. This article follows what happens next. It draws on my earlier articles on contract administration and on training machines to detect fraud, both of which argued that RFIs, potential change orders, change orders and claims must be linked, not managed as separate logs.

Is this article for you?

Read this if RFIs, variations and claims on your projects travel as correspondence in Aconex, a DMS or a CDE, or if your PMIS manages RFIs but not the PCO, change order and commitment records their answers lead to. If you advise clients on project governance, the adviser's checklist near the end turns this article into diagnostic questions and recommendations. Ministries of finance and sovereign funds will find a funder's lens on this topic near the end.

How Change Becomes a Fraud Channel

• Unsubstantiated change orders. Approved without a clear cause, entitlement or supporting records.
• Over-estimated change orders. Priced at rates or quantities above the contract or market, often on items the contractor priced high at bid.
• Design errors paid twice. The designer's error becomes a contractor change paid by the owner, while the designer's liability is never pursued.
• RFIs used to manufacture variations. Questions raised not to clarify but to create grounds for a change or a claim.
• Claims by strategy. A contractor bids low and recovers margin through a high volume of RFIs, notices and claims, project after project.
• Acceleration paid for self-inflicted delay. The owner pays to recover time that the contractor's own performance lost.

The Change Chain in PMWEB

PMWEB manages change as a connected chain of records, each with its own template, attachments and workflow. The links between them are what make the chain auditable.

RFIs that carry cost

Design errors and omissions are usually discovered by the contractor, who raises an RFI. The designer's response may recommend additional work, which leads to a change order. PMWEB has a built-in link between RFIs and change orders, so every change caused by an RFI response can be traced back to the question, the designer's answer and the date of each. In the piling case, the contractor's RFI reporting the soil investigation and its effect on the pile design should have raised one alert, and the designer's response confirming cost and time impact should have raised a second. Both would also point to the designer's liability.

A checklist on the RFI template helps separate genuine questions from engineered ones: the RFI is a request for information already in the contract documents, it does not instruct a change, it is the only RFI on the subject, and it is not raised to create grounds for a variation. Each item is confirmed by the reviewing engineer.

PCOs that force entitlement to be shown

The PCO process obliges every contract party to submit the details of any event it believes could result in a change, with the documents and records that support its entitlement. The owner then rejects the PCO or approves it, in which case a change order is generated. Because the PCO carries the evidence, nobody can later approve a change order on a verbal assurance that "the contractor is entitled".

Change orders priced from the contract

The change order captures the cost adjustment and the time extension, line by line, against the commitment's schedule of values and cost codes. All supporting documents, links to related records and imported emails are attached, and a workflow with DoA rules governs its approval. Two checks become automatic: whether the rates on the change order match the contract rates for the same items, and whether the change sits on items that were flagged as unbalanced at award.

Claims with cause, effect and counterclaim on one record

Claims are managed with a custom form built in PMWEB. It captures the cause and effect, the contractor's entitlement to time and money, the contract clause relied on (for example a FIDIC clause), whether the work is outside scope, whether there is cost and schedule impact, and the first schedule activity affected. A table records each proposal and counter-proposal: date, description, time extension, adjusted completion date, compensation and status. The counterclaim response is held on the same record.

The owner's claim team may sit in different locations with other duties. The workflow maps who prepares the entitlement assessment, who drafts the response and who approves the final answer, with branches that follow the DoA. Every claim document and linked record is stored in the PMWEB repository, so the claim file is complete when it reaches a dispute board or tribunal.

Correspondence Platforms Hold the Letters, Not the Change

On many projects, RFIs, change requests, variation orders and claim notices are exchanged through a correspondence platform such as Aconex, a document management system or a CDE, as letters and transmittals. The owner can show that every document is filed, numbered and searchable, and concludes that change is under control. For fraud control, that conclusion is false.

• The cost impact is trapped in the attachment. An RFI response that admits a design error, or a variation priced at an inflated rate, is a PDF. No rule can read its amount, its cause or the contract items it affects.
• Links are between documents, not data. A letter can reference an earlier letter. It cannot link a change order's line items to the commitment's schedule of values, so rates above contract rates go unnoticed.
• Design liability disappears. Because the cause of each change is not captured as a value, the owner cannot total how much it has paid for design errors, or pursue the designer for it.
• Claim strategies look like normal correspondence. A contractor raising three times the portfolio rate of RFIs and claim notices simply generates more mail. Without structured data across projects, the pattern is invisible.

Correspondence control is necessary, and PMWEB integrates with Aconex, Autodesk ACC, SharePoint and Egnyte where an owner keeps one. But the change itself, its cause, value, time impact, entitlement and approval, has to be managed as a structured chain of records, or the owner is filing the evidence of fraud without ever detecting it.

No excuse to stay on the wrong platform

If change lives as correspondence in Aconex, a DMS or a CDE, or your PMIS stops at the RFI, the cost of design errors, over-priced changes and claim strategies cannot be measured. Migrating the change chain to a PMIS like PMWEB, integrated with your document platform during transition, turns that correspondence into controllable data.

One project rarely reveals a strategy. The portfolio does. When RFIs, PCOs, claims and bid history for every contract sit in one database, a pattern can emerge: a contractor that always bids lowest, raises far more RFIs per unit of contract value than its peers, issues a stream of claim notices, and ends most of its projects in claims or disputes. Its prequalification submission may even show pending claims with other owners. None of this proves wrongdoing, but it tells the owner how to price risk, what to watch and whether the next invitation is wise.

Change, RFI and Claims Integrity Report — Power BI on the PMWEB database, embedded in PMWEB. Illustrative data.

In the illustrative report, more than a fifth of approved change value is attributed to design errors and omissions, a figure the owner should be recovering from designers rather than absorbing. Contractor A has a change ratio nearly three times the target, the lowest average bid rank, the highest RFI rate and four of four projects ending in claims. Nine change orders above SAR 1 million were approved in under three days, quicker than any genuine review of entitlement and pricing allows.

Where PMWEB 2026 AI Helps Separate Logs, Correspondence Platforms and a Linked Change Chain

The funder's lens — ministries of finance and sovereign funds

• Change is where approved budgets quietly grow. Funders should see change ratio, design-error changes and changes approved in days, by entity and contractor.
• Design-error costs recovered from designers are capital returned to the funder; ask whether the entity tracks them at all.

Adviser's checklist — for consultants recommending project governance

Questions to ask in the diagnostic

• Can the client trace each change order to its cause and its originating RFI?
• Is change priced against the contract schedule of values, or negotiated in correspondence?
• Does the client know how much it has paid for design errors, and has it pursued designers for it?

Recommendations to put in the governance report

• Manage RFIs, change events, PCOs, change orders and claims as one linked chain of records.
• Capture change cause as data and report design-error changes for recovery.
• Profile contractor RFI, claim and change behaviour across the portfolio before each new invitation.

Evidence That Change Controls Are Working

• Traceability. Every change order linked to its cause: a change event, PCO, RFI or owner instruction.
• Contract-rate pricing. Change line items priced at schedule of values rates unless a variance is approved and explained.
• Design recovery. Design-error change value with a corresponding notice or back-charge to the designer.
• Review time. High-value change orders no longer approved faster than a genuine review allows.
• Change ratio. Approved changes within tolerance by contract, contractor and programme.

A change order is the end of a story that starts with an RFI, a change event or a bid. When PMWEB links every record in that story, an over-priced change, a design error passed to the owner or a claim strategy is no longer hidden in separate logs.

Filing every letter in a correspondence platform is not the same as controlling change; the cause, value and rate must be data.

The owner sees the whole chain, and so does anyone who reviews it later.

Migrating the change chain to PMWEB turns correspondence into controllable data.

Next in the series: Part 5 turns to payments: how PMWEB progress invoice data exposes abuse of approval power through delayed approvals, unjustified cuts and selective payment release.