Owner requirement
Identify applicable O-PAS requirements and profiles and record ambiguous conformance, interoperability or portability language as clarification items.
Home › O-PAS Project Estimating Guide
Use the O-PAS Project Change Order and Scope Growth Management Guide →
EPC Estimating · Proposal Strategy · Scope Basis · Commercial Risk
How to estimate an O-PAS project Price defined scope, not undefined integration risk
A practical estimating framework for EPC proposal, controls and project teams responding to an owner requirement for O-PAS™. Define the architecture, quantities, interfaces, responsibilities, schedule and verification basis first; then price the work and apply contingency to the unknowns that remain.
The estimating rule
Estimate an O-PAS project in two passes.
Pass one establishes the scope basis: target architecture, applicable requirements, component and supplier boundaries, quantity basis, interface inventory, IEC 61131 application strategy, verification scope, responsibility allocation, schedule basis and handover deliverables. Pass two prices that work breakdown and applies contingency only to identified residual risks. Multi-vendor integration work remains real whether or not the bid names it.
01 · Scope basis
What must be known before an O-PAS estimate is credible?
The estimate does not need every design decision. It does need a defensible position on the decisions that control scope.
Target architecture
Define functional components, deployment boundaries, retained systems, engineering environment and system-management approach.
Supplier boundaries
State who provides each component and where technical and commercial responsibility begins and ends.
Integration authority
Name the party accountable for the integrated system. Unassigned accountability is unpriced scope.
IEC 61131 basis
Separate new applications from reuse, conversion, redevelopment and functional-replication migration work.
Verification basis
Separate product conformance evidence, system interoperability testing and project acceptance.
Bid gate: if the team cannot describe the architecture, interfaces, application basis, integration responsibility, verification basis and lifecycle handover, issue clarifications and qualified assumptions before pricing.
02 · Estimate maturity
Use the O-PAS Bid Clarifications and Technical Exceptions Guide →
Match estimate precision to decision maturity
Do not present a definitive number from a conceptual architecture. State the estimate class, information available and unresolved decisions that control accuracy.
| Estimate stage | Minimum O-PAS basis | Appropriate treatment |
|---|---|---|
| ROM / screening | Program objective, preliminary architecture, major retained systems, supplier strategy and broad application basis. | Ranges, parametric quantities and explicit maturity assumptions. |
| Budget / authorization | Architecture revision, component roles, preliminary supplier list, interface classes, application quantities, integration environment and verification concept. | Work-package quantities, supplier budget quotes and named allowances. |
| Bid / control estimate | Contract requirements, responsibility matrix, counted interfaces, application basis, supplier quotations, test cycles, schedule and handover scope. | Defined quantities, productivity, commercial exposure and residual contingency. |
| Post-award baseline | Accepted architecture, awarded suppliers, interface register, application inventory, execution schedule and verification plan. | Reconcile bid assumptions into control accounts and change baselines. |
03 · Quantity basis
Count the objects that actually drive O-PAS engineering effort
Use quantities that map to engineering, coordination, test and lifecycle work rather than a blanket percentage uplift.
| Quantity | Examples | Why it matters |
|---|---|---|
| Components by architecture role | Products, runtime environments, engineering and system-management assets. | Drives configuration, procurement, lifecycle and verification scope. |
| Suppliers | Component, application, infrastructure and specialist suppliers. | Drives coordination, releases, technical queries and correction ownership. |
| Interfaces by class | Established, configured, first-of-kind and legacy boundaries. | Drives definition, mapping, integration, correction and test effort. |
| IEC 61131 applications | New modules, migrated applications, libraries, units and sequences. | Drives design, build, deployment, migration and functional verification. |
| Integration releases | Planned component, application and configuration baselines. | Drives environment resets, regression and supplier coordination. |
| Test scenarios | Boundary, failure, recovery, replacement, resilience and performance tests. | Drives procedure development, execution, evidence and correction cycles. |
| Site phases | Installations, cutovers, operating windows and stabilization periods. | Drives mobilization, shifts, supplier attendance and commissioning effort. |
| Lifecycle artifacts | Source, configurations, interface records, certificates, procedures and support records. | Drives handover completeness and owner acceptance. |
04 · Estimate Basis Memorandum
Make the assumptions behind the number reviewable
The Estimate Basis Memorandum should travel with the estimate and identify the dated technical and commercial position from which the number was built.
Design basis
Architecture revision, O-PAS edition/profile basis, component roles, retained systems and major boundaries.
Responsibility basis
Owner, EPC, integrator and supplier allocation; quotations; inclusions; exclusions and allowances.
Delivery basis
Interface inventory, IEC 61131 application quantities, environment, test cycles, schedule, site phases and handover.
Use the O-PAS Responsibility Matrix to make the commercial allocation explicit.
05 · Work breakdown
The O-PAS estimating work breakdown structure
Use these categories as estimate control accounts or as a completeness check against the EPC controls-system WBS.
| Work package | Scope to estimate | Primary drivers |
|---|---|---|
| Requirements and architecture | Specification review, applicability, target architecture, functional allocation and boundaries. | Requirements, subsystems, suppliers, phases. |
| Component procurement | Hardware, software, licensing, support, spares, engineering systems and supplier services. | Products, environments, licenses, support periods. |
| Interface engineering | Definition, information mapping, configuration, integration and issue resolution. | Interface count, class, maturity and complexity. |
| Control applications | New IEC 61131 logic, migrated logic, libraries, deployment and equivalence testing. | Modules, loops, sequences, units, legacy applications. |
| System management | Inventory, configuration, deployment, monitoring, backup, restore and lifecycle procedures. | Component types, releases, environments and roles. |
| Cybersecurity | Architecture, hardening, identity, certificates, access, logging and verification. | Zones, identities, interfaces and owner requirements. |
| Integration environment | Representative system, hosting, setup, supplier access, test data and reset capability. | Components, duration, releases and test cycles. |
| Verification and FAT | Conformance review, interoperability, functional, failure, recovery, replacement and resilience scenarios. | Requirements, scenarios, configurations and witnesses. |
| Site execution | SAT, commissioning, cutover, startup, correction and stabilization. | Sites, phases, shifts, suppliers and duration. |
| Project controls | Supplier coordination, schedule integration, queries, change, risk and documentation. | Suppliers, milestones, changes and duration. |
| Training and handover | Training, source/configuration turnover, evidence, licenses and support model. | Roles, trainees, artifacts and support period. |
For environment scope and correction-cycle planning, use the O-PAS Integration Environment and Testbed Planning Guide.
06 · Interface estimating
Estimate interfaces as engineering objects, not line items
| Class | Typical condition | Estimating treatment |
|---|---|---|
| A — Established | Previously integrated products, stable definition, known owner and repeatable test. | Demonstrated productivity plus project-specific allowance. |
| B — Configured | Known technologies with new information mapping, security configuration or use case. | Design, configuration, test development and one controlled correction cycle. |
| C — First-of-kind | New supplier combination, immature definition, uncertain behavior or shared ownership. | Prototype or early integration, supplier support, additional test cycles and schedule risk. |
| D — Legacy gateway | Connection to proprietary or poorly documented retained systems. | Discovery, mapping, gateway engineering, performance test and site validation. |
Every interface needs a commercial owner
Assign one technical definition, one accountable owner, one acceptance method and a correction basis. “By others” is not a strategy unless the other party accepts the same boundary.
Use the Interface Definition and Boundary Management Guide →07 · Supplier quotation normalization
Compare scope before comparing price
Two supplier quotations can look comparable while carrying different amounts of integration, licensing, tooling, test support, correction and lifecycle work.
| Normalize | Check in every quotation |
|---|---|
| Product basis | Exact product, version, quantity, applicable evidence, dependencies and options. |
| Engineering | Configuration, application support, interface definition, information mapping and documentation. |
| Tools and licenses | Engineering tools, runtime licenses, development licenses, renewals and transfer rights. |
| Integration support | Remote/on-site hours, environment support, diagnostic participation and supplier coordination. |
| Testing | Procedure support, witnesses, correction cycles, retest, travel and laboratory costs. |
| Lifecycle | Support term, updates, obsolescence notice, replacement path, spares and training. |
| Exclusions | Third-party dependencies, project integration, remediation, site attendance and additional cycles. |
Use the O-PAS Procurement Specification Checklist to require comparable bidder information before quotations arrive.
08 · Schedule-loaded estimating
Use the O-PAS Project Schedule and Integration Milestone Planning Guide →
Price the time required to integrate, correct and retest
O-PAS estimating is schedule-sensitive because supplier releases, integration environment availability, correction loops and acceptance gates create real labor and commercial exposure.
Integration duration
Setup, commissioning, staged integration, resets, maintenance and supplier access.
Supplier dependencies
Required product, configuration and application releases and their decision dates.
Retest loops
Planned formal correction cycles, response times and regression scope.
FAT entry
Criteria that must be met before formal acceptance consumes witness time.
Operating windows
Cutovers, shifts, supplier attendance, rollback coverage and stabilization.
Schedule risk
Price named schedule exposure rather than assuming all suppliers move together.
09 · Verification
Keep conformance, interoperability and project acceptance separate
Conformance evidence
Review evidence for the exact product, version and applicable O-PAS scope. Product evidence does not prove the assembled project.
Interoperability testing
Price environment, scenarios, data, witnesses, correction and retest for selected products operating together.
Acceptance
Price FAT, SAT, performance, failure, recovery, resilience and lifecycle demonstrations required by the contract.
Use the O-PAS FAT and Interoperability Testing Guide for the detailed evidence and correction model.
10 · Commercial exposure
Choose the commercial treatment item by item
Undefined work should not disappear inside a percentage. Assign each uncertain item an explicit commercial mechanism.
| Treatment | Use when | Control |
|---|---|---|
| Fixed price | Scope, quantity, responsibility and acceptance basis are sufficiently defined. | Carry normal productivity risk inside the work package. |
| Allowance | Work is known but quantity or duration remains bounded. | State quantity basis and reconciliation rule. |
| Unit rate | Repeatable work exists but final quantities will mature. | Define unit, productivity inclusions and measurement method. |
| Provisional sum | Required work is foreseeable but cannot yet be scoped credibly. | Name approval and drawdown mechanism. |
| Owner dependency | Price or schedule depends on owner information, infrastructure or decisions. | State required date and consequence of delay. |
| Explicit exclusion | The EPC is not carrying the work. | Define the boundary and mechanism for later inclusion. |
11 · Risk pricing
Apply contingency to named residual risks
For each unresolved item, record cause, cost consequence, schedule consequence, probability, mitigation owner, decision date and estimate account. Price residual exposure after mitigation. Keep management reserve separate from contingency for known uncertainty.
| Risk example | Mitigation before bid | Residual treatment |
|---|---|---|
| Supplier combination not previously integrated. | Compatibility workshop or prototype. | Additional integration and retest cycles tied to the interface package. |
| Integration authority unassigned. | Clarification and responsibility matrix. | Qualify the estimate; do not bury accountability in contingency. |
| Legacy application inventory incomplete. | Sample discovery and complexity classification. | Quantity ranges and unit rates with reconciliation. |
| Acceptance scenarios undefined. | Submit proposed verification basis. | Price stated scenarios; treat additions through change. |
12 · Estimate reconciliation
Convert bid assumptions into the post-award control baseline
After award, reconcile every material estimating assumption as architecture, suppliers, interfaces and application quantities mature. This prevents the bid basis from disappearing while execution scope changes underneath it.
Revision change
Compare the awarded architecture with the estimate-basis revision and identify scope movement.
Count and class
Reconcile preliminary interface quantities against the controlled interface register.
Inventory maturity
Reconcile IEC 61131 application counts, migration classes and complexity.
Awarded scope
Normalize final supplier scope against quotation assumptions and exclusions.
Verification maturity
Reconcile scenario counts, witnesses, correction cycles and site demonstrations.
Change baseline
Move differences into approved estimate transfers, allowances or formal change control.
13 · Bid gate
O-PAS estimate review checklist
| Requirements | Specific O-PAS requirements and ambiguous terms identified? |
| Architecture | Estimating-level target architecture documented? |
| Responsibility | Every integration and verification activity assigned? |
| Quantities | Components, suppliers, interfaces, applications, releases, tests and site phases counted? |
| Environment | Integration environment owner, location and duration included? |
| Testing | Product conformance review, interoperability and project acceptance separated? |
| Corrections | Defined correction and retest cycles included? |
| Schedule | Supplier dependencies, FAT gates and site windows loaded? |
| Handover | Lifecycle artifacts and source deliverables listed? |
| Risk | Contingency tied to named residual risks? |
Final question: if two products with applicable conformance evidence fail to operate together during FAT, does the contract say who resolves the problem, who pays and what test closes it? If not, the estimate is not finished.
Primary reference basis
Use current O-PAS program documents and certification records
The applicable edition of the O-PAS Standard and The Open Group certification-program documents provide the authority basis for O-PAS terminology, requirements, profiles and product-conformance claims. Project architecture, integration, interoperability, applications, acceptance and lifecycle obligations still require project-specific engineering and verification.
Confirm the reference basis current for the project or procurement date rather than relying on an undated summary or general statement of O-PAS compatibility.
Frequently asked questions
O-PAS project estimating questions
How do you estimate an O-PAS project?
Use two passes. First establish requirements, architecture, suppliers, quantities, interfaces, IEC 61131 application strategy, responsibilities, schedule, verification and handover. Then price the defined work breakdown and apply contingency only to identified residual risks.
Does an O-PAS project require a percentage uplift over a DCS estimate?
There is no defensible universal percentage. The difference depends on architecture, supplier maturity, interface count, legacy conditions, application migration, test requirements and responsibility allocation. Build the estimate from quantities and named work packages.
What is the largest estimating risk in an O-PAS project?
Unassigned integration responsibility is a major exposure because work that was previously internal to one supplier can move into project architecture and system integration. The contract should explicitly assign architecture authority, interface ownership, correction and system acceptance.
Does O-PAS product conformance eliminate interoperability testing?
No. Product conformance evidence addresses the evaluated product scope. System interoperability testing demonstrates that selected products work together in the project architecture, and project acceptance establishes that the delivered system satisfies the contract.
What should an EPC include in O-PAS FAT scope?
Include conventional controls testing plus the project-specific interface, deployment, configuration, failure, recovery, replacement, resilience, cybersecurity and application scenarios required by the acceptance basis, together with planned correction and retest cycles.
What belongs in an O-PAS Estimate Basis Memorandum?
Record the architecture revision, applicable O-PAS basis, supplier and responsibility assumptions, quantity basis, interface inventory, IEC 61131 application basis, integration environment, verification scope, schedule, quotations, exclusions, allowances and dated residual risks.
How should supplier quotations be compared?
Normalize exact products and versions, engineering scope, tools and licenses, integration support, test attendance, correction cycles, lifecycle support and exclusions before comparing price.
When should an EPC bring in an O-PAS specialist?
Before the bid basis is frozen, while architecture, supplier boundaries, verification requirements and commercial assumptions can still inform the estimate rather than become post-award changes.
Before the bid basis is frozen
Turn the O-PAS requirement into an estimable scope
CSI works with EPC proposal, estimating and controls teams to review owner requirements, define responsibility boundaries, establish quantities, normalize supplier scope, define verification and document the assumptions behind the estimate.
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 an estimating and project-planning aid and does not imply endorsement by The Open Group. The applicable contract, owner specification, current O-PAS Standard, supplier quotations and current certification records govern the project.