Project Controls, AI & Transformation FAQ

The contractual schedule is the enforceable baseline: it sets the milestones, the deadline obligations and the reference for measuring the delay. The work schedule is the short-term management tool, continuously updated, which reflects the reality on the ground. The two must remain reconcilable: if the discrepancy is no longer explainable line by line, you lose both control and the ability to defend a claim.

Four quick tests: is the logic complete (no orphan activity, no fixed constraint that hides the critical path); are the durations resourced; does the critical path pass through activities that have physical meaning; and is progress measured on objective rules rather than on assessment. A schedule that fails these four tests is a communications document, not a control tool.

It depends on the question asked and the contract. The prospective Time Impact Analysis is the strongest to justify a deadline extension at the time of the event. The window analysis is more suitable in retrospect on a long project. As-planned versus as-built remains the most questionable but sometimes the only possible option if the quality of the updates has been insufficient. The practical rule: choose the method before the drift, not after.

It's not the delay on a milestone. This is the deterioration of data quality: late updates, declarative progress, activities which remain blocked at 90%, risk registers not touched for a month. Schedule drift is a consequence; loss of information discipline is the cause.

A defensible EAC is based on three converging views: performance measured to date (CPI and trend), a bottom-up batch reforecast with scope managers, and the balance of risks and opportunities valued. If these three views diverge by more than a few percent, we do not publish a median figure, we explain the difference and the hypothesis adopted.

Yes, provided you accept that EVM measures execution, not development. On a wind project, the development and permitting phase is poorly served by the EVM because the value is not proportional to the effort. As soon as construction begins, EVM becomes relevant again: civil engineering, roads, foundations, assembly, connection. The right system is mixed: weighted milestones upstream, EVM in execution.

The contingency covers risks identified and quantified within the baseline; it belongs to the project manager and is consumed against a documented event. The management provision covers the unknown and remains in the hands of the sponsor, outside the baseline. Confusing the two produces two classic pathologies: a contingency spent like a budget, and a sponsor with no room for maneuver when a real hazard arises.

The cost incurred, the cost recorded and the disbursement never coincide in time. A serious system produces three distinct curves and explains the discrepancies: contractual commitments, costs incurred in terms of progress, and actual cash-out according to payment deadlines. It is this reading that allows you to have a useful conversation with financial management.

As soon as the event is known and the contract requires it, including if the impact has not yet been quantified. The vast majority of rights lost in FIDIC or NEC contracts are not lost on the merits but on the notification period. Best practice is to notify early, qualify the event, and explicitly reserve quantification for later submission.

FIDIC organizes the relationship around the engineer, the claims and a more adversarial logic of recourse. NEC organizes the relationship around early warning, compensation events and an obligation of active collaboration, with short deadlines and tacit acceptance in the event of silence. Concretely, NEC requires much more daily administration discipline, but resolves issues more quickly.

Four bricks: the contractual basis (which clause opens the right), causality (which event, when, attributable to whom), demonstration of impact (scheduling and costs, with explicit method), and documentary traceability. A claim that presents an amount without the full chain of causation trades down, regardless of its substantive legitimacy.

The asymmetry between the main contract and the supplier contracts. When deadline obligations, penalty regimes and definitions of force majeure are not passed back-to-back, the holder of the main contract alone absorbs a risk that he has sold as distributed. The second most underestimated risk is take-or-pay signed without checking the synchronization of the downstream infrastructure.

To make resource allocation and contingency decisions, not to document compliance. A useful register has few lines, each with a named owner, a dated action, an impact in euros and weeks, and a review date. A 300-line ledger without an owner is a reporting artifact.

No. Quantitative analysis is justified when the decision depends on it: sizing a contingency, commitment to a date, arbitration between two execution strategies. It requires quality planning and reasoned uncertainty distributions. Without this, a Monte Carlo produces a false precision that is more dangerous than an honest qualitative matrix.

Starting from the quantified risk, not a percentage. We model the cost and time exposure, we retain a level of confidence consistent with the sponsor's appetite — typically P50 for the work budget and P80 for the external commitment — and we document the gap. A flat rate percentage is only acceptable at a very early stage, and must be replaced from the baseline.

As a schedule and permit risk before being a technical risk. In a sensitive area, authorized windows, seasonal restrictions, monitoring protocols and exemption conditions dictate the sequencing. Project control must integrate these constraints into the planning logic, otherwise the baseline is wrong from day one.

Because it is the raw material of any contractual defense and any auditable decision. In the event of a claim or arbitration, what is enforceable is not what was experienced but what was transmitted, dated and recorded. A weak document control turns a strong legal position into an indefensible one.

The rate of deliverables issued on the contractual date, the average time for return of customer comments, the number of deliverables under review beyond a threshold, the age of open transmittals and the gap between the register of deliverables and the progress declared in planning. This last gap is one of the best detectors of fictitious progress.

A single source of truth, strict codification applied from the first deliverable, a common data environment with differentiated rights, and an absolute rule: no circulation of deliverables outside transmittal. Discipline is gained in the first six weeks of the project; afterwards, she has difficulty catching up.

The as-built and the end-of-business file are not an administrative formality: they condition the operation, the guarantee and sometimes the payment of the balance. The documentary closure plan must be defined at start-up, with the client's acceptance criteria, and followed as a contractual deliverable in its own right.

Because companies start from the tool instead of from the problem. Before choosing a solution, five questions must be answered: are we solving the right problem; is AI necessary or would process simplification be enough; what decision, what flow, what cost, what risk or what deadline do we improve; do we need automation, prediction, generative, RAG, agents, optimization or something simpler; and is our data reliable enough for the expected decision.

Those where the data is already structured and where the decision is recurring: detection of cost anomalies, prediction of planning drift over history, consistency check between planning, costs and risk register, assisted reading of contractual correspondence, preparation of reporting. On the other hand, AI does not replace sequencing arbitration, negotiation, or commitment to a date.

It’s an AI-generated deliverable that looks finished and square but contains none of the thinking and data needed to move the topic forward. Work from BetterUp Labs and Stanford's Social Media Lab estimates that 41% of employees surveyed received it over a month, with approximately two hours of untangling per case. The real cost is not only financial: 42% of recipients then trust the sender less.

Three rules are enough to get started. Any AI production is a draft to which a named human responds, like a plan that is not transmitted without having checked and signed it. The use cases are approved pending, with a value criterion and a data quality criterion. The metrics tracked are adoption and quality of the deliverable, never the number of licenses or drivers.

The process is structured in three phases of definition before execution. FEL-1 qualifies the opportunity and the business case. FEL-2 compares concepts and selects the reference option. FEL-3 develops the definition, FEED, cost, planning, risks and contractual strategy to the level required for the Final Investment Decision. Each phase ends with a formal gate with deliverables, maturity criteria, responsible parties and an explicit decision: continue, recycle or stop.

By sequencing: first clarify the roles and the RACI on the truly structuring decisions, then install the governance bodies, then only move the reporting lines. The classic mistake is to start with the organizational chart. A matrix without decision-making bodies produces double command and paralysis.

Three to six months to deliver visible value, provided you start with a narrow scope: a reliable baseline, a reduced set of indicators, a regular review ritual. Full maturity takes longer, but a PMO that hasn't produced anything useful after six months will be seen as an administrative cost and lose its mandate.

Two families. System indicators: baseline coverage, data freshness, ritual compliance rate, adoption of tools. Results indicators: reduction in the cost and time gap, accuracy of forecasts, decision time on escalation points. The transformation is successful when the second family moves, not the first.

Through the transfer of skills and responsibility. Operational training rather than awareness, mentoring of project managers, standards documented and appropriate by the teams, and a simple rule: everyone remains responsible for what bears their name, regardless of the tool that produced it.