Home › Blog › How to put together a technical diving proposal

How to put together a technical diving proposal

Published 9 September 2026 · 10 min read · 1,981 words

In brief

A technical diving proposal is the document that turns a client's need into a method, a team, a timeframe and a price. The ones that win aren't the cheapest or the longest: they're the ones that show the person who wrote it has understood the problem, thought through the method, and put in writing what is and isn't covered by the price.

Behind every underwater job there's a document almost never shown outside the company: the technical proposal. It's the paper where a vague client need — 'the quay piles need inspecting', 'something's fallen to the bottom', 'we need the water intake cleaned' — turns into a concrete method, with a team, a timeframe, deliverables and a price.

Writing proposals is a professional skill in its own right, and it's the natural next step for a diver or supervisor starting to move towards management. Knowing how to carry out a job doesn't necessarily mean knowing how to describe it in writing in a way that's credible, defensible and profitable.

Before writing anything: understand the brief

Most bad proposals start with a rushed reading of the brief. The client rarely knows what they need in technical terms; they know what problem they have. The first job is translation.

There are questions worth settling before working anything out. What the real goal is: not 'inspect', but 'find out whether the quay can keep operating this season'. What decision the work will feed into, because that sets the level of detail the deliverable needs. What information already exists: drawings, previous inspections, reports from the original works. Who else is involved: if there's an engineering firm, a site management team or a port authority involved, the conditions change.

And one that's often forgotten: why now. A job responding to an incident has a different urgency and tolerance than scheduled maintenance, and that affects price and timeframe as much as depth does.

The site survey

Whenever it's practical, visit. And when it isn't, say so in the proposal. A site visit settles things no phone call ever will: where the truck can park, whether a crane is available, how you get into the water, what the current is like and when, whether the site has marine traffic, where the power supply point is, and how long it takes from the work site to the nearest medical centre.

When a visit isn't possible, the proposal should list the supuestos it was prepared on. It's an uncomfortable list to write, and it's the one that protects the margin: 'vehicle access to the water's edge is assumed', 'visibility over one metre is assumed', 'the client is assumed to provide a power supply point within 30 metres'. If one of those assumptions turns out to be wrong, there's a contractual basis to revise it instead of an argument.

Scope: what's included and, above all, what isn't

Scope is the part of the proposal that gets reread most often when something goes wrong. It's written in the positive — what work is carried out, on which elements, over what extent and against what acceptance criteria — and closed with an explicit section of exclusiones.

The usual exclusions in underwater work include obtaining permits and authorisations that are the facility owner's responsibility, surface lifting equipment if none has been provided for, managing and removing waste generated, waiting time for weather or sea conditions, work arising from unforeseen findings, and any repair identified during an inspection. None of that is bad faith: it's defining what the price covers.

It's also worth setting the completion criterion. A cleaning job finishes when the surface reaches a defined condition, not when the client considers it good enough. An inspection finishes with delivery of the report, not with the last dive.

Method: the part that shows competence

This is where one proposal stands apart from another. The method statement explains how the work will be done, in what sequence, and why that technique was chosen over the alternatives.

A solid method statement covers the diving mode planned and its justification, the sequence of operations from mobilisation to demobilisation, the actual technique used — the inspection method, the cleaning system, the repair procedure — the positioning and reference means used underwater, and how the work carried out is recorded.

When there's more than one way to solve the problem, saying so counts in your favour. Explaining why the most obvious alternative was ruled out — because visibility won't allow it, because access doesn't work, because the client's timeframe doesn't fit — shows the job has actually been thought through, not just copied from a template.

Equipment and personnel

The equipment is sized from the method, not the other way round. The proposal should make clear what diving system is being mobilised, what surface support goes with it, what specific tools are needed, and what backup is planned for critical items. An experienced client will read that list looking for inconsistencies: a method that needs continuous gas supply paired with equipment that can't support it, or a depth that doesn't match the system proposed.

As for personnel, the proposal states the team's make-up and the qualifications required for each role. The chain of command of a diving operation isn't negotiable downward: headcount is set by the diving mode and the applicable regulations, not by a target price. A proposal that cuts personnel to bring the price down shifts risk onto the team doing the work, and it usually shows.

Safety, risk and emergency response

The safety section isn't a box-ticking annex. A serious client reads it closely because their own liability depends on who they hire.

It should set out the site-specific hazards identified — marine traffic, current, suction points, energy sources present at the facility, water contamination — the control measures for each, and a reference to the permit to work and risk assessment that will be drawn up before work starts, plus the emergency plan with the resources in place and the area's medical and hyperbaric references.

That last point is the most neglected, and the one that rules a proposal out fastest. Knowing how far away the nearest operational recompression chamber is, and what evacuation means would be used, isn't a formality: in many contracts it's a pass/fail requirement.

Timeframe and operating window

The timeframe for an underwater job isn't just a tally of dive hours. It depends on the real operating window: tides, current, traffic, hours allowed by the facility, daylight if that's a requirement, and sea conditions. Giving a timeframe without explaining the window is an invitation to conflict.

The most honest approach is to give a timeframe with the window spelled out, stating what counts as a non-working day and how it's treated contractually. A client who sees that level of detail understands that whoever wrote the proposal knows the site.

Entregables

If the job generates information — and almost all of them do — the proposal should state exactly what's delivered, in what format and by when. An inspection report with referenced photographs, tabulated measurements and usable conclusions doesn't cost the same as raw video on a hard drive, and the client needs to know which of the two they're buying.

Spelling out deliverables protects both sides: the client, because they know what they'll receive, and the company, because it caps an office workload that can otherwise grow very large. The reasoning behind that documentation is covered in the article on document management and as-built records.

Price and terms

The pricing structure should match the nature of the work. The usual schemes are a fixed price for a defined scope, a day rate for the team mobilised, and a unit price per element inspected or metre treated. Each spreads risk differently, and choosing the wrong one is as costly as getting the sums wrong.

Alongside the price come the terms: how long the proposal is valid, payment terms, how waiting time is treated, how changes in scope are revised, and any penalty clauses. The billing mechanics are covered in detail in the article on how a diving job gets invoiced.

Supporting documentation

Many technically sound proposals fall down over the administrative pack. Clients commonly require proof of the company's accreditation, evidence of the personnel's certifications qualifications, current medical certificates, equipment maintenance records, insurance policies and the health and safety management system.

Keeping that pack live and up to date — not rebuilt in a rush the night before — is part of the craft of putting together proposals. In small outfits it's often the same person who dives, writes the proposal and issues the invoice; in larger companies it's a role of its own, close to that of the project engineer.

A proposal is also a calling card

In the end, a client receiving three proposals and with no diving expertise judges by what they can judge: whether the document shows their problem has been understood, whether the terms are clear, and whether it gives them the confidence to sign. A short, well-organised, specific document beats a long, generic one almost every time.

And the best proposal is the one that can be delivered exactly as written. Promising an impossible operating window or a timeframe that doesn't add up wins a contract and opens a problem. Anyone who's been in the water knows exactly where that line is, and that's the advantage of having proposals written by people with field experience.

Frequently asked questions

What's the difference between a technical proposal and a simple quote?

A quote just says how much it costs. A technical proposal explains what's going to be done, with what method, with what equipment and personnel, in what timeframe, with what deliverables and under what terms. In underwater work that difference matters a great deal, because the price only makes sense once the scope is clear: the same job can cost twice as much if the operating window or the access method changes.

What's the most costly mistake when writing a proposal?

Not defining the exclusions. If the proposal doesn't explicitly say what it excludes — access, permits, client-supplied services, weather delays, waste removal — those costs end up absorbed by whoever does the work. The second most costly mistake is assuming site conditions that nobody has actually checked.

Do you have to visit the site before submitting a proposal?

Whenever possible, yes. And when it isn't, the proposal should state that it was prepared on information supplied by the client and list the specific assumptions made. That turns a hidden assumption into a visible contractual condition, which is exactly what avoids arguments later.

How do you justify a higher price than the competition's?

With the method and with what's delivered. A properly sized team, a realistic operating window, a serious emergency plan and a usable inspection report all cost money and save a great deal more. The proposal is the place to explain that difference with technical detail, not with adjectives.

What documentation does the client usually ask for alongside the proposal?

It depends on the client and the country, but it's common for them to ask for accreditation of the company and its personnel, current medical and training certificates, evidence of equipment maintenance, insurance cover and the safety management system. It's worth keeping that pack ready and up to date, because its absence rules out otherwise technically sound proposals.

Published 8 September 2026 · By Arthur More, professional saturation diver

Photo: Cityswift - Ireland · CC BY via Openverse

WhatsApp