Document {{ORG_PREFIX}}-012
Design & Development Procedure¶
1. Purpose¶
This procedure defines how {{ORG_NAME}} plans, controls, and records the design
and development of its products and services, so that what reaches delivery has
been designed against known requirements, checked against those requirements,
and confirmed fit for its intended use. It operationalises the quality
commitments of quality-ohs-policy for design work; the hand-off from a
released design into delivery is governed by
operational-control-service-delivery-procedure.
The intent, at ~25 people, is a light but real stage discipline: a small number of named stages, a design file per project, and a review before anything moves forward — not a heavyweight gate process.
2. Scope¶
This procedure covers the work defined in [ORG-DECISION: the concrete
triggers that put a piece of work in scope of this procedure, e.g. new
service offerings, custom engineered products, bespoke client solutions
above a defined size; versus routine configuration of standard offerings,
which is handled under operational-control-service-delivery-procedure].
Behind the list sits the test that generated it: {{ORG_NAME}} is developing
something new, or substantially changing something existing, and must work
out for itself what the result has to be and do, because neither the
customer nor any established specification settles that detail. The test
governs: work that meets it is in scope even when no listed trigger names
it, and the {{ROLE_QUALITY_MANAGER}} makes and records the scope call
(§3.1).
This document is gated by the design_and_development feature flag. If
{{ORG_NAME}} performs no design or development, the flag is off, this document
is dropped at instantiation, and the exclusion is stated and justified in the
IMS Scope Statement.
3. Procedure¶
3.1 Design planning¶
Design work at {{ORG_NAME}} runs inside the five-stage model below. Each project gets its own plan before design work starts; the stages, controls, and records this procedure defines carry across projects, so the discipline exists before any single project does. The {{ROLE_QUALITY_MANAGER}} keeps this procedure current and judges when it applies to a piece of work.
Every in-scope project passes through five stages:
| Stage | What happens | Exit condition |
|---|---|---|
| 1. Brief | Inputs gathered and confirmed (§3.2) | Design brief record committed |
| 2. Develop | Outputs produced against the brief (§3.4) | Draft outputs exist |
| 3. Review | Design review held (§3.3) | Review record committed; problems actioned |
| 4. Verify | Outputs checked against inputs (§3.3) | Verification record committed |
| 5. Validate & release | Result confirmed fit for intended use; design released to delivery (§3.3) | Validation record committed; release noted in the design plan record |
Planning steps for each project:
| Step | Action | Responsible role | Output / record |
|---|---|---|---|
| 1 | Confirm the work is in scope of this procedure (per §2) and open a design project | {{ROLE_QUALITY_MANAGER}} | Design plan record opened in docs/records/design-reviews/ |
| 2 | Appoint the design lead and name the reviewers and verifiers for stages 3 to 5; the design lead may not verify their own outputs alone | {{ROLE_QUALITY_MANAGER}} | Responsibilities section of the design plan record |
| 3 | Write the design plan, sizing the discipline to this particular piece of work | Design lead | Stage plan, resources and interfaces, customer and user touchpoints, and records list sections of the design plan record |
The design plan record carries these sections:
- Stage plan. How the five stages run for this job: which run separately and which combine, and how deep the checking at stages 4 and 5 goes. Simple work may combine stages into a single session; complex or long-running work gets separate sessions. Where the customer or another interested party expects the design to be controlled to a particular level, the design lead records that expectation here and plans the stages to meet it.
- Responsibilities. The design lead, and the reviewers and verifiers named at step 2.
- Resources and interfaces. The people, skills, tools, and specialist input the project needs, whether {{ORG_NAME}} holds them or brings them in from outside, together with how the interfaces between all participants, any external design contributor included, are controlled: who decides what, and how design information passes between them.
- Customer and user touchpoints. The points at which the customer and
users review or sign off, and how their feedback enters the design file;
those touchpoints are also reflected in the contract record per
operational-control-service-delivery-procedure. This section also states what the result will need in delivery, operation, and support once it is released, so the design accounts for it. - Records list. The records this project will produce as the evidence that the design met what the brief asked: at minimum a brief, a review record, a verification record, and a validation record.
The design plan is a living record: as the work progresses and the plan changes, an updated plan record is appended and the original is never edited.
3.2 Inputs¶
Before development starts, the design lead compiles the design brief: {{ORG_NAME}}'s written statement of what this design has to satisfy.
The brief states what the result must do and how well, drawn from the
customer's stated needs and from {{ORG_NAME}}'s own offer definition, and
what it would cost the customer and users if the result failed. Where
failure could affect the health and safety of anyone involved, the design
lead consults the {{ROLE_OHS_COORDINATOR}} and writes the resulting
requirements into the brief. Statutory and regulatory requirements, together
with the standards and codes of practice {{ORG_NAME}} has committed to
apply, come in through the compliance obligations process with the
{{ROLE_QUALITY_MANAGER}} and are referenced to their Compliance Obligations
register entries. The design lead also draws on what {{ORG_NAME}} already
learned from previous similar designs: prior design files in
docs/records/design-reviews/, relevant nonconformity and incident history,
and delivery feedback.
The design lead and the {{ROLE_QUALITY_MANAGER}} then work through the assembled brief together against one test: could a designer build from this without coming back to ask what a line means or what the job still needs? Anything that fails the test goes back for more substance before the brief is settled. They also look for inputs that pull against each other, as when a customer asks for something an applicable code forbids, or when two obligations point different ways. Every such clash is resolved before development starts, whether by going back to the customer, by the {{ROLE_QUALITY_MANAGER}} ruling between competing obligations, or by reworking the brief, and the brief's adequacy-confirmation and conflict-resolution notes record how each was settled.
The design lead then commits the brief to docs/records/design-reviews/;
development does not start until the brief record is committed.
An input that surfaces mid-project (a new requirement, a changed regulation) enters through §3.5 as a design change, so the brief and the completed checks stay in step with reality.
3.3 Controls¶
The design plan (§3.1) states, before each stage runs, what the stage must
deliver. Stages 3 to 5 of the §3.1 pipeline are where the checking happens;
each produces its own record in docs/records/design-reviews/, so every
project holds evidence of review, verification, and validation:
| Stage | Check | Responsible role | Record |
|---|---|---|---|
| 3. Review | Hold a design review at the stage(s) the design plan sets, asking one question: can the results so far meet the requirements in the brief? Participants per the plan, including the customer where the plan says so. | Design lead (chairs); {{ROLE_QUALITY_MANAGER}} (participates) | Design review record: attendees, findings, decisions |
| 4. Verify | Check the design outputs against the brief's input requirements item by item, using whichever method the plan calls for: checking against the brief, a calculation check, a peer check, or a test against specification. | Verifier named in the design plan, never solely the design lead | Verification record: what was checked against what, and the result |
| 5. Validate & release | Confirm the result actually works for the application specified for it and the use it is designed to serve, under realistic conditions where practicable: a pilot, a trial delivery, or a customer acceptance test per the plan. | Design lead, with customer or user involvement per the plan | Validation record |
Problems found at any of these stages follow one rule: the design lead logs the problem, takes the necessary action (rework the design, revisit the inputs, or escalate), and closes it only once the action is recorded in the problems-and-actions log inside the relevant stage record. No design is released with an open problem unless {{ROLE_TOP_MANAGEMENT}} explicitly accepts it in writing. The design lead commits each record as it happens, actions included.
For simple work the design plan may schedule the three checks within a single session; they answer different questions, so the record must still show each distinctly.
3.4 Outputs¶
Design outputs are the specifications, drawings, service definitions, work instructions, configurations, or acceptance test plans that delivery will work from:
Whatever mix of these artefacts a project produces, the design lead shapes
the output set for the people who will deliver from it. The question the
design lead asks before release is whether a delivery crew could pick this
pack up cold and do the job right, because on {{ORG_NAME}}'s work the
designer is usually somewhere else by then. So the pack has to run the job
on its own under operational-control-service-delivery-procedure, and it
has to tell delivery what "right" looks like: the acceptance criteria they
will judge the result against, and the tolerances, test points and
acceptance checklists behind them, either written into the pack or pointed
to from it. It has to say what makes the result work and what keeps it safe
to deliver and to use, with safety-critical characteristics called out where
a crew could otherwise miss them, and the {{ROLE_OHS_COORDINATOR}} looks
over that call where the work carries real risk. Nothing in the brief is
left hanging: verification (§3.3) walks the brief item by item against the
outputs, so anything the brief asked for is answered somewhere in the pack
or the gap is visible before release.
Once the outputs are final, the design lead commits them to
docs/records/design-reviews/ or, where outputs live in delivery systems,
commits to that same folder an output summary listing each output, its
version and its location. Either way the project's design file shows exactly
what {{ORG_NAME}} handed delivery and when, which is what anyone tracing a
delivered result back to its design needs, and what any later change (§3.5)
is measured against. Outputs reach delivery only after stage 5 of §3.1
completes.
3.5 Changes¶
A reviewed, verified, and validated design stays trustworthy only while nothing alters it unchecked. A change request may come from the customer, from problems found in delivery, or from a new obligation, and it may land while the design is still in progress or after release; either way the same five steps apply, so a late change cannot break a checked design unnoticed:
| Step | Action | Responsible role | Output / record |
|---|---|---|---|
| 1 | Identify and log the proposed change: what is changing, why, and which released or in-progress design it affects | Whoever identifies it, logged by the design lead | Change entry in a design change record, docs/records/design-reviews/ |
| 2 | Review the change: impact on the design brief, on already-verified or validated results, on delivery in progress, and on safety-relevant characteristics; determine whether verification or validation must be repeated | Design lead, with {{ROLE_QUALITY_MANAGER}}; {{ROLE_OHS_COORDINATOR}} where safety-relevant | Review outcome in the design change record |
| 3 | Authorise or reject: [ORG-DECISION: change authorisation thresholds, e.g. design lead for minor changes, {{ROLE_QUALITY_MANAGER}} for changes affecting verified results, {{ROLE_TOP_MANAGEMENT}} for changes affecting safety-critical characteristics or contractual commitments] | Authoriser per the decision rule | Named authoriser and decision in the design change record |
| 4 | Act on the decision: update the affected outputs, repeat verification or validation as determined at step 2, and notify delivery and the customer where they are affected | Design lead | Actions recorded in the design change record; updated outputs per §3.4 |
| 5 | Commit the completed change record | Design lead | Design change record retained in docs/records/design-reviews/ |
Changes to the wider management system (as opposed to a specific design) are outside this procedure and follow the management-of-change process.
4. Records and Registers¶
| Activity | Register (index) | Record (evidence) |
|---|---|---|
| Design planning (§3.1) | — (no dedicated register; design records are indexed by the generated records index) | Design plan record, docs/records/design-reviews/YYYY-MM-<project-slug>-plan.md |
| Design inputs (§3.2) | — | Design brief record, docs/records/design-reviews/YYYY-MM-<project-slug>-brief.md |
| Reviews, verification, validation, problems (§3.3) | — | Review / verification / validation records, docs/records/design-reviews/YYYY-MM-<project-slug>-<activity>.md |
| Design outputs (§3.4) | — | Design outputs record, docs/records/design-reviews/YYYY-MM-<project-slug>-outputs.md |
| Design changes (§3.5) | — | Design change record, docs/records/design-reviews/YYYY-MM-<project-slug>-change-<n>.md |
All design evidence lives in docs/records/design-reviews/ (gated, like this
document, by the design_and_development flag). Records are append-only: a
superseded plan or brief is followed by a new record, never edited.
related_registers is empty because no Airtable register indexes design work;
the generated records index built by tools/gen_views.py is the retrieval aid.
Honest status: docs/records/design-reviews/ stays empty until the first
design project has actually run through this procedure. Until then, this
procedure is documented but has not operated, and no other claim is made.
5. Exceptions¶
An exception to this procedure (for example, compressing stages for an urgent customer commitment beyond what §3.1 step 3 already allows) is requested in writing to the {{ROLE_QUALITY_MANAGER}}, who assesses the impact on verification and validation coverage and refers the request to {{ROLE_TOP_MANAGEMENT}} for approval. An approved exception is recorded in the affected project's design plan record and is valid for that project only, for at most [ORG-DECISION: exception validity period, e.g. 90 days] before re-review.
No exception is available to: releasing a design without a committed verification and validation record (§3.3), or releasing with open problems without written acceptance by {{ROLE_TOP_MANAGEMENT}} (§3.3 step 4).
6. Related Documents¶
quality-ohs-policy— the policy this procedure implements (implementsfrontmatter); design discipline is one of its quality commitments in action.operational-control-service-delivery-procedure— receives released design outputs and applies the acceptance criteria they define; also governs the routine work that this procedure's §2 scope test excludes.
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}}-012 |
|---|---|
| Type | Procedure |
| Version | 0.1 |
| Status | Draft |
| Owner | {{ROLE_QUALITY_MANAGER}} |
| Reviewer | {{ROLE_DOCUMENT_CONTROLLER}} |
| Approver | {{ROLE_TOP_MANAGEMENT}} |
| Next Review | 2026-08-15 |
| Classification | Internal |
| Capability | design_and_development |
Held in the document frontmatter, mirrored to the Document Register.