Should Cost Modeling in PLM: Design-to-Cost, Parametric Costing and BOM Rollups

Most product cost is decided long before anyone asks for a quote. Design choices made in the first weeks, such as material, tolerance class, part count and process route, lock in the large majority of what the product will cost to build, and the commonly cited industry rule of thumb is that this lock-in is on the order of 70 to 80 percent by the end of concept design (a heuristic, not a law). Yet in many companies cost lives in a spreadsheet owned by finance, refreshed quarterly, and disconnected from the CAD and bill of materials where the decisions are actually made. Engineers learn that a part was too expensive only when a purchase order bounces back.

Should cost modeling closes that loop. It estimates what a part or assembly ought to cost given its geometry, material, process and a reasonable supplier, and it does so inside the PLM backbone, against the same BOM and change records the engineers already use. This article explains how to build that capability: the three families of cost models, the mechanics of a BOM cost rollup with effectivity and quantity breaks, the discipline of comparing a should-cost figure with a supplier quote, and how to attach cost to CAD features and engineering changes.

What this covers: design-to-cost as a process, analogous, parametric and bottom-up models, rollup mechanics with SQL and Python, quote teardown, uncertainty ranges, a worked illustrative example, failure modes, and a rollout checklist.

Context and Background

Cost engineering is an old discipline with a precise vocabulary. In United States federal procurement, the Federal Acquisition Regulation separates price analysis, which evaluates a proposed price without examining its separate cost elements, from cost analysis, which reviews the separate cost elements and profit in a proposal to judge how well they represent what the work should cost under reasonable economy and efficiency. FAR 15.404-1 lists parametric estimating methods and rough yardsticks such as dollars per pound among the price-analysis techniques, and it lists parametric models and cost-estimating relationships among the cost-analysis techniques (FAR 15.404-1). The same distinction maps cleanly onto commercial practice: a quote comparison is price analysis, and a should-cost model is cost analysis performed by the buyer before the supplier speaks.

Three terms are easy to conflate, so it helps to pin them down.

Target costing works backwards from the market. A target selling price minus the required margin yields an allowable cost, and that allowable cost is allocated to subsystems and components as a budget.
Design-to-cost (DTC) is the engineering process that treats the cost target as a design requirement alongside mass, power and reliability. It uses cost estimates at each design gate and triggers redesign when the estimate exceeds budget.
Should-cost is the estimate itself: a bottom-up reconstruction of what a part should cost, built from material, process time, labor and machine rates, overhead, and a reasonable profit. It is contrasted with the quote, which is what the supplier will charge. Vendors of cost-modeling software describe should-cost as a bottom-up method that breaks costs into granular elements and sums them, then use the result to anchor negotiations in data rather than in the assertion that a price is too high (aPriori overview).

The PLM angle is what makes this article different from a procurement primer. A PLM system owns the structure (the BOM), the geometry (CAD and its feature tree), the lifecycle state, and the change record. A cost model that reads those four things directly stays in sync with the design, whereas a cost model in a spreadsheet drifts the moment a part number is revised. The existing posts on EBOM to MBOM transformation and on engineering change management with effectivity describe the structures this article builds on, so those mechanics are summarised rather than repeated.

Why does this matter more in 2026 than it did a decade ago? Three pressures stack up. Component and commodity prices have been volatile enough that a price list from last year is a weak yardstick. Product variety has grown, which multiplies the number of BOM variants that need a cost. And procurement teams increasingly expect engineers to arrive at the table with a defensible number, not a hunch. A cost model embedded in PLM is the only approach that scales across thousands of parts without a standing army of analysts.

From Target Cost to Released Design: The Design-to-Cost Reference Architecture

Direct answer: Design-to-cost is a closed loop. A target price and margin yield a target cost, the target cost is budgeted across subsystems, each design iteration is costed with a model whose fidelity matches the design’s maturity, and any gap against budget triggers cost-reduction levers before release. After release, supplier quotes are compared against the should-cost figure to drive negotiation or redesign.

Figure 1: The design-to-cost loop. The cost model sits between the CAD/BOM design and the release gate, and the same model is reused after release as the should-cost reference for supplier quotes.

The figure shows two loops sharing one model. The inner loop is design-time: concept, cost estimate, decision, and either a lever pull or a release. The outer loop begins at release, when a quote arrives and is compared against the very estimate that approved the design. Reusing the model is the crucial point. If the design-time estimate and the negotiation-time should-cost come from different tools, the numbers will disagree for reasons nobody can trace, and the credibility of both collapses.

Step 1: Derive and allocate the target cost

The arithmetic is simple, and the discipline is in doing it explicitly. Suppose (illustrative) a product must sell at a target price of 1,000 currency units through a channel that takes 30 percent, and the company requires a 25 percent gross margin on its net revenue. Net revenue is 700, the allowed cost of goods sold is 525, and that 525 is the product’s target cost. Allocation then splits the 525 across functions or subsystems, usually informed by the cost shares of a predecessor product or a benchmark teardown. If the predecessor’s power electronics took 22 percent of its cost, the new budget starts near 22 percent of 525, roughly 115, and is adjusted for scope changes.

Allocation is a negotiation between systems engineering and finance, and it should be stored as data. In PLM terms, each node of the product structure at the budgeting level carries a target_cost attribute, and the rollup compares the estimated cost of that node’s subtree against it. A subsystem that overruns by 8 percent is a visible, queryable fact rather than a conversation in a hallway.

Step 2: Match model fidelity to design maturity

Early in design there is no geometry to cost, so the model must be coarse. Late in design there is a full CAD model, so the model can be fine. The mistake is applying a fine model early (false precision, wasted effort) or a coarse model late (missing the cost drivers that matter). The table below summarises the match.

Design stage	Available inputs	Appropriate model	Typical uncertainty (illustrative)
Concept	Function, rough mass, comparable product	Analogous	wide, plus or minus 30 to 50 percent
Preliminary design	Material, envelope, process family, volume	Parametric	plus or minus 15 to 30 percent
Detailed design	Full CAD, tolerances, finishes, routings	Bottom-up, feature-based	plus or minus 5 to 15 percent
Post-quote	Supplier quote, line items	Quote teardown against should-cost	gap analysis, not an estimate

The uncertainty ranges are illustrative planning values, not published benchmarks; every organisation should calibrate its own by comparing past estimates against actual purchase prices. Calibration is itself a PLM feature: if estimates and actuals are stored against the same part number and revision, the error distribution per model type falls out of a simple query.

Step 3: Pull cost levers with a ranked list

When the estimate exceeds budget, teams need a ranked set of levers, not a brainstorm. Typical levers include part-count reduction through integration, material substitution, relaxing non-critical tolerances, process change (for example casting plus light machining in place of machining from billet), standardising fasteners and purchased parts, and re-sourcing. Each lever has a cost effect and an engineering risk. Recording the lever, the estimated saving and the decision on the change record builds an institutional memory that later programmes can query. The same lever data feeds the change-order linkage discussed later in this article.

Why the loop usually breaks in practice

Three breaks recur. First, the target cost is set once and never revised when scope changes, so the budget becomes fiction. Second, the cost model is owned by a separate group and fed manually, so estimates lag the design by weeks. Third, nobody records which assumptions (volume, region, supplier tier) sat behind an estimate, so a later quote cannot be reconciled against it. The architecture in this article addresses each by making the budget, the model inputs and the assumptions first-class records attached to the product structure.

The Three Families of Cost Model

Every cost model in practice is one of three kinds, or a hybrid. Understanding what each one assumes, and where each one lies, is more valuable than knowing any particular tool.

Analogous estimating

An analogous model scales the known cost of a similar item. If last year’s 4 kW inverter cost 180 to build, and the new one is 6 kW with similar topology, an analogous estimate might scale by a power exponent and add adjustments for new features. Its strength is speed: it needs no geometry and works at the concept gate. Its weakness is that it inherits every hidden assumption of the reference, including the reference’s supplier, volume and vintage.

In PLM, analogous estimating is a similarity search over the part and product catalogue. The useful implementation stores, for every costed item, a normalised feature vector (mass, material class, process family, size envelope, tolerance class, annual volume) and the actual cost with its date. A nearest-neighbour query then returns candidates with an inflation or commodity adjustment applied. The adjustment matters: a four-year-old aluminium part cost needs the aluminium index movement applied to its material share, not a flat inflation factor on the whole price.

Parametric estimating

A parametric model expresses cost as a function of a few drivers using a cost-estimating relationship (CER). The canonical form is a power law, cost = a x (driver)^b, fitted by regression on historical data. Because it is linear after taking logarithms, ordinary least squares applies: ln(cost) = ln(a) + b ln(driver). The exponent b captures economies of scale: b below 1 means cost grows more slowly than the driver, which is typical of size-driven items such as castings or pressure vessels.

Parametric models are explicitly recognised as legitimate estimating methods in procurement regulation; FAR 15.404-1 lists them in both the price-analysis and cost-analysis technique lists. The United States Government Accountability Office’s Cost Estimating and Assessment Guide (GAO-20-195G, March 2020) sets out best practices for building reliable cost estimates and, in its chapters on estimating methodologies, discusses analogy, engineering build-up and parametric approaches (GAO-20-195G). The GAO guidance is written for large government programmes, but the logic transfers to commercial product cost: the credibility of a CER depends on the quality, relevance and homogeneity of the data behind it.

Here is a compact, runnable fit of a power-law CER with a prediction interval, suitable for a nightly calibration job. The data are synthetic and generated inside the script purely to demonstrate the mechanics.

import numpy as np

rng = np.random.default_rng(42)

# Synthetic history: finished mass in kg vs purchased unit price (illustrative only)
mass = rng.uniform(0.2, 6.0, 80)
true_a, true_b = 14.0, 0.72
price = true_a * mass**true_b * rng.lognormal(0.0, 0.12, mass.size)

# Fit ln(price) = ln(a) + b ln(mass)
X = np.column_stack([np.ones_like(mass), np.log(mass)])
y = np.log(price)
beta, *_ = np.linalg.lstsq(X, y, rcond=None)
ln_a, b = beta
resid = y - X @ beta
dof = len(y) - X.shape[1]
s = np.sqrt(resid @ resid / dof)          # residual std dev in log space

def predict(m, z=1.645):
    """Median estimate and ~90 percent band, ignoring parameter uncertainty."""
    mu = ln_a + b * np.log(m)
    return np.exp(mu), np.exp(mu - z * s), np.exp(mu + z * s)

mid, lo, hi = predict(1.8)
print(f"a={np.exp(ln_a):.2f} b={b:.3f} sigma_log={s:.3f}")
print(f"1.8 kg part: {mid:.2f} (90% band {lo:.2f} to {hi:.2f})")

Two practical notes. The band above ignores the uncertainty in the fitted coefficients, which understates the interval at the edges of the data; a proper prediction interval adds the leverage term, and a bootstrap is an acceptable shortcut. And a CER must never be applied outside the range of drivers it was fitted on. A fit on parts from 0.2 to 6 kg says nothing about a 40 kg casting.

Parametric models also include learning curves, which handle the fact that unit cost falls with cumulative volume. In Wright’s formulation, the cost of the x-th unit follows Y_x = Y_1 x^b, where b = log(learning rate) / log 2. An 85 percent curve means each doubling of cumulative output cuts unit cost to 85 percent of its prior value, giving b of about minus 0.234. Use it carefully: a learning curve describes labour-intensive, repetitive operations, and it flattens once the process is stable. Applying it to a fully automated, material-dominated part produces savings that never appear.

Bottom-up and feature-based estimating

A bottom-up model builds the cost from the manufacturing process itself. For a machined part, the elements are material (stock mass times price, less scrap value), process time (cycle time times machine rate), setup (setup time times rate, divided by batch size), secondary operations, tooling and fixtures amortised over volume, then overhead, general and administrative cost, and profit applied as markups. This is the method that most closely matches what a supplier’s estimator does, which is why it is the right reference for a quote conversation.

The word “feature-based” refers to how cycle time is derived. Instead of an engineer guessing 14 minutes, the model reads manufacturing features from the CAD model (holes, pockets, bosses, thin walls, thread callouts, tolerance and finish annotations) and sums per-feature time from a machining-time database or from calibrated formulas. Cost-modeling products from several vendors automate exactly this, for example by computing manufacturing process time and cost from the geometry and the chosen process route; the point for the architect is that the geometry-to-cost step is an integration, not a rewrite of the CAD system.

The three families are not rivals. They form a ladder: analogous at concept, parametric in preliminary design, feature-based at detail, with the lower rungs calibrated by the data produced at the higher ones. A parametric CER is, in effect, a compressed memory of many bottom-up estimates and real quotes.

Attaching Cost to CAD Features

Direct answer: To attach cost to CAD features, extract machining, forming or casting features and their annotations from the model, map each to a process time or material quantity using calibrated tables, convert time to cost with machine and labor rates, and add overhead and profit. Store the result against the part revision so a geometry change automatically invalidates and re-triggers the estimate.

Figure 3: Feature-based should cost modeling. CAD features and annotations drive material mass, cycle time and tolerance-driven cost multipliers, which combine with overhead, SG&A and profit into a range, not a point.

What to extract

From the CAD model, the minimum viable extraction set is: finished volume and mass (from the material assignment), bounding box (which sets stock size), the count and type of features by process (holes by diameter and depth, pockets by volume and corner radius, threads, bends, ribs), and surface area for finishing. From the drawing or model-based definition annotations come the tolerance classes, surface finish callouts and any special requirements such as heat treatment or inspection plans. If the company practises model-based definition, these annotations are already structured; if not, the extraction degrades to manual tagging and the estimate quality falls with it.

The tolerance multiplier

Tolerance is the cost driver most often under-modelled, because it is not a geometry quantity. Tightening a tolerance does not just add an operation; it can change the process (from milling to grinding), slow feeds, add inspection time and raise scrap. Cost models generally capture this as a multiplier or as an added operation keyed to tolerance class. The multipliers should be calibrated against your own suppliers’ quotes, not copied from a generic table, because shops differ in equipment and capability. A good PLM implementation exposes the tolerance class as an attribute that engineers can see next to the cost it triggers, which turns “do we really need plus or minus 0.02 here” into a data-driven question during design review.

Keeping geometry and cost in sync

The binding rule is that a cost estimate belongs to a part revision, not to a part number. When a designer changes a pocket depth, the new revision has a new geometry hash; the cost service sees the new revision through the PLM event stream and either recomputes or flags the old estimate stale. An estimate that is silently reused across revisions is the single most common source of wrong rollups. The estimate record should carry the revision, a hash of the geometry and annotations used, the model version, the rate table version, and the assumptions (volume, region, material price date). With those five fields, every number is reproducible.

BOM Cost Rollup Mechanics: Effectivity, Quantity and Cost Basis

Direct answer: A BOM cost rollup multiplies each component’s unit cost by its extended quantity through the product structure and sums the results, but only for the BOM lines effective on the evaluation date or serial range, using the price valid at the relevant volume break. The correct output is a cost with its basis and range per line, not a single total.

Figure 2: A BOM cost rollup. Each leaf resolves to a cost from a different source (contract price, CAD feature model, quote or process model), and the rollup applies extended quantity and effectivity before summing.

A rollup looks trivial, a recursive sum over a tree, and the naive version is. The production version has four sources of complexity, and each is a place where cost numbers go quietly wrong.

Effectivity decides which lines count

A PLM BOM is not one tree but a family of trees over time and configuration. Lines carry effectivity, a date range, a serial-number range or a lot range, that says when a given usage of a child under a parent is valid. A rollup therefore takes an evaluation context, for example “as of 2027-03-01” or “serial 10,000 and up”, and selects only matching lines. The mechanism is the same as in release control; the earlier post on engineering change management with effectivity covers how the lines get their ranges. For costing, the consequence is that the product has a different cost at different dates, and a cost report without its effectivity context is ambiguous.

Extended quantity compounds down the tree

If an assembly uses four of a subassembly, and each subassembly uses six fasteners, the fastener extended quantity is 24 for that branch. Extended quantity is computed top-down by multiplying quantities along the path. A part that appears in several branches has its extended quantities summed. Getting this wrong by treating quantity as per-parent rather than per-root is a classic error in hand-built spreadsheets.

Cost basis and the price-break lookup

Each leaf has a cost, but cost of what kind? A useful model distinguishes at least these bases: a negotiated contract price, a quote, a should-cost estimate, a standard cost set by finance, and a placeholder. Mixing them silently produces a total nobody can interpret. The rollup should carry the basis for each line and report the share of the total that rests on each basis. A total in which 60 percent of the value is placeholder is a very different object from one that is 90 percent contracted price.

Purchased parts also have volume-dependent prices. The lookup is: given the annual volume or order quantity for this evaluation, pick the price break with the largest minimum quantity not exceeding it. This needs the volume, which is a property of the evaluation scenario, not of the part.

Make versus buy and the overhead trap

For make parts, a rollup that sums material and conversion cost but forgets that the shared assembly overhead is allocated at the parent level will understate cost at the leaves and double count at the top. Decide where overhead is applied (usually once, at the process-cost level for each make part, and at the assembly level for assembly labour) and apply it exactly once.

SQL: a recursive rollup with effectivity and price breaks

The following PostgreSQL query expresses the rollup directly. It assumes a bom_link table with effectivity dates, a part_cost table holding unit costs with volume breaks, and bind parameters for the root, the as-of date and the annual volume. It is a pattern to adapt, not a drop-in.

-- Tables (simplified)
-- bom_link(parent_id, child_id, qty numeric, eff_from date, eff_to date)
-- part_cost(part_id, basis text, min_qty int, unit_cost numeric,
--           cost_low numeric, cost_high numeric, valid_from date, valid_to date)

WITH RECURSIVE exploded AS (
    SELECT l.child_id AS part_id,
           l.qty      AS ext_qty,
           1          AS depth,
           ARRAY[l.parent_id, l.child_id] AS path
    FROM   bom_link l
    WHERE  l.parent_id = :root_id
      AND  :as_of >= l.eff_from
      AND  :as_of <  COALESCE(l.eff_to, 'infinity'::date)

    UNION ALL

    SELECT l.child_id,
           e.ext_qty * l.qty,
           e.depth + 1,
           e.path || l.child_id
    FROM   exploded e
    JOIN   bom_link l ON l.parent_id = e.part_id
    WHERE  :as_of >= l.eff_from
      AND  :as_of <  COALESCE(l.eff_to, 'infinity'::date)
      AND  NOT l.child_id = ANY(e.path)      -- cycle guard
      AND  e.depth < 40
),
leaf_qty AS (                                 -- sum quantity for parts used in many branches
    SELECT part_id, SUM(ext_qty) AS ext_qty
    FROM   exploded e
    WHERE  NOT EXISTS (SELECT 1 FROM bom_link c
                       WHERE c.parent_id = e.part_id
                         AND :as_of >= c.eff_from
                         AND :as_of <  COALESCE(c.eff_to, 'infinity'::date))
    GROUP  BY part_id
)
SELECT q.part_id,
       q.ext_qty,
       pc.basis,
       pc.unit_cost,
       q.ext_qty * pc.unit_cost AS ext_cost,
       q.ext_qty * pc.cost_low  AS ext_low,
       q.ext_qty * pc.cost_high AS ext_high
FROM   leaf_qty q
LEFT   JOIN LATERAL (
         SELECT *
         FROM   part_cost p
         WHERE  p.part_id = q.part_id
           AND  p.min_qty <= :annual_volume
           AND  :as_of BETWEEN p.valid_from AND COALESCE(p.valid_to, 'infinity'::date)
         ORDER  BY p.min_qty DESC
         LIMIT  1
       ) pc ON true;

Two details deserve comment. The cycle guard and depth limit protect against malformed data, which exists in every real PLM system. And the LEFT JOIN LATERAL leaves rows with a null cost visible instead of dropping them, so missing costs show up as explicit gaps; an inner join would silently lower the total, which is the worst possible failure for a cost report.

The recursive-CTE approach works well to a few hundred thousand BOM lines per query. For very deep, heavily shared structures queried interactively for “what does changing this part cost across all products,” a graph store can be faster; the post on graph databases for PLM impact analysis and where-used queries compares the two for the same traversal problem.

Python: a rollup with ranges and a Monte Carlo total

Sums of ranges are not ranges of sums in any useful sense. Adding every line’s low case gives an absurdly pessimistic floor, because it assumes every estimate errs the same way at once. A Monte Carlo over triangular distributions gives a more honest band for the total, and it is small enough to run on every rollup.

import numpy as np
from dataclasses import dataclass

@dataclass
class Line:
    part_id: str
    ext_qty: float
    low: float      # per-unit low
    mode: float     # per-unit most likely
    high: float     # per-unit high
    basis: str      # contract | quote | should_cost | placeholder

def rollup(lines, n=20000, seed=7, correlation_group=None):
    """Monte Carlo total with optional shared driver for correlated lines.

    correlation_group: dict part_id -> group name. Lines in one group share the
    same uniform draw, which models a common driver such as an aluminium index.
    """
    rng = np.random.default_rng(seed)
    total = np.zeros(n)
    group_u = {}
    for ln in lines:
        if ln.basis == "contract" or ln.low == ln.high:
            total += ln.ext_qty * ln.mode
            continue
        g = (correlation_group or {}).get(ln.part_id)
        if g is not None:
            if g not in group_u:
                group_u[g] = rng.random(n)
            u = group_u[g]
        else:
            u = rng.random(n)
        # inverse CDF of a triangular distribution
        c = (ln.mode - ln.low) / (ln.high - ln.low)
        x = np.where(u < c,
                     ln.low + np.sqrt(u * (ln.high - ln.low) * (ln.mode - ln.low)),
                     ln.high - np.sqrt((1 - u) * (ln.high - ln.low) * (ln.high - ln.mode)))
        total += ln.ext_qty * x
    p10, p50, p90 = np.percentile(total, [10, 50, 90])
    share = {}
    for ln in lines:
        share[ln.basis] = share.get(ln.basis, 0.0) + ln.ext_qty * ln.mode
    return {"p10": p10, "p50": p50, "p90": p90, "basis_share": share}

lines = [
    Line("BRKT-001", 2, 22.1, 25.4, 28.6, "should_cost"),
    Line("MOTR-010", 1, 41.0, 44.0, 49.0, "quote"),
    Line("FSTN-777", 14, 0.08, 0.08, 0.08, "contract"),
    Line("PCBA-200", 1, 30.0, 36.0, 52.0, "placeholder"),
]
print(rollup(lines, correlation_group={"BRKT-001": "alu", "MOTR-010": "alu"}))

The correlation hook is the important design feature. Lines that depend on the same commodity or the same supplier move together, and ignoring that makes the band too narrow. In PLM terms, each cost record can carry a driver tag, and the rollup groups on it. If you cannot model correlation, widen the reported band instead of trusting a clean-looking independent result.

The basis_share output is the quiet hero of the function. It tells a reviewer how much of the total is contract, quote, should-cost or placeholder, which is the information that determines how much to trust the number.

Should-Cost Versus Supplier Quote: Teardown, Not Tug-of-War

A supplier quote and a should-cost estimate answer different questions. The quote answers “what will this supplier charge,” which includes their real costs, their capacity situation, their risk appetite and their view of your leverage. The should-cost estimate answers “what would an efficient, reasonable supplier need to charge,” which is a benchmark. The gap between them is not an accusation; it is a list of questions. Treating it as a lever for a blunt percentage discount is how procurement teams lose supplier goodwill and still miss the actual savings.

Normalise before comparing

The comparison is only valid if both sides describe the same thing. Before computing a gap, align these items: the part revision quoted, the incoterms and packaging, the annual volume and the batch or release size, who supplies material and who owns tooling, the region and its labour and energy rates, quality requirements such as certifications and inspection plans, and the payment terms. A quote for a batch of 50 against a should-cost for 5,000 per year will show a spectacular gap that is entirely setup amortisation. The PLM record of the request for quotation should capture these assumptions so the should-cost run uses the same ones.

Decompose both into the same cost buckets

Ask suppliers for a line-item breakdown where the relationship allows it, and map the lines to the buckets in the should-cost model: material (gross, scrap credit), conversion (machine time, setup, labour), secondary operations and outsourced processes, tooling, logistics and packaging, overhead and SG&A, and profit. When a supplier will not break down the quote, the should-cost model still provides the structure for questions, and the totals can be compared even if the buckets cannot.

Classify each gap

Each bucket gap falls into one of four categories, and the category determines the action.

Assumption mismatch. The supplier quoted a different volume, tolerance reading or finish. The action is clarification, not negotiation.
Model error. Your cycle time is optimistic, your material price is stale, your machine rate is wrong for that region. The action is to correct the model and record the lesson, which improves every later estimate.
Supplier inefficiency or margin. Legitimate to challenge, with data. The action is a fact-based negotiation on specific buckets.
Design driver. The gap exists because the design asks for something expensive: a tight tolerance, an exotic material, a low-volume feature. The action is redesign, which feeds the design-to-cost loop.

The fourth category is where PLM earns its keep. A negotiation can recover a few points of supplier margin once; a design change that removes a cost driver reduces cost for the life of the product and for every supplier.

A Worked Illustrative Example: A Machined Aluminium Bracket

All numbers below are illustrative, constructed to demonstrate the method. They are not market data, and the rates are not benchmarks.

Part: a machined 6061-type aluminium bracket. Finished mass 0.62 kg, cut from a block of 1.35 kg. Annual volume 5,000, released in batches of 250. Anodised by an outside process.

Should-cost build-up (per unit):

Element	Basis (illustrative)	Cost
Material	1.35 kg x 4.80 per kg = 6.48, less chip credit 0.73 kg x 1.20 = 0.88	5.60
Machining	14.0 min x 55 per hour (machine rate with operator)	12.83
Setup	90 min x 55 per hour = 82.50, over 250 parts	0.33
Deburr and inspect	2.0 min x 30 per hour	1.00
Anodise (outsourced)	assumed processing price per part	1.40
Fixture amortisation	3,000 over 15,000 parts	0.20
Manufacturing subtotal		21.36
SG&A at 10 percent		2.14
Profit at 8 percent of the running total		1.88
Should cost (mid)		25.38

Range. The dominant uncertainty is cycle time, estimated at 11 to 17 minutes depending on programming and fixturing. Holding everything else constant, 11 minutes gives machining of 10.08 and a total of about 22.1; 17 minutes gives 15.58 and about 28.6. The reported should-cost is therefore 25.4, with a plausible band of roughly 22.1 to 28.6. Reporting a single number here would hide that the single largest driver is a guess.

Quote. A supplier quotes 31.50 for the same revision, volume and batch size. That is 6.12 above the midpoint (24 percent) and 2.86 above the top of the band. The band says the quote cannot be explained by cycle-time uncertainty alone, which is exactly the kind of conclusion a point estimate cannot support.

Teardown (supplier breakdown versus model):

Bucket	Quote	Should cost	Gap
Material	7.20	5.60	+1.60
Machining and setup	15.10	13.16	+1.94
Deburr and inspect	1.60	1.00	+0.60
Anodise	2.10	1.40	+0.70
Tooling	0.30	0.20	+0.10
Overhead and profit	5.20	4.02	+1.18
Total	31.50	25.38	+6.12

Reading the gaps. Material is 1.60 higher: the supplier gives no chip credit and prices stock at a higher rate, which is partly model error (small shops often do not capture scrap value) and partly a design driver, since a 1.35 kg block for a 0.62 kg part scraps more than half the material. A near-net-shape stock size, or an extrusion profile, is a design lever. Machining plus setup is 1.94 higher: it implies a cycle time near 16 minutes at the model’s rate, inside the uncertainty band but at its top, so ask which features drive the time. Deburr and inspect is 0.60 higher, plausibly an inspection plan stricter than assumed. Overhead and profit differ by 1.18, partly because the quote’s markup applies to a higher base. After clarifying assumptions, the actionable items are a stock-size redesign and a tolerance review, not a flat request for a 20 percent discount.

If the stock change moved to a 0.95 kg extrusion section at the same price per kg (illustrative), material would fall by 0.40 kg x 4.80 = 1.92 before chip credit adjustments, and the saving would repeat on every unit for the life of the design. That is the design-to-cost payoff, and it is why the teardown output should flow back into the design backlog.

Cost Meets Change: Linking Estimates to Engineering Change Orders

Direct answer: Every engineering change request should carry a cost delta: roll up the affected BOM with and without the change, express the difference with its range, add one-time costs such as tooling, rework and scrap of existing stock, and compute payback. The delta is attached to the change record, so the approval board decides on cost, risk and schedule together.

Figure 4: Costing an engineering change. The PLM system asks the cost engine for a delta, requests updated supplier quotes in parallel, and compares quotes with the should-cost before the change board decides.

Change is where cost control most often fails, because changes are small, frequent and approved on technical merit. A fastener swap, a thicker gauge, a connector upgrade each look cheap in isolation. Ten of them in a quarter can move the product cost by several percent, and nobody sees it because no one rolls up the cumulative effect.

The change cost delta

The delta has recurring and non-recurring parts. Recurring: new unit costs times extended quantities across all effective usages, minus the old. Non-recurring: new tooling, qualification and testing, re-certification, engineering time, and the write-off of obsolete inventory and work in progress. The effectivity decision interacts with cost directly. A change effective on a date leaves old-revision stock on hand; a change effective at the next serial number after depletion has a different cash profile. The change record should hold the cost delta for each effectivity option the board is considering, so the trade-off between “cut in now and scrap stock” and “run out then cut in” is explicit.

Payback is then simple arithmetic. If a change saves 0.85 per unit (illustrative) on 40,000 units per year and costs 60,000 one-time, the annual saving is 34,000 and simple payback is about 1.8 years. The model should also check the other side: a change made for performance that adds 1.20 per unit has a recurring cost that the programme must have budget to absorb, and the BOM cost target for the affected subsystem should be visibly updated.

Closing the loop with quotes

Cost deltas computed from a should-cost model are estimates. For material changes, the sourcing team requests a revised quote, and the change record stores both. When the quote arrives, the same teardown runs, and the difference between delta estimate and quote delta calibrates the model. Over a year of changes, this produces a substantial, high-quality dataset of estimate versus actual that no standalone cost study could match.

Data model sketch

A minimal data model has these entities: cost_estimate (part revision, method, model version, assumptions, mid, low, high, created_at), cost_actual (part, supplier, price, volume break, valid dates, source document), cost_target (structure node, target, version), cost_delta (change record id, effectivity option, recurring delta, non-recurring cost, payback), and assumption_set (volume, region, rate-table version, material price date). The foreign keys to part revision and change record are what make the model PLM-native. Everything else is ordinary relational design.

Uncertainty, Calibration and Governance

Costing credibility is built by being measurably right, and by being honest about being wrong. Three practices make the difference.

Every cost should travel with a low, mode and high, and every rollup with a basis share. Those two additions convert a cost number from an assertion into an auditable claim. They also change behaviour: a design review looking at 41 plus or minus 8 asks different questions from one looking at 41.

Calibrate with a scheduled back-test

Each month, compare estimates with the actual purchase prices that have landed since. For each model type (analogous, parametric, feature-based), compute the median ratio of actual to estimate and the spread. If the median ratio sits well above 1, the model is systematically optimistic. If the spread is wide, the ranges need widening. The rule is to correct drivers (rate tables, tolerance multipliers, cycle-time formulas), not to apply a global fudge factor, which just hides the cause. Version the rate tables and CERs, and never overwrite them; a rollup run six months ago must be reproducible with the tables as they were then.

Govern the assumptions

Material prices, labour and machine rates, exchange rates, and overhead allocations are inputs that finance and procurement own. Engineering should consume them from a governed table with effective dates, not copy numbers into models. The same applies to the commodity indexes used to adjust old data. A stale rate table is the quiet way a good model produces bad numbers, and the version of the table used should be stamped on every estimate.

Trade-offs, Gotchas, and What Goes Wrong

False precision. A model that outputs 25.38 invites people to treat the second decimal as meaningful. The inputs are good to perhaps 10 to 15 percent, so show ranges and round for display. Precision is a property of the data, not of the formatting.

Garbage geometry, garbage cost. Feature extraction fails on poorly built CAD: suppressed features, imported solids with no feature tree, or models where the material is unassigned. The cost service must detect and report these cases rather than guess. A part flagged “not costable: no material assigned” is useful information; a part given a default aluminium assumption is a hidden error.

Supplier-specific reality. A should-cost model assumes a reasonable supplier. Real suppliers have different equipment, different utilisation and different strategic interest in your business. A quote below should-cost is not necessarily good news: it may signal a misread drawing, a buy-in price to win volume, or a supplier planning to recover cost through change orders. Verify before celebrating.

Gaming the model. Once engineers are measured against a cost target, they will find the cheapest way to hit it in the model. If the model does not price a tolerance, designers will tighten it for free. If it does not price part count, assemblies will grow. Model gaps become design behaviour, which is a reason to review what the model cannot see, not only what it can.

Cost as the only objective. Design-to-cost done badly produces a cheap product that fails in the field. Cost must sit in the same trade space as reliability, serviceability, compliance and supply risk. The related posts on component obsolescence management and product compliance tracking in the BOM cover two constraints that routinely override a cheaper part.

Variant explosion. Configurable products multiply the number of BOMs to cost. Costing every combination is infeasible; cost the base plus option deltas, and cost full configurations only for the high-volume or high-risk ones. The structure is covered in the post on 150 percent BOM and variant management.

Stale data in the rollup. Missing costs silently treated as zero, expired quotes still counted, and estimates reused across revisions are the three bugs that account for most wrong totals. Each is prevented by the same rule: surface the gap instead of absorbing it. Missing is a state, not a value.

Legal and ethical boundaries. Using a supplier’s quote breakdown to share cost information with competing suppliers is a trust breach and, depending on contract terms and jurisdiction, can violate confidentiality clauses. Keep each supplier’s detail inside that supplier’s record and share only the buyer’s own should-cost findings.

Practical Recommendations

Start small and instrument the loop before polishing the model. A feature-based model that nobody calibrates is less valuable than a crude parametric model that is back-tested monthly. The sequence below reflects what tends to work, offered as engineering judgment rather than a universal recipe.

First, establish the data spine: part revision as the key for every cost record, a governed rate table with effective dates, and the rollup with effectivity and basis tracking. This delivers value alone, because it makes the existing cost picture honest and shows how much of the total is placeholder. Second, add parametric CERs for the top commodity families by spend, since the Pareto principle usually puts a small number of families at a large share of cost. Third, add feature-based costing for the few high-volume make parts where the spend justifies the integration effort. Fourth, wire cost deltas into the change process so every ECR arrives with one. Fifth, run the monthly back-test and publish the error statistics to the engineers who depend on the model.

A short checklist for a first release:

Each cost record keyed to part revision, with basis, low, mode, high, model version and assumption set.
Rollup honours effectivity, extended quantity and price breaks, and reports missing costs explicitly.
Rollup output includes the share of total by cost basis.
Target cost stored per structure node and compared with the rolled-up estimate.
Should-cost and quote normalised on revision, volume, incoterms, tooling ownership and region before any gap analysis.
Gaps classified as assumption mismatch, model error, supplier margin or design driver.
Change requests carry recurring and non-recurring cost deltas for each effectivity option.
Monthly back-test of estimate versus actual, by model type, with rate tables versioned.
A named owner for each governed input: rates, indexes, overhead.

Finally, resist the urge to automate the negotiation. The model’s job is to give engineers and buyers a shared, reproducible fact base. The conversation with the supplier remains a human skill.

Frequently Asked Questions

What is should cost modeling?

Should cost modeling estimates what a part or product ought to cost, built bottom-up from material, process time, labour and machine rates, tooling, overhead and a reasonable profit. It represents an efficient, reasonable supplier rather than any real quote. Teams use it during design to check cost targets, and after release to benchmark supplier quotes, find the buckets that explain a gap, and decide whether to negotiate or redesign.

What is the difference between design-to-cost and target costing?

Target costing sets the allowable cost by working backwards from the market price and required margin. Design-to-cost is the engineering practice of treating that allowable cost as a design requirement: budgeting it across subsystems, estimating cost at each design gate and pulling cost levers when the estimate exceeds budget. In short, target costing produces the number, and design-to-cost is the process that makes the design meet it.

How accurate is parametric cost estimation?

Accuracy depends on the quality and relevance of the historical data and on staying within the range the model was fitted on. Illustratively, parametric estimates in preliminary design might carry a plus or minus 15 to 30 percent band, but that must be calibrated against your own estimate-versus-actual history. A back-test by commodity family gives a real error figure, which is better than any published rule of thumb.

How should a BOM cost rollup handle effectivity?

The rollup takes an evaluation context, such as a date or serial range, and includes only the BOM lines effective in that context. It then multiplies quantities down the tree, resolves each leaf to a cost valid on that date at the relevant volume break, and sums. Reporting the effectivity context with the result is essential, because the same product has different costs on different dates.

Should I trust a supplier quote below the should-cost estimate?

Treat it as a prompt to verify, not as good news. A low quote can reflect a misread drawing, a buy-in price to win volume, a different process route or genuine supplier efficiency. Confirm the quoted revision, scope, tolerances, finish and quality requirements match, review the cost breakdown if available, and check the supplier’s capability and change-order history before awarding.

Do I need a commercial cost-modeling tool to start?

No. The data spine, rollup, parametric CERs and quote comparison can be built with a relational database and a few hundred lines of code, as shown above. Commercial tools add value mainly in geometry-driven process simulation and maintained cost databases for specific processes. A sensible path is to build the PLM integration and governance yourself, and decide on specialist tools only for the processes where feature-based accuracy repays the licence.