Calculators and Worksheets¶
Six pieces of arithmetic carry most of the quantitative work in this course. This page gives the formula, a worked example, the assumptions behind it, and a command that reproduces the example — so you can check your own spreadsheet rather than trust it.
How to use this page
Work the example by hand first. The command is a checking aid, not a substitute for understanding the arithmetic, and every lab that uses a calculator expects you to show your working.
The calculator tool¶
tools/spm-calculators.py needs only Python 3 — no packages to install.
python tools/spm-calculators.py --check # validate every formula against this page
python tools/spm-calculators.py pert 4 6 14 # three-point estimate
python tools/spm-calculators.py schedule --file docs/templates/csv/project-schedule.csv
--check validates 29 known results taken from the worked examples below and from
Lab 10, Lab 18,
and Lab 21; it runs in the repository's checks, so a
formula that contradicts this page fails.
1. Three-point (PERT) estimation¶
Formula
$$E = \frac{O + 4M + P}{6} \qquad \sigma = \frac{P - O}{6}$$
where $O$ is optimistic, $M$ most likely, and $P$ pessimistic. For several activities in series, expected values add and variances add:
$$E_{total} = \sum E_i \qquad \sigma_{total} = \sqrt{\sum \sigma_i^{2}}$$
Worked example — an 8-day activity where the team is unsure:
| Estimate | Value | Reasoning |
|---|---|---|
| Optimistic | 4 days | Everything works first time |
| Most likely | 6 days | The normal case |
| Pessimistic | 14 days | The integration behaves as it did last time |
$E = (4 + 4(6) + 14) / 6 = 42 / 6 = \mathbf{7 days}$ · $\sigma = (14 - 4) / 6 = \mathbf{1.67 days}$
A second activity estimated $(6, 10, 20)$ gives $E = 11$ and $\sigma = 2.33$. In series:
$$E_{total} = 7 + 11 = \mathbf{18 days} \qquad \sigma_{total} = \sqrt{1.67^2 + 2.33^2} = \mathbf{2.87 days}$$
Assumptions and limitations
- The weights of 1, 4, 1 are a convention, not a law. They produce a useful weighted average; they do not make the estimate true.
- The formula treats $O$ and $P$ as realistic bounds. If they are round numbers chosen to widen the range, the resulting standard deviation is meaningless.
- Independence is assumed. If two activities share the same risk — the same unfamiliar subsystem, the same external queue — their uncertainties are correlated and the combined standard deviation is understated. For a series that shares a risk, treat the shared cause as a separate item.
- Adding 2σ to a schedule is a planning decision, not a probability guarantee. State the range, then decide.
- Used in Module 07 and Lab 13.
2. Cost estimation¶
Formula
$$base = effort \times rate \qquad overhead = base \times overhead\% \qquad subtotal = base + overhead$$
$$contingency = subtotal \times contingency\% \qquad total = subtotal + contingency$$
Worked example — 42 person-days at a day rate, 10% overhead, 5% contingency:
| Component | Calculation | Amount |
|---|---|---|
| Base | 42 × 45,000 | 1,890,000 |
| Overhead | 1,890,000 × 10% | 189,000 |
| Subtotal | 2,079,000 | |
| Contingency | 2,079,000 × 5% | 103,950 |
| Total | 2,182,950 |
Assumptions and limitations
- The rate must be the all-in cost the organisation uses, and stated as such. Whether it includes supervision, equipment, and leave is the most common source of disagreement between two estimates.
- Effort is in person-days, not elapsed days. A 42 person-day task done by three people is not necessarily 14 days of calendar time.
- Contingency is not a padding percentage. It covers identified uncertainty; unexplained padding should be removed and the underlying estimate challenged instead.
- The order of overhead and contingency changes the answer, so follow the organisation's convention and say which you used. Here contingency applies to the subtotal, not the base.
- Currency is not handled. All figures must be in one currency at one point in time.
- Used in Module 07 and Lab 13.
3. Risk exposure¶
Two distinct uses, which must not be mixed:
| Use | Formula | Meaning |
|---|---|---|
| Ranking on the course's 1–3 scale | $exposure = P \times I$ (ordinal) | A comparative score from 1 to 9 that prioritises attention |
| Expected monetary value | $EMV = p \times impact$ (real units) | Money or days, used to size a contingency reserve |
Worked example — a risk with a 40% chance and a 500,000 impact: $EMV = 0.4 \times 500{,}000 = \mathbf{200{,}000}$. On the ordinal scale, probability 2 (medium) and impact 3 (high) gives exposure $\mathbf{6}$, at the threshold where a written response is required (see the risk assessment matrix).
Assumptions and limitations
- Ordinal exposure is comparative, not arithmetic. A risk scoring 9 is not three times as important as one scoring 3, and scores cannot be summed into a meaningful total.
- Expected value is an average over many repetitions. For a single project it is not a prediction, and a low expected value does not justify ignoring a risk whose impact would end the project. That is why the response threshold is set by impact as well as score.
- Multiplying ordinal scores assumes the two are independent, which is convenient rather than true.
- Expecting every risk to be scored with false precision is worse than a rough ranking. Where a number would be invented, say "not quantified".
- Used in Module 08 and Lab 17.
4. Earned value management¶
Formulas
| Measure | Formula | Reading |
|---|---|---|
| Cost variance | $CV = EV - AC$ | Positive = under budget |
| Schedule variance | $SV = EV - PV$ | Positive = ahead of plan, in value terms |
| Cost performance index | $CPI = EV / AC$ | 1.0 = on budget |
| Schedule performance index | $SPI = EV / PV$ | 1.0 = on plan |
| Estimate at completion | $EAC = BAC / CPI$ | Forecast cost if current efficiency continues |
| Variance at completion | $VAC = BAC - EAC$ | Forecast over- or under-spend |
| To-complete performance index | $TCPI = (BAC - EV) / (BAC - AC)$ | Efficiency required from now on |
Worked example — a scaled position with the same schedule performance as Lab 18 (SPI 0.80) but a worse cost performance, so the two readings can be compared:
| Measure | Calculation | Result |
|---|---|---|
| Cost variance | 160,000 − 190,000 | −30,000 (over budget) |
| Schedule variance | 160,000 − 200,000 | −40,000 (behind plan) |
| Cost performance index | 160,000 / 190,000 | 0.84 |
| Schedule performance index | 160,000 / 200,000 | 0.80 |
| Estimate at completion | 800,000 / 0.8421 | 950,000 |
| Variance at completion | 800,000 − 950,000 | −150,000 |
| To-complete performance index | 640,000 / 610,000 | 1.05 |
Note that SPI 0.80 agrees with a completely different measure in Lab 22: 16 of 20 planned items delivered. Two independent readings agreeing is what makes the figure credible, and a disagreement between them is information worth chasing.
Assumptions and limitations
- Earned value requires a meaningful baseline and a rule for what counts as "earned" — usually the definition of done. Without both, EV is a guess with three decimal places.
- A front-loaded baseline distorts SPI, flattering it early and harshly penalising it later. Always read SPI alongside a plain count of days slipped against named milestones (Lab 18 works through exactly this discrepancy).
- $EAC = BAC / CPI$ assumes current efficiency continues to the end. That is an assumption, not a forecast — if the overrun was a one-off, it is pessimistic; if the cause is systemic, it may be optimistic.
- Percent-complete measures for work in progress are the least reliable input. Use objective completion criteria, not a developer's estimate of progress.
- Earned value says nothing about quality. Work can be 100% complete and defective; check the defect log alongside it.
- Used in Module 11 and Lab 18.
5. Resource capacity¶
Formula
$$capacity = headcount \times working days \times availability factor \qquad balance = capacity - demand$$
Worked example — one tester, six weeks, and a shared DBA (from Lab 21):
| Role | Headcount | Days | Availability | Capacity | Demand | Balance |
|---|---|---|---|---|---|---|
| Backend developer | 2 | 30 | 0.8 | 48 | 42 | +6 |
| Frontend developer | 1 | 30 | 0.8 | 24 | 30 | −6 |
| DBA (shared) | 0.2 | 30 | 1.0 | 6 | 9 | −3 |
Assumptions and limitations
- The availability factor is a stated assumption, not a measurement. 0.8 is realistic for a person with leave, support duties, and meetings; 1.0 is a planning error that appears later as unexplained slippage.
- Totals can balance while every period fails. Compute this per period and per skill, never for the project as a whole — that aggregation error is the entire point of Lab 21.
- Capacity is a ceiling, not a commitment. A shared resource is released the first time the other project has an incident.
- The tool has no levelling algorithm. Resolving a shortfall is a decision — resequence using float, substitute skills, reduce scope, then negotiate capacity — and it belongs in the plan, not in a formula.
- Used in Module 10 and Lab 21.
6. Schedule calculations¶
Method — a forward pass, a backward pass, float, and the critical path:
- Forward pass: $ES = \max(EF \text{ of predecessors})$, then $EF = ES + duration$.
- Project duration = the largest $EF$ in the network.
- Backward pass: $LF = \min(LS \text{ of successors})$, then $LS = LF - duration$; the last activity's $LF$ equals the project duration.
- Total float $= LF - EF$ (equivalently $LS - ES$).
- Critical path = the chain of activities with zero float.
Worked example — the ten-activity network from Lab 10, which is also the worked example in the project schedule template:
| ID | Duration | ES | EF | LS | LF | Float | Critical |
|---|---|---|---|---|---|---|---|
| A | 5 | 0 | 5 | 0 | 5 | 0 | Yes |
| B | 4 | 5 | 9 | 5 | 9 | 0 | Yes |
| C | 6 | 9 | 15 | 19 | 25 | 10 | No |
| D | 5 | 9 | 14 | 9 | 14 | 0 | Yes |
| E | 8 | 9 | 17 | 23 | 31 | 14 | No |
| F | 6 | 15 | 21 | 25 | 31 | 10 | No |
| G | 7 | 14 | 21 | 14 | 21 | 0 | Yes |
| H | 10 | 21 | 31 | 21 | 31 | 0 | Yes |
| I | 5 | 31 | 36 | 31 | 36 | 0 | Yes |
| J | 4 | 36 | 40 | 36 | 40 | 0 | Yes |
Duration 40 working days · critical path A → B → D → G → H → I → J. Activity I waits for three predecessors and starts at the largest early finish (31), not the sum.
Assumptions and limitations
- Day 0 is the start. The tool calculates in working days and does not know your calendar — excluding weekends and public holidays is your step, and it is where most date errors occur.
- Resources are assumed available. This is not resource levelling, and a levelled schedule can be longer than the critical path implies.
- Float belongs to the project, not to the activity's owner. Spending float on one path can move the critical path.
- The critical path is only valid for the current durations and logic. Change either and it must be recalculated — a stale critical path is worse than none.
- Real projects have loops, optional work, and probabilistic durations. This tool handles none of them; it is a checking aid for small networks, not a scheduling package.
- Used in Module 06 and Lab 09 · Lab 10.
Further practice¶
- Every one of these calculators is exercised in a lab, and the labs give the scenario and the data: Lab 13 · Lab 16 · Lab 17 · Lab 18 · Lab 21.
- The spreadsheet-ready inputs are in the CSV library, whose conventions explain why durations are labelled in working days and estimates carry a basis.
- Instructor answer keys with the full working are in the answer keys area. Attempt the lab before reading them.