Project delivery
A project should be reviewable at every stage, not only at the end.
Delivery runs through six recorded stages. Each one has a defined output, so that progress can be checked against something concrete rather than against a percentage on a report.
Delivery stages
Stage 01
Requirement definition
We document what the system must do, including process duty, utilities, footprint, cleaning regime, control philosophy, documentation expectations and constraints imposed by existing plant. Ambiguity is resolved here, in writing, not during commissioning.
Output
Requirement register, constraints list, open questions log
Stage 02
Concept & budget engineering
Options are compared on process fit, buildability, footprint, maintenance access and installation risk. Cost and schedule are estimated against a stated scope boundary so the numbers can be reviewed rather than taken on trust.
Output
Concept layout, option comparison, priced scope boundary
Stage 03
Detailed design & review
Engineering is developed to build level and reviewed with your engineering, quality, operations and maintenance stakeholders. Design freeze is a recorded event; changes after it follow change control.
Output
P&IDs, specifications, calculations, review minutes
Stage 04
Fabrication & factory testing
Modules are built and tested in the workshop. Welding, testing and inspection records are compiled during the build, and factory acceptance testing is run against the agreed test specification before shipment.
Output
Weld and test records, FAT protocol and results
Stage 05
Installation & commissioning
Site work runs to agreed shutdown windows and permit systems. Commissioning progresses through documented stages with defects tracked to closure before production release.
Output
Installation records, commissioning reports, punch list closure
Stage 06
Handover & continued support
Documentation, spares information and training are handed to the teams who will run and maintain the system. Ongoing support scope is defined by contract rather than implied.
Output
Turnover dossier, as-builts, spares and training records
Quality and evidence
Verification is recorded while the work happens.
Records are produced at the point of work by the people doing it, then compiled into the turnover dossier in the structure your document control requires. Nothing is recreated retrospectively to close a gap.
E-01 / Design records
Requirement register, calculations, specifications and dated review minutes, including the decisions taken where a specification was silent.
E-02 / Build records
Weld logs, welder identification, material certificates, pressure and leak test results, surface treatment records where applicable.
E-03 / Controls records
Functional design specification, loop schedules, software version records and test results against the specified functions.
E-04 / Commissioning records
Static check sheets, loop verification, wet commissioning and performance run results, plus punch list status through to closure.
Qualification and validation ownership remains with your quality function. Our scope is to supply the documentation defined in the contract in the format agreed at the start.
Fig. 06 / field records taken beside a control enclosure
Change and risk
Changes are priced, not absorbed silently.
Design freeze
A recorded event with a named baseline. Everything after it goes through change control.
Change control
Each change is described, assessed for cost and schedule effect, then agreed in writing before work proceeds.
Scope boundaries
Tie-in points, supply limits, utilities and responsibilities are listed in the quotation, not implied.
Risk register
Known risks, owners and mitigations are tracked and reviewed with you during the project.
Handover
Handover means your team can run the system without us.
The turnover dossier contains as-built drawings, test and inspection records, instrument and calibration data, control software configuration and version details, spares information and operating instructions. Operator and maintenance training is delivered against that documentation so the system is understood, not just accepted.
