A booked order is not automatically ready to build. The customer may have accepted the commercial offer while interface dimensions, approved drawings, supplier selections or test requirements remain open. Releasing the whole order anyway turns those gaps into scrap, expediting and arguments about who knew what.
The opposite response causes damage too. Waiting for every detail on a long engineer-to-order project can waste months. Standard modules, long-lead components and low-risk fabrication may be ready while one customer-dependent package remains blocked.
This checklist works at the level of the release package. It helps engineering, planning, sourcing, quality and manufacturing decide what may start now, what may start under a named condition and what must wait.
Use three release decisions: ready, conditional or blocked
Give every package one decision. Ready means the required evidence exists and the authorized owner has released the work. Conditional means a specific residual risk remains inside an approved limit, with an owner, expiry or stop point. Blocked means starting would expose the company to an uncontrolled technical, commercial, quality, safety or schedule risk.
Do not use amber as a polite way to avoid a decision. State the condition and the work it permits. “Release motor purchase after electrical load list approval; do not release the control panel” is actionable. “Mostly ready” is not.
Apply the decision to an object: a drawing set, supplier package, production order, operation, module or site activity. One blocked input should stop the work it affects, not every activity on the project.
| Decision | Meaning | Required record |
|---|---|---|
| Ready | The package meets every mandatory release condition | Baseline, evidence, approver and release time |
| Conditional | A bounded exception permits named work to proceed | Condition, owner, due date, limit and stop point |
| Blocked | A missing or failed condition makes release unsafe or uneconomic | Blocker, affected work, owner and recovery action |
1. Confirm the customer order is the one the company accepted
Start with the accepted quote, final proposal, customer purchase order, order acknowledgment and approved differences. Confirm customer identity, sold-to and ship-to entities, currency, tax treatment, delivery term, payment milestones, warranty, liabilities and the effective date. Record each source and revision.
A purchase order number does not prove agreement. The buyer may have incorporated a newer specification, shortened the date or added terms by reference. Complete the PO-to-quote comparison and close every difference that can alter the released work.
Check the commercial start conditions. If the schedule starts after advance payment, customer data or a notice to proceed, capture the event and evidence. Planning can model the work before that event, but the project should not treat an untriggered date as firm.
| Order check | Evidence required | Stop release when |
|---|---|---|
| Accepted scope | Final quote, proposal and signed variance record | The PO adds or omits material scope |
| Price and currency | Cleared order value and line bridge | The order total does not reconcile |
| Delivery basis | Named date, start event, location and Incoterm | The customer and seller use different bases |
| Payment | Milestones, invoices, security and credit release | Required payment or credit approval is absent |
| Terms | Accepted warranty, liability and incorporated documents | An unresolved term changes execution risk |
2. Name the released product configuration
Identify the base model, selected options, customer-specific characteristics, materials, voltage, controls, duty, environment, standards and governing revisions. Give the package one configuration identity that connects the sales record to ERP, PLM, drawings and manufacturing.
The released configuration must answer a simple shop-floor question: which product are we building? If one system says Option B, another says Option C and the drawing title says “typical,” block the package.
NASA’s configuration-management guidance defines technical baselines as approved configuration documentation with performance, interface and verification requirements. An industrial OEM can use a lighter process, but it still needs a named baseline and controlled changes after release.
| Configuration check | Pass condition |
|---|---|
| Identity | Model, variant, serial/project identity and revision agree across systems |
| Options | Selected, rejected and deferred options have explicit states |
| Characteristics | Values, units and allowable ranges are complete |
| Interfaces | Each mechanical, electrical, process, controls and data boundary has an owner |
| Governing sources | The package points to the current drawings and specifications |
| Change authority | The team knows who can change the released configuration |
3. Allocate every material customer requirement
Turn specifications, drawings, clarifications and proposal responses into requirements that engineering and quality can use. Preserve the customer wording and source location. Add the accepted interpretation, responsible discipline, affected item and verification method.
Resolve contradictions before release. A specification may call for 316 stainless while a drawing calls for painted carbon steel. A clarification response may supersede both. The checklist should point to the governing decision, not make manufacturing compare three documents again.
Trace each material requirement to a design output and planned proof. This is especially important for performance guarantees, customer hold points, regulated features and requirements the proposal qualified. A requirement with no owner or verification path is not ready.
| Requirement check | Pass condition |
|---|---|
| Source | Document, revision, section and original text recorded |
| Disposition | Comply, qualify, deviate or clarify decision accepted |
| Allocation | System, assembly, discipline and owner named |
| Design trace | Drawing, model, calculation or specification identified |
| Verification | Analysis, inspection, demonstration or test defined |
| Exception | Open issue has an owner and blocks the affected release |
4. Release enough design definition for the package
Decide which design outputs the work actually needs. A supplier RFQ may need a performance specification and interface envelope. A casting purchase may need a released material specification and drawing. Fabrication may need approved drawings, weld details, tolerances and inspection points. Do not demand a full-project design freeze when the package uses a narrower stable boundary.
Check revision, approval state, units, tolerances, notes and referenced documents. Confirm the bill of material matches the drawing or model. Flag temporary or preliminary documents and state the work they can support.
The NIST digital-thread program focuses on reliable product-definition data moving from design into manufacturing and inspection. The practical release test follows the same idea: manufacturing and quality must receive the definition, intent and revision they need without reconstructing it by hand.
| Design output | Ready when |
|---|---|
| Drawing/model | Released revision contains geometry, materials, tolerances and notes for the work |
| Calculation | Inputs match the sold duty and the responsible engineer approved the result |
| BOM | Items, quantities, revisions and make/buy status match the design |
| Interface record | Boundary, owner, values and mating-item revision agree |
| Software/controls | Functions, I/O, interfaces and test basis support the released stage |
| Deviation | Authorized concession identifies affected units and expiry |
5. Check the bill of material, routing and work instructions
Confirm that the manufacturing record represents the released design. The BOM needs the correct components, quantities, effectivity and alternates. The routing needs the operations, sequence, work centers, setup and run basis. Work instructions need the controlled steps and acceptance points the operator cannot infer from the drawing.
Look for phantom or placeholder items, zero quantities, obsolete revisions, unapproved substitutes and operations with no resource. Confirm whether tooling, fixtures, programs and inspection plans belong to the order or to reusable master data.
Run an engineering-to-manufacturing reconciliation before release. Compare the released engineering structure with the production BOM and routing, then assign every difference. A green document status does not help if the wrong revision reached the order.
| Manufacturing definition | Release question |
|---|---|
| Production BOM | Does it contain the released parts, quantities, effectivity and approved alternates? |
| Routing | Can the named sites and work centers perform the operations in sequence? |
| Work instructions | Do operators have the controlled method and critical cautions? |
| Tooling/fixtures | Do the required tools exist, fit the revision and have a ready date? |
| Programs | Are CNC, robot, PLC or test programs tied to the right product revision? |
| Inspection plan | Do characteristics, methods, sampling and records match the requirement? |
6. Prove material and supplier readiness
Check material availability on every date the routing needs it. Total stock alone can hide a shortage at the first operation. Separate on-hand, allocated, ordered and unconfirmed supply. Verify shelf life, heat or lot traceability, approved manufacturers, substitutions and customer-source restrictions where they apply.
For bought-out packages, connect the released supplier scope to the selected response. Confirm specification revision, price, lead time, validity, freight, submittals, tests, exclusions and open technical points. Refresh evidence that expired between bid and order release.
SAP checks component availability when a planner creates or releases a production order. Oracle’s material-availability flow can release work orders with critical material assigned and hold orders with shortages. Your checklist should make the same distinction even if planners work across several systems.
| Supply check | Evidence | Possible decision |
|---|---|---|
| Critical material | Available or committed quantity on required date | Release, resequence or hold |
| Long-lead item | Approved specification and current supplier commitment | Early release under named baseline |
| Alternate part | Technical, quality and commercial approval | Use for named effectivity only |
| Supplier package | Selected quote and closed technical deviations | Issue PO or return for clarification |
| Customer-furnished item | Owner, condition, delivery and inspection plan | Hold dependent operation |
| Traceability item | Source, certification and lot/heat control | Quarantine supply that lacks evidence |
7. Test capacity and schedule against the released routing
Schedule the actual operations at the intended site. Check constrained engineering disciplines, machines, test bays, specialist labor, tooling and external processes. Confirm shift assumptions and calendars. A delivery date copied from the quote does not prove that capacity exists after award.
Use finite capacity or an explicit manual constraint check for the resources that can move the customer date. SAP’s capacity availability check evaluates each production-order operation against the load at its work center. The release meeting needs that result or an equivalent fact, not a general promise that operations will fit it in.
Compare requested, accepted and current planned dates. Show float on customer approvals, supplier deliveries, critical operations, FAT and shipment. If the plan misses the commitment, resolve the schedule before the package becomes shop-floor work.
| Capacity check | Pass condition |
|---|---|
| Engineering | Required disciplines have named work and available dates |
| Internal work centers | Critical operations fit the loaded calendar |
| External processes | Supplier slot and transit meet the routing date |
| Tooling/test assets | Fixture, program and test-bay dates support the sequence |
| Labor/skills | Qualified people or approved plan cover the work |
| Customer milestone | Current plan meets the accepted date with visible float and risk |
8. Release the quality and test plan with the work
Define incoming, in-process and final inspections for the released package. Include customer, regulatory and internal hold or witness points, required notice, acceptance criteria and the person authorized to release the next step.
Confirm how the team will prove performance requirements. Name the test conditions, instrumentation, calibration, sampling, calculation and record. If the contract promises a capacity under specified feed or utilities, those conditions belong in the test plan.
Map certificates and records to the item that produces them. Material certificates, weld records, coating reports, software versions and test results should reach the final data package without a late document hunt.
| Quality check | Pass condition |
|---|---|
| Inspection plan | Characteristics, methods, stages and acceptance criteria released |
| Hold/witness points | Party, notice, evidence and release authority defined |
| Test procedure | Conditions, instruments, calculations and pass/fail rule approved |
| Nonconformance path | Disposition authority and customer-notification rule known |
| Certificates | Required record, source, item link and due event identified |
| Final data pack | Index, format, language and submission milestone established |
9. Confirm safety, regulatory and site obligations
List the codes, directives, permits, hazardous-area rules, customer standards and internal safety reviews that govern the package. Record the edition and scope. Assign each obligation to a design output, manufacturing control or acceptance record.
Check whether the planned site, supplier and process hold the required qualifications. A drawing release cannot authorize work that needs a qualified weld procedure, licensed design review or customer-approved source the company has not secured.
Include handling, lifting, storage, preservation and transport risks. Large equipment can pass design review and still become unbuildable because the team has no lift plan, shipping split or route for the assembled module.
| Obligation | Release evidence |
|---|---|
| Code/standard | Edition, applicability, owner and verification path |
| Qualified process | Approved procedure, people, equipment and validity |
| Site rule | Customer standard or permit reflected in design and work method |
| Hazard review | Required review completed with actions closed or gated |
| Handling/lifting | Weight, center of gravity, lift points, equipment and method |
| Shipping split | Module size, preservation, packaging and field reassembly plan |
10. Clear the customer inputs and approval gates
List every customer input that affects the package: process data, utility information, interface drawings, site measurements, approved vendors, samples, cybersecurity requirements and document approvals. Confirm receipt, completeness, revision and engineering acceptance.
Do not mark a dependency complete because a file arrived. The owner must decide whether the content supports the released work. Record missing fields and the downstream tasks they block.
Use the contract schedule rules when the customer is late. Preserve the request, due date, reminder, receipt and review outcome. This evidence supports a revised plan and gives commercial change control facts to work from.
| Customer dependency | Ready when | If not ready |
|---|---|---|
| Process/interface data | Engineering accepts complete values and revision | Hold affected design and supply |
| Drawing approval | Authorized response closes comments for the package | Release only work outside approval scope |
| Customer-furnished equipment | Interface and delivery status support the plan | Hold mating work or use approved envelope |
| Site access/readiness | Conditions, dates and responsibilities confirmed | Do not mobilize |
| Witness participation | Date and notice path accepted | Apply contract waiver or reschedule rule |
| Approval delay | Schedule effect recorded and owner assigned | Escalate with evidence |
11. Reconcile cost and authorization before spend starts
Connect the released work to the approved cost baseline. Confirm labor, material, supplier, freight, tooling, testing, installation and contingency treatment. Update supplier costs or effort estimates that changed after the bid.
Check that each early release has commercial authority. The company may accept the risk of buying a long-lead item before customer approval, but the decision needs the value at risk, cancellation terms, technical boundary and approver.
Set the cost codes and budgets that will capture actuals. If the project cannot trace cost back to the estimate and sold scope, it will discover overruns after the money has gone.
| Cost check | Pass condition |
|---|---|
| Baseline | Released cost reconciles to the approved bid and changes |
| Supplier value | Current quote or authorized allowance supports the package |
| Contingency | The baseline names each risk and the person who can draw reserve |
| Early commitment | Amount at risk and cancellation exposure approved |
| Cost collection | WBS, job, operation and purchase coding exists |
| Forecast | First current forecast reflects the released schedule and supply position |
12. Validate the system records the shop will use
Open the actual ERP, PLM, MES, QMS and project records. Confirm order, item, revision, site, quantity, dates, BOM, routing, supplier package, inspection plan and document links. A handover file can be correct while the transaction that drives work remains wrong.
Check the status transition and its side effects. Oracle defines a work order as the authority to produce a specific product. Release can also start material picking. SAP release can make reservations and purchase requisitions active. The approver must understand what the button will trigger.
Record the transaction IDs in the release case. If an integration writes the data, read the created object back and compare it with the approved source. A successful API response does not prove every field, component and date landed correctly.
| System | Record to validate | Material failure |
|---|---|---|
| ERP | Sales/project order, production order, BOM, routing and dates | Wrong product, quantity, site, cost or schedule |
| PLM/PDM | Released item, revision, documents and effectivity | Old or conflicting design reaches execution |
| MES | Operation, instruction, program and data collection | Operator cannot perform or prove the work |
| QMS | Inspection plan, hold point and nonconformance path | Required control or evidence disappears |
| Project system | Package, owner, dependencies and milestone | The release breaks the customer schedule chain |
| Sourcing | Requisition/PO scope and selected supplier basis | Supplier receives wrong revision or terms |
13. Set change control before the first release
Freeze the baseline identity at release. Define how customer requests, engineering discoveries, supplier substitutions and manufacturing deviations will change it. Name the authority for technical, schedule and commercial decisions.
A released drawing can still change, but the new revision must identify affected material, work in process, supplier orders, inspections, documents and customer commitments. State the effective unit, serial range or operation.
Tie technical change to the commercial change path. The project should not absorb an added customer requirement because engineering could implement it quickly.
| Change control check | Pass condition |
|---|---|
| Baseline ID | Released configuration, documents and work package have fixed revisions |
| Change intake | Customer, engineering, supplier and shop requests enter one owned path |
| Impact review | Cost, date, quality, inventory, WIP and customer effect assessed |
| Authority | Technical and commercial approvers are explicit |
| Effectivity | Affected units, lots, orders and operations identified |
| Closure | Every downstream record reflects the approved result |
Use partial release to move without gambling the order
Split the project into packages with stable boundaries. Release standard modules, customer-data requests, approved long-lead components and project setup while dependent custom design waits. The package must state the interfaces and assumptions that make the early work safe.
IFS Project Deliverables connects customer-facing deliverables with shop-order, purchase and project-MRP plans. That separation is useful for the checklist: release a specific supply or manufacturing plan because its deliverable boundary is stable, not because the overall order is “green enough.”
Calculate exposure before an early release. Include committed spend, cancellation charges, rework, obsolete inventory and schedule benefit. Expire the exception at a named event. If a late input crosses the agreed boundary, stop and reopen the decision.
| Package | Can release when | Hold when |
|---|---|---|
| Standard base frame | Loads and interfaces stay inside released envelope | Customer layout can change mounting geometry |
| Long-lead drive | Duty, power, environment and interface are stable | Open process data can change size or protection |
| Controls panel | The customer has approved the I/O count, architecture and standard | Customer network or area classification remains open |
| Fabricated module | Drawing, material, weld and inspection plan released | Approval or interface controls final geometry |
| Project/document setup | Order, owner and required register exist | Rarely blocked by detailed design |
Run the release review from exceptions and evidence
Send the checklist and source links before the meeting. Ask engineering, planning, sourcing, quality, manufacturing, project and finance owners to accept their conditions or raise a blocker. Do not spend the meeting reading every green row.
Review blockers, conditional releases, cross-functional conflicts and actions that the status change will trigger. Let the accountable release owner decide each package after the functional owners present their evidence.
Capture the decision in the work record: object, scope, baseline, status, conditions, approvers, time and downstream actions. Meeting minutes alone rarely state exactly which drawing, operation or purchase package gained authority.
| Review role | Decision owned |
|---|---|
| Engineering | Requirements, configuration, design and interface maturity |
| Planning/operations | Routing, capacity, schedule and execution sequence |
| Sourcing | Supplier scope, commitment and material position |
| Quality | Inspection, test, qualification and record plan |
| Project management | Dependencies, milestones, risk and customer actions |
| Finance/commercial | Spend authority, budget, payment and change exposure |
| Release owner | Final ready, conditional or blocked decision for the package |
Worked example: release a $6.8 million bulk-material handling system
An OEM books a $6.8 million system that receives, screens and transfers abrasive mineral product. The order covers a feed hopper, belt conveyors, magnetic separator, dust extraction, controls, structural steel, FAT, installation supervision and commissioning. The accepted date is 48 weeks after advance payment and approved layout data.
The project contains five release packages. The standard conveyor drives and bearings have long lead times. The structural module depends on customer foundation coordinates. The dust-extraction package depends on final particle data and area classification. The controls panel depends on the customer network standard. Project setup and the document register can start immediately.
The checklist clears the commercial order and Configuration BMHS-420 Rev 1. It allocates 142 requirements and closes the BOM for the standard conveyor modules. Current supplier quotes support the drives, bearings and magnetic separator. The loaded production schedule has capacity for the conveyor frames in week 9. Quality has released the weld plan and inspection points.
The team releases the conveyor drive purchase and standard frame detailing. It conditionally releases the magnetic separator subject to the supplier returning one material certificate before fabrication. It blocks the structural fabrication, dust package and controls panel. Each block names its customer input and affected work.
Six days later the customer submits foundation coordinates. Engineering finds a 120 mm interface shift, updates the arrangement and closes the structural hold before steel cutting. The particle data shows a higher dust load than the quoted basis. The team opens a priced change for the extraction package instead of buying the undersized equipment. Partial release saves four weeks without turning the open inputs into rework.
| Package | Decision | Reason and next action |
|---|---|---|
| Project/document setup | Ready | Accepted order, owner, milestones and register exist |
| Conveyor drives and standard frames | Ready | Stable duty and interface; supplier and capacity confirmed |
| Magnetic separator | Conditional | Release after supplier certificate arrives; no fabrication before acceptance |
| Structural fabrication | Blocked, then ready | Customer coordinates changed interface before steel cutting |
| Dust extraction | Blocked | Particle data exceeds bid basis; price revised package first |
| Controls panel | Blocked | Customer network standard still missing |
Measure whether the release decision held up
Track what happens after release. Count packages stopped for a missing requirement, wrong revision, material shortage, capacity conflict or absent customer input. Measure scrap, rework, expedite cost and days lost back to the failed release condition.
Review conditional releases separately. Compare the schedule time they saved with the exposure they created. If exceptions routinely expire without closure, the company has turned partial release into unmanaged risk.
Use the findings to tighten the checklist where evidence failed. Do not add fields because they sound thorough. Add or change a condition when it would have prevented a real error or made a valid release faster.
| Measure | Calculation | What it finds |
|---|---|---|
| First-pass release rate | Packages released without rework ÷ packages reviewed | Checklist and source quality |
| Post-release stop rate | Released packages later stopped ÷ released packages | False-ready decisions |
| Release-caused rework | Hours and cost traced to missing or wrong release evidence | Financial damage |
| Conditional-release aging | Days open by condition and owner | Exceptions becoming permanent |
| Blocked time | Days each package waits by blocker type | Customer, engineering and supply bottlenecks |
| Early-release benefit | Critical-path days saved by approved partial release | Whether staged release earns its risk |
How Bourne runs the build-ready check
Bourne assembles the released order, configuration, requirements, drawings, BOM, routing, supplier responses, material position, capacity plan, quality controls and customer dependencies for the selected package. Each check points to the source record and current revision.
The workflow applies the company’s mandatory gates, finds missing or conflicting evidence and routes each exception to the person who can decide it. Owners mark the package ready, conditional or blocked. A conditional decision records the permitted work, risk limit, due event and stop point.
After approval, Bourne creates or updates the relevant release state through available APIs or controlled browser workflows, then reads the result back. ERP, PLM, MES and QMS continue to control execution. Bourne connects their evidence and reopens the package when a changed requirement, revision or supplier condition crosses the released boundary.
Buğra Gündüz
Buğra Gündüz is the co-founder and CEO of Bourne and co-founder of HockeyStack. He built HockeyStack into an eight-figure AI business. At Bourne, he works with entrepreneurs and established companies to create AI products and services.