Parametric Estimation

Goal

Parametric estimation produces by a calculation, rather than by intuition, the number every plan calls for before the work exists: how many francs, how many hours, how many weeks. It rests on a simple observation, that on comparable work the cost or the effort varies with a quantity one can measure and that the ratio between the two is stable enough to serve as a rule. You measure that quantity on the new work, multiply it by the rate observed in the past, and obtain an estimate whose every step is explicit. The problem it solves is one of traceability as much as of accuracy: a parametric estimate defends itself line by line, recomputes when an assumption changes and does not depend on the mood or the seniority of whoever sets it.

The decision it supports is a budgetary or calendar commitment made early, often before detailed framing. Reserving a budget, arbitrating between two solution variants that differ mainly in the volume of a single driver, forecasting the load of a portfolio of recurring requests, all these decisions need a number that grows in proportion to a known quantity. The technique excels exactly there: when a single measurable parameter dominates the cost, it turns its measurement into an estimate in one operation, and that operation replays at will over as many elements as needed.

The deliverable is a quantified estimate together with its assumptions: the driver chosen and its measured value, the calibrated rate and its source, the adjustment factors applied and the result expressed as a range rather than a single point. Parametric estimation is the method of the estimation family that fills this deliverable by calculation, where bottom-up estimation fills it by summing the detail and the Delphi method by converging expert judgements.

Usage

When to use it

• Measurable, stable driver: a measurable quantity correlates demonstrably with the cost or the effort.
• Own history available: the organisation holds the data of comparable projects to calibrate the rate on its own productivity.
• A fast, defensible, reproducible number: the decision demands an estimate that recomputes on its own and justifies itself step by step.
• Comparing solution variants: two options differ mainly in the volume of the same driver, the calculation separates them directly.
• Early budgeting: a single measurable parameter dominates the cost, the forecast is built before the task detail.

When not to use it

• No history to calibrate: on wholly new work the statistical relationship does not yet exist, seek expert judgement structured by the Delphi method.
• Driver not yet measurable: too early in the cycle, the quantity is not countable, deliver a rough order of magnitude (ROM) until it becomes so.
• Broken historical relationship: new technology, team or non-linear scale effect invalidate the rate, rebuild by bottom-up estimation.

Description

The model: driver, rate, adjustment

The technique rests on a relationship one can write in one line. The estimate is the product of a measured quantity and a calibrated rate:

estimate = quantity (measured driver) × rate (calibrated unit)

The cost driver is the measurable parameter that varies with the cost or the effort. The canonical drivers are well identified by trade: francs per square metre of area in construction, hours per function point in software development, cost per test case in test design, labour hours per metre or per drawing in engineering. The rate is the unit value that converts the quantity into cost or effort. In practice the base form is not enough, and one adds one or more adjustment factors that correct the known deviations between the new work and the calibration base:

estimate = quantity × rate × adjustment factor(s)

Calibrate the rate on your own history

The rate is calibrated on the organisation's own history. This is the step that makes the technique worth its while, and the BABOK insists on it: the organisation calibrates the model on its own history, because the value of the rate reflects the skills of its people and the processes by which the work is done. Calibration follows a stable order. First you gather the records of comparable work, carried out by a team of similar skill with similar techniques. Then you measure the driver on each of those past jobs and pair it with the cost or effort actually observed. From that you derive the rate, the mean of the ratios when the points are few, the slope of a regression when they are numerous enough to warrant it. Finally you check that the relationship holds, that is that the cost varies with the driver and that the correlation rests on enough points to be statistically real.

From there comes the technique's gravest trap, the one that empties its principle: substituting for the calibrated rate an industry average or an external benchmark. That rate imports another organisation's productivity, exactly what calibration on one's own history exists to avoid. A model fed on public data produces a number of rigorous appearance and foreign foundation. Calibration is redone as new actuals arrive: an estimate is iterative, and today's rate is only the best given today's history.

Adjustment factors and the non-linear form

The new work rarely resembles the calibration base closely enough to do without adjustment. A novel technical stack, a stricter compliance requirement, higher complexity, a different site each warrant a multiplier that moves the base estimate away from the value a plain product would give. These factors are a judgement. It is through them that expertise enters a calculation that seemed mechanical. The parametric software models generalise this adjustment and show that scale is not always linear: COCOMO II writes effort as a × size^b × ∏ multipliers, with an exponent b that curves the relationship and multipliers that correct each cost factor. The second trap is applying a linear rate beyond the range on which it was calibrated. A rate per square metre verified on buildings of eight hundred square metres has no reason to hold on a structure ten times larger, where scale effects change the picture.

Express the result as a range

A parametric estimate is delivered as a range. The product returns a single number whose displayed precision exceeds that of the inputs. This is the third trap: a computed result looks exact because it is computed, whereas its accuracy is bounded by the quality of the calibration and by the judgement passed on the adjustment factors. A parametric estimate called definitive, calibrated on solid history and a well-measured driver, holds within a range of the order of plus or minus ten per cent around the computed value; a rough estimate, set early on little data, is announced within a much wider range and owned as such. The range tells the truth the single number disguises, and it is the range, with its assumptions, that one commits to.

AI considerations

The calculation itself calls for no artificial intelligence: a product and a factor fit in a few spreadsheet cells. A model's contribution lies around the calculation, on the upstream calibration and on the checking of assumptions.

Upstream, statistical analysis helps to establish the rate from the organisation's history. A regression or a curve fit derives or refreshes the unit rate and, above all, detects the non-linearity the eye misses, the place where the relationship ceases to be a straight line. A model also spots the outliers and the non-comparable jobs in the history before they distort the calibration, and it can test which measured parameters correlate with past results, which helps to pick the right driver rather than a plausible but weak candidate. On counting function points from the text of the requirements, an assistant produces a first count the analyst revises, a tedious task it shortens without replacing.

What the machine must not decide comes down to the principle and the data. A model trained on public or sector data imports another organisation's productivity and undoes the rule that founds the technique, calibration on one's own history. Fed too few points or non-comparable ones, it returns a rate of deceptive assurance, an appearance of precision on an absent foundation, and it is the estimator who remains responsible for the confidence interval and the assumptions. Finally, the costs, efforts and individual productivities in the history are sensitive financial and HR data: they are not entrusted to an external tool without the controls that apply.

Examples

The IT department of a canton estimates a functional development of its e-government portal. The functional size is counted on the requirements, and the department calibrates its rate on its five last delivered projects.

Each row is a named factor, measured or calibrated, and the result arises from their product. The driver, 240 function points, is the analyst's own artefact, counted on the requirements they wrote, which anchors the estimate in the analysis work. The rate of eight hours per function point is the only row that carries the department's own productivity, drawn from its five last projects, and it is the one that would make the estimate wrong if it were replaced by a market average. The adjustment factor of 1.15 is the point where judgement enters an otherwise mechanical calculation: the new technical stack is not in the history, it is accounted for explicitly. The range of CHF 278'000 to CHF 340'000 is the deliverable: it recognises that the rate and the factor carry an uncertainty that the exact product of CHF 309'120 disguises under false precision.

Visualisations

The calculation table is the deliverable itself: made of rows and columns, recomputable step by step, it is rechecked product by product.

The model diagram carries its logic, which is better seen drawn than tabulated. It chains the measured driver and the rate calibrated on the history into a base estimate, then applies the adjustment factor, then expresses the whole as a range. It shows at a glance the form of the technique, a pipeline where a measured quantity becomes an estimate through a sequence of named operations, independent of the driver chosen.

Cost

Tools

The spreadsheet is the honest choice and hard to beat. The product, the adjustment factor and the range sit in a few cells, and sensitivity analysis, replaying the estimate under a revised rate or a different factor, happens in the same workbook. For most estimates, nothing more is needed, and the spreadsheet keeps a clear trace of every assumption.

Calibration proper benefits from a statistical tool as soon as the history holds enough points: a spreadsheet suffices for a mean, but a regression, a correlation test and outlier spotting are better run in a data-analysis environment, which also tells whether the relationship is linear over the wanted range. Specialised software-estimation tools build in function-point counting and calibrated models of the COCOMO kind natively, with their cost multipliers already parameterised; they are justified only where the volume of estimates and the stakes of the pricing make them pay off, since they impose adopting and maintaining their model rather than one's own.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.19 Estimation: the placement of parametric estimation among the estimation methods, the use of a calibrated parametric model of the estimated attributes and the principle that carries it, calibration on the organisation's own history because the value of the attributes reflects the skills of the people and the processes.
• PMI, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 8th edition, parametric estimating: the definition of the method and its arithmetic, the measured quantity multiplied by a unit rate to estimate cost, duration and resources and the expression of the result together with its uncertainty.
• ISO/IEC 20926:2009, IFPUG functional size measurement method (function point analysis): the standard behind the «hours per function point» driver, which defines how to count functional size from the requirements.
• B. Boehm et al., Software Cost Estimation with COCOMO II, Prentice Hall, 2000: the reference parametric model for software cost, effort = a × size^b × ∏ multipliers, cited for the non-linear form of the parametric model and not for a prescription.