3. Project initiation for CAE

Project initiation is where a CAE engagement either gains a solid foundation or inherits problems that surface months later as missed deadlines, scope disputes, and rework. For an automotive CAE project, initiation is not a single kickoff meeting; it is a structured sequence of decisions that converts a vehicle program's performance targets into a bounded, resourced, and contractually agreed simulation scope. This chapter walks through the four artifacts that define that foundation: the scope definition, the CAE work breakdown structure (WBS), the resource estimate, and the statement of work (SOW).

3.1 Scope Definition: From Vehicle Targets to Simulation Boundaries

Scope definition answers a deceptively simple question: which CAE deliverables will this project produce, and which will it explicitly not produce? In automotive practice, scope is derived top-down from program milestones and attribute targets. A typical body-in-white (BIW) program might carry targets such as a first torsional mode above 45 Hz, a global bending stiffness of 28 kN/mm, and a frontal crash pulse within a specified corridor. Each target implies a set of load cases, and each load case implies models, boundary conditions, and acceptance criteria.

The practical technique is to build a scope matrix that maps program attributes to CAE load cases and marks each as in-scope, out-of-scope, or deferred. Consider a simplified example for a BIW durability and NVH scope:

Two boundaries deserve explicit attention. First, the model fidelity boundary: will the crash model include a detailed powertrain, or a lumped mass representation? This single decision can change model size by a factor of three and runtime by an order of magnitude. Second, the design freeze boundary: scope must state which CAD data release the CAE model is based on (for example, "CATIA data release R3, dated 2025-03-15"). Without this, results become unverifiable the moment the geometry changes.

3.2 CAE Work Breakdown Structure

The WBS decomposes the agreed scope into manageable work packages that can be estimated, scheduled, and assigned. A CAE WBS is typically organized by deliverable and load case rather than by department, because CAE work is naturally deliverable-oriented. A three-level structure for a BIW NVH and crash project might look like this:

• 1.0 BIW CAE Delivery
  • 1.1 Model build
    • 1.1.1 Geometry cleanup and midsurfacing
    • 1.1.2 Mesh generation and quality check
    • 1.1.3 Connections (spot welds, adhesives, seams)
    • 1.1.4 Material and section assignment
  • 1.2 NVH analysis
    • 1.2.1 Static stiffness (torsion, bending)
    • 1.2.2 Normal modes
    • 1.2.3 Forced response (if in scope)
  • 1.3 Crash analysis
    • 1.3.1 Full frontal model setup
    • 1.3.2 Solver run and stabilization
    • 1.3.3 Pulse and intrusion post-processing
  • 1.4 Reporting and design recommendations

Each leaf work package should be estimable in person-days and have a single accountable owner. A common failure mode is a WBS that stops at "1.2 NVH analysis" — too coarse to estimate, too vague to track. The rule of thumb is the 8/80 rule: no leaf package smaller than 8 hours or larger than 80 hours of effort. Packages exceeding 80 hours should be decomposed further.

3.3 Resource Estimation

Resource estimation converts the WBS into people, compute, and time. For CAE, three resource categories dominate:

1. Engineering effort — measured in person-days per work package. A midsurfacing and meshing package for a full BIW (roughly 8–12 million elements) commonly consumes 15–25 person-days depending on geometry quality and automation level.
2. Compute resources — measured in core-hours and wall-clock time. A 10-million-element explicit crash run on 64 cores may take 8–14 hours wall-clock; a normal modes run on the same model may take 20–40 minutes.
3. Software licenses — solver tokens, pre/post-processor seats, and any optimization tools, tracked against concurrent usage peaks.

A practical estimation table for the NVH and crash scope above might read:

These figures are illustrative and must be calibrated against your team's historical data. The critical estimation discipline is to separate effort from duration: 68 person-days does not mean 68 calendar days if two engineers work in parallel. It also does not mean 10 weeks of continuous work — dependencies (model build must precede analysis) and review gates create idle time that must be planned explicitly.

3.4 Statement of Work

The SOW is the contractual translation of scope, WBS, and resources. It is the document that protects both the CAE team and the customer when priorities shift. A robust CAE SOW contains, at minimum:

• Deliverables list — each report, model, and dataset, with format (e.g., Nastran .bdf, LS-DYNA .k, PowerPoint report) and delivery date.
• Acceptance criteria — the measurable conditions under which a deliverable is considered complete (e.g., "mesh quality: 95% of elements with Jacobian ≥ 0.6").
• Input dependencies — CAD release, material cards, load cases, and boundary conditions the customer must provide, with dates.
• Assumptions and exclusions — carried directly from the scope matrix.
• Change control — how scope changes are requested, estimated, and approved, including the impact on schedule and cost.
• Review gates — model freeze review, results review, and final delivery review, with named participants.

The SOW should also state the coordinate system and unit conventions used throughout the project. Automotive CAE commonly uses millimeters, tonnes, seconds, and Newtons (mm-tonne-s-N) for crash, and millimeters, kilograms, seconds for NVH — mixing these silently is a classic source of catastrophic unit errors. State the convention once, and reference it in every deliverable.

3.5 How the Four Artifacts Interlock

Scope, WBS, resources, and SOW are not sequential documents; they are four views of the same commitment. Scope defines what; WBS defines how it is decomposed; resources define what it costs; SOW defines what is agreed. The diagram below shows how a program target flows through these four artifacts into a signed, resourced plan.

The feedback loop is the part teams most often omit. When a design change arrives — and in automotive programs it always does — the scope matrix must be revisited, affected WBS packages re-estimated, and the SOW revised through change control. A CAE plan without a defined change path is a plan that will be silently overrun.

3.6 Practical Initiation Checklist

Before the kickoff meeting, confirm the following are complete and mutually consistent:

• Scope matrix lists every load case with an explicit in/out/deferred status and a measurable acceptance criterion.
• CAD data release is named and dated; model fidelity decisions (lumped masses, weld representation) are documented.
• WBS leaves are sized between 8 and 80 hours and each has one accountable owner.
• Effort, compute, and license estimates are separated and calibrated against historical data.
• SOW includes deliverables, acceptance criteria, input dependencies with dates, assumptions, change control, and review gates.
• Unit and coordinate conventions are stated once and referenced everywhere.

When these six conditions hold, the CAE project has a defensible baseline. Everything that follows — scheduling, execution, tracking, and delivery — depends on the quality of this initiation work. A weak scope or an uncalibrated estimate cannot be rescued by good simulation later; it can only be absorbed as overtime and rework.