Ship repair project kickoff process map

What is in this map

16 steps across 5 swimlanes and 5 phases, with 3 decision points.

Swimlanes (who does the work)

Sales / customer, Technical review, Project Manager, Procurement and Workshops

Phases (left to right)

Intake, Technical review, Planning, Kickoff and Execution

Why map this process

Most kickoff failures are not technical — they are scope that was never actually confirmed before work started. This map puts a confirmation decision at the kickoff meeting itself, with a named loop back to revise scope or schedule, because 'we discussed it' and 'the customer confirmed scope, schedule and price' are different states and only one of them should let work begin.

Splitting scope into work packages is what turns a specification document into a plannable job. Each package gets an owner, a workshop and estimated hours, which is also what makes the in-house-capacity decision answerable: without packages, 'do we have capacity' is a guess about the whole project; with them, it is a specific answer about which package needs a subcontractor.

Every step in the map

This is the spreadsheet behind the diagram. The numbers in “Goes to” are row numbers, which is exactly what the editor’s “Line to” column holds — so you can read the flow here and retype any part of it.

The decision points

Every branch in the map, with the label on each outgoing line. These are the questions the process has to be able to answer.

• 4. Scope complete and technically **feasible** as specified?

  Owned by Technical review · Technical review

  • Yes → step 6
  • No → step 5

• 8. In-house capacity covers all *work packages*?

  Owned by Project Manager · Planning

  • Yes → step 10
  • No → step 9

• 13. Customer **confirms scope, schedule and price** at kickoff?

  Owned by Project Manager · Kickoff

  • Confirmed → step 15
  • Changes requested → step 14

Notes on specific steps

These notes travel with the map. In the editor they live in the Notes column and appear when you open a box.

7. Break scope into *work packages* by discipline

Each package gets its own owner, workshop and estimated hours, so 'the electrical scope' becomes a set of numbered jobs someone can actually be held to rather than a paragraph in the contract.

Making it yours

Work packages are rows, not a separate document: the work-breakdown step is where scope becomes 'the electrical package', 'the hydraulic package', and so on, each pointed at its own Line to target. When you adapt this map for your own yard, resist the urge to describe the technical review in more detail than the chart needs — its job is to answer one question, feasibility, and the actual review criteria belong in the Notes column rather than as additional rows, since the reader adapting this map wants to see the decision, not your standard checklist for making it.

What to watch out for

• The scope-clarification loop sends the process back to technical review, not back to intake. If a customer's specification is incomplete, re-reviewing a clarified scope is a different action from re-logging a new request, and merging the two loses the distinction between 'we don't understand it yet' and 'we haven't received it yet'.
• Do not skip the in-house-capacity decision even when your yard almost always has capacity. The subcontractor-engagement branch is what makes the schedule that follows it honest — a plan built assuming in-house capacity that later needs a subcontractor is a plan that was wrong from the kickoff meeting onward.
• Kickoff has to be able to fail. If holding the kickoff meeting flows straight into issuing work packages with no decision in between, the map is claiming every kickoff meeting ends in agreement, which is exactly the assumption that produces a project executing against scope the customer never actually confirmed.

Frequently asked questions