A network with the wrong numbers is a confident way to be wrong. Parameter learning is how you fill the tables from evidence rather than from optimism.
Chapters 1 and 2 assumed the conditional probability tables were already populated. In reality someone has to choose those numbers, and the choice is consequential: the same structure can give sober or reckless advice depending on the parameters inside it. Parameter learning is the principled way to set them — from data where you have it, and from disciplined judgement where you don’t.
1The obvious method, and its sharp edge
Maximum likelihood estimation chooses the parameters that make the data you actually observed as probable as possible. For a risk table this reduces to something intuitive: use the observed frequencies. If 3 of your last 20 similar packages had a design change, the estimate is 3/20. It is simple, unbiased in the large-sample limit, and exactly what a base-rate table is.
Its sharp edge is small samples — which is nearly all project risk data. If none of your last five projects hit a particular failure, maximum likelihood assigns it probability zero: not “rare”, but impossible. One dramatic near-miss then looks like a miracle the model insists cannot occur. Estimating rare, high-consequence events from a handful of observations is precisely where this method misleads most.
2Bayesian estimation: start from a belief, update with data
The Bayesian approach treats the parameters themselves as uncertain. You begin with a prior — your belief before seeing this project’s data — and update it into a posterior as evidence arrives. For probabilities this is clean: a Beta (or, for multi-outcome tables, a Dirichlet) prior updates simply by adding your observed counts to a set of pseudocounts that encode the prior. Those pseudocounts behave exactly like imagined prior observations.
Two properties make this the right default for risk work. With abundant data, the prior washes out and the Bayesian estimate converges to the maximum-likelihood one — you lose nothing. With scarce data, the prior stabilises the estimate, and crucially a sensible prior never assigns a genuine hazard a flat zero. You get graceful behaviour across the whole range from “no data” to “lots”.
3Pseudocounts are expert judgement, made honest
Good risk practitioners already blend history with judgement — they just do it in their heads, invisibly. Pseudocounts make that blend explicit and defensible: “our prior is equivalent to having seen this fail twice in fifty comparable jobs” is a claim a reviewer can interrogate and a data trail can eventually overrule. It is the difference between an auditable assumption and a gut feel wearing a number.
Maximum likelihood trusts only this project’s data; Bayesian estimation blends it with prior knowledge and lets the data win as it accumulates. For the thin, lopsided datasets typical of project risk, the blend is not a nicety — it is what stops the model from declaring rare disasters impossible.
4When the record has gaps
Project data is not only sparse but incomplete — a field left blank, an outcome never recorded. The expectation–maximization approach handles this by alternating: estimate the missing pieces using the current model, then re-fit the parameters as if those estimates were real, and repeat until it settles. It lets you learn from imperfect records instead of discarding every row with a hole in it.
Anchor your risk numbers in data wherever you have it, but state your priors openly and carry them where you don’t. Never let a small sample talk you into a probability of zero for something that can plainly happen. Write your assumptions as pseudocounts — “as if we’d seen n cases” — so that experience can override them as your portfolio grows. A model that learns is a model that gets less wrong every project.