Document {{ORG_PREFIX}}-011

Operational Control & Service Delivery Procedure¶

1. Purpose¶

This procedure defines how {{ORG_NAME}} plans, carries out, and controls the delivery of its services, so that every job produces a conforming deliverable through work that is safe for the people doing it. It operationalises the delivery-facing commitments of quality-ohs-policy: each job is planned proportionately, delivered under controlled conditions, its outputs identified and traceable, customer property protected, work verified before release, and OH&S controls applied to the work itself — with the evidence that all of this happened retained in the job file.

2. Scope¶

This procedure applies to every job {{ORG_NAME}} delivers — client engagements and internal projects run as jobs — from the point an engagement is accepted (the handover from customer-requirements-contract-review-procedure) to the completion of any post-delivery obligations. It covers office-based and field work, and binds all workers performing delivery work, including contractors working under {{ORG_NAME}}'s direction.

It does not cover:

winning work and pre-commitment review — customer-requirements-contract-review-procedure;
purchasing, subcontractor selection, and contractor management — the Procurement & Contractor Management Procedure;
pre-planned changes to the management system, organisation, or ways of working generally — the Management of Change Procedure (in-flight changes to a specific job stay here, §3.8).

Throughout this procedure, job lead means the worker named in the job file as responsible for delivering that job. It is an assignment made at planning (§3.1), not a standing position.

3. Procedure¶

3.1 Operational planning¶

3.1.1 The job file¶

Every job has exactly one job file — the single per-job home of operational documented information, held in [ORG-DECISION: where job files live and their standard structure — e.g. one folder per job in the organisation's document system, or a job record in its project-management tool]. The job file defines, job by job, which per-job records exist. Two confirmations size that set: from the completed job file a reader can verify that the deliverables meet their requirements and can see that delivery ran to plan. A record that supports neither confirmation is not kept. Evidence of this kind is operational: it belongs in the job file for its job, never in docs/records/. The clause maps carry the same convention and mark rows evidenced by per-job records "operational".

Job-file item	When required	Governing section
Accepted requirements and the contract-review outcome	Every job	`customer-requirements-contract-review-procedure`
Delivery plan: process and acceptance criteria, stages, verification points, resources, OH&S criteria	Every job (short-form for routine work)	§3.1.2
Verification evidence at each planned stage	Every job	§3.6
Release record	Every job	§3.6
Deliverable and data identifiers; traceability linkage	Identifiers always; traceability linkage where traceability is required	§3.3
Customer / external-provider property log	Whenever such property is held or used	§3.4
In-delivery change records	Whenever the job changes in flight	§3.8
Pre-start hazard check and OH&S coordination notes	Field work and shared workplaces	§3.10
Post-delivery obligations and their fulfilment	Whenever such obligations exist	§3.7

3.1.2 Planning steps¶

Step	Action	Responsible role	Output / record
1	Open the job file; name the job lead; carry the accepted requirements and contract-review outcome into it.	{{ROLE_QUALITY_MANAGER}} (or the job lead once named)	Job file opened, requirements attached
2	Write the delivery plan into the job file: the stages the job runs through and the verification point set at each; the acceptance criteria each deliverable must pass before release; the process criteria the in-process checks test against (§3.6); and the people, equipment, IT, and any subcontracted work the job draws on.	Job lead	Delivery plan in the job file
3	Bring planning actions into the job: confirm which existing hazard controls and risk treatments apply, per `risk-opportunity-hazard-methodology`; identify job-specific hazards and log any new ones in the Hazard Register.	Job lead, with {{ROLE_OHS_COORDINATOR}} for new or changed hazards	OH&S criteria in the delivery plan; Hazard Register rows
4	Decide what per-job documented information the job needs beyond the §3.1.1 minimum. Walk the job's activities and ask where a missing written instruction or check could let the work drift from plan; every activity where it could gets one.	Job lead	Job-file contents list in the delivery plan
5	Confirm the plan is proportionate: routine jobs use the standard short-form plan; novel, complex, or higher-risk jobs get a fuller plan reviewed for quality by {{ROLE_QUALITY_MANAGER}} and for OH&S by {{ROLE_OHS_COORDINATOR}}.	{{ROLE_QUALITY_MANAGER}}	Reviewed delivery plan

The output of planning takes the form {{ORG_NAME}} actually works in — the job file and its short delivery plan. No standalone "quality plan" document is produced unless a client contract specifically requires one, in which case it is filed in the job file like any other deliverable.

3.2 Controlled conditions¶

All service delivery runs under conditions {{ORG_NAME}} controls. The controls follow the shape of the delivery lifecycle, and they scale: a control applies as far as the job at hand engages it.

Plan. Before work starts, the job file fixes what the deliverable is and what it must satisfy: the accepted requirements arrive with the contract-review handover, and the delivery plan adds the acceptance criteria (§3.1.2). No job proceeds without both in the job file.
Staff. Delivery work goes only to workers competent for it, per the organisation's competence, training and awareness arrangements. A competence gap found at planning is closed before the affected work starts, by supervision, training, or reassignment.
Execute. The work runs on infrastructure and in a work environment kept fit for it, per §3.9. The monitoring and measuring resources a job calls for are on hand and in use, per monitoring-measurement-calibration-procedure; where a measurement matters to conformity, workers use only equipment controlled under that procedure. Defences against human error are built into how the work runs: standard templates and checklists for recurring work, the pre-start checks of §3.10 for field work, and the second-person review of §3.6 before anything is released. [ORG-DECISION: any further error-proofing measures, e.g. system validation rules, paired field work.]
Check. Verification happens where the delivery plan puts it: in-process checks test the work against the process criteria, and final verification tests the deliverable against its acceptance criteria, per §3.6.
Release and after. The release gate of §3.6 and the post-delivery arrangements of §3.7 control how deliverables leave {{ORG_NAME}} and what happens once they have.
Validate where checking cannot. A service whose output later checking cannot verify needs its own regime. [ORG-DECISION: whether any of the organisation's services produce such outputs, e.g. one-off field observations, destructive sampling, live interventions. If so: the method is qualified before first use, performed only by workers assessed as competent in it, witnessed or peer-observed at a defined frequency, and revalidated whenever the method, tooling, or people materially change. If not, record "none" here at instantiation.]

3.3 Identification and traceability¶

Every job is identifiable. Each job carries a unique job identifier [ORG-DECISION: the job numbering scheme and where identifiers are issued], and every deliverable, dataset, and significant working file carries that identifier plus a version.
Traceable outputs carry their linkage. Where a contract, a compliance obligation, or the delivery plan calls for traceable outputs, the job file records, against each output's unique identifier, the linkage behind it: the inputs and source data it derives from, the equipment used and its calibration state (via monitoring-measurement-calibration-procedure), and who performed and who verified the work.
The trail stays in the job file. Identifiers and linkage entries are kept for as long as the applicable retention obligation requires.
Status gates release. Each deliverable shows its verification status at every point in delivery, moving through Draft → In review → Verified → Released, and only deliverables at Released leave the organisation (§3.6). [ORG-DECISION: the marking mechanism: a filename convention, a document control block on the deliverable, or a status field in the job system.]

3.4 Customer and external provider property¶

In the course of a job {{ORG_NAME}} often holds or uses things that belong to a customer or to an external provider, among them: personal data, credentials and site or system access, datasets and documents, samples and materials, equipment, and intellectual property.

Step	Action	Responsible role	Output / record
1	Log the property in the job file on receipt: what it is, whose it is, and its verified condition or completeness.	Job lead	Property log entry in the job file
2	Protect it while held: access limited to the job team, storage on managed systems or in secure physical storage, use only for the purpose it was provided for.	Job lead	—
3	Return, destroy, or retain the property at job end as agreed with its owner; close out the property log entry.	Job lead	Closed property log entry
4	A property log entry can turn bad before it closes: the item is damaged while in {{ORG_NAME}}'s care, goes astray, or turns out unable to do the job it was provided for. A bad entry is worked out with its owner: the job lead raises it with the owner straight away, notes the event in the job file, and settles the way forward with them, adding the agreed outcome to that note. Where the event also involves harm or potential harm to people, or is a data or security event, it is raised in the Incident Register under the organisation's incident reporting arrangements.	Job lead, escalating to {{ROLE_QUALITY_MANAGER}}	Loss/damage record in the job file; Incident Register row where applicable

3.5 Preservation¶

{{ORG_NAME}}'s outputs are predominantly data and documents, so preservation is chiefly about integrity:

Single authoritative copy — the job file holds the authoritative version of every deliverable and dataset; local-only working copies are not an acceptable home for job outputs.
Backups — [ORG-DECISION: the backup and recovery regime — what is covered, frequency, retention, and how restoration is periodically proven. Restore tests are entered in the Schedule register so they actually happen.]
Version integrity — the identification and status rules in §3.3 prevent superseded or unverified versions being mistaken for current ones.
Physical items — where a job involves physical samples, media, or equipment, they are labelled with the job identifier and handled, stored, and transported so their condition and evidential value are maintained, proportionate to their fragility and value.

3.6 Release of deliverables¶

Step	Action	Responsible role	Output / record
1	Carry out the verification set for each stage of the delivery plan: check the work against the process criteria (in-process points) and the deliverable against its acceptance criteria (final point). Final verification of a deliverable is done by someone other than its author.	Verifier named in the delivery plan	Verification evidence in the job file, status moved to Verified
2	Keep the deliverable at its current status while any planned verification is still open or has failed. Customers only ever receive deliverables that have passed the full verification set.	Job lead	Deliverable held at its current status
3	Authorise release: confirm the verification set is closed out and mark the deliverable Released. [ORG-DECISION: the default release authority, e.g. the {{ROLE_QUALITY_MANAGER}}, or a nominated senior reviewer per service line, named in each delivery plan.]	Release authority	Completed release record in the job file (content below)
4	Sometimes a job needs a deliverable out before its verification set has finished. That takes a concession: {{ROLE_TOP_MANAGEMENT}} approves it in writing and, where the contract calls for it, the customer agrees in writing as well. The concession record states the reason and lists the verification still owed.	{{ROLE_TOP_MANAGEMENT}}, with the release authority	Concession record in the job file

Every release closes with a release record in the job file: it identifies what went out, carries the evidence that the deliverable met its acceptance criteria, and names who signed it off. The job file retains these records like every other piece of job evidence.

3.7 Post-delivery¶

Post-delivery obligations are identified at contract review and re-checked at release: warranty or support periods, agreed follow-up activities, data retention or return commitments, and statutory duties identified through the organisation's compliance-obligations arrangements.

How much post-delivery activity a job carries is a judgement, made first at contract review and confirmed at release. The job lead asks:

What has the customer asked for beyond handover, and what has their feedback added?
What is this deliverable, how will it be used, and how long will it stay in use?
If it fails or misleads in use, who is affected and how badly?
What do the legal requirements identified for this job add on top?

The obligations, and evidence of fulfilling them, live in the job file. Obligations that fall due after job close-out (e.g. a data-destruction date, a scheduled follow-up) are entered in the Schedule register so they surface when due — the register is the reminder, the job file is the evidence.

3.8 Change control in delivery¶

Jobs change in flight: scope moves, methods get swapped, timing slips, people rotate, subcontracting appears. None of it takes effect unreviewed. Every in-flight change runs the table below first. The step-1 assessment sets what the remaining steps have to do: where the change moves the delivery plan's acceptance criteria, verification points, resources or OH&S criteria, or alters what the customer will receive, steps 2 to 4 run in full on every part it moves; where it moves none of them, step 3 authorises the change on the strength of the step-1 assessment alone and the change record carries that finding:

Step	Action	Responsible role	Output / record
1	Assess the proposed change: effect on the acceptance criteria, verification points, resources, and OH&S criteria of the delivery plan.	Job lead; {{ROLE_OHS_COORDINATOR}} where OH&S criteria are affected	Change assessment note
2	Where the change alters what the customer will receive, route it through the requirements-change step of `customer-requirements-contract-review-procedure` before adopting it.	Job lead	Amended requirements in the job file
3	Authorise the change and update the delivery plan. The authoriser signs the change record in their own name and lists the actions the change calls for; the step-1 assessment goes into the same record.	{{ROLE_QUALITY_MANAGER}} [ORG-DECISION: or a lower authorisation threshold for minor in-job changes]	Completed change record in the job file
4	Verify the actions arising were done at the next verification point.	Verifier per the delivery plan	Verification evidence

Changes to the management system, organisation, equipment fleet, or ways of working in general are not in-delivery changes — they route through the Management of Change Procedure.

3.9 Infrastructure and environment¶

The table below is {{ORG_NAME}}'s working list of the infrastructure its delivery depends on, and of how each item is provided and kept fit for the work:

Infrastructure	Provision and maintenance
IT systems, software, and data storage	[ORG-DECISION: the organisation's IT arrangement — in-house or managed provider, and the core systems relied on for delivery]; access provisioned at onboarding and revoked at offboarding; systems kept patched and supported; job files stored per §3.1.1 and preserved per §3.5
Field equipment and tools	Fit for purpose and maintained per manufacturer requirements; equipment used for measurement is additionally controlled under `monitoring-measurement-calibration-procedure`
Vehicles	Where vehicles are used for work: registered, serviced on schedule, and fit to drive. [ORG-DECISION: the vehicle arrangement — fleet, allowances, or private-vehicle-for-work rules, including who verifies servicing]
Premises and workspace	Provided by {{ORG_NAME}}; defects affecting output quality or safety are reported to [ORG-DECISION: the role or channel responsible for premises issues] and, where they are hazards, logged in the Hazard Register

Recurring maintenance obligations — vehicle servicing, equipment checks, backup restore tests — are entered in the Schedule register so they surface when due. The completed maintenance evidence stays with the asset or job records; the register only indexes and reminds.

A fit work environment is part of the same provision: workspaces with enough room, light, and quiet; field conditions fit for the work at hand; workloads and deadlines set realistically at planning (§3.1.2); and a working climate where raising a problem is expected, never punished. Concerns about the work environment go through the organisation's consultation channels or the {{ROLE_WORKER_REP}}; an environment issue that is also a hazard goes in the Hazard Register.

3.10 OH&S operational controls¶

3.10.1 Controls built into delivery¶

OH&S criteria in every delivery plan — planning (§3.1.2 step 3) sets the OH&S criteria the work must meet, and the work is carried out to them. Field work starts with a completed pre-start hazard check, filed in the job file.
Hierarchy of controls, applied at job level — when a control is chosen for a job hazard, the choice works down the hierarchy of controls in the order risk-opportunity-hazard-methodology defines, settling on a lower rung only once the rungs above it have been ruled out for that hazard. New or changed hazards found during delivery are reported by any worker through the hazard reporting channel and logged in the Hazard Register; the {{ROLE_OHS_COORDINATOR}} assesses and confirms controls per that methodology.
Work adapted to workers — work is arranged to fit the people doing it, not the reverse: assignments consider competence and current workload; equipment, vehicles, and workstations suit their users; the workers who will do the job take part in setting the method at planning; fatigue, workload, and fit concerns can be raised at planning, through the {{ROLE_WORKER_REP}}, or directly to the {{ROLE_OHS_COORDINATOR}} at any time.
Documentation where its absence would cause deviation — planning step 4 (§3.1.2) explicitly asks where a missing instruction or check could let the work drift from plan, and adds one there.
Evidence work went as planned — completed pre-start checks, verification evidence, change records, and release records in the job file are the retained evidence that delivery ran as planned, for OH&S as for quality.
Incidents — incidents and near misses during delivery are reported and investigated under the organisation's incident reporting arrangements and indexed in the Incident Register.
Outsourced processes — where part of a delivery process is outsourced, {{ORG_NAME}} keeps control of it through the Procurement & Contractor Management Procedure (selection, OH&S requirements in the engagement, and monitoring of performance). Outsourcing never transfers {{ORG_NAME}}'s responsibility for the conformity or safety of the delivered service.

3.10.2 Shared and multi-employer workplaces¶

{{ORG_NAME}} does not always have a workplace to itself: it delivers from co-located premises, on client sites, and on construction workplaces. Wherever another organisation shares the workplace, {{ORG_NAME}} agrees the safety ground rules with everyone working there and runs the job to them:

Step	Action	Responsible role	Output / record
1	Before work starts: exchange hazard and control information with the host and other organisations present; obtain and complete any site induction the host requires.	Job lead, supported by {{ROLE_OHS_COORDINATOR}}	Coordination note and induction evidence in the job file
2	Agree who controls what: which organisation's arrangements apply to which activities, and whose emergency arrangements apply on site.	{{ROLE_OHS_COORDINATOR}}	Agreed arrangements recorded in the job file
3	During the work: follow the host's arrangements and {{ORG_NAME}}'s own controls — whichever is stricter governs; report hazards and incidents both to the host and into {{ORG_NAME}}'s own Hazard and Incident Registers.	All workers on the job	Hazard Register / Incident Register entries as they arise
4	Revisit the coordination whenever the shared workplace, the parties present, or the work changes.	Job lead	Updated coordination note

4. Records and Registers¶

Activity	Register (index)	Record (evidence)
Per-job planning, verification, traceability, property handling, in-delivery changes, release, post-delivery fulfilment	— (job files are indexed by the organisation's job tracking arrangement, not an IMS register)	The job file: this evidence is operational, so it stays with its job, never in `docs/records/`
Hazards identified in planning or during delivery	Hazard Register	The assessment and controls recorded per `risk-opportunity-hazard-methodology`; job-level control evidence (e.g. pre-start checks) in the job file
Incidents and near misses during delivery	Incident Register	`docs/records/incidents/` per the organisation's incident reporting arrangements
Recurring maintenance, backup restore tests, and post-close post-delivery obligations	Schedule	Completed maintenance / fulfilment evidence with the asset records or the job file — the Schedule row is a reminder, never the proof

Honest status: this procedure's evidence is per-job. Until the first job has been delivered under it, no job file produced by it exists, and docs/records/incidents/ remains empty until an incident has actually been logged. Neither empty state is papered over.

5. Exceptions¶

An exception to this procedure is requested in writing to the {{ROLE_QUALITY_MANAGER}}, who assesses the quality impact; any exception touching OH&S criteria or controls is also assessed by the {{ROLE_OHS_COORDINATOR}}. Approval rests with {{ROLE_TOP_MANAGEMENT}}. An approved exception is recorded in the affected job file(s) and is valid for at most [ORG-DECISION: exception validity period, e.g. 90 days] before re-review.

No exception is available to:

releasing a deliverable without either completed verification or a documented early-release concession (§3.6);
weakening a hazard's control below its assessed hierarchy level without reassessment per risk-opportunity-hazard-methodology;
skipping coordination at a shared workplace (§3.10.2).

quality-ohs-policy — the policy this procedure implements (implements frontmatter); its commitments to conforming services and safe work are made operational here.
risk-opportunity-hazard-methodology — the risk, opportunity, and hazard methodology, including the hierarchy of controls this procedure applies at job level and the Hazard Register conventions.
customer-requirements-contract-review-procedure — the upstream procedure that establishes and reviews the requirements every job delivers against, and the route for requirement changes (§3.8 step 2).
monitoring-measurement-calibration-procedure — control of the monitoring and measuring resources and calibrated equipment used during delivery (§3.2, §3.3, §3.9).

7. Revision History¶

Version	Date	Author	Description of Changes	Reviewed By	Review Date	Approved By	Approval Date
0.1	2026-07-16	{{ROLE_QUALITY_MANAGER}}	Initial draft	—	—	—	—

8. Document Control

Document	`{{ORG_PREFIX}}-011`
Type	Procedure
Version	0.1
Status	Draft
Owner	{{ROLE_QUALITY_MANAGER}}
Reviewer	{{ROLE_OHS_COORDINATOR}}
Approver	{{ROLE_TOP_MANAGEMENT}}
Next Review	2026-08-15
Classification	Internal

Held in the document frontmatter, mirrored to the Document Register.