Awarded obligation
Owner specification, O-PAS basis, accepted clarifications and negotiated technical requirements.
Home › O-PAS Project Change Order and Scope Growth Management
Change Orders · Scope Growth · Supplier Correction · Integration · Commercial Control
O-PAS project change order and scope growth management Decide whether the work changed before deciding who pays
A practical guide for owner, EPC and system-integration teams distinguishing included multi-vendor integration work, supplier correction, normal design development and compensable project change.
The short answer
An O-PAS technical problem is not automatically a change order.
Start with the awarded requirement, bid clarification, responsibility allocation, interface definition, exact supplier commitment, estimate basis, schedule basis and accepted technical baseline. Determine whether the event is included integration work, supplier correction, normal design development, an owner-directed change, a changed requirement, a changed interface or IEC 61131 application scope, a differing documented condition, or additional verification beyond the contract basis. Then assess cost and schedule entitlement separately from the technical need to resolve the issue.
01 · Contract baseline
Reconstruct the awarded position before classifying the event
Change entitlement depends on the difference between the current requirement and the controlled contract basis, not on whether the work is difficult or unexpected.
Responsibility allocation
Owner, EPC, system integrator and supplier boundaries for design, integration, correction and acceptance.
Priced basis
Quantities, assumptions, allowances, exclusions, unit rates and provisional treatment.
Time basis
Supplier information dates, integration cycles, correction windows, FAT/SAT and site milestones.
Accepted baseline
Architecture, products, versions, interfaces, IEC 61131 applications and configuration.
Acceptance basis
Required product evidence, interoperability tests, project acceptance and lifecycle deliverables.
Commercial stop condition: the team is debating entitlement without a common copy of the requirement, clarification, responsibility matrix and technical baseline that were actually awarded.
02 · Event classification
Not every additional hour is additional scope
| Event class | Typical condition | Initial commercial position |
|---|---|---|
| Included integration work | Work required to make awarded products and interfaces satisfy the defined project requirements. | Normally within the party's assigned integration scope. |
| Supplier correction | Offered product, configuration or deliverable fails to meet its committed requirement. | Correction responsibility follows the supplier obligation and contract. |
| Normal design development | Detail matures within the awarded requirement, quantities and responsibility basis. | Normally included unless the contract defines otherwise. |
| Owner-directed change | Owner changes requirement, architecture, quantity, sequence or acceptance basis after award. | Evaluate compensable cost and schedule impact. |
| Changed project condition | Documented baseline condition materially differs from the condition on which the bid was instructed to rely. | Evaluate under applicable contract provisions. |
| Additional verification | New test, witness, environment or acceptance condition beyond the awarded evidence basis. | Evaluate incremental scope unless already included by broader obligation. |
| EPC/integrator error | Rework caused by incorrect design, configuration, coordination or implementation within assigned responsibility. | Normally correction, not owner change. |
Contract terms govern entitlement; this classification is a technical scope-control framework, not a substitute for the applicable contract.
03 · Requirement change
Trace the requirement before pricing the delta
Use requirements traceability to show whether the obligation changed, the interpretation changed or the project simply discovered what the existing obligation requires.
| Question | Evidence |
|---|---|
| What was required at award? | Specification revision, O-PAS applicability basis, clarification and accepted supplier response. |
| What is required now? | Change instruction, revised requirement, design decision or new acceptance criterion. |
| What is the delta? | Changed function, quantity, performance, architecture, evidence or lifecycle obligation. |
| Who owns the affected scope? | Responsibility matrix and contract allocation. |
| What work is invalidated? | Design, procurement, configuration, IEC 61131 applications, interfaces, tests and site work. |
Use the O-PAS Requirements Traceability and Verification Matrix Guide to establish the requirement and evidence delta.
04 · Interface changes
Separate failed integration from a changed boundary
Correction
If the awarded provider and consumer fail to meet the defined interface behavior, resolve under assigned integration and supplier-correction obligations.
Potential change
A newly introduced provider, consumer or interface can create additional definition, configuration and verification scope.
Assess delta
Changed information, commands, state, quality or diagnostics can affect mappings and dependent applications.
Assess implementation
New identity, certificate, access or zone requirements can change both sides of the boundary.
Assess regression
New degraded-operation, restoration or resilience expectations can expand verification.
Check bid basis
Late information is not automatically a change if the bidder already carried responsibility for developing the definition.
The interface register is commercial evidence
Controlled provider, consumer, behavior, responsibility and revision records make it possible to distinguish correction from scope change.
Use the Interface Definition and Boundary Management Guide →05 · IEC 61131 application scope
Classify application change by required outcome
| Event | Scope-control question |
|---|---|
| Defect correction | Does the application fail an awarded functional requirement or accepted design basis? |
| Design development | Is detailed logic being completed within the original functional requirement and quantity basis? |
| Functional change | Has the owner changed sequence, alarm, interlock, control intent or operating behavior? |
| Migration discovery | Was legacy source/behavior condition represented accurately in the bid basis and discovery allowance? |
| Runtime change | Who directed the runtime/product change and what application adaptation or regression does it cause? |
| Additional portability proof | Was the requested redeployment or portability demonstration included in the awarded acceptance basis? |
Use the O-PAS Application Portability Guide to keep source, runtime, migration and functional-equivalence scope explicit.
06 · Supplier correction
Do not convert supplier nonperformance into owner scope growth
When an awarded product or supplier deliverable does not satisfy its committed requirement, preserve the technical evidence and follow the contractual correction path before treating remediation as new project scope.
What was offered?
Exact product/version, capability, interface, evidence and supplier response.
What did not satisfy?
Requirement, expected result, actual behavior and reproducible evidence.
Who must act?
Supplier remediation, integrator coordination, regression and release obligations.
Use the O-PAS Supplier Bid Evaluation and Technical Comparison Guide to preserve awarded supplier commitments.
07 · Verification scope growth
Determine whether the test changed or the system failed the test
| Condition | Typical treatment |
|---|---|
| Failed awarded test | Correction and required regression normally follow existing obligations. |
| Additional scenario | Compare against awarded test basis; evaluate incremental procedure, environment, execution and correction exposure. |
| Changed expected result | Trace whether the underlying requirement changed. |
| Additional witness | Evaluate incremental attendance/schedule impact if not already included. |
| Repeated test after unrelated change | Use impact assessment to determine whether regression is technically required and who owns the triggering change. |
Use the O-PAS FAT and Interoperability Testing Guide for the awarded verification basis and evidence model.
08 · Schedule impact
Separate technical impact from time entitlement
A technical change can affect critical-path activities, but schedule entitlement still depends on responsibility, timing, available float, mitigation and the applicable contract.
Event date
Record instruction, discovery or failure date and when affected work was scheduled.
Affected activities
Identify design, procurement, integration, correction, FAT, site and handover dependencies.
Approved schedule
Compare against the current controlled schedule and milestone basis.
Recovery options
Resequence, parallel work, alternate release or additional resources where technically credible.
Contemporaneous record
Track real effect rather than relying only on forecast impact.
Contract assessment
Apply notice, causation, float and delay provisions under the governing contract.
Use the O-PAS Project Schedule and Integration Milestone Planning Guide to maintain the technical predecessor basis.
09 · Change evidence
Build the record while the event is happening
| Evidence | Purpose |
|---|---|
| Source requirement | Shows the awarded obligation and revision. |
| Clarification / exception | Shows negotiated interpretation, assumption or excluded position. |
| Responsibility matrix | Shows assigned delivery, correction and acceptance accountability. |
| Technical baseline | Shows products, versions, configuration, interfaces and IEC 61131 application state before the event. |
| Change instruction | Shows who directed what and when. |
| Impact assessment | Shows affected requirements, dependencies, engineering, regression and lifecycle work. |
| Schedule record | Shows affected activities, dates, float, mitigation and actual consequence. |
| Cost record | Shows labor, supplier, material, environment, test and site delta. |
10 · Change workflow
Use one path from event to technical and commercial disposition
Record the event
Identify trigger, date, source and immediate technical consequence.
Protect the operating/project position
Take required safe or schedule-protective action without prejudging commercial entitlement.
Establish the baseline
Retrieve requirement, clarification, responsibility, estimate, schedule and technical state.
Classify the event
Included work, correction, design development, owner change, changed condition or additional verification.
Assess technical impact
Trace requirements, interfaces, applications, suppliers, tests, lifecycle assets and regression.
Assess cost and schedule
Quantify incremental work and time consequence separately from technical classification.
Obtain direction
Use the contract's notice, authorization and change mechanism before uncontrolled execution where practicable.
Reconcile the baseline
Update requirements, estimate, schedule, configuration, evidence and contract records after disposition.
11 · Governance
Review technical and commercial positions together
Architecture authority
Confirms requirement, baseline, impact and technically necessary correction or change.
Controls authority
Maintains schedule, estimate, change log, notices and approved baseline.
Contract authority
Determines entitlement and authorized commercial disposition under the governing contract.
12 · Connected guidance
Connect change control to the complete commercial and technical basis
Bid
Bid Clarifications
Preserve assumptions and exceptions that define the awarded basis.
EstimateProject Estimating
Reconcile quantities, allowances and commercial exposure.
ScheduleProject Schedule
Assess impact against controlled technical milestones.
RequirementsTraceability Matrix
Identify the requirement and evidence delta.
TechnicalChange and Regression
Control the resulting system baseline and regression.
ScopeResponsibility Matrix
Establish who owns delivery, correction and acceptance.
Frequently asked questions
O-PAS project change and scope questions
Is a failed O-PAS interface automatically a change order?
No. First determine the awarded interface requirement and responsibility. If the defined provider and consumer fail to satisfy an included interface obligation, the work may be integration or supplier correction rather than changed owner scope.
When can additional O-PAS testing represent scope growth?
When the requested scenario, witness, environment, acceptance criterion or evidence is additional to the awarded verification basis. Repeating a failed included test after correction is different from adding a new contractual test.
How should IEC 61131 application changes be classified?
Compare the requested outcome with the awarded functional requirement, application inventory, migration basis and runtime assumptions. Defect correction and normal design development should be distinguished from owner-directed functional or scope change.
What records are most important for O-PAS change entitlement?
The controlled requirement, clarification/exception register, responsibility matrix, estimate basis, schedule baseline, interface register, application baseline, supplier commitments, change instruction and contemporaneous impact records.
Should technical work stop while commercial responsibility is disputed?
Not necessarily. Safe operation and project protection may require technical action before entitlement is resolved. The team should preserve evidence, follow notice and authorization requirements and avoid conflating urgent technical resolution with final commercial disposition.
How does CSI support O-PAS change management?
CSI helps owners and EPCs reconstruct technical baselines, classify scope events, trace requirements and interfaces, assess regression and schedule impact, distinguish supplier correction from changed scope and document the technical basis for commercial review.
Before every integration problem becomes a commercial dispute
Establish whether the O-PAS scope actually changed
CSI can help owner and EPC teams reconstruct the technical basis, classify change events, trace impacts and create the evidence needed for disciplined project and commercial decisions.
O-PAS™ and Open Process Automation™ are trademarks of The Open Group. CSI is an independent commercial licensee of the O-PAS Standard. This guide is a technical project-control aid, not legal advice, and does not imply endorsement by The Open Group. Contract entitlement is governed by the applicable agreement, amendments, approved clarifications and governing law.