From Particular Conditions to Platform: Configuring the Bank-Funded Contract in PMWEB

The General Conditions tell you how FIDIC works. The Particular Conditions tell you how your contract works, and on a Bank-financed project that is where the obligations that matter to the Bank are written. If those provisions live only in a PDF, every member of a rotating PIU has to remember them. Configured in PMWEB, they are enforced for everyone, on every record, from the first day.

Every FIDIC project team knows the General Conditions by clause number. Far fewer can say, without opening the contract, what their own Particular Conditions changed. This article explains how to configure a Bank-financed contract in PMWEB so that the Particular Conditions are applied by the system, not by memory. Every later article in this series depends on this step.

First question: which contract is actually in force?

Before configuring anything, the PIU has to establish precisely which form governs each contract. On development-financed programmes, three generations often run side by side:

• FIDIC 2017 General Conditions with the Bank’s Particular Conditions. Newer World Bank-financed works use the 2017 General Conditions, with Particular Conditions organised as Part A Contract Data, Part B Specific Provisions, Part C the Bank’s policy on corrupt and fraudulent practices, and Part D the environmental and social reporting metrics for progress reports.
• The FIDIC MDB Harmonised Edition (the Pink Book). First published in May 2005, amended in March 2006 and reissued in June 2010, based on the 1999 Red Book. Many contracts financed by participating banks still run on it.
• The 1999 Red Book with bank-specific Particular Conditions. Still found on older loans and with some lenders.

The differences are not cosmetic. The Pink Book makes Contract Data Part A of the Particular Conditions and gives the Bank the right to inspect and audit the Contractor’s accounts and records (Sub-Clause 1.15). It requires the Employer to evidence its financial arrangements before the Commencement Date (2.4) and to notify its claims within 28 days (2.5). It fixes profit at 5% unless stated otherwise, and it adds Contractor termination grounds such as suspension of the loan or credit (16.2). The 2017 edition restructures claims, notices and the Engineer’s determination entirely. A system configured for the wrong edition will calculate the wrong deadlines with complete confidence.

PMWEB records the form of contract, edition and governing Particular Conditions as fields on the contract record. That classification decides which workflows, form templates and deadline rules apply, so a programme can run Pink Book and 2017 contracts side by side without one team applying the other’s rules.

Contract Data as master data

Part A Contract Data is, in effect, a configuration file written in prose. It holds the values every other process depends on: the Commencement Date mechanism, Time for Completion of the Works and each Section, the Defects Notification Period, the amount and form of the Performance Security, the advance payment percentage and repayment terms, retention percentages and limits, the currencies and proportions of payment, delay damages and their cap, the percentage above which a Variation needs Employer approval, and the DAAB arrangements.

In PMWEB these values become structured fields on the commitment (contract) record and its related records, not text in an attachment:

Once Contract Data is master data, nobody has to remember it. The system does.

Specific Provisions as rules and approval paths

Part B Specific Provisions, like the bank-driven amendments in the Pink Book, are less about values than about behaviour: who must approve what, within what time, with what evidence. These become rules in the PMWEB workflow engine.

The most important example is the Engineer’s authority. Under the Pink Book, Sub-Clause 3.1 requires the Engineer to obtain the Employer’s specific approval before certain actions. These include agreeing or determining time or cost for unforeseeable physical conditions, instructing a Variation that would increase the Accepted Contract Amount above the percentage in the Contract Data, and approving a Contractor’s variation proposal. Under the 2017 edition, Sub-Clause 3.2 requires the Engineer to obtain the Employer’s consent wherever the Particular Conditions say so. Either way, the contract itself imposes a Delegation of Authority (DoA).

In PMWEB that DoA is configured as approval levels with conditional routing. A Change Order below the threshold flows from the Engineer to issue. Above it, the workflow inserts the Employer’s approval step automatically and, where the Bank’s prior review applies, a Bank no-objection step as well. The step cannot be skipped, the approver and timestamp are recorded, and the Bank’s response is attached to the record. When the Employer changes the Engineer’s authority, which the Pink Book requires it to notify promptly to the Contractor, the DoA is updated once and applies to every new record.

The contract baseline register

Responsibilities, calendars and languages

Three further configuration decisions determine whether the system works for the people who must use it.

• A Responsibility Assignment Matrix (RAM). In our book Digitalization of Construction Contract Administration Under FIDIC Contracts, each contract administration function is assigned through a RAM: who prepares, who reviews, who approves and who is informed. On a Bank-financed project, the matrix must also show the Employer’s approval steps and the Bank’s role. In PMWEB the RAM becomes the role structure behind every workflow, so a new PIU member inherits the correct responsibilities on day one.
• Workdays for tasks, calendar days for the contract. FIDIC periods run in calendar days unless the Particular Conditions say otherwise, and PMWEB calculates contractual deadlines on that basis. Internal workflow tasks, such as the PIU engineer’s review, the legal check and the director’s approval, are better managed in workdays, respecting the working week and public holidays. Separating the two allocates internal review time realistically while protecting the contractual date.
• Bilingual outputs. Many borrower countries administer contracts in a national language while the Bank works in English. PMWEB output forms can be designed in both languages from the same record, an approach we describe in the book as Arabizing the contract administration functions. The letter to the Contractor, the report to the ministry and the submission to the Bank all come from one source rather than three translations.

The Contract Configuration & DoA Compliance dashboard

The dashboard below is built in PMWEB’s embedded Power BI reporting for the sample programme P-2100, with values in USD millions. It shows whether each contract is configured correctly and whether the DoA the contracts impose is being respected.

• Three forms, one programme, eight configured contracts. Six contracts run on the 2017 Red and Yellow Books with Bank A’s Particular Conditions Parts A to D; two run on the Pink Book 2010 with Bank B’s Contract Data. Each applies its own Employer approval threshold: 5% on the 2017 contracts and 10% on the Pink Book contracts.
• Contract Data is 97% complete, and the gap is visible. C2105 Ring Road South is at 88%, so two of its deadline rules still rely on manual checks. The dashboard names the gap before an auditor does.
• 1,146 approvals in twelve months, none outside the DoA. 812 closed at Engineer level and 296 at PIU Director level. 38 reached Employer approval under Pink Book 3.1 or 2017 Sub-Clause 3.2, and 18 of those also needed the Bank’s no-objection.
• The DoA works without slowing the project. The average approval cycle is 6.4 workdays against a target of 7. Engineer reviews take 3.1 workdays (target 5) and PIU reviews 2.4 (target 3).
• The Bank’s no-objection is the longest step. It averages 11.5 workdays against a 14-day target. Three of the 18 requests made in the last four quarters are still pending, so the PIU plans the Bank’s turnaround into every Variation timetable.
• Employer approvals are steady quarter by quarter. Between 8 and 11 a quarter, with no-objection requests peaking at 6 in Q2-26. That is the pattern of a programme whose change is controlled, not absorbed.

PMWEB 2026 AI on contract configuration

Action is taken only with the user’s approval, and PMWEB AI honours security settings, so contract configuration data is visible only to the roles permitted to see it.

What the PIU must put in place

• A form-in-force register. Edition, Particular Conditions and financing source recorded on every contract before the first notice.
• Contract Data as structured fields. Dates, money, securities and thresholds entered once, checked against the signed contract, and never retyped.
• The imposed DoA, configured. Engineer limits, Employer approvals and Bank no-objection steps as conditional workflow routing.
• A RAM behind every workflow. Preparer, reviewer, approver and informed parties defined for each function, including the Bank.
• Two calendars. Calendar days for contractual periods and workdays for internal review tasks.
• Bilingual output templates. One record producing correspondence in the national language and English.
• One configuration for the whole loan. Built at programme level and applied to every contract, then reused on the next loan.

Over to you: on your Bank-financed contracts, how long does it take a new PIU engineer to learn what the Particular Conditions changed, and where do they find out?

The series: Article 1, Funding Comes with Conditions; Article 2, From Particular Conditions to Platform; Article 3, The First 90 Days; Article 4, ESHS as Evidence; Article 5, People on Site; Article 6, Integrity by Design; Article 7, Change under Scrutiny; Article 8, Paying through the Loan; Article 9, Reporting to the Bank; Article 10, Closing the Contract, Closing the Loan.