Contract Administration I: RFIs, Change Management and Payment Certification

Contract administration is where a PMC's judgement meets the owner's money. Every RFI answer, every instruction, every variation and every payment certificate either protects the owner's position or quietly erodes it, and the difference is almost always in how well the process is recorded and connected.

In the GCC, the PMC typically acts as the owner's representative or the Engineer named in the contract, or as that party's team, under conditions of contract that the owner has amended. That role carries weight. The PMC answers the contractor's questions, issues instructions, evaluates variations, recommends or determines their value, and prepares the payment certificates the owner pays against. On a Dubai master developer's mixed-use scheme or a Kuwaiti ministry's infrastructure programme, those decisions run into thousands of records over the life of a contract.

The problem is rarely competence; it is connection. The RFI log sits in one spreadsheet, site instructions in another, the variation register in a third, and the payment certificate in a workbook that the quantity surveyor rebuilds every month. When the owner asks a simple question, how did this RFI turn into a variation, how much of our contingency have we used, how much advance payment is still to be recovered, the answer takes days and depends on who is asked.

The CMAA Standards of Practice expect the CM to administer the contract fairly, promptly and transparently, with a record that allows every decision to be traced. Each PMC firm, and each owner, will run these processes in its own way: different thresholds, different approval routes, different forms. PMWEB is configured to those procedures, and the CMAA Standard stays the reference. This article covers the first half of contract administration; Article 8 continues with notices, claims avoidance and closeout.

What the CMAA Standard Expects

Throughout, the CMAA Standard expects the CM to maintain complete records, to act fairly between owner and contractor, and to keep the owner informed of the financial position of the contract, including pending and potential changes, not only those already approved.

How GCC PMC Firms Typically Do It Today

The processes exist on every project. The pain points come from running them in isolation.

• RFIs used as informal variations. RFI responses change the scope without anyone flagging it, and the cost surfaces months later as a claim the owner did not see coming.
• Instructions without a cost trail. Site instructions and field directives are issued by letter or email, and their link to the variation that eventually values them is held in someone's memory.
• Only approved changes are visible. The variation register shows approved change orders, but pending and potential changes, the exposure the owner most needs to see, sit in the quantity surveyor's personal workbook.
• Approval levels checked by hand. Whether a variation needs the project director, the owner's committee or a ministry approval is checked against a PDF of the DoA, and cumulative limits are easy to miss.
• Payment certificates rebuilt monthly. Each interim payment is a new spreadsheet: previous totals are retyped, retention and advance recovery recalculated, VAT added, and errors carried forward.
• No single view of the contract. Original value, approved variations, pending variations, paid to date, retention held and advance outstanding are never shown together in one place.

How PMWEB Digitalises It

PMWEB administers each of these processes as structured records linked to the contract, the budget and the schedule. The chain from question to payment exists as data, not as a story someone has to reconstruct.

RFIs

Each RFI is raised against the contract, discipline, location and the drawing or specification it concerns. The workflow routes it to the PMC reviewer and, where needed, to the designer, with the response period set by the contract and escalation before it lapses. The response is recorded, and a simple but decisive field asks whether the response has a potential cost or time impact. If it does, a potential change order can be created directly from the RFI, carrying its context with it. The owner can then see which clarifications have become changes, and the contractor cannot later argue that a scope change was hidden inside a routine answer.

Site instructions and field directives

Instructions issued by the owner's representative or the Engineer named in the contract, or by the PMC, are recorded as their own records with a number, date, issuer, the clause under which they are issued and the affected work. Where an instruction may change the scope, it is linked to a potential change order, so that it is valued through the variation process rather than resurfacing later as a claim.

• Change order request. Under most conditions of contract this follows either an instruction or a request for proposal. The contractor's proposal, with its valuation, time impact and supporting detail, is submitted and evaluated by the PMC against contract rates, agreed rates or a fair valuation.
• Change order. Once agreed, or determined, the change order is approved through the workflow engine and added to the commitment. The budget, the schedule of values and the forecast update accordingly, and any time impact is linked to the schedule record described in Article 5.

Budget transfers from contingency are recorded alongside, so the owner always knows how much contingency remains and what it has been used for.

Approval under the delegation of authority

The workflow engine routes each change order according to the owner's delegation-of-authority matrix, by value, type and contract. Crucially, it can consider cumulative value as well as the single change, so when the running total of variations on a contract crosses a threshold that requires higher approval, the routing reflects that. Delegation and escalation are handled in the workflow, and every approval is recorded with approver, date and comment.

Cumulative variation tracking

Because potential change orders, change order requests and change orders are all data against the contract, PMWEB reports what the owner needs to know in one view: original contract value, approved variations, pending requests, potential changes, and the resulting forecast final contract value. For owners whose procurement rules limit cumulative variations, this is the view that shows how close a contract is to needing a higher approval or a new procurement route.

Configuring PMWEB to Your Firm's Procedures

The CMAA Standard expects fair, prompt and traceable administration on every contract. How that is done, with which forms, thresholds and routes, is decided by each PMC firm and each owner, and PMWEB is configured to those decisions.

Evidence That the Practice Is Working

A PMC that has digitalised its contract administration in line with the CMAA Standard should be able to show it from PMWEB data. Each firm will set its own targets; the indicators are defined below.

• RFI response time. The elapsed time from RFI submission to response, by discipline, compared with the contractual period.
• RFI-to-change conversion. The proportion of RFIs flagged with cost or time impact that became potential change orders, showing whether design clarity is improving.
• Change cycle time. The elapsed time from potential change order to approved change order, by stage.
• Unpriced exposure. The value and count of potential changes and pending requests not yet resolved on each contract.
• Cumulative variation position. Approved and forecast variations as a proportion of original contract value, tracked against the owner's approval thresholds.
• Payment certificate timeliness. The elapsed time from payment application to issue of the payment certificate, against the contractual period.

Key takeaway

The CMAA Standard asks the CM to administer the contract fairly, promptly and with complete records, and to keep the owner informed of the full financial position, including the changes still coming. That is only possible when RFIs, instructions, variations and payments are connected, not kept in separate logs.

PMWEB turns the chain from question to payment into linked, structured records, routed under the owner's DoA and configured to each firm's procedures, each owner's conditions of contract and each owner's procurement rules. The PMC can then show, in data, that its contract administration executes and evidences what the CMAA Standard expects.

Next in the series: Article 8 — Contract Administration II: Notices, Claims Avoidance and Closeout