4. Statement of work (SOW) development

A Statement of Work (SOW) is the single most consequential document in a CAE outsourcing program. It converts a business intent — "we need crash simulation support" — into a measurable, enforceable, and auditable scope. When a SOW is vague, every downstream dispute (missing load cases, incompatible meshes, disputed pass/fail judgments) traces back to it. This chapter focuses on the three technical pillars that determine whether a CAE SOW is executable: deliverables, acceptance criteria, and model handover formats.

From Scope Statement to Deliverable Register

A scope statement such as "perform full-vehicle frontal impact CAE" is not a deliverable. A deliverable is a named, versioned, reviewable artifact with a defined content boundary. The practical technique is to decompose the scope into a deliverable register — a table that maps each work product to its format, timing, and owner.

For a typical frontal offset crash program, the register might include: the updated full-vehicle CAE model (assembled, with boundary conditions applied), the solver deck and result files for each load case, a correlation report against physical test data, a design-variant comparison matrix, and a final summary presentation. Each entry must specify whether it is a draft for review or a final release, because acceptance criteria differ between the two.

The register forces both parties to agree on what "done" means before work begins. It also prevents the common failure mode where a supplier delivers a solver deck but no result files, or delivers results without the model that produced them.

Acceptance Criteria: Making "Pass" Objective

Acceptance criteria must be written so that two independent engineers, given the same deliverable, reach the same accept/reject decision. This requires numeric thresholds, defined measurement locations, and specified evaluation methods.

Consider a requirement for occupant compartment integrity in a frontal offset test. A weak criterion is "no excessive intrusion." A strong criterion is: "Maximum intrusion at the brake pedal reference point shall not exceed 120 mm, measured along the vehicle X-axis in the global coordinate system, evaluated at the time of peak occupant load." The strong version specifies the metric, the location, the coordinate convention, the threshold, and the evaluation time.

Acceptance criteria should also address model quality, not just results. Typical model-quality gates include: no negative volume elements at initialization, initial penetration below 0.5 mm for all contact interfaces, mass scaling below 5% of total kinetic energy, and hourglass energy below 5% of internal energy. These are checked before any result is considered valid.

For correlation deliverables, criteria should define the correlation metric and the acceptable band. For example: "The chest acceleration curve shall achieve a CORA rating of at least 0.80 in the 0–120 ms window, and peak chest acceleration shall be within ±15% of the physical test value." This makes the correlation report itself subject to objective acceptance.

Model Handover Formats: The Technical Contract

Model handover is where CAE outsourcing programs most often fail. A supplier may deliver a model that runs, but the OEM cannot open it, cannot trace the include structure, or cannot reproduce the boundary conditions. The SOW must therefore define the handover format as precisely as the deliverables themselves.

Key format decisions include:

• Solver and version: LS-DYNA R13.1, double precision, SMP. Specify the exact version because keyword support and contact behavior change between releases.
• Include structure: A single master main.k that references sub-includes by relative path, with a documented directory tree. No absolute paths.
• Units: mm, ton, s, N, MPa. State this explicitly; unit inconsistency is a silent killer in crash models.
• Part and material naming: A naming convention that maps each part to its CAD part number and material specification.
• Boundary condition documentation: A separate BC_readme.txt or equivalent that lists every prescribed velocity, constraint, and initial condition with its source.
• Result file set: Which output blocks are required (d3plot, binout, glstat, matsum, rcforc) and at what output interval.

The handover package should also include a model run log: the exact solver command line, the number of CPUs, the wall-clock time, and the termination status. This allows the receiving engineer to reproduce the run and verify that the delivered results correspond to the delivered model.

Structuring the SOW for Enforcement

The three pillars — deliverables, acceptance criteria, and handover formats — should be cross-referenced. Each deliverable in the register should point to the acceptance criteria that govern it and the handover format that defines its structure. This creates a traceable chain from scope to verification.

A practical SOW also defines the review and rejection cycle. If a deliverable fails acceptance, the supplier has a defined window (e.g., 10 business days) to correct and resubmit. The SOW should state whether re-review is billable and how many cycles are included in the fixed price. Without this, rejection becomes a commercial negotiation rather than a technical process.

Practical SOW Development Sequence

In practice, the SOW is built in a sequence that mirrors the traceability chain. First, the engineering team defines the load cases and the physical test data available for correlation. Second, they derive the deliverable register from those load cases. Third, they write acceptance criteria for each deliverable, referencing the physical test values and the model-quality gates. Fourth, they specify the handover format, including solver version, include structure, and documentation requirements. Finally, they define the review cycle and the consequences of rejection.

This sequence matters because acceptance criteria cannot be written without knowing the physical test data, and handover formats cannot be written without knowing which solver features the model uses. Attempting to write the SOW in a different order produces criteria that are either unmeasurable or unenforceable.

A well-developed SOW does not eliminate all disputes, but it ensures that disputes are technical rather than interpretive. When a supplier claims a deliverable is complete and the OEM disagrees, the SOW provides the shared reference that resolves the question: the deliverable register defines what was promised, the acceptance criteria define what "complete" means, and the handover format defines what the OEM should have received. That is the standard against which CAE outsourcing programs should be measured.