Selecting a QRA consultant should be a technical vendor-qualification exercise, not a comparison of report price and delivery date alone. The quality of a quantitative risk assessment depends on scenario completeness, data discipline, model selection, frequency analysis, population assumptions, peer review and the ability to turn results into practical risk reduction.
This checklist helps procurement, EHS, project and process-safety teams compare proposals on a consistent basis. It focuses on the consultant-selection decision; organisations looking to commission a full study can review Elion’s Quantitative Risk Assessment service.
1. Define the decision the QRA must support
A clear scope starts with the decision, not the software. State whether the study is for environmental clearance, layout selection, occupied-building siting, emergency planning, insurance review, regulatory approval, expansion, management of change or comparison of design alternatives. Ask every bidder to confirm how the methodology and deliverables will answer that decision.
2. Verify relevant team competence
Request the proposed team structure and the role of each person. Relevant experience should match the hazards and facility type, such as petroleum storage, LPG or LNG, pipelines, city gas, chemicals, pharmaceuticals or other process industries.
- Who will lead HAZID and scenario selection?
- Who will perform frequency and consequence modelling?
- Who will check inputs, calculations and report conclusions?
- Has the team handled comparable inventories and operating conditions?
- Will the named specialists remain assigned through review and close-out?
A list of company projects is less useful than evidence that the proposed team understands the specific release physics, operational context and approval objective.
3. Examine the proposed methodology
The proposal should explain how process data will be verified, how scenarios will be selected, which failure-frequency sources will be used, how safeguards will be credited, and how consequence and risk results will be generated. A generic statement that “QRA software will be used” is not a methodology.
- HAZID and scenario-screening approach
- Hole-size and release-duration basis
- Event-tree and ignition-probability method
- Weather, occupancy and population treatment
- Fire, explosion and toxic model selection
- Individual-risk, societal-risk and ALARP method
4. Check software capability without treating software as competence
Tools such as PHAST, SAFETI or ALOHA may be appropriate depending on the required outcomes and scope. The consultant should identify the proposed tool, version-control approach, model limitations and quality checks. Software cannot compensate for an incomplete scenario register or weak assumptions.
Ask whether native model files, input registers or reviewable calculation outputs will be available. The owner should not receive only images of contours with no audit trail.
5. Require traceable data and assumptions
A strong consultant establishes an input register early and marks every value as client-provided, site-verified, calculated, referenced or assumed. The proposal should state what happens when data are missing and how assumptions will be approved.
- Current plot plan, PFDs and relevant P&IDs
- Equipment, line and relief-system data
- Hazardous-material properties and maximum credible inventories
- Operating and design conditions
- Detection, isolation, shutdown and fire-protection performance
- Weather, occupancy, population and sensitive receptors
6. Review the quality-assurance process
Ask for a documented independent check before issue. Quality assurance should cover the scenario register, frequencies, model inputs, contour generation, tabulated results, dominant risk contributors and consistency between findings and recommendations.
The report should have clear revision control and a comment-resolution process. For complex or high-consequence facilities, define an intermediate review after scenario selection and another after preliminary results; waiting until the final report makes corrections expensive.
7. Specify decision-ready deliverables
A technically adequate QRA package normally includes more than a narrative report.
- Study basis and applicability matrix
- Data, assumption and scenario registers
- Frequency calculations and event trees
- Consequence tables for thermal radiation, overpressure and toxic exposure
- Individual-risk contours and societal-risk F-N curves where applicable
- Dominant-contributor analysis
- ALARP evaluation and prioritised action register
- Model files or agreed reviewable outputs
- Presentation and technical comment close-out
8. Use a weighted technical-commercial evaluation
Score technical proposals before opening or comparing commercial bids. A practical evaluation can weight scope understanding, relevant team experience, methodology, data and QA controls, deliverables, schedule realism and references. Price can then be evaluated among technically acceptable bidders.
A low bid may exclude site verification, population analysis, societal risk, model files, review meetings or comment close-out. Normalise these exclusions before comparing totals.
9. Look for proposal warning signs
- The proposal promises a fixed report without reviewing available data
- No named technical lead or independent checker
- No distinction between consequence analysis and full QRA
- Risk contours offered without frequency or population methodology
- Regulatory requirements copied without facility-specific applicability
- Extremely short schedules with no client-input milestones
- Important deliverables listed as optional after award
10. Confirm governance at kickoff
Before modelling begins, agree the battery limits, document register, responsible contacts, site visit, scenario-review workshop, modelling assumptions, acceptance criteria, report stages and comment-response timetable. Record who can approve assumptions and who owns mitigation decisions.
Questions to include in a QRA request for proposal
- What similar facility and hazard experience does the proposed team have?
- How will scenarios and failure frequencies be selected and checked?
- Which models and software will be used, and what are their limitations?
- How will missing data and assumptions be controlled?
- Which risk outputs and editable or native files are included?
- What independent technical review is performed before issue?
- How many review cycles and meetings are included?
- How will ALARP options be evaluated and prioritised?
Elion can provide a scoped proposal aligned to the facility, decision objective and applicable requirements. Send the project brief, plot plan, hazardous inventory and target schedule for a technical review.