Before structural-steel fabrication moves to the next project-defined production step, the EPC buyer needs a clear answer to one practical question: are the inputs, document versions, decision owners and unresolved questions visible enough for the project to make its own decision?

This checklist is an editorial decision-support tool for international EPC procurement, package engineering, project controls and QA/QC coordination teams. It does not authorize production, establish a hold point, assign contractual responsibility or replace the project’s contract, specifications, controlled documents or approval process. Those sources remain authoritative. The checklist simply helps a buyer record what is confirmed, what is pending, and who must decide the next step.

Start with a project-defined decision, not a generic “release”

“Production start” can mean different things on different projects. It may refer to one package, a defined group of members, a limited preliminary activity or another milestone set by the project. Do not assume that it means a universal notice-to-proceed, material purchase instruction, fabrication release or final acceptance.

At the kickoff meeting, ask the project to define:

  • the package, assemblies or work scope the decision covers;
  • the next step under consideration;
  • the project documents that govern the decision;
  • the person or role authorized to confirm the project’s position; and
  • any conditions, limits or open items that still apply.

The result can be recorded using project-defined states such as confirmed, pending, blocked or conditionally released. These are examples for a decision log, not mandatory labels. A conditional next step should be used only where the authorized project party has documented its conditions and scope.

What the kickoff checklist is designed to make visible

The useful purpose of a kickoff is not to repeat every design, quality or schedule activity. It is to bring together the specific inputs that affect the project’s next decision and make their status traceable. The following categories are prompts to confirm where applicable; they are not a universal list of fabrication requirements.

1. Package boundary and scope record

Confirm which package, assemblies or member range the meeting covers and which project record describes that boundary. Where the project uses exclusions, assumptions or change-control records, identify the current controlled reference and the person who can clarify a conflict. Do not use the checklist to reopen settled commercial terms or infer that another party owns an unresolved item.

2. Controlled drawings and document versions

Record the drawing, model, schedule, list or other input reference the project expects the team to use, together with its revision identifier if the project has one. The point is not to decide which engineering document ought to govern; it is to expose whether the project has identified the applicable source and document-control route. If the references are incomplete or inconsistent, record the question rather than choosing a version by assumption.

3. Interfaces and technical inputs

For each known civil, mechanical, installation or package interface, identify the project input that is required for the next decision, the party expected to confirm it and the document or route used to close the question. This article does not prescribe loads, connections, tolerances, materials, detailing methods or technical acceptance criteria. Those items must come from project-controlled information or an appropriately authorized technical decision.

4. Material-list and package-reference inputs

If the project uses a material list, member schedule, bill of materials or package register, note the relevant reference and its current status. The checklist should not claim that a particular list is complete, correct or universally required. Its job is to show whether the project has identified the reference needed for the intended next step and whether a missing or conflicting item has an owner and escalation path.

5. Programme and decision timing

The team may need to identify the project schedule baseline, decision date or milestone relevant to the package. This is not a promise of fabrication duration, delivery timing or project outcome. It is a way to ensure that an open decision has a visible project deadline and that the people responsible for resolving it understand the timing context.

6. Quality-document and review route

Where the project expects quality documents, inspection planning, review comments or other records to inform the next step, capture the route and source reference. Do not turn this article into an inspection-and-test plan or assert an inspection rule, standard, certificate or acceptance outcome. The project’s approved quality documentation and procedures define any such requirements.

7. Decision ownership and escalation

Every open item should have a project role that can confirm, assign or escalate it. The role may differ across projects and may not be the same as the party preparing a drawing, supplying a package or attending the meeting. Keep the ownership field project-specific, and record how the question will be returned, escalated or closed.

A buyer-facing fabrication kickoff decision log

Use a controlled project format where one exists. The table below is an editorial template that makes the minimum decision information visible. Bracketed fields must be completed or adapted by the project; they are not default contractual allocations.

Fabrication kickoff decision log
Topic to recordScope or package affectedProject source / revisionStatusProject role to confirmDecision pointOpen item, condition or escalation routeClosing evidence or reference
Package boundary[Project-defined package or range][Controlled reference]Confirmed / pending / blocked / conditional[Named project role][Project-defined date or gate][Question, condition or route][Project-controlled record]
Drawing or input version[Affected scope][Document number and revision, if used]Confirmed / pending / blocked / conditional[Named project role][Project-defined date or gate][Question, condition or route][Project-controlled record]
Interface input[Affected scope][Controlled reference]Confirmed / pending / blocked / conditional[Named project role][Project-defined date or gate][Question, condition or route][Project-controlled record]
Material-list or package reference[Affected scope][Controlled reference]Confirmed / pending / blocked / conditional[Named project role][Project-defined date or gate][Question, condition or route][Project-controlled record]
Programme context[Affected scope][Project schedule reference, if applicable]Confirmed / pending / blocked / conditional[Named project role][Project-defined date or gate][Question, condition or route][Project-controlled record]
Quality-document route[Affected scope][Project-controlled reference]Confirmed / pending / blocked / conditional[Named project role][Project-defined date or gate][Question, condition or route][Project-controlled record]

The log should include the applicable package or member range, reference version, confirmation date and closing evidence so that the project can distinguish a documented decision from an informal meeting note. If a record is not available, the correct status is open—not silently complete.

Route unresolved items without turning the kickoff into another checklist

An unresolved item does not always have to stop every activity, but it should be visible and handled according to the project’s authority and documents. Use the decision log to describe the gap and its route; do not invent a universal sequence.

  • If the question concerns the original RFQ inputs or package references, direct the team to the project’s steel-structure RFQ package guide as a contextual source for the RFQ package record.
  • If the question concerns a scope version, exclusion or clarification that the project needs to document, direct it to the scope-freeze checklist as a related record. This does not imply that the RFQ must be reopened.
  • If the question concerns schedule context or a project milestone, use the fabrication schedule checklist as a contextual route. It does not establish a delivery promise or programme result.
  • If the question concerns the project’s planned quality-document or inspection route, use the inspection and test plan checklist for related planning material. It does not define inspection requirements or acceptance criteria for this package.

These links are intended to help readers locate related decision-support material. Before production integration, confirm that each destination is appropriate and available in the current project release.

Final buyer review before the project’s next step

Use these questions to prepare for the project’s own authorization decision:

  1. Is the affected package or member range explicitly named?
  2. Are the project-controlled inputs and their applicable versions recorded rather than assumed?
  3. Does every open item have a project role, decision point and route for escalation or closure?
  4. Are confirmed items, pending items, blocked items and any authorized conditional items clearly distinguished?
  5. Does the meeting record state which project party may decide the next step and what document provides that authority?

If any answer is unclear, the next action is to record the gap, retain the appropriate status and obtain project direction. The checklist should make uncertainty easier to see; it should not convert uncertainty into an unsupported approval.

Limits and next step

This article is a buyer-oriented editorial checklist for a post-award, pre-production coordination meeting. It is not a contract, technical specification, fabrication schedule, inspection-and-test plan, quality procedure or production-release authorization. It makes no claim about standards, certifications, supplier capability, cost, programme, production performance or project outcome.

The next step is to use the project’s controlled format to record the agreed scope, input references, decision owners and open items, then obtain direction from the party authorized by the project documents to decide whether and how the next step may proceed.