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.
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.