Ship repair project kickoff SOP: specification to work packages
A ship repair project kickoff SOP: specification intake, mechanical/electrical/hydraulic review, PM assignment, work-package breakdown, subcontractor gap-fill, scheduling, and a confirm/revise kickoff before work reaches the workshops.
What the ship repair project kickoff SOP: specification to work packages process is
A repair specification rarely arrives complete enough to schedule against. A customer describes a vibration in the port shaft line or a hydraulic steering fault, not a bill of work, and the yard's own mechanical, electrical and hydraulic leads have to turn that description into scope before anyone can promise a dock date. Skip the technical review, or let one discipline sign off for all three, and the gap surfaces at the worst possible time: mid-repair, with the vessel already off-hire and the missing hydraulic finding turning a two-week job into a five-week one. That is why this chart puts a feasibility decision right after the review, with an explicit loop back to the customer for clarification or a site survey rather than a lead quietly guessing at scope to keep the schedule moving.
The second half of the process is a resourcing problem as much as a technical one. FAYARD's workshops, cranes and dry docks are a shared, finite resource across every live project, so "can we do this in-house" has to be answered discipline by discipline, not once for the whole job. A work package that needs specialist hydraulic testing the yard doesn't carry in-house has to be routed to a subcontractor before it reaches the schedule, not discovered after a berth slot is already booked around it. Risk and safety review sits deliberately late, after the work packages and the schedule exist, because a risk review against an abstract scope produces generic findings; against a dated, resourced set of work packages it produces the findings that actually change the plan.
The kickoff meeting is the process's own approval gate: the customer sees the scope, schedule and price together and either confirms them or sends the project back to revise and reconvene, rather than work starting on an understanding only the yard has agreed to. Because every row in this chart carries a named owner and an estimated workload, the same diagram doubles as the resourcing record: Sales, the three technical-review leads, the project manager, procurement and the workshops each show up with hours against their name, so a PM assigned to three simultaneous repair projects is a number on the workload panel before it is a missed deadline.
What this flowchart covers
In this template
- Five stage lanes, Intake through Technical review, Planning, Kickoff and Execution, crossed by five role lanes including "Technical review", "Project Manager" and "Sales / customer", so every step shows both where it sits in the process and who owns it.
- Intake and the feasibility loop: the specification is logged in the intake register, then "Technical review of scope by mechanical, electrical and hydraulic leads" feeds the decision "Scope complete and technically feasible as specified?", with the No branch routing to "Request clarification or a site survey from the customer" and back into review rather than forward into a schedule.
- Project ownership and scope breakdown: "Assign project manager and project number" precedes "Break scope into work packages by discipline", so a named PM exists before the work is subdivided, not after.
- The make-or-buy decision: "In-house capacity covers all work packages?" branches to "Source and engage a subcontractor for the gap" on No, so a capacity shortfall is resolved before scheduling rather than discovered during it.
- Scheduling and risk: "Schedule workshop resources and dock or berth slot" and "Review project risks and safety requirements" run in sequence in the Planning lane, putting the safety review against a resourced, dated plan instead of an abstract scope.
- The customer kickoff gate: "Hold kickoff meeting with customer and project team" feeds "Customer confirms scope, schedule and price at kickoff?", where Changes requested loops to "Revise scope or schedule and reconvene kickoff" and Confirmed proceeds to "Issue work packages to workshops and open the job in the system".
When to use this template
- A repair specification just came in from a customer or broker and you need a fixed sequence for turning it into a costed, scheduled project rather than an ad hoc set of emails between sales, the technical leads and the PM.
- Vessels are arriving with vaguer specifications than the yard can schedule against, and scope keeps getting clarified after the dock slot is already booked instead of before.
- You need a standard make-or-buy checkpoint for deciding when a work package goes to an in-house workshop versus a subcontractor, so the decision is made once, on record, rather than negotiated project by project.
- A customer kickoff meeting has, more than once, surfaced a scope or price disagreement after work had already started, and you want a documented confirm-or-revise gate before workshops open the job.
- You are onboarding a new project manager or technical lead and need one diagram that shows how a specification becomes an assigned PM, a set of work packages, a schedule and an issued job.
How it works
Match the lanes to your own department names
The five role lanes here, Sales / customer, Technical review, Project Manager, Procurement and Workshops, map to how FAYARD is organized. If your yard splits technical review into separate mechanical, electrical and hydraulic lanes instead of one shared lane, add them; if procurement and the PM are the same person on smaller jobs, merge the lanes rather than drawing a handoff that doesn't happen.
Name the people, not just the roles, on each step
Put a real person on the People column for every row, and a realistic workload estimate in hours next to it, the way "Technical review of scope by mechanical, electrical and hydraulic leads" carries three named leads and a combined estimate. That is what lets the workload BI panel show you a lead double-booked across two live kickoffs before it shows up as a missed review date.
Write the feasibility criteria behind the first decision
"Scope complete and technically feasible as specified?" is only a useful gate if the leads share a written standard for what counts as complete: drawings, tolerances, access constraints, prior survey data. Without it, the decision becomes a judgment call that varies by which lead reviews it, and the clarification loop gets used inconsistently.
Set the rule for when a work package goes to a subcontractor
"In-house capacity covers all work packages?" should route on a documented rule, not a gut check: named skills the yard doesn't carry, a workshop already booked past capacity for the dock window, or a specialist test the yard doesn't run in-house. Record the rule next to the decision so a PM under schedule pressure can't quietly skip the subcontractor step to keep a date.
Fix what "confirmed" means at kickoff before you use the chart
"Customer confirms scope, schedule and price at kickoff?" needs the same three things on the table every time: the work packages, the dock or berth dates, and the price. If the customer only ever sees one of the three at the meeting, the Confirmed branch is worthless as an approval and disputes will surface later, during execution, instead of here.
Keep the chart live as the project's system of record
Because the diagram already carries owners and workload per step, keep it updated through execution rather than treating it as a one-time kickoff artifact: an added work package or a reassigned lead belongs on the same chart, versioned, so the workload panel and the schedule never drift from what's actually happening in the yard.
Frequently asked questions
Why does the technical review need three separate disciplines and one decision?
Because a ship repair specification is rarely single-discipline in practice, even when it reads that way: a hydraulic steering fault often has an electrical control component and a mechanical linkage component behind it. Reviewing with mechanical, electrical and hydraulic leads together, then gating on one shared feasibility decision, is what catches the cross-discipline finding before it becomes a mid-repair surprise. Splitting the review into three separate sign-offs with no shared decision is the usual way a yard ends up with three disciplines each confident the scope is complete and no one who checked it as a whole.
Why does the make-or-buy decision come after the work-package breakdown, not before?
Because "in-house capacity covers all work packages?" can only be answered discipline by discipline, against real work packages with real hours attached, not against the specification as a whole. Breaking the scope into work packages first is what turns "can we do this ourselves" from a guess into a checklist: each package either fits an available workshop and skill set or it doesn't, and only the packages that don't need to go to a subcontractor.
What happens if the customer doesn't confirm at the kickoff meeting?
The chart routes Changes requested to "Revise scope or schedule and reconvene kickoff", which loops back into the risk review stage rather than into execution. That matters because a revised scope or schedule can change the risk picture, the resourcing, or both, so the process re-enters planning instead of quietly patching the disagreement and moving straight to issuing work packages.
Where does subcontractor work rejoin the main schedule?
"Source and engage a subcontractor for the gap" feeds directly into "Schedule workshop resources and dock or berth slot", the same step the in-house path reaches on a Yes answer. That keeps scheduling as one step that accounts for both in-house and subcontracted work packages together, rather than two separate schedules that have to be reconciled later against a single dry dock or berth window.
How does this differ from a general project change request process?
This SOP is about starting a repair project, from a customer's specification to an issued, resourced job; a change request process governs altering scope, cost or schedule after a project is already underway and baselined. The kickoff meeting here is the point where scope, schedule and price are agreed for the first time. Any change after that point, once workshops have opened the job, belongs in a separate change control process rather than in a revised kickoff.
Why put workload estimates on individual rows instead of one total on the project?
A single project-level hour estimate hides exactly the information a PM needs during kickoff: whether Sales, a specific technical lead, procurement or a workshop is the bottleneck. Per-row workload, rolled up by the workload BI panel, shows a project manager or a hydraulic lead carrying hours across several concurrent kickoffs before that shows up as a slipped review date, which is the earlier and cheaper point to catch it.
Where this process fits
In most operations this process follows Dry docking and undocking SOP: block plan to refloat and hands off to Shipyard subcontractor onboarding SOP: induction to checkout.
It is one step in Ship repair.
Step 2: Dry docking and undocking SOP: block plan to refloat
A shipyard SOP for dry docking and undocking a vessel: block plan verification, controlled dewatering, a stability check, dry-period repair work, and refloat, with an owner and workload hours on every step.
Step 3: Ship repair project kickoff SOP: specification to work packages You are here
A ship repair project kickoff SOP: specification intake, mechanical/electrical/hydraulic review, PM assignment, work-package breakdown, subcontractor gap-fill, scheduling, and a confirm/revise kickoff before work reaches the workshops.
Step 4: Shipyard subcontractor onboarding SOP: induction to checkout
A shipyard subcontractor onboarding SOP for ship repair yards: document and insurance verification, a pass/fail safety induction, access and PPE issue, a hot work or confined space permit decision, supervised work and checkout.
Step 6: Vessel repair handover SOP: completion review to departure