How to define the contracting architecture of an engineering project through package strategy, contract model selection, interfaces, responsibilities, and risk allocation.
Check it out!
An engineering contracting strategy defines the project’s contractual architecture: how scope will be divided into packages, which contract models will be applied, how interfaces and responsibilities will be distributed, which risks belong to each party, and which decisions need to occur before going to market. It uses the market analysis produced by Strategic Sourcing and precedes the procurement plan, but it is not the same as either: sourcing addresses the market and suppliers; the plan operationalizes schedules, accountable parties, and Procurement milestones.
In complex projects, the strategy is not limited to deciding whether to “buy” or “contract.” It connects engineering maturity, the owner’s internal capability, market structure, interfaces between disciplines, schedule, long-lead items, operating constraints, delivery model, selection criteria, and contract governance. The expected result is a defensible contracting logic in which each package has a purpose, boundaries, accountable parties, risks, and criteria for progressing to the next phase.
A robust strategy reduces excessive fragmentation, gaps between contracts, overlapping responsibilities, inappropriate concentration of risk, and tenders launched before the scope is sufficiently mature. It also makes it possible to decide when to use an RFI, RFP, or RFQ and when contracting requires prequalification, TBE, technical negotiation, or additional control mechanisms.
What a Contracting Strategy Needs to Decide
A contracting strategy is not a shopping list. It defines the project’s architecture of responsibilities: how packages, market conditions, interfaces, risks, and selection criteria will be combined before any RFP or RFQ is issued.
The contracting strategy starts with the relationship between what the project needs to deliver and how the market will be mobilized to produce that result. The World Bank treats this phase as part of the Project Procurement Strategy for Development (PPSD): before inviting bids, the buyer should analyze the market, operating environment, and project risks to select a Procurement approach suited to the objective and expected value.
In engineering, the strategy needs to answer at least five groups of decisions:
- scope structure: what will be contracted and which deliverables make up each package;
- delivery model: separate contracting, design-build, EPC, EPCM, turnkey, discipline-based contracts, or other combinations;
- market: how many suppliers exist, how they are structured, which capabilities are scarce, and where manufacturer dependency exists;
- risks and interfaces: who controls each risk and which party is best positioned to manage it;
- selection process: RFI, RFP, RFQ, prequalification, shortlist, mandatory criteria, scored criteria, and negotiation.
Contracting Strategy Is Not a Procurement Plan
The two documents are related, but they have different responsibilities. The strategy defines why and how the project will contract; the procurement plan turns that logic into who, when, in which package, and through which process.
| Dimension | Contracting strategy | Procurement plan |
| central question | how should contracting be structured? | how should procurement be executed and controlled? |
| horizon | structural project decisions | operational Procurement planning |
| focus | packages, models, market, risks, criteria | dates, accountable parties, milestones, status, and deliverables |
| result | contracting architecture | Procurement execution baseline |
| update | at gates and upon relevant changes | continuously throughout the project |
This distinction prevents a schedule spreadsheet from being called a “strategy” when the structural decisions have not yet been resolved.
Engineering Maturity Conditions the Strategy
The lower the technical maturity of the scope, the greater the risk of trying to contract a solution whose extent is not yet known. Conceptual Design, FEED, Basic Design, specifications, Basis of Design, equipment lists, and functional requirements progressively improve the ability to create comparable packages.
This does not mean every procurement must wait for Detailed Design. The model needs to be compatible with the available maturity. An RFP may allow differentiated solutions when the problem and performance requirements are clear, while an RFQ assumes a more standardized and sufficiently stable scope for price to have comparable meaning.
When Engineering cannot yet establish even boundaries, interfaces, and acceptance criteria, the priority should be to mature the scope or consult the market through an RFI rather than prematurely launch a formal tender.
Make-or-Buy and the Owner’s Internal Capability
One of the decisions that precedes Procurement is determining which activities should remain under the owner’s direct responsibility and which should be acquired externally. PMBOK treats this as make-or-buy analysis and recommends considering resources, competencies, the need for independent specialization, and risks.
In engineering projects, this decision also involves governance. An owner may outsource design, implementation, supervision, or management, but still needs to retain the capability to define requirements, make decisions, accept deliverables, and manage risks that have not been contractually transferred.
Fully outsourcing technical capability can create dependency on the same supplier that will be evaluated. Therefore, Owner’s Engineering, Engineering Consulting, or an independent Technical Authority may be needed to preserve the contracting party’s decision-making capability.
How to Define the Package Strategy
Dividing the project into packages is one of the most sensitive decisions. Larger packages reduce direct contractual interfaces, but concentrate responsibility and may reduce competition. Smaller packages increase specialization and competition, but transfer a greater integration burden to the owner.
The decision should consider:
- technical and physical interfaces;
- construction sequence;
- uneven maturity among disciplines;
- market concentration;
- the owner’s coordination capability;
- long-lead items;
- integration risks;
- standardization opportunities;
- availability of suppliers capable of assuming integrated scopes.
EPC, EPCM, Design-Build, and Separate Contracting
There is no universally superior model. The delivery model should reflect risks, maturity, management capability, and the project’s objectives.
EPC or turnkey
It is appropriate when the owner seeks greater concentration of responsibility for Engineering, Procurement, and construction and can define performance requirements and boundaries with sufficient clarity. Contractual transfer does not eliminate risk: incomplete scope, late changes, and ambiguous requirements may reappear as contingency pricing, claims, or change orders.
EPCM
It preserves greater owner participation in contracting and allows integrated management by a specialized agent. It requires governance, timely decisions, and the capability to manage multiple contracts and interfaces.
Design-build
It integrates design and execution and can reduce interfaces between designer and contractor. It requires functional requirements and performance criteria capable of guiding the solution without depending on complete owner-developed detailing.
Separate contracting
Design, supply, installation, and integration may be contracted as separate packages. This increases control and specialization, but makes interface coordination a critical responsibility of the contracting party.
Market Analysis Before Choosing the Model
A contracting strategy designed only internally may fail when it encounters a market different from what was assumed. The World Bank’s PPSD recommends structured market and supply-chain analysis to determine a fit-for-purpose approach.
The team should understand:
- the number and size of capable suppliers;
- market concentration or manufacturer dependency;
- barriers to entry;
- production capacity;
- location and logistics;
- the market’s appetite for the proposed risk allocation;
- usual contractual practices;
- availability of specialized personnel;
- warranty and support conditions;
- price and lead-time trends.
An RFI can be used to test these assumptions before the strategy is frozen.
Risk Allocation: Transfer Is Not Elimination
Contracts often attempt to shift as much risk as possible to the supplier. This practice can produce higher prices, reduced competition, or risks that, although written into the contract, remain materially under the owner’s control.
Allocation should consider which party is best positioned to prevent, control, absorb, or insure the risk. Examples include:
| Risk | Party with the greatest potential influence | Strategic treatment |
| incomplete field data | owner/Engineering | survey and due diligence before tendering |
| equipment performance | supplier | functional specification, warranties, and testing |
| integration between contracts | owner/EPCM/OE | interface matrix and cross-functional governance |
| manufacturing and delivery | supplier | milestones, expediting, and inspections |
| requirement change | owner | change control and formal baseline |
| hidden brownfield condition | shared | surveys, contingencies, and discovery rules |
Contractual transfer without real control capability is not mitigation.
Selection Strategy: When to Use RFI, RFP, and RFQ
The strategy should define the instrument that fits the scope. An RFI is useful for reducing market uncertainty; an RFP is more appropriate when solutions may vary and technical quality needs to be evaluated; an RFQ works best for standardized and sufficiently defined scopes.
This decision affects schedule, market effort, the need for technical criteria, and the evaluation method. For complex scopes, issuing an RFQ too early can produce prices that appear comparable but actually reflect different scopes.
The content on RFI vs. RFP vs. RFQ explores this boundary in greater depth, while the article on TBE in Engineering addresses the formal technical evaluation process after proposals are received.
Prequalification and Shortlisting
When the supplier universe is large or the scope requires specific capabilities, the strategy may include prequalification. The objective is to verify organizational capability before requesting detailed proposals.
Supplier qualification should be proportional to risk and based on evidence of experience, technical capability, organization, quality, supply chain, support, and other criteria genuinely connected to the scope.
A poorly constructed shortlist limits competition before proposals are even evaluated. Criteria therefore need to be justified and documented.
Evaluation Criteria Need to Originate in the Strategy
Selection criteria should not be invented after the RFP has been issued. The World Bank recommends that evaluation factors be proportional to the nature, complexity, risk, and objective of the procurement and be defined in the Procurement documents.
The strategy determines which aspects genuinely differentiate alternatives: performance, methodology, risk, specific experience, schedule, integration capability, sustainability, lifecycle, or other factors.
This also prevents automatic use of corporate scoring templates that do not correspond to the actual risk of the package.
Long-Lead Items and Early Procurement
Long-lead equipment may require Procurement before other parts of the project. The strategy needs to assess whether early procurement reduces schedule risk or creates the risk of purchasing before Engineering has stabilized the interfaces.
When early procurement is necessary, the following should be defined:
- parameters that are already frozen;
- interfaces that remain open;
- responsibility for subsequent changes;
- vendor data required for design;
- documentation and approval milestones;
- FAT, inspections, and expediting;
- logistics and preservation until installation.
Brownfield and Operating Environments
In retrofit, expansion, and modernization projects, existing-condition risk is central. The strategy should consider site surveys, shutdown windows, coexistence with operating systems, migration, contingencies, testing, and reversibility.
Packages that work well in greenfield projects may be unsuitable in operating plants because the main risk is not the supply itself, but the interfaces with existing assets.
Contracting Governance and Stage-Gates
The strategy should define when a package is authorized to advance. Gates may verify scope maturity, budget, requirements, market conditions, risks, internal approval, solicitation documents, and evaluation criteria.
An illustrative flow may use the following points:
- need and objective confirmed;
- package strategy approved;
- technical baseline ready for the market instrument;
- suppliers qualified when applicable;
- RFP/RFQ approved for issue;
- technical and commercial evaluation completed;
- recommendation and contracting conditions approved;
- contract issued and management plan mobilized.
This governance connects Procurement to approval authorities and the project’s broader stage-gates.
Contracting Strategy Deliverables
A sufficiently mature strategy may be documented in a report, executive plan, or section of the Project Execution Plan. Regardless of format, it should consolidate:
- Procurement objectives;
- Engineering assumptions;
- make-or-buy analysis;
- package structure;
- market analysis;
- delivery and contract model;
- risk allocation;
- selection strategy;
- need for RFI or prequalification;
- evaluation criteria;
- long-lead items;
- sequence and interfaces between packages;
- governance and gates;
- key decisions still open.
How the Strategy Becomes a Procurement Plan
Once the structural decisions are approved, the procurement plan converts each package into an executable sequence: requisition dates, RFI/RFP/RFQ, receipt of bids, TBE, negotiation, award, submittals, manufacturing, inspections, FAT, expediting, logistics, and delivery.
This sequence is essential because Procurement does not end at contract award. For critical equipment and systems, supply quality depends on technical control throughout execution.
Final Considerations
The contracting strategy is an engineering and governance decision before it is an administrative purchasing activity. It determines what will be purchased, what the market will need to be capable of delivering, where the owner will retain control, how risks will be distributed, and which instruments will be used to form a comparable decision.
The earlier these choices are addressed in an integrated manner with design, risks, schedule, and market conditions, the lower the probability that the project will attempt to fix through the contract problems that originated in the contracting architecture itself.
Transferring risk through a contractual clause does not mean transferring the capability to control it. The strategy needs to place each risk with the party that has the best technical and operational conditions to manage it.
Technical References
[1] PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge (PMBOK® Guide). 8th ed. Newtown Square: PMI, 2025. Available at: [https://www.pmi.org/standards/pmbok](https://www.pmi.org/standards/pmbok)
[2] WORLD BANK. Project Procurement Strategy for Development: PPSD Long Form Detailed User Guidance. Washington, DC, 2025. Available at: [https://thedocs.worldbank.org/en/doc/b6bd32d73ca9f00f9cd83c90550d8a63-0290012025/original/PPSD-Procurement-Guidance-FINAL-aug-25.pdf](https://thedocs.worldbank.org/en/doc/b6bd32d73ca9f00f9cd83c90550d8a63-0290012025/original/PPSD-Procurement-Guidance-FINAL-aug-25.pdf)
[3] WORLD BANK. Procurement for Borrowers. Washington, DC. Available at: [https://www.worldbank.org/ext/en/what-we-do/project-procurement/for-borrowers](https://www.worldbank.org/ext/en/what-we-do/project-procurement/for-borrowers)
[4] INFRASTRUCTURE AND PROJECTS AUTHORITY; HM TREASURY. Project Routemap: Procurement Module. London. Available at: [https://www.gov.uk/government/publications/improving-infrastructure-delivery-project-initiation-routemap](https://www.gov.uk/government/publications/improving-infrastructure-delivery-project-initiation-routemap)
Frequently Asked Questions
It is the structured definition of how the project will be divided into packages, which delivery and contract models will be used, how risks will be allocated, which market will be accessed, and how suppliers and proposals will be selected.
The strategy defines the contracting architecture and principles. The procurement plan turns those decisions into packages, dates, accountable parties, milestones, and Procurement execution status.
The decision depends on requirements maturity, owner capability, available market, interfaces, risks, and the need to concentrate or distribute responsibilities. There is no universally superior model.
Yes. The RFP is an instrument for executing the strategy. Packages, contract model, risks, criteria, and market approach need to be sufficiently defined before issuance.
It is the analysis that compares performing an activity with internal resources against acquiring it externally, considering competence, capacity, costs, risks, and the need for specialization.
They may require early packages or specific Procurement milestones, but early purchasing needs to be reconciled with the maturity of technical interfaces to avoid later changes and rework.
Complementary Technical Materials
Related Solutions
- Requirements, Evidence, and Acceptance Criteria Management
- Contracts, Scope, and Deliverables Management
Related Services
- Technical Procurement: Specification, Bid Equalization, Suppliers, and Contracting Support
- Owner’s Engineering: Technical Governance, Supervision, and Acceptance
Core Content on the Topic
- Procurement in Engineering Projects: Definition, Stages, Criteria, and Supplier Management
- RFI vs. RFP vs. RFQ: Differences and When to Use Each Document in Engineering
