Every calculation method inside ICB4 scope, with the formula, a worked example in numbers, and a diagram where the shape of the answer matters more than the arithmetic. Each method is mapped to the ICB4 competence element it serves.
75 methods · 14 groups · mapped to ICB4
How to use this. Each method has four parts: what it answers, the formula, a worked example with real numbers, and where relevant a diagram. Worked examples use invented but internally consistent figures — they exist to show the mechanics, not to represent any real project. The amber blocks flag the specific mistakes that cost marks.
Scope note: IPMA publishes no official list of quantitative methods. This document covers the calculation methods that fall inside the ICB4 competence elements, and maps each one to the element it serves. It is not a statement of what any specific certification body tests.
A Time ICB4 4.5.4
A1 Critical path method
Primary4.5.4 Time · KCI 4.5.4.4 Sequence project activities and create a schedule
How long the project takes, which activities cannot slip, and how much slack the rest have.
You build a network of activities with dependencies, push dates forward through it to get the earliest each activity can happen, then pull dates backward from the project finish to get the latest each can happen without delaying the end. The gap between them is float.
Forward pass EF = ES + Duration ES = max(EF of all predecessors)
Backward pass LS = LF − Duration LF = min(LS of all successors)
Total float TF = LS − ES = LF − EF
Free float FF = min(ES of successors) − EF
Critical path the chain of activities where TF = 0
Activity-on-node network. A–B–D is critical at 12 days. C carries 2 days of total float, E carries 4.
Worked example
Five activities. A (3d) starts the project. B (4d) and C (2d) both follow A. D (5d) needs both B and C. E (3d) needs C only.
Forward pass
A: ES 0, EF 0+3 = 3
B: ES 3, EF 3+4 = 7
C: ES 3, EF 3+2 = 5
D: ES = max(EF_B, EF_C) = max(7, 5) = 7, EF = 7+5 = 12
E: ES 5, EF 5+3 = 8
Project duration = max(12, 8) = 12 daysBackward pass (project LF = 12)
D: LF 12, LS 12−5 = 7
E: LF 12, LS 12−3 = 9
B: LF = LS_D = 7, LS = 7−4 = 3
C: LF = min(LS_D, LS_E) = min(7, 9) = 7, LS = 7−2 = 5
A: LF = min(LS_B, LS_C) = min(3, 5) = 3, LS = 3−3 = 0
Total float A 0 B 0 C 5−3 = 2 D 0 E 9−5 = 4
Free float of C min(ES_D, ES_E) − EF_C = min(7, 5) − 5 = 0Critical path A → B → D = 3 + 4 + 5 = 12 days
C has two days of total float but zero free float: delaying C by even one day pushes E, because E starts the moment C finishes. Total float belongs to the path, free float belongs to the activity alone.
Exam trap. Take the minimum on the backward pass and the maximum on the forward pass. Reversing them is the single most common arithmetic error, and it silently produces a plausible-looking wrong critical path. Also: a network can have more than one critical path, and float can be negative if an imposed finish date is earlier than the calculated one.
A2 Precedence relationships and lags
Primary4.5.4 Time · KCI 4.5.4.4 Sequence project activities and create a schedule
How two activities are actually tied together, and how much the tie shifts the dates.
Four relationship types exist. Each constrains a different pair of endpoints, so each changes the forward-pass formula. A lag adds waiting time to the constraint; a lead (negative lag) removes it.
FS Finish-to-Start ESsucc = EFpred + lag most common
SS Start-to-Start ESsucc = ESpred + lag
FF Finish-to-Finish EFsucc = EFpred + lag
SF Start-to-Finish EFsucc = ESpred + lag rare, used in handovers
The four dependency types. Shading marks the predecessor; the dashed line marks the constrained pair of endpoints.
Worked example
Data migration (10d) and reconciliation testing (6d), linked SS + 3d. Migration starts on day 0.
Migration: ES 0, EF 10
Testing (SS+3): ES = ES_migration + 3 = 3, EF = 3 + 6 = 9
Same pair as FS + 0:
Testing (FS): ES = EF_migration = 10, EF = 16 → 7 days later
Choosing SS over FS shortened the pair by seven days at the cost of running the two activities concurrently, which is the definition of fast-tracking (A4).
Exam trap. An SS or FF link only constrains one end of the successor. The other end floats freely, so an FF-linked successor can be dragged earlier or later without violating the logic. When a question asks for a duration after adding an SS link, check whether the successor's own duration, not the link, is now driving the finish.
A3 PERT and probabilistic duration
Primary4.5.4 Time · KCI 4.5.4.2 Determine the work effort and duration of activitiesAlso4.5.11 Risk and opportunity
How long an uncertain activity takes on average, and what the odds are of hitting a given date.
PERT replaces a single duration guess with three: optimistic, most likely, pessimistic. The weighted mean gives an expected duration; the range gives a standard deviation. Add variances along a path and you can attach a probability to any target date via the normal distribution.
Expected duration te = (O + 4M + P) / 6 beta-PERT
Triangular mean te = (O + M + P) / 3
Std deviation σ = (P − O) / 6
Variance σ² = ((P − O) / 6)²
Path std deviation σpath = √(σ²1 + σ²2 + … + σ²n)
Z-score z = (target date − expected date) / σpath
Path duration as a distribution. The mean is the PERT sum; the spread comes from the summed variances.
Worked example
Critical path A–B–D from A1, now estimated in three points.
Exam trap. Add variances, never standard deviations. √(0.111+0.444+0.444) = 1.00, but 0.333+0.667+0.667 = 1.667 — a 67% overstatement. Second trap: the single-point CPM duration equals the PERT mean only by coincidence; a right-skewed estimate (P far from M) pushes te above M. Memorise z = 1.282 for 90%, 1.645 for 95%, 2.326 for 99%.
A4 Schedule compression — crashing and fast-tracking
Primary4.5.4 Time · KCI 4.5.4.5 Monitor progress against the schedule and make any necessary adjustmentsAlso4.5.7 Finance
The cheapest way to buy back schedule, and what it costs per day.
Crashing adds resources to shorten activities and always costs money. Fast-tracking overlaps activities that were sequential and costs rework risk instead. For crashing, you rank critical activities by cost slope and buy the cheapest days first.
Cost slope = (crash cost − normal cost) / (normal duration − crash duration)
= cost per day saved
Procedure 1. crash only activities on the critical path
2. take the lowest cost slope first
3. respect each activity's crash limit
4. after every step, recalculate — another path may go critical
Direct cost rises as you compress; indirect cost falls with duration. Total cost has a minimum, and it is rarely at either extreme.
Worked example
Critical path A–B–D, 12 days. Target: 10 days.
Activity
Normal
Normal cost
Crash
Crash cost
Max days
Slope
A
3d
30,000
2d
38,000
1
8,000/d
B
4d
40,000
2d
52,000
2
6,000/d
D
5d
50,000
4d
57,000
1
7,000/d
Slope B = (52,000 − 40,000) / (4 − 2) = 12,000 / 2 = 6,000 per day ← cheapest
Step 1: crash B by 1 day → path A-B-D = 11d, added cost 6,000
Step 2: crash B by 1 more → path A-B-D = 10d, added cost 6,000 (B now at crash limit)
Re-check all paths at 10 days
A-B-D = 3 + 2 + 5 = 10 critical
A-C-D = 3 + 2 + 5 = 10 now also critical
A-C-E = 3 + 2 + 3 = 8
Target met. Total crash premium = 12,000 for 2 days.
To reach 9 days you can no longer crash B. The next day must come from an
activity on both critical paths: A (8,000/d) or D (7,000/d) → crash D, 7,000.
Exam trap. Crashing a non-critical activity buys nothing and is a guaranteed mark lost. And once a second path goes critical, a single activity crash no longer shortens the project unless that activity sits on every critical path — otherwise you must crash one activity on each path, and the effective cost per day is the sum of their slopes.
A5 Milestone trend analysis
Primary4.5.4 Time · KCI 4.5.4.5 Monitor progress against the schedule and make any necessary adjustmentsAlso4.5.10 Plan and control
Whether your milestone forecasts are drifting, and in which direction, across successive reports.
At each reporting date you re-forecast every milestone's finish date and plot it. Reporting dates run along one axis, forecast dates along the other. A horizontal line means a stable forecast. A rising line means the milestone keeps slipping. A falling line means it keeps being pulled earlier, which usually signals over-optimistic replanning rather than genuine recovery.
Reading the slope
horizontal → forecast stable, plan is holding
rising → slipping; slope of 1.0 means one day lost per day elapsed
falling → forecast pulled in; check whether scope moved with it
crossing the diagonal → milestone reached
Milestone trend chart. The 45° diagonal is "today"; a milestone is delivered where its line meets it.
Worked example
Go-live milestone forecast at four monthly reports: 1 Sep, 15 Sep, 1 Oct, 15 Oct.
Elapsed between reports: 30 days each (3 intervals = 90 days)
Total forecast slip: 1 Sep → 15 Oct = 44 days
Slip rate = 44 / 90 = 0.49 days lost per day elapsed
Extrapolated: to close a 44-day gap at zero recovery rate is impossible;
at the current rate the milestone recedes a further 0.49 d per elapsed day,
so the forecast finish converges only when slip rate falls below 1.0 and
the line crosses the diagonal. Current trajectory: no convergence.
Exam trap. A falling line is not automatically good news. Ask what changed: descoping, a re-baselined milestone definition, or a genuine acceleration. MTA is a trend indicator, not a measure of performance — use EVM (B1) for that.
A6 Duration estimating techniques
Primary4.5.4 Time · KCI 4.5.4.2 Determine the work effort and duration of activities
Where a duration number comes from before it enters the network.
Four techniques, in ascending order of effort and accuracy. Exams usually give you the data for one and ask you to apply it, or describe a situation and ask which technique fits.
Analogous duration = past duration × scaling factor top-down, fast, low accuracy
Parametric duration = quantity × productivity rate needs a validated rate
Bottom-up duration = sum of work-package durations highest effort and accuracy
Three-point see A3 quantifies the uncertainty
Worked example — all four on the same activity
Activity: migrate 240 customer data tables to a new core platform.
Analogous
Previous migration: 160 tables in 20 days.
Scaling by volume: 20 × (240 / 160) = 30 daysParametric
Validated rate: 1 engineer completes 4 tables per day. Team of 3.
Effort = 240 / 4 = 60 engineer-days
Duration = 60 / 3 = 20 daysBottom-up
Simple tables 180 × 0.20 d = 36.0 engineer-days
Complex tables 50 × 0.75 d = 37.5 engineer-days
Reference data 10 × 2.00 d = 20.0 engineer-days
Total effort = 93.5 engineer-days
Duration at 3 engineers = 93.5 / 3 = 31.2 daysThree-point on the bottom-up figure
O = 26, M = 31, P = 46
t_e = (26 + 124 + 46) / 6 = 32.7 days
σ = (46 − 26) / 6 = 3.3 days
The parametric answer is the outlier because its rate was calibrated on simple tables only. The spread across techniques is itself information: it tells you the estimate is sensitive to the complexity mix, which is exactly what the three-point range then quantifies.
Exam trap. Effort and duration are different quantities and the conversion is not always division. Duration = effort / (resources × availability), and availability is rarely 100% — a nominal 3-person team at 80% availability gives 2.4 effective engineers, not 3. Watch for questions that hand you effort in person-days and ask for elapsed calendar time.
B Plan and control ICB4 4.5.10
All five methods in this group use one running example: a core-platform migration with BAC = €500,000 over 10 months, reported at the end of month 6.
B1 Earned value — core metrics
Primary4.5.10 Plan and control · KCI 4.5.10.3 Control project performance against the project plan and take any necessary remedial actionsAlso4.5.7 Finance · 4.5.4 Time
Whether you are ahead or behind, over or under, in one integrated set of numbers.
EVM compares three cumulative money figures at a single point in time. Planned value is what you said you would have accomplished by now. Earned value is the budget of what you actually accomplished. Actual cost is what you spent doing it. Every other EVM number is derived from these three.
PV planned value budgeted cost of work scheduled (BCWS)
EV earned value budgeted cost of work performed (BCWP)
AC actual cost actual cost of work performed (ACWP)
BAC budget at completion = total PV at the end
Cost variance CV = EV − AC negative = overspent
Schedule variance SV = EV − PV negative = behind
Cost perf. index CPI = EV / AC below 1.0 = overspent
Sched. perf. index SPI = EV / PV below 1.0 = behind
Variance % CV% = CV / EV SV% = SV / PV
The classic S-curve. EV below PV is the schedule gap; AC above EV is the cost gap. Both are measured vertically at the data date.
Worked example
At end of month 6: PV = 300,000 EV = 270,000 AC = 310,000 BAC = 500,000
CV = EV − AC = 270,000 − 310,000 = −40,000 overspent
SV = EV − PV = 270,000 − 300,000 = −30,000 behind schedule
CPI = EV / AC = 270,000 / 310,000 = 0.871 87.1 cents of value per euro spent
SPI = EV / PV = 270,000 / 300,000 = 0.900 90% of planned progress
CV% = −40,000 / 270,000 = −14.8%
SV% = −30,000 / 300,000 = −10.0%
% complete = EV / BAC = 270,000 / 500,000 = 54%
% spent = AC / BAC = 310,000 / 500,000 = 62%
The project has produced 54% of the scope while consuming 62% of the budget, six months into a ten-month plan.
Exam trap. SV is expressed in money, not time — €30,000 behind does not mean any particular number of weeks late. That is exactly what earned schedule (B4) fixes. Also memorise the sign convention: everything is EV minus something, so negative is always bad, and both indices are EV over something, so below 1.0 is always bad.
B2 Forecasting — EAC, ETC, VAC, TCPI
Primary4.5.10 Plan and control · KCI 4.5.10.4 Report on project progressAlso4.5.7 Finance
What the project will finally cost, what remains to spend, and how efficient you must become to still hit the number.
Four EAC formulas exist because they encode four different assumptions about the future. The examiner is usually testing whether you can justify which one applies, not just compute it.
EAC 1 — past variance was atypical
EAC = AC + (BAC − EV) remaining work at budgeted rate
EAC 2 — current cost performance continues
EAC = BAC / CPI = AC + (BAC − EV) / CPI
EAC 3 — cost and schedule pressure both continue
EAC = AC + (BAC − EV) / (CPI × SPI)
EAC 4 — bottom-up re-estimate
EAC = AC + new ETC
ETC = EAC − AC estimate to complete
VAC = BAC − EAC negative = forecast overrun
TCPI to BAC = (BAC − EV) / (BAC − AC)
TCPI to EAC = (BAC − EV) / (EAC − AC)
TCPI to BAC of 1.211 says the remaining work must be delivered 21% more efficiently than budgeted, when performance to date has been 13% worse than budgeted. A swing of that size without a change in method or scope is not credible — which is the argument for re-baselining to the EAC.
Exam trap. TCPI to EAC always returns roughly the current CPI when the EAC was itself derived from CPI, so it tells you nothing new — its value is as a sanity check that the two are consistent. The meaningful figure is TCPI to BAC. Rule of thumb the examiners look for: if TCPI to BAC exceeds CPI by more than about 0.10, the baseline is no longer achievable.
B3 Percent-complete conventions
Primary4.5.10 Plan and control · KCI 4.5.10.3 Control project performance against the project plan and take any necessary remedial actions
How EV gets a number attached to it in the first place, and why the choice changes your reported performance.
EV is only as honest as the rule used to credit partial progress. Each convention trades subjectivity against responsiveness.
Convention
Credit rule
Best for
Weakness
0 / 100
Nothing until complete, then full budget
Short packages inside one reporting period
Understates progress; jumpy
50 / 50
Half on start, half on completion
Packages spanning two periods
Rewards starting, not finishing
20 / 80
20% on start, 80% on completion
Long packages with heavy back end
Arbitrary split
Milestone weighting
Fixed credit at each defined milestone
Long packages with verifiable gates
Needs milestones defined up front
Units complete
Units delivered / total units
Repetitive work — tables, tickets, metres
Assumes units are equal effort
Percent complete
Manager's judgement
Nothing, ideally
Fully subjective; the 90% syndrome
Apportioned effort
Tracks a linked base package
QA, PM overhead
Inherits the base package's errors
Level of effort
EV = PV automatically
Support functions with no output
SV always zero; distorts totals
Worked example
Four work packages, €100,000 each. WP1 finished, WP2 and WP3 started but unfinished, WP4 not started.
WP1 WP2 WP3 WP4 Total EV
0/100 100,000 0 0 0 100,000
50/50 100,000 50,000 50,000 0 200,000
20/80 100,000 20,000 20,000 0 140,000
Units complete 100,000 62,000 38,000 0 200,000
With AC = 230,000 across all four:
CPI under 0/100 = 100,000 / 230,000 = 0.435
CPI under 50/50 = 200,000 / 230,000 = 0.870
CPI under 20/80 = 140,000 / 230,000 = 0.609
Same project, same spend, three CPI figures between 0.43 and 0.87. This is why the convention must be fixed in the baseline and applied consistently, and why comparing CPI across organisations is meaningless without knowing the rule.
Exam trap. Level of effort packages inflate the aggregate SPI toward 1.0 because their EV equals their PV by definition. If a question gives you an SPI that looks suspiciously healthy alongside a visibly late project, check whether LOE packages are diluting the total — the fix is to compute SPI on discrete-effort packages only.
B4 Earned schedule
Primary4.5.10 Plan and control · KCI 4.5.10.3 Control project performance against the project plan and take any necessary remedial actionsAlso4.5.4 Time
Schedule performance expressed in time units instead of money, and without the end-of-project distortion.
Instead of subtracting PV from EV vertically, you project the EV level horizontally onto the PV curve and read off the date at which that much value should have been earned. The gap between that date and today is the schedule variance in months.
ES = the time at which cumulative PV equals current EV
= N + (EV − PVN) / (PVN+1 − PVN) N = last period where PV ≤ EV
AT = actual time elapsed
SV(t) = ES − AT schedule variance in time units
SPI(t) = ES / AT
IEAC(t) = PD / SPI(t) PD = planned duration
Earned schedule reads horizontally, not vertically. The answer comes out in months.
Worked example
Baseline PV is linear at 50,000 per month over 10 months. EV = 270,000, AT = 6.0.
Find N: PV at month 5 = 250,000 ≤ 270,000; PV at month 6 = 300,000 > 270,000 → N = 5
ES = 5 + (270,000 − 250,000) / (300,000 − 250,000)
= 5 + 20,000 / 50,000
= 5.4 months
SV(t) = 5.4 − 6.0 = −0.6 months about 13 working days behind
SPI(t) = 5.4 / 6.0 = 0.900
IEAC(t) = 10 / 0.900 = 11.11 months forecast 1.1 months late
Compare: SV = −30,000 tells you the size of the gap in money but not in time.
Exam trap. Classic SPI is mathematically forced back to exactly 1.0 at project completion, because EV and PV both converge on BAC no matter how late you finish. SPI(t) does not — a project delivered two months late still shows SPI(t) = 10/12 = 0.833 at handover. If a question mentions a late-stage project with SPI near 1.0, earned schedule is the expected answer.
B5 Variance thresholds and trend extrapolation
Primary4.5.10 Plan and control · KCI 4.5.10.3 Control project performance against the project plan and take any necessary remedial actions
When a variance stops being noise and becomes a reportable exception, and where the trend is heading.
A single period's CPI is largely noise. Control is exercised on the cumulative index and its direction of travel, against tolerance bands agreed in the baseline. Thresholds are usually asymmetric and tighten as the project progresses, because the ability to recover falls as remaining work shrinks.
Cumulative index CPIcum = ΣEV / ΣAC the control figure
Period index CPIperiod = EVperiod / ACperiod the leading indicator
Threshold breach |variance %| > agreed tolerance → exception report
Linear extrapolation forecast index = current + (slope × periods remaining)
Recovery test required CPI = TCPI to BAC; feasible only if within
reach of the best period CPI achieved so far
Index trend against a tolerance band. The breach point, not the current value, is where control should have been exercised.
Worked example
CPI_cum by month: 1.00, 0.98, 0.95, 0.93, 0.90, 0.871
Tolerance: cost variance beyond ±5% requires an exception report.
First breach: month 3, CPI 0.95 — exactly at the −5% limit.
Slope over months 3–6 = (0.871 − 0.95) / 3 = −0.0263 per month
Extrapolated to month 8 = 0.871 + (−0.0263 × 2) = 0.818
Forecast at that CPI: EAC = 500,000 / 0.818 = 611,000Recovery feasibility
Required from here: TCPI to BAC = 1.211
Best period CPI achieved so far: 1.00 (month 1)
Gap between required and best-ever = 0.21 → not achievable without a
change in scope, method or baseline. Escalate rather than promise recovery.
Exam trap. Do not extrapolate from cumulative indices alone — they lag, because early good periods keep dragging the average up. The period index turns first. A question that gives both period and cumulative figures is usually testing whether you notice that the period CPI has already fallen below the cumulative one, which means the cumulative figure is still falling.
B6 Change request impact quantification
Primary4.5.10 Plan and control · KCI 4.5.10.5 Assess, get agreement on and implement project changesAlso4.5.7 Finance · 4.5.3 Scope
What a proposed change actually costs once schedule, float and risk are priced in, and which pot of money pays for it.
A change request is priced across four channels, not one. Direct effort and materials are the visible part. Schedule impact is only the portion of added duration that survives the float already in the path. Risk impact is the movement in expected monetary value caused by the change. Time-related costs then convert any surviving delay into money. The funding decision is separate from the pricing and is where most marks are lost.
Direct cost Σ(effort × rate) + materials
Net delay max(0, added duration − total float on that path)
Time-related cost net delay × daily standing cost
Risk delta ΔEMV = (p₁ × i₁) − (p₀ × i₀)
Total change value direct + time-related + ΔEMV
Cumulative ratio Σ approved change value / original BAC
Funding rule realised known risk → contingency reserve
new or altered scope → management reserve or baseline change
Ten days of added duration against six days of float. Four days extend the project; the other six consume the buffer that protected every downstream path.
Worked example
Change request: add a regulatory reporting module.
Direct cost
Effort 120 h × 85/h = 10,200
Licence and materials = 3,500
Direct total = 13,700Schedule
Added duration on the affected path 10 days
Total float available on that path 6 days
Net delay = max(0, 10 − 6) = 4 days
Standing cost 1,900/day × 4 = 7,600Risk
Integration failure, before: 0.10 × 40,000 = 4,000
Integration failure, after: 0.25 × 40,000 = 10,000
ΔEMV = 6,000Total change value 13,700 + 7,600 + 6,000 = 27,300Funding this is new scope, not a realised known risk, so contingency
may not be used. It needs management reserve or a baseline change.
Cumulative change ratio
Approved to date 41,000 + this 27,300 = 68,300
68,300 / 500,000 = 13.7% of original BAC
Exam trap. The float is the trap. Candidates add all ten days to the project finish; only four survive the float and only those four carry time-related cost. The reverse error is treating a fully float-absorbed change as free — the direct cost and the ΔEMV are still payable, and the float consumed was protecting every path downstream. Second: contingency covers risks that were identified and priced, not scope that has just been invented. Funding new scope from contingency is the single most common change-control error, and it hides the growth until the reserve is empty.
C Finance ICB4 4.5.7
C1–C6 use one running appraisal: a platform investment of €400,000 at t=0 returning €120,000 a year for five years, appraised at a 10% discount rate.
C1 Time value of money and discount factors
Primary4.5.7 FinanceAlso4.3.1 Strategy
What a future euro is worth today, which is the foundation under every other appraisal method here.
A euro received in three years is worth less than a euro today, because today's euro can be invested. Discounting converts every future cash flow back to a common point in time so that flows arriving in different years can legitimately be added together.
Future value FV = PV × (1 + r)nPresent value PV = FV / (1 + r)nDiscount factor DFn = 1 / (1 + r)nAnnuity factor AF = (1 − (1 + r)−n) / r for n equal annual flows
Perpetuity PV = C / r flow forever
Rule of 72 years to double ≈ 72 / (r in %)
Exam trap. Be explicit about whether a flow arrives at the start or end of the period. Standard convention is end of period, so a year-1 flow is discounted once, not zero times. An investment made at t=0 is not discounted. Getting this off by one period changes NPV by roughly the discount rate.
C2 Net present value
Primary4.3.1 Strategy · KCI 4.3.1.3 Develop and ensure the ongoing validity of the business / organisational justificationAlso4.5.7 Finance
Whether an investment creates value in absolute money terms, after paying for the cost of capital.
NPV sums every discounted inflow and outflow across the appraisal period. A positive NPV means the investment beats the discount rate. It is the primary decision rule because it is additive across projects and expressed in currency, not percentages.
NPV = Σt=0n Ct / (1 + r)tDecision rule NPV > 0 accept NPV < 0 reject
among mutually exclusive options, take the highest NPV
Each year's inflow shrinks as it is pushed further into the future. The shortfall between the pale and solid bars is the cost of capital.
Worked example
Year
Cash flow
DF @ 10%
Present value
Cumulative PV
0
−400,000
1.0000
−400,000
−400,000
1
120,000
0.9091
109,091
−290,909
2
120,000
0.8264
99,174
−191,735
3
120,000
0.7513
90,158
−101,577
4
120,000
0.6830
81,962
−19,615
5
120,000
0.6209
74,511
54,896
NPV
200,000
—
54,896
—
NPV = +54,896 → accept
Sensitivity: at r = 15%, AF = 3.3522 → PV = 402,264 → NPV = +2,264
at r = 20%, AF = 2.9906 → PV = 358,872 → NPV = −41,128
The undiscounted profit looks like €200,000. Discounting removes €145,104 of that — the price of tying up €400,000 for five years.
Exam trap. Sunk costs never enter an NPV. Money already spent is irrecoverable and cannot change a forward-looking decision, however painful. Conversely, opportunity costs — the value forgone by using a resource here rather than elsewhere — do enter, even though no cash moves.
C3 Internal rate of return
Primary4.3.1 Strategy · KCI 4.3.1.3 Develop and ensure the ongoing validity of the business / organisational justificationAlso4.5.7 Finance
The discount rate at which the investment exactly breaks even, expressed as a percentage return.
IRR is the r that drives NPV to zero. It is popular with boards because it is a single comparable percentage, and dangerous for the same reason: it ignores scale and assumes reinvestment at the IRR itself.
Definition solve Σ Ct / (1 + IRR)t = 0
Linear interpolation between two trial rates
IRR ≈ r₁ + (NPV₁ / (NPV₁ − NPV₂)) × (r₂ − r₁)
Decision rule IRR > hurdle rate accept
MIRR corrects the reinvestment assumption using an explicit
reinvestment rate for inflows and finance rate for outflows
Worked example
Because the inflows are equal, use the annuity factor directly:
AF required = 400,000 / 120,000 = 3.3333
Five-year annuity factors:
at 15%: (1 − 1.15⁻⁵) / 0.15 = 3.3522
at 16%: (1 − 1.16⁻⁵) / 0.16 = 3.2743
Interpolate:
IRR = 15% + [(3.3522 − 3.3333) / (3.3522 − 3.2743)] × 1%
= 15% + (0.0189 / 0.0779) × 1%
= 15% + 0.24%
= 15.24%
Same answer from NPV trials:
NPV at 15% = +2,264 NPV at 20% = −41,128
IRR ≈ 15% + [2,264 / (2,264 + 41,128)] × 5% = 15% + 0.26% = 15.26%
Hurdle rate 10% → IRR exceeds it by 5.24 points → accept
The two interpolations differ slightly because NPV is a curve, not a line; the wider your trial rates, the larger the interpolation error. Bracket the true IRR tightly.
Exam trap. IRR breaks in three cases the examiners like. First, non-conventional cash flows — if the sign of the net flow changes more than once, there can be multiple IRRs or none. Second, mutually exclusive projects of different size: a small project with 40% IRR can create less value than a large one with 15%, so decide on NPV. Third, IRR implicitly assumes interim cash is reinvested at the IRR itself, which is why MIRR exists.
C4 Payback and discounted payback
Primary4.3.1 Strategy · KCI 4.3.1.3 Develop and ensure the ongoing validity of the business / organisational justificationAlso4.5.7 Finance
How long the money is at risk before the investment returns it.
Payback is a liquidity and risk measure, not a profitability measure. It answers "when do I get my money back", ignores everything after that point, and in its simple form ignores the time value of money entirely.
Simple payback (even flows) = initial investment / annual net inflow
Simple payback (uneven) = full years before recovery
+ (unrecovered amount / next year's flow)
Discounted payback = same, using discounted cumulative flows
Worked example
Simple payback
400,000 / 120,000 = 3.333 years = 3 years 4 monthsDiscounted payback (cumulative PV column from C2)
End of year 4: cumulative PV = −19,615 — not yet recovered
Year 5 discounted inflow = 74,511
Discounted payback = 4 + (19,615 / 74,511) = 4 + 0.263 = 4.26 years
The 0.93-year gap between the two is the cost of capital made visible.
If the organisation applies a four-year payback rule, this investment passes on simple payback and fails on discounted payback. Which rule is written into the governance framework decides the outcome, not the arithmetic.
Exam trap. Payback is blind to everything beyond the payback point. Two options with identical 3.3-year payback can have radically different NPVs if one stops earning in year 4 and the other runs for fifteen. Never present payback as a standalone accept/reject rule — present it as a risk-exposure figure alongside NPV.
C5 Profitability index, benefit-cost ratio and ROI
Primary4.3.1 Strategy · KCI 4.3.1.3 Develop and ensure the ongoing validity of the business / organisational justificationAlso4.5.7 Finance
Value per unit of money invested — the measure you need when capital is rationed.
NPV tells you how much value is created; PI tells you how efficiently. When the constraint is a fixed capital budget rather than a hurdle rate, ranking by PI produces the highest total NPV within the constraint.
Profitability index PI = PV of future inflows / initial investment
equivalently PI = 1 + (NPV / initial investment)
Benefit-cost ratio BCR = PV of benefits / PV of costs
Simple ROI ROI = (total benefit − total cost) / total cost
Annualised ROI = simple ROI / number of years (approximation)
Decision rule PI > 1.0 accept; under capital rationing rank by PI
Worked example
PI = 454,896 / 400,000 = 1.137
check: 1 + (54,896 / 400,000) = 1 + 0.137 = 1.137 ✓
BCR = 454,896 / 400,000 = 1.14 (costs all at t=0, so PV of costs = 400,000)
Simple ROI = (600,000 − 400,000) / 400,000 = 50% over five years
Annualised = 50% / 5 = 10% per year — note this ignores compounding
and is therefore below the true IRR of 15.24%
Capital rationing budget 500,000, three competing projects:
NPV Investment PI
Project X 54,896 400,000 1.137
Project Y 38,000 200,000 1.190
Project Z 61,000 500,000 1.122
Ranking by NPV alone picks Z: total NPV = 61,000
Ranking by PI picks Y then X: 200,000 + 400,000 = 600,000 — over budget
Feasible best: Y + partial, or Y alone plus reserve.
Y + X is infeasible; Y alone = 38,000; Z alone = 61,000 → take Z.
PI ranks correctly only when the projects are divisible or the budget can be filled exactly. Where it cannot, you must test the feasible combinations against total NPV, which is the point of the last block above.
Exam trap. Simple ROI is not comparable to IRR and never should be presented alongside it without saying so. ROI has no time dimension, so a 50% return over five years and a 50% return over one year produce the same figure. Also watch the denominator: some organisations define ROI on total cost, others on net investment after residual value.
C6 Discount rate selection and WACC
Primary4.5.7 FinanceAlso4.3.1 Strategy
Where the r in every formula above actually comes from.
The discount rate represents the organisation's cost of capital plus, in most frameworks, a premium for project-specific risk. The weighted average cost of capital blends the cost of equity and the after-tax cost of debt in the proportions the organisation actually uses.
WACC = (E/V × Re) + (D/V × Rd × (1 − T))
E = market value of equity Re = cost of equity
D = market value of debt Rd = cost of debt
V = E + D T = corporate tax rate
CAPM for the cost of equity
Re = Rf + β(Rm − Rf)
Rf = risk-free rate β = systematic risk (Rm − Rf) = market premium
Risk-adjusted project rate = WACC + project risk premium
Worked example
Capital structure: 60% equity, 40% debt. Tax rate 20%.
Cost of equity via CAPM: R_f = 3.5%, β = 1.2, market premium = 5.5%
R_e = 3.5% + 1.2 × 5.5% = 3.5% + 6.6% = 10.1%
Cost of debt R_d = 6.0%
WACC = (0.60 × 10.1%) + (0.40 × 6.0% × (1 − 0.20))
= 6.06% + (0.40 × 4.8%)
= 6.06% + 1.92%
= 7.98%
Project risk premium for a first-of-kind platform migration: +2.0%
Discount rate applied = 7.98% + 2.0% ≈ 10% ← the rate used in C1–C5
Effect of getting it wrong:
at 8% NPV = 120,000 × 3.9927 − 400,000 = +79,124
at 12% NPV = 120,000 × 3.6048 − 400,000 = +32,576
A four-point error moves NPV by 46,548 — 85% of the base-case NPV.
Exam trap. Debt is multiplied by (1 − T) because interest is tax-deductible; equity is not. Forgetting the tax shield overstates WACC. Second point examiners probe: WACC is the right rate only for projects with the same risk profile as the firm's existing business. A materially riskier project needs a higher rate, or you will systematically approve bad projects and reject good safe ones.
What the thing costs across its whole life, not just what it costs to build.
LCC captures acquisition, operation, maintenance, upgrade and disposal. Two options with identical purchase prices routinely differ by 40% or more over a life cycle, and the difference usually sits in the run costs and the timing.
LCC = acquisition + operation + maintenance + upgrade + disposal − residual value
Discounted LCC = Σ (cost in year t) / (1 + r)tEquivalent annual cost EACann = discounted LCC / annuity factor
use this to compare options with different lives
Worked example — build vs subscribe
Cost element
Build: nominal
Build: PV @10%
Subscribe: nominal
Subscribe: PV @10%
Acquisition / setup, t=0
350,000
350,000
60,000
60,000
Annual run, yrs 1–5
300,000
227,448
650,000
492,804
Major upgrade, yr 3
80,000
60,104
—
—
Decommission / exit, yr 5
20,000
12,418
40,000
24,836
Total
750,000
649,970
750,000
577,640
Annual run, build: 60,000 × AF(10%,5) = 60,000 × 3.7908 = 227,448
Annual run, subscribe: 130,000 × 3.7908 = 492,804
Upgrade in year 3: 80,000 × 0.7513 = 60,104
Nominal totals are identical at 750,000.
Discounted, subscribing is cheaper by 72,330 — 11% of the LCC.
The entire difference comes from timing. Building front-loads €350,000 to t=0 where no discount applies; subscribing spreads the same money across five discounted years. Nothing about the two options' quality has been assessed — only when the cash leaves.
Exam trap. When two options have different useful lives, comparing raw LCC totals is invalid. Convert both to equivalent annual cost, or extend both to a common horizon (lowest common multiple of the lives). A five-year option at €578k and an eight-year option at €790k cannot be compared directly: €578k/3.7908 = €152k per year against €790k/5.3349 = €148k per year, which reverses the ranking.
C8 Break-even analysis
Primary4.3.1 Strategy · KCI 4.3.1.3 Develop and ensure the ongoing validity of the business / organisational justificationAlso4.5.7 Finance
The volume at which a venture stops losing money, and how much headroom you have above it.
Contribution per unit = price − variable cost per unit
Break-even units = fixed costs / contribution per unit
Break-even revenue = fixed costs / contribution margin ratio
Contribution margin % = contribution per unit / price
Margin of safety = (expected volume − break-even volume) / expected volume
Target-profit volume = (fixed costs + target profit) / contribution per unit
Break-even is where the revenue line crosses total cost, not where it crosses fixed cost.
Worked example
Fixed costs 180,000. Price 45 per unit. Variable cost 27 per unit.
Contribution per unit = 45 − 27 = 18
Contribution margin = 18 / 45 = 40%
Break-even units = 180,000 / 18 = 10,000 units
Break-even revenue = 180,000 / 0.40 = 450,000 (check: 10,000 × 45 ✓)
Expected volume 14,000 units:
Margin of safety = (14,000 − 10,000) / 14,000 = 28.6%
Profit = (14,000 × 18) − 180,000 = 252,000 − 180,000 = 72,000
Volume needed for a 90,000 profit:
(180,000 + 90,000) / 18 = 15,000 units
Sensitivity: a 10% price cut to 40.50 drops contribution to 13.50
new break-even = 180,000 / 13.50 = 13,333 units — up 33%
A 10% price move produced a 33% move in break-even volume. Contribution-based businesses are far more sensitive to price than to volume, which is why discounting decisions belong at governance level.
Exam trap. Costs must be split into fixed and variable before you start, and semi-variable costs must be decomposed — typically with the high-low method: variable rate = (cost at high volume − cost at low volume) / (high volume − low volume). Questions often bury a stepped fixed cost (a second shift, a second server tier) that jumps at a volume threshold, which creates two break-even points.
C9 Cash flow forecasting and the funding requirement
How much cash the project needs at its deepest point, and when.
The budget tells you the total; the cash flow profile tells you the peak exposure. The funding requirement is the largest cumulative negative position, and it is what the treasury function actually has to arrange.
Net cash flowt = inflowst − outflowstCumulative position = Σ net cash flow up to t
Funding requirement = |most negative cumulative position|
Peak funding date = the period in which that low point occurs
Buffer = funding requirement × (1 + management reserve %)
The trough, not the total spend, sets the credit facility the project needs.
Worked example
Month
Outflow
Inflow
Net
Cumulative
1
70,000
0
−70,000
−70,000
2
70,000
0
−70,000
−140,000
3
85,000
30,000
−55,000
−195,000
4
85,000
45,000
−40,000
−235,000
5
90,000
70,000
−20,000
−255,000
6
95,000
55,000
−40,000
−295,000
7
90,000
65,000
−25,000
−320,000
8
60,000
70,000
+10,000
−310,000
Peak
—
—
—
−320,000 in month 7
Funding requirement = 320,000, needed by end of month 7
With a 10% management reserve: facility to arrange = 320,000 × 1.10 = 352,000
Note the total project spend to month 8 is 645,000, but the facility
needed is half that, because inflows arrive alongside the outflows.
Cost of carry: 320,000 held for 4 months at 6% p.a.
= 320,000 × 0.06 × (4/12) = 6,400 — a real project cost, often omitted
Exam trap. Cash flow is not the same as cost accrual. An invoice recognised in month 3 on 60-day terms leaves the bank in month 5, and the shift can move the peak funding date by a whole quarter. If a question gives payment terms, use them — that is the point of the question.
C10 Cost estimating techniques and estimate classes
How a cost number is produced, and how much to trust it at each stage.
Analogous cost = past cost × scaling factor −25% to +75% typical
Parametric cost = quantity × unit rate needs a validated rate
Bottom-up cost = Σ work-package costs −5% to +15% typical
Three-point cost = (O + 4M + P) / 6 with σ = (P − O)/6
Vendor bid cost = quoted price + internal effort
Scaling with capacity cost₂ = cost₁ × (capacity₂ / capacity₁)x
x is typically 0.6–0.7 — economies of scale
Estimate accuracy narrows as design definition increases. Most frameworks define five classes, from an order-of-magnitude figure at concept to a definitive figure at execution readiness. The class, not the number, is what a governance board should be told.
Stage
Technique
Typical range
Use
Concept
Analogous
−30% / +50%
Screening, portfolio triage
Feasibility
Parametric
−20% / +30%
Business case
Definition
Mixed
−15% / +20%
Funding request
Design complete
Bottom-up
−10% / +15%
Baseline
Execution
Bottom-up + actuals
−5% / +10%
Control
Worked example — same scope, four techniques
Scope: migrate 240 tables (from A6), plus environment and testing.
Analogous previous 160-table migration cost 520,000
520,000 × (240/160) = 780,000Capacity-scaled analogous with x = 0.65
520,000 × (240/160)^0.65 = 520,000 × 1.2846 = 668,000Parametric validated rate 2,900 per table
240 × 2,900 = 696,000Bottom-up migration effort 93.5 person-days × 1,400 = 130,900
environment build = 95,000
test cycles (3 × 62,000) = 186,000
vendor licences = 240,000
PM and governance 12% of the above = 78,228
total = 730,128Three-point on the bottom-up
O = 640,000 M = 730,000 P = 950,000
Expected = (640,000 + 2,920,000 + 950,000) / 6 = 751,667
σ = (950,000 − 640,000) / 6 = 51,667
P80 figure ≈ 751,667 + 0.842(51,667) = 795,170
The linear analogous estimate is 12% above the capacity-scaled one, because doubling the volume of a migration does not double the fixed environment and tooling work. When a question gives you a scaling exponent, it is testing exactly that.
Exam trap. An estimate range is not the same as contingency. The range describes the estimator's uncertainty; contingency is money actually set aside against identified risk (C11). A −10%/+15% estimate with zero contingency is not a funded project. Also: parametric rates must come from the same organisation, technology and period, or they are analogous estimates wearing a parametric label.
C11 Contingency, management reserve and the cost baseline
Primary4.5.7 Finance · KCI 4.5.7.2 Establish the project budgetAlso4.5.11 Risk and opportunity
Which pot of money covers which kind of surprise, and who is allowed to release it.
The distinction is about authority as much as arithmetic. Contingency covers identified risks and sits inside the project manager's control. Management reserve covers unknown-unknowns and sits with the sponsor. Only one of the two is inside the cost baseline.
Cost baseline = work package estimates + contingency reserve
Cost budget = cost baseline + management reserve
Contingency covers known risks, released by the project manager,
measured against EVM (it is part of PV and BAC)
Management reserve covers unknown risks, released by the sponsor via
change control, and sits outside BAC
Contingency sizing = Σ EMV of identified risks (see D4)
or = P80 estimate − P50 estimate (from Monte Carlo, D5)
Worked example
Work package estimates (bottom-up) 730,000
Contingency: sum of risk EMVs + 68,000
---------
Cost baseline = BAC798,000
Management reserve at 8% of baseline + 63,840
---------
Total cost budget861,840
Alternative sizing from Monte Carlo:
P50 = 751,000 P80 = 812,000
Contingency = 812,000 − 751,000 = 61,000
Effect on EVM. When a risk fires and 40,000 of contingency is drawn:
AC rises by 40,000 immediately.
EV does not rise, because no additional scope was completed.
→ CPI falls. Contingency draw always shows as cost overrun in EVM
unless the contingency was distributed into the affected packages.
When management reserve is released instead:
BAC and the baseline are formally increased through change control,
so PV, EV and BAC all move together and CPI is not distorted.
Exam trap. Management reserve is not in BAC. A question giving you "budget 861,840, of which 63,840 management reserve" and asking for EAC expects BAC = 798,000. Second trap: contingency is not a percentage plucked from air — if a question describes a risk register with probabilities and impacts, it wants an EMV-derived figure, not "10% of budget".
C12 Inflation and currency exposure
Primary4.5.7 FinanceAlso4.5.11 Risk and opportunity
Keeping cash flows and discount rates in the same money, and sizing the exchange-rate risk on cross-border work.
Fisher relationship (1 + nominal) = (1 + real) × (1 + inflation)
real rate = ((1 + nominal) / (1 + inflation)) − 1
Consistency rule nominal cash flows → discount at the nominal rate
real cash flows → discount at the real rate
never mix the two
Escalating a cost costyear n = costtoday × (1 + i)nInterest rate parity F = S × (1 + rquote) / (1 + rbase)
FX exposure = contracted foreign amount × (worst rate − budget rate)
Worked example — inflation
Nominal discount rate 10%, expected inflation 3%.
Real rate = (1.10 / 1.03) − 1 = 1.06796 − 1 = 6.796%
(the approximation 10% − 3% = 7% is close but not exact; use the ratio)
A cost of 100,000 in today's money, incurred in year 4:
nominal cost = 100,000 × 1.03⁴ = 100,000 × 1.1255 = 112,551
discounted at nominal 10%: 112,551 × 0.6830 = 76,872
same flow in real terms: 100,000 × (1/1.06796⁴) = 100,000 × 0.7687 = 76,872 ✓
Both routes give the same answer. Mixing them — discounting a real
100,000 at the nominal 10% — gives 68,300, understating by 11%.
WORKED EXAMPLE — CURRENCY
A contract commits the project to pay USD 600,000 in twelve months.
Budget rate 1.08 USD per EUR.
Budgeted cost = 600,000 / 1.08 = 555,556 EUR
Adverse scenario: USD strengthens to 1.00
Cost becomes = 600,000 / 1.00 = 600,000 EUR
Exposure = 600,000 − 555,556 = 44,444 EUR (+8.0%)
Forward rate via interest rate parity, EUR rate 3.0%, USD rate 4.5%:
F = 1.08 × (1.045 / 1.030) = 1.08 × 1.01456 = 1.0957
Hedged cost = 600,000 / 1.0957 = 547,595 EUR
Hedging locks in a cost 7,961 below the budget rate and removes the
44,444 downside. The residual risk is that the rate moves favourably
and the hedge becomes an opportunity cost.
Exam trap. The approximation real ≈ nominal − inflation is only acceptable at low rates. At 20% nominal and 12% inflation it gives 8% against a true 7.14% — an 11% relative error that compounds over the appraisal period. Use the ratio form unless the question explicitly permits the approximation.
C13 Depreciation
Primary4.5.7 Finance
How a capital asset's cost is spread across the periods that benefit from it — which changes reported profit, tax and therefore project cash flow.
Straight line annual charge = (cost − residual value) / useful life
Reducing balance annual charge = net book value × rate
Units of production charge = (cost − residual) × (units this period / total units)
Sum of years' digits charge = (cost − residual) × remaining life / Σdigits
Net book value = cost − accumulated depreciation
Tax shield = depreciation charge × tax rate (a real cash benefit)
Worked example
Asset cost €240,000, useful life 5 years, residual value €40,000. Depreciable amount = €200,000.
Year
Straight line
NBV
Reducing balance @30%
NBV
1
40,000
200,000
72,000
168,000
2
40,000
160,000
50,400
117,600
3
40,000
120,000
35,280
82,320
4
40,000
80,000
24,696
57,624
5
40,000
40,000
17,287
40,337
Total
200,000
—
199,663
—
Straight line = (240,000 − 40,000) / 5 = 40,000 per year
Reducing balance year 1 = 240,000 × 0.30 = 72,000
year 2 = 168,000 × 0.30 = 50,400Units of production, total expected output 500,000 units,
year 1 actual 120,000 units:
200,000 × (120,000 / 500,000) = 48,000Tax shield at 20% tax, year 1:
straight line 40,000 × 0.20 = 8,000 cash saved
reducing balance 72,000 × 0.20 = 14,400 cash saved
PV of the shield over 5 years at 10%:
straight line 40,000 × 0.20 × 3.7908 = 30,326
reducing balance (14,400×0.9091)+(10,080×0.8264)+(7,056×0.7513)
+(4,939×0.6830)+(3,457×0.6209) = 32,238
Accelerated depreciation moves the tax relief forward, so its present value is higher — €1,912 more here — even though the nominal total relief is almost identical.
Exam trap. Depreciation is a non-cash charge and must be added back when building a cash flow forecast. It enters the appraisal only through its tax effect. A question that hands you accounting profit and asks for NPV expects: cash flow = profit after tax + depreciation.
D Risk and opportunity ICB4 4.5.11
D1–D7 use one register of five risks on the €730,000 migration from C10.
D1 Probability-impact matrix and risk scoring
Primary4.5.11 Risk and opportunity · KCI 4.5.11.3 Assess the probability and impact of risks and opportunities
Ranking risks quickly when you have judgement but not reliable numbers.
Each risk gets a probability band and an impact band, usually on a 1–5 scale. The product is a risk score, and the matrix cell determines the response required. It is ordinal, not cardinal: a score of 20 is not twice as bad as a score of 10.
Risk score = probability rating × impact rating
Typical bands 1 very low 2 low 3 medium 4 high 5 very high
Zones score 1–4 accept, monitor
score 5–9 manage, named owner
score 10–14 mitigate actively, reserve allocated
score 15–25 escalate, avoid or transfer
Multi-criteria impact impact rating = max(cost, time, quality, reputation)
or a weighted blend if the framework defines one
R2 scores 16 and must be escalated; R4 is a rare but severe risk sitting in a cell that ordinal scoring under-weights.
Worked example
ID
Risk
P rating
I rating
Score
Zone
R1
Vendor delivery slips
3
4
12
Mitigate
R2
Data quality defects
4
4
16
Escalate
R3
Key engineer leaves
2
3
6
Manage
R4
Regulatory change
1
5
5
Manage
R5
Vendor delivers early (opportunity)
2
3
6
Exploit
Ranking by score: R2 (16) > R1 (12) > R3 = R5 (6) > R4 (5)
Ranking by EMV (D2, using the money values):
R1 (30,000) > R2 (20,000) > R3 (16,000) > R4 (12,000)
The two rankings disagree at the top. Ordinal scoring puts R2 first;
monetary expectation puts R1 first, because R1's impact band (4) covers
100,000 while R2's band (4) covers only 40,000 in this register.
Exam trap. The matrix systematically mis-ranks low-probability, catastrophic risks like R4. A score of 5 sits it beside a routine staffing risk, yet its unmitigated impact could end the project. Whenever an exam register contains a 1×5 risk, the expected answer names the limitation of ordinal scoring and moves to EMV or a separate severity screen.
D2 Expected monetary value
Primary4.5.11 Risk and opportunity · KCI 4.5.11.3 Assess the probability and impact of risks and opportunitiesAlso4.5.7 Finance
The average cost of a risk if you faced the same situation many times — the basis for pricing contingency.
EMV = probability × impact
Convention threats carry a negative impact, opportunities positive
(or: express both as costs, with opportunities negative)
Aggregate total EMV = Σ EMV of all risks
Post-response EMV = residual probability × residual impact
Value of a response = EMV before − EMV after − cost of the response
Worked example
ID
Probability
Impact
EMV
R1 Vendor delivery slips
0.30
100,000
30,000
R2 Data quality defects
0.50
40,000
20,000
R3 Key engineer leaves
0.20
80,000
16,000
R4 Regulatory change
0.10
120,000
12,000
R5 Vendor delivers early
0.25
−40,000
−10,000
Total risk exposure
—
—
68,000
R1 EMV = 0.30 × 100,000 = 30,000
Total = 30,000 + 20,000 + 16,000 + 12,000 − 10,000 = 68,000
→ the contingency reserve figure used in C11.
Evaluating a response to R2.
Proposed: a data profiling and cleansing sprint costing 15,000.
Effect: probability falls 0.50 → 0.15, impact unchanged at 40,000.
EMV before = 0.50 × 40,000 = 20,000
EMV after = 0.15 × 40,000 = 6,000
Reduction = 14,000
Cost = 15,000
Net value = 14,000 − 15,000 = −1,000 → not justified on EMV alone
If the response also cut impact to 25,000:
EMV after = 0.15 × 25,000 = 3,750
Net value = (20,000 − 3,750) − 15,000 = +1,250 → justified
Exam trap. EMV is an average over many repetitions, and a project runs once. A risk with EMV of €12,000 built from a 10% chance of €120,000 will, on the day, cost either nothing or €120,000 — never €12,000. This is why EMV sizes the reserve pool across a portfolio of risks but never justifies ignoring a single ruinous exposure.
D3 Decision tree analysis
Primary4.5.11 Risk and opportunity · KCI 4.5.11.3 Assess the probability and impact of risks and opportunities
Choosing between options when each leads to uncertain outcomes, by rolling expected values back to the decision point.
Squares are decisions you control, circles are chance events you do not. You build the tree left to right and evaluate it right to left, replacing each chance node with its EMV and each decision node with the best branch.
At a chance node node value = Σ (branch probability × branch value)
At a decision node node value = best branch value; prune the others
Roll back evaluate from the right-hand ends toward the root
EVPI expected value of perfect information
= EV with perfect information − EV of the best single decision
Chance nodes collapse to their EMV; the decision node takes the better of the two. Cost minimisation, so lower wins.
Worked example
Branch A — build in-house
Base cost 400,000.
Works first time p = 0.60 → total 400,000
Rework needed p = 0.40 → total 400,000 + 200,000 = 600,000
EMV = (0.60 × 400,000) + (0.40 × 600,000)
= 240,000 + 240,000 = 480,000Branch B — buy from vendor
Base cost 450,000.
Clean integration p = 0.80 → total 450,000
Integration issues p = 0.20 → total 450,000 + 100,000 = 550,000
EMV = (0.80 × 450,000) + (0.20 × 550,000)
= 360,000 + 110,000 = 470,000Decision: buy. Expected saving 10,000.
Sensitivity. The decision flips if the build rework probability
falls below p where 400,000 + 200,000p = 470,000
200,000p = 70,000 → p = 0.35
So the recommendation is only 5 percentage points from reversing. That
fragility, not the 10,000, is what a board needs to hear.
Exam trap. Branch probabilities at a chance node must sum to 1.0 and the branches must be mutually exclusive. Two other habits earn marks: always state whether the tree is minimising cost or maximising benefit (the "best" branch flips), and always run the sensitivity, because a near-tie decision presented as a firm recommendation is the kind of answer assessors mark down.
D4 Contingency sizing from aggregate exposure
Primary4.5.11 Risk and opportunity · KCI 4.5.11.3 Assess the probability and impact of risks and opportunitiesAlso4.5.7 Finance
Converting a risk register into a defensible reserve figure.
Three routes exist, in ascending order of rigour. Which one is acceptable depends on the governance framework, but the EMV route is the minimum defensible standard at Level B.
1. Percentage rule contingency = baseline × fixed %
fast, indefensible, ignores the actual risk profile
2. EMV aggregation contingency = Σ EMV of identified risks
defensible, but assumes independence and gives a P50-ish figure
3. Simulated percentile contingency = Ptarget − P50 (from Monte Carlo, D5)
handles correlation and gives an explicit confidence level
Reserve drawdown curve plan the release profile: reserve should fall
roughly in step with the closure of the risks it was sized against
Worked example — three routes on the same register
Cost baseline before contingency: 730,000
Route 1 flat 10% rule
contingency = 73,000 no traceability to any specific risk
Route 2 EMV aggregation (D2)
contingency = 68,000 traceable line by line to R1–R5
Route 3 Monte Carlo at P80 (D5)
P50 = 751,000, P80 = 812,000
contingency = 812,000 − 751,000 = 61,000 above the P50 estimate
or 812,000 − 730,000 = 82,000 above the deterministic baseline
The three answers differ by 21,000 — 29% of the smallest. State which
route you used and against which base, or the number is not interpretable.
Drawdown plan
R4 regulatory window closes at month 3 → release 12,000
R2 data quality resolved at month 5 → release 20,000 if unused
R1 vendor delivery confirmed at month 7 → release 30,000 if unused
Reserve held to closure 16,000 (R3, staffing)
Exam trap. Summing EMVs assumes the risks are independent. They rarely are — vendor delay (R1) and data quality (R2) share a root cause in this register, so they will tend to fire together and the true aggregate exposure exceeds the sum of the individual EMVs. Correlation is the reason Monte Carlo exists; say so if the question gives you correlated risks.
D5 Monte Carlo simulation
Primary4.5.11 Risk and opportunity · KCI 4.5.11.3 Assess the probability and impact of risks and opportunitiesAlso4.5.4 Time · 4.5.7 Finance
The full distribution of possible outcomes, not a single number, produced by sampling every uncertain input thousands of times.
You assign a probability distribution to each uncertain input, draw one random value from each, compute the model output, and repeat. The collected outputs form a distribution you can read percentiles from. It is the only method here that handles correlation and path convergence properly.
Common input distributions
Triangular defined by O, M, P mean = (O + M + P) / 3
Beta-PERT defined by O, M, P mean = (O + 4M + P) / 6, less tail weight
Normal defined by μ, σ symmetric, unbounded — rarely right for cost
Uniform defined by min, max use when only the range is known
Discrete for risk events: p of occurring, impact if it does
Reading the output
P50 median — equal chance of over or under
P80 the common governance commitment level
P90 used where overrun is severely penalised
contingency = Ptarget − P50
The output S-curve. Steep means low uncertainty; flat means the range of plausible outcomes is wide.
Worked example
Model inputs
Migration effort triangular O 100k M 131k P 190k
Environment build triangular O 80k M 95k P 140k
Test cycles triangular O 150k M 186k P 260k
Licences fixed 240k
PM and governance 12% of the above, correlated to total
R1 vendor delay discrete p 0.30, impact 100k
R2 data quality discrete p 0.50, impact 40k
Deterministic sum of most-likely values
131 + 95 + 186 + 240 = 652k, plus 12% = 730k ← the C10 baseline
Simulation output, 10,000 iterations
P10 = 698,000 P50 = 751,000 P80 = 812,000 P90 = 838,000
mean = 761,000 σ = 48,000
Two things to notice
1. P50 (751k) exceeds the deterministic baseline (730k) by 21,000.
Right-skewed inputs and one-sided risk events push the median above
the sum of most-likely values. This is why "sum the most likely
figures" systematically underfunds projects.
2. Mean (761k) exceeds P50 (751k). In a right-skewed distribution the
mean is always above the median, so a mean-based commitment already
carries under 50% confidence.
Contingency at P80 = 812,000 − 751,000 = 61,000
Exam trap. Correlation and merge bias. If two parallel schedule paths each have an 80% chance of finishing on time and are independent, the chance that both do is 0.8 × 0.8 = 64% — so the merge point is late more often than either path alone. Deterministic CPM cannot see this; Monte Carlo can. Any question about parallel paths converging on a milestone is asking about merge bias.
D6 Sensitivity analysis and tornado diagrams
Primary4.5.11 Risk and opportunity · KCI 4.5.11.3 Assess the probability and impact of risks and opportunitiesAlso4.3.1 Strategy
Which input variables actually move the answer, so you know where to spend effort reducing uncertainty.
You vary one input at a time across its plausible range, holding the others at base case, and record the swing in the output. Sorting the swings by magnitude gives a tornado shape: the widest bar at the top is the variable that matters.
Swing = output at high input − output at low input
Sensitivity / elasticity = (% change in output) / (% change in input)
Switching value = the input value at which the decision reverses
(e.g. the NPV = 0 point for that variable)
Ordered widest to narrowest. Benefit realisation is worth four times the analytical attention of the discount rate.
Worked example
Base case from C2: NPV = €54,896 on a €400,000 investment returning €120,000 a year for five years at 10%.
Variable
Low case NPV
High case NPV
Swing
Rank
Annual benefit ±20%
−36,083
145,875
181,958
1
Project life ±1 year
−19,612
122,636
142,248
2
Initial cost ±15%
−5,104
114,896
120,000
3
Discount rate ±4 pts
32,576
79,124
46,548
4
Annual benefit −20%
96,000 × AF(10%,5) = 96,000 × 3.7908 = 363,917
NPV = 363,917 − 400,000 = −36,083Elasticity of NPV to benefit
% change in NPV = (−36,083 − 54,896) / 54,896 = −165.7%
% change in input = −20%
elasticity = 165.7 / 20 = 8.3 a 1% benefit shortfall costs 8.3% of NPV
Switching values — where NPV hits zero
Annual benefit: 400,000 / 3.7908 = 105,519 (−12.1% from base)
Initial cost: 454,896 (+13.7% from base)
Discount rate: the IRR, 15.24% (+5.2 points)
Project life: between 4 and 5 years — the project does not
break even until part way through year 5
The benefit stream needs only a 12% shortfall to destroy the case, while the cost estimate has 14% of headroom. That reverses where most projects put their assurance effort.
Exam trap. One-at-a-time sensitivity ignores interactions. If benefits fall because adoption is slow, the project life usually extends and costs usually rise too — three bars moving together, which the tornado cannot show. Sensitivity analysis identifies the variables worth simulating; Monte Carlo then handles them jointly. Present them as a pair, not as alternatives.
D7 Risk-adjusted schedule and cost forecasts
Primary4.5.11 Risk and opportunity · KCI 4.5.11.3 Assess the probability and impact of risks and opportunitiesAlso4.5.10 Plan and control
Folding quantified risk back into the committed dates and numbers.
Risk-adjusted cost = deterministic estimate + contingency at the
agreed confidence level
Risk-adjusted duration = deterministic critical path + schedule
contingency (buffer) at the agreed level
Expected delay = Σ (probability × delay impact)
Commitment level state the percentile: "P80 of 812,000"
not "812,000"
Worked example
Cost
Deterministic baseline (C10) 730,000
Contingency at P80 (D5) + 82,000
Risk-adjusted cost commitment = 812,000 (P80)
Management reserve, sponsor-held + 63,840
Total authorised budget = 875,840
Schedule
Deterministic critical path 12.0 months
Schedule risks:
R1 vendor delay p 0.30, impact 2.0 months → 0.60
R2 data quality p 0.50, impact 0.8 months → 0.40
R3 key engineer p 0.20, impact 1.5 months → 0.30
R5 early delivery p 0.25, impact −0.5 months → −0.125
Expected delay = 0.60 + 0.40 + 0.30 − 0.125 = 1.175 months
Expected duration = 12.0 + 1.18 = 13.2 months
Simulated P80 duration = 14.1 months
Schedule buffer to commit at P80 = 14.1 − 12.0 = 2.1 monthsWhat to publish
Internal working target 12.0 months / 730,000 (P30–P40)
Committed external date 14.1 months / 812,000 (P80)
The gap between them is the buffer, and it must be visible
to the sponsor and invisible to the delivery teams.
Exam trap. Never add cost contingency and schedule contingency as if they were independent choices — a delay usually costs money (time-related overheads, extended team) and a cost problem usually costs time. Double-counting is as common an error as omission: if your cost model already contains R1's €100,000 impact and your schedule model already contains R1's two months, and the two months are separately priced at €60,000 of standing costs, you have counted part of R1 twice.
D8 Probability fundamentals
Primary4.5.11 Risk and opportunity · KCI 4.5.11.3 Assess the probability and impact of risks and opportunities
The arithmetic underneath every method in this group.
Complement P(not A) = 1 − P(A)
Independent AND P(A and B) = P(A) × P(B)
General AND P(A and B) = P(A) × P(B | A)
Mutually excl. OR P(A or B) = P(A) + P(B)
General OR P(A or B) = P(A) + P(B) − P(A and B)
At least one P(≥1 of n) = 1 − Π(1 − pi)
Expected value E[X] = Σ pixiBayes P(A | B) = P(B | A) × P(A) / P(B)
Worked example
At least one risk fires, using R1–R4 as independent:
P(none fires) = (1−0.30)(1−0.50)(1−0.20)(1−0.10)
= 0.70 × 0.50 × 0.80 × 0.90 = 0.252
P(at least one) = 1 − 0.252 = 0.748
Intuition check: no single risk exceeds 50%, yet a 75% chance that
something fires. This is why contingency exists at portfolio level.
Both parallel paths on time (merge bias, D5):
P(path 1 on time) = 0.80, P(path 2 on time) = 0.80
P(milestone on time) = 0.80 × 0.80 = 0.64
With three parallel paths: 0.80³ = 0.512Conditional: R2 data quality is twice as likely if R1 vendor delay
fires, because the vendor's data extracts drive the quality issue.
P(R1) = 0.30, P(R2 | R1) = 0.80, P(R2 | not R1) = 0.37
P(R2) = (0.30 × 0.80) + (0.70 × 0.37) = 0.24 + 0.259 = 0.499 ✓
P(both) = 0.30 × 0.80 = 0.24
If independent, P(both) would be 0.30 × 0.50 = 0.15.
Correlation raises the joint exposure by 60%.
Bayes: a schedule health check flags 90% of truly-late projects
and falsely flags 20% of healthy ones. 30% of projects are truly late.
P(late | flagged) = (0.90 × 0.30) / [(0.90 × 0.30) + (0.20 × 0.70)]
= 0.27 / (0.27 + 0.14) = 0.27 / 0.41 = 0.659
A flag means a 66% chance of a real problem, not 90%.
Exam trap. Adding probabilities that are not mutually exclusive. P(R1 or R2) is not 0.30 + 0.50 = 0.80; it is 0.30 + 0.50 − 0.24 = 0.56 using the correlated joint probability above. Any time a question puts "or" between two events that can both happen, the general OR rule applies.
E Quality ICB4 4.5.6
E1–E7 use the migration's testing data: 450 defects found across 240 migrated tables.
E1 Cost of quality
Primary4.5.6 Quality · KCI 4.5.6.1 Develop and monitor the implementation of and revise a quality management plan for the projectAlso4.5.7 Finance
What quality actually costs, split into money spent preventing problems and money spent because of them.
The PAF model divides quality cost into four categories, grouped into conformance and non-conformance. The governing insight is that prevention is the cheapest category and external failure is the most expensive, typically by an order of magnitude.
Cost of conformance
Prevention training, standards, reviews, tooling, design quality
Appraisal testing, inspection, audits, verification
Cost of non-conformance
Internal failure rework, scrap, retesting — found before delivery
External failure incidents, penalties, remediation, reputation — after
Total CoQ = prevention + appraisal + internal failure + external failure
CoQ ratio = total CoQ / total project cost
1-10-100 rule a defect costs 1 to prevent, 10 to fix in test,
100 to fix in production
Worked example
Category
Type
Cost
% of CoQ
Prevention — standards, data profiling, reviews
Conformance
40,000
8%
Appraisal — three test cycles
Conformance
90,000
18%
Internal failure — rework of failed migrations
Non-conformance
120,000
24%
External failure — post-go-live incidents
Non-conformance
250,000
50%
Total cost of quality
—
500,000
100%
Conformance = 40,000 + 90,000 = 130,000 (26%)
Non-conformance = 120,000 + 250,000 = 370,000 (74%)
CoQ ratio = 500,000 / 730,000 project cost = 68%Business case for shifting spend
Proposal: triple prevention spend, 40,000 → 120,000, targeting the
data mapping defects that drive most external failures (see E5).
Expected effect: external failure falls 60%, internal failure falls 40%.
Prevention 40,000 → 120,000 +80,000
Appraisal 90,000 → 90,000 0
Internal failure 120,000 → 72,000 −48,000
External failure 250,000 → 100,000 −150,000
---------
New total CoQ = 382,000 −118,000
Return on the prevention investment = 118,000 / 80,000 = 2.5×
Exam trap. Appraisal is a conformance cost, not a failure cost — testing is something you choose to do, not something a defect forces on you. The rework triggered by a test finding is internal failure. Questions frequently mis-file test execution as failure cost to see whether you catch it.
E2 Statistical process control
Primary4.5.6 Quality · KCI 4.5.6.3 Verify the achievement of project quality objectives and recommend any necessary corrective and/or preventive actions
Distinguishing normal process variation from a real change that needs investigating.
Control limits describe what the process actually does when nothing unusual is happening. They are calculated from the process data, not set from requirements. A point outside them, or a non-random pattern inside them, signals a special cause.
Individuals chart UCL = μ + 3σ LCL = μ − 3σ
X-bar chart UCL = x̄̄ + A₂R̄ LCL = x̄̄ − A₂R̄
A₂ depends on subgroup size: n=3 → 1.023,
n=4 → 0.729, n=5 → 0.577, n=6 → 0.483
R chart UCL = D₄R̄ LCL = D₃R̄
Out-of-control signals
1. any point beyond 3σ
2. seven consecutive points on one side of the mean (rule of seven)
3. seven consecutive points trending up or down
4. two of three consecutive points beyond 2σ on the same side
5. any non-random pattern — cycles, hugging the centre line
The run of seven points above the mean is the earlier and more actionable signal; the limit breach merely confirms it.
Worked example
Migration batch processing time, subgroups of n = 5.
Grand mean x̄̄ = 12.00 minutes. Mean range R̄ = 1.40 minutes. A₂ = 0.577.
UCL = 12.00 + (0.577 × 1.40) = 12.00 + 0.808 = 12.81 minutes
LCL = 12.00 − 0.808 = 11.19 minutes
Batch 13 recorded 13.05 minutes → above UCL → special cause,
investigate before continuing.
But batches 7–13 were all above the mean:
P(7 consecutive on one side by chance) = (0.5)⁷ = 0.0078
→ less than a 1 in 128 chance. The process had already shifted at
batch 7, six batches before the limit breach was visible.
Estimating σ from R̄ σ ≈ R̄ / d₂, d₂ = 2.326 for n = 5
σ ≈ 1.40 / 2.326 = 0.602 minutes — needed for E3
Exam trap. Control limits and specification limits are unrelated. Control limits come from the process (what it does); specification limits come from the customer (what is required). A process can be perfectly in control and still produce nothing acceptable, or be out of control while every unit passes spec. Confusing the two is the classic SPC error and the whole point of E3.
E3 Process capability — Cp, Cpk and sigma level
Primary4.5.6 Quality · KCI 4.5.6.3 Verify the achievement of project quality objectives and recommend any necessary corrective and/or preventive actions
Whether the process is good enough for the requirement, and whether it is centred on target.
Cp compares the spread of the process against the width of the specification, assuming perfect centring. Cpk drops that assumption and measures the distance to the nearer specification limit. Cp is the potential; Cpk is the reality.
Cp = (USL − LSL) / 6σ potential capability
Cpk = min[ (USL − μ) / 3&sigma , (μ − LSL) / 3σ ] actual capability
Reading the numbers
Cpk < 1.00 process cannot meet spec
Cpk = 1.00 3σ process, about 2,700 defects per million
Cpk = 1.33 4σ process, the common industrial minimum
Cpk = 1.67 5σ
Cpk = 2.00 6σ, 3.4 DPMO allowing a 1.5σ long-term drift
Sigma level z = 3 × Cpk
DPMO = defects / (units × opportunities per unit) × 1,000,000
Yield = 1 − (DPMO / 1,000,000)
Worked example
Batch processing must complete between LSL = 10.0 and USL = 14.0 minutes.
Process mean μ = 12.4 minutes, σ = 0.5 minutes (post-improvement).
Cp = (14.0 − 10.0) / (6 × 0.5) = 4.0 / 3.0 = 1.333
Cpk = min[ (14.0 − 12.4) / (3 × 0.5) , (12.4 − 10.0) / (3 × 0.5) ]
= min[ 1.6 / 1.5 , 2.4 / 1.5 ]
= min[ 1.067 , 1.600 ]
= 1.067
Cp of 1.333 says the process is narrow enough.
Cpk of 1.067 says it is off-centre — sitting 0.4 minutes above the
midpoint of 12.0, eating the upper margin.
Recentring alone, without reducing variation:
move μ from 12.4 to 12.0 → Cpk = 2.0/1.5 = 1.333 = Cp
A pure adjustment, no variation reduction, and capability rises 25%.
Defect rate at Cpk 1.067
z to the near limit = 3 × 1.067 = 3.20
P(Z > 3.20) = 0.000687 → 687 DPMO
Yield = 1 − 0.000687 = 99.93%
After recentring: z = 4.00, P = 0.0000317 → 32 DPMO, a 21× improvement
DPMO on the migration itself
450 defects, 240 tables, 12 checkable fields per table
= 450 / (240 × 12) × 1,000,000 = 450 / 2,880 × 1,000,000
= 156,250 DPMO ≈ 2.5 sigma. Nowhere near production-ready.
Exam trap. Cpk can never exceed Cp, and the two are equal only when the process is perfectly centred. If a calculation gives Cpk > Cp, you have made an arithmetic error. Second trap: a one-sided specification (a maximum response time with no minimum) has no Cp at all — only the relevant half of Cpk, sometimes written Cpu or Cpl.
E4 Sampling and sample size
Primary4.5.6 Quality · KCI 4.5.6.3 Verify the achievement of project quality objectives and recommend any necessary corrective and/or preventive actions
How many items to inspect to make a defensible statement about the whole population.
Sample size for a proportion
n = z² × p(1 − p) / e²
z = confidence z-score p = expected proportion e = margin of error
use p = 0.5 when unknown — it maximises n, the safe assumption
Finite population correction
nadj = n / (1 + (n − 1) / N) N = population size
Sample size for a mean
n = (zσ / e)²
Acceptance sampling lot size → sample size n and acceptance number c
accept the lot if defects in the sample ≤ c
Confidence z-scores 90% → 1.645 95% → 1.960 99% → 2.576
Worked example
How many migrated records to verify?
Population N = 2,400 reconciliation records. Want 95% confidence,
±5% margin of error, no prior estimate of the defect rate.
n = 1.96² × 0.5 × 0.5 / 0.05²
= 3.8416 × 0.25 / 0.0025
= 0.9604 / 0.0025
= 384.16 → 385 records
Finite population correction:
n_adj = 384.16 / (1 + (384.16 − 1) / 2,400)
= 384.16 / (1 + 0.1597)
= 384.16 / 1.1597
= 331.3 → 332 recordsEffect of tightening the margin of error
±10% → n = 0.9604 / 0.01 = 97
±5% → n = 0.9604 / 0.0025 = 385
±2.5% → n = 0.9604 / 0.000625 = 1,537
Halving the error quadruples the sample. Precision is expensive.
Using a prior estimate. Earlier cycles suggest p ≈ 0.15:
n = 3.8416 × 0.15 × 0.85 / 0.0025 = 0.4898 / 0.0025 = 196
A credible prior halves the sample. This is why pilot batches pay for themselves.
Result interpretation. 332 records sampled, 41 defective.
p̂ = 41 / 332 = 0.1235
standard error = √(0.1235 × 0.8765 / 332) = √0.000326 = 0.0181
95% CI = 0.1235 ± (1.96 × 0.0181) = 0.1235 ± 0.0354
= 8.8% to 15.9% defective across the full population
On 2,400 records that is between 211 and 382 defects.
Exam trap. Sample size depends on the margin of error and confidence level, and barely at all on population size until the sample becomes a large fraction of it. The instinct that a bigger population needs a proportionally bigger sample is wrong: 385 works for a population of 10,000 and for 10,000,000. The finite population correction only bites when n approaches N.
E5 Pareto analysis
Primary4.5.6 Quality · KCI 4.5.6.3 Verify the achievement of project quality objectives and recommend any necessary corrective and/or preventive actions
Finding the small number of causes responsible for most of the problem.
Method 1. count occurrences by cause category
2. sort descending
3. compute cumulative percentage
4. the categories reaching ~80% cumulative are the vital few
Weighted Pareto sort by (frequency × cost per occurrence) instead of
frequency alone, when impacts differ materially
Bars are frequency, the line is cumulative percentage. The break point is where the line flattens, not exactly at 80%.
Worked example
Defect category
Count
%
Cumulative %
Cost each
Total cost
Data mapping errors
187
41.6
41.6
340
63,580
Encoding / charset
96
21.3
62.9
120
11,520
Missing reference data
71
15.8
78.7
880
62,480
Rounding / precision
43
9.6
88.2
1,450
62,350
Timestamp / timezone
28
6.2
94.4
260
7,280
Duplicates
15
3.3
97.8
190
2,850
Other
10
2.2
100.0
210
2,100
Total
450
100
—
—
212,160
By frequency mapping, encoding, reference data = 78.7% of defects
By cost mapping (63,580), reference data (62,480), rounding (62,350)
= 188,410 / 212,160 = 88.8% of the cost
The two lists differ. Encoding is the second most frequent defect but
only the fifth most expensive; rounding is the fourth most frequent
and the third most expensive, because each one requires a financial
reconciliation to unwind.
Fix priority by cost, not count.
Exam trap. The 80/20 split is an observed tendency, not a law — here it is 79/43. Never force the data to hit exactly 80%; report the actual cumulative figure. Second point examiners look for: a frequency Pareto and a cost-weighted Pareto can rank differently, and the cost-weighted one is the one that should drive action.
E6 Histograms, scatter plots and correlation
Primary4.5.6 Quality · KCI 4.5.6.3 Verify the achievement of project quality objectives and recommend any necessary corrective and/or preventive actions
Seeing the shape of a distribution, and testing whether two variables actually move together.
Histogram frequency by value bucket; shows centre, spread and shape
(bimodal usually means two processes mixed together)
Correlation coefficient
r = Σ(x − x̄)(y − ȳ) / √[ Σ(x − x̄)² × Σ(y − ȳ)² ]
ranges −1 to +1; |r| > 0.7 usually called strong
Coefficient of determination r² = proportion of variance explained
Least-squares regression line y = a + bx
b = Σ(x − x̄)(y − ȳ) / Σ(x − x̄)² a = ȳ − bx̄
Scatter with fitted line and the matching histogram of defects per table. The skew is why mean and median differ (M1).
Worked example
Does table complexity predict defect count? Six sampled tables.
x complexity
y defects
x−x̄
y−ȳ
(x−x̄)(y−ȳ)
(x−x̄)²
(y−ȳ)²
2
4
−3.5
−5.67
19.83
12.25
32.11
3
6
−2.5
−3.67
9.17
6.25
13.44
5
9
−0.5
−0.67
0.33
0.25
0.44
6
8
0.5
−1.67
−0.83
0.25
2.78
8
15
2.5
5.33
13.33
6.25
28.44
9
16
3.5
6.33
22.17
12.25
40.11
Σ 33
Σ 58
—
—
64.00
37.50
117.33
x̄ = 33 / 6 = 5.50 ȳ = 58 / 6 = 9.67
r = 64.00 / √(37.50 × 117.33) = 64.00 / √4,399.9 = 64.00 / 66.33 = 0.965
r² = 0.931 → 93% of the variation in defects is explained by complexity
Regression line:
b = 64.00 / 37.50 = 1.707 defects per complexity point
a = 9.67 − (1.707 × 5.50) = 9.67 − 9.39 = 0.28
y = 0.28 + 1.71x
Predicted defects for a complexity-7 table = 0.28 + (1.71 × 7) = 12.2Use. With 50 complex tables remaining at an average complexity of 7,
forecast defects = 50 × 12.2 = 610, which sizes the remaining test
and rework effort far better than a flat average would.
Exam trap. Correlation is not causation, and it is also not slope. A steep regression line can have weak correlation and a shallow one strong correlation — r measures scatter around the line, b measures the line's gradient. Third point: never extrapolate the regression beyond the observed range of x; the relationship at complexity 20 is unknown.
E7 Defect density, removal efficiency and rework rate
Primary4.5.6 Quality · KCI 4.5.6.3 Verify the achievement of project quality objectives and recommend any necessary corrective and/or preventive actions
Normalised quality metrics that let you compare across releases, teams and phases.
Defect density = defects / size (per KLOC, per table,
per function point, per requirement)
Defect removal efficiency DRE = defects found before release
/ (found before + found after) × 100
Phase containment = defects found in the phase they were injected
/ defects injected in that phase
Rework rate = rework effort / total effort
Defect escape rate = defects found in production / total defects
Mean time to repair = total repair time / number of repairs
Worked example
Defect density
450 defects across 240 tables = 1.88 defects per table
Split by complexity band:
simple (180 tables) 148 defects → 0.82 per table
complex ( 50 tables) 262 defects → 5.24 per table
reference (10 tables) 40 defects → 4.00 per table
Complex tables carry 6.4× the defect density of simple ones.
Defect removal efficiency
Found before go-live 450
Found in production 38
DRE = 450 / (450 + 38) × 100 = 450 / 488 × 100 = 92.2%
Industry expectation for a regulated migration is 95%+, so the
test strategy under-performed by roughly 3 points.
Defects that a 95% DRE would have caught before go-live:
total defects 488 × 0.95 = 463.6 → 14 more caught in test
at a 1-10-100 cost ratio, 14 production defects at ~2,400 each
versus ~240 each in test = 30,240 avoidable costRework rate
Rework effort 142 person-days, total effort 930 person-days
= 142 / 930 = 15.3%
A rework rate above ~10% usually indicates a requirements or design
problem, not a build problem — consistent with E5, where the top
defect category is data mapping, a specification activity.
Escape rate = 38 / 488 = 7.8% (the complement of DRE)
Exam trap. Defect density is meaningless without a stated size unit, and comparisons across projects require the same unit and the same defect definition. "1.88 defects per table" and "1.88 defects per KLOC" are not comparable quantities. Second trap: DRE can only be computed after a settling period in production — a DRE quoted on go-live day is always 100% and always wrong.
F Resources ICB4 4.5.8
F1 Resource histograms and loading
Primary4.5.8 Resources · KCI 4.5.8.4 Allocate and distribute resources according to defined needAlso4.5.4 Time
Whether the schedule you built is actually staffable with the people you have.
You sum each period's resource demand across all concurrently scheduled activities and plot it against available capacity. Peaks above the capacity line are over-allocations that the network alone cannot see.
Period demand = Σ (resource units required by each active activity)
Over-allocation = period demand − available capacity, where positive
Resource-days = demand × duration; the area under the histogram
Peak-to-average = peak demand / mean demand; above ~1.5 signals
a profile that will be expensive to staff
Demand profile before levelling. The red segments are the work that has nowhere to go.
Worked example
Monthly demand: 2, 4, 8, 10, 9, 5, 4, 3, 2 engineers
Available capacity: 6 engineers
Total resource-months = 2+4+8+10+9+5+4+3+2 = 47
Mean demand = 47 / 9 = 5.22 engineers
Peak demand = 10
Peak-to-average ratio = 10 / 5.22 = 1.92 — badly peaked
Over-allocation:
month 3: 8 − 6 = 2
month 4: 10 − 6 = 4
month 5: 9 − 6 = 3
total = 9 resource-months with nowhere to go
Capacity available across the 9 months = 6 × 9 = 54 resource-months
Demand = 47. The total capacity is sufficient; only the profile is wrong.
That is the case where levelling works. If demand exceeded 54, no amount
of levelling would help — you would need more people or less scope.
Exam trap. Always test total demand against total capacity before proposing levelling. Levelling redistributes work in time; it cannot create capacity. If the area under the histogram exceeds the area under the capacity line, the answer is more resource, reduced scope or a longer schedule — not levelling.
F2 Resource levelling and smoothing
Primary4.5.8 Resources · KCI 4.5.8.4 Allocate and distribute resources according to defined needAlso4.5.4 Time
Two different ways of fixing an unstaffable profile, distinguished by whether the end date is allowed to move.
Levelling respects a hard resource constraint; delays activities as
needed even if the critical path lengthens
→ end date can move; float can be consumed entirely
→ may create a resource-critical path different from the
logical critical path
Smoothing respects the end date; adjusts activities only within
their available float
→ end date fixed; peaks reduced but not always eliminated
Test can the peak be removed using float alone?
yes → smoothing is sufficient no → levelling is required
Worked example
Same profile. Activities contributing to the month 3–5 peak:
Act P 3 engineers, months 3–5, total float 0 critical, cannot move
Act Q 3 engineers, months 4–5, total float 2 can shift
Act R 2 engineers, month 4 only, total float 4 can shift
Attempt smoothing first (end date must hold)
Shift Q by 2 months → now months 6–7
Shift R by 4 months → now month 8
New profile: 2, 4, 5, 5, 6, 8, 7, 5, 2
Month 6 now peaks at 8 — still 2 over capacity, and R and Q have
no float left. Smoothing alone is insufficient.Level (accept schedule extension)
Push Q a further 2 months beyond its float, into months 8–9.
New profile: 2, 4, 5, 5, 6, 6, 5, 6, 5, 3 over 10 months
Peak = 6, within capacity.
Peak-to-average = 6 / 4.7 = 1.28 (was 1.92)
Cost: project extends from 9 to 10 months.Resource-critical path
The logical critical path was P → ... → finish at month 9.
After levelling, Q's forced delay drives the finish. Q is now on the
resource-critical path even though its logical total float was 2.
Any further delay to Q now delays the project one-for-one.
Exam trap. After levelling, the original float figures are void. An activity shown with 2 days of total float in the logic network may have zero effective float once a resource constraint binds it. Questions that ask "what is the float of activity Q after levelling" are testing this: the answer is not the number from the CPM pass.
F3 Capacity, utilisation, FTE and man-months
Primary4.5.8 Resources · KCI 4.5.8.5 Evaluate resource usage and take any necessary corrective actions
Converting between headcount, effort and elapsed time without double-counting.
FTE = contracted hours / standard full-time hours
Available hours = FTE × working days × hours per day × availability %
Utilisation = billable or project hours / available hours
Duration = effort / (resources × availability)
Man-months = headcount × elapsed months
Two distinct figures — never conflate them
Management effort = the project manager's own time on the project
Execution effort = total team effort ≈ average headcount × duration
Worked example
Availability
Standard year: 260 working days
Less public holidays −12
Less annual leave −25
Less training and sickness −8
Productive days per FTE = 215
Applying a 15% deduction for line management, internal meetings and
administration not chargeable to the project:
Project-available days = 215 × 0.85 = 182.75 per FTE per year
= 15.2 days per month, not the nominal 21.7.
Effective availability = 182.75 / 260 = 70%Duration from effort
Effort required 93.5 person-days, nominal team of 3.
Naive: 93.5 / 3 = 31.2 working days
Realistic: 93.5 / (3 × 0.70) = 93.5 / 2.1 = 44.5 working days
A 43% difference, entirely from availability.
Man-months for a certification application
Project ran 18 months, average team size 11.
Execution effort = 11 × 18 = 198 man-months
Management effort = the PM's own 18 months at 60% allocation
= 18 × 0.60 = 10.8 man-months
These are separate figures answering separate questions. Reporting
198 as "your management effort" overstates it by a factor of 18.
Utilisation
Engineer logged 1,340 project hours against 1,462 available hours
(182.75 days × 8)
Utilisation = 1,340 / 1,462 = 91.7%
Sustained utilisation above ~85% leaves no absorption capacity for
variation, so queues and delays grow non-linearly (see L4).
Exam trap. Effort is additive, duration is not. Two 10-day activities running in parallel are 20 person-days of effort and 10 days of duration. And adding people to a late activity does not divide its duration proportionally — communication overhead grows with n(n−1)/2 (J1), so the marginal person contributes less than the last.
F4 Learning curve
Primary4.5.8 ResourcesAlso4.5.4 Time
How unit effort falls as cumulative volume doubles — essential for repetitive work like migrations, rollouts and site deployments.
Learning rate the proportion of the previous effort required when
cumulative output doubles. An 80% curve means the 2nd
unit takes 80% of the 1st, the 4th 80% of the 2nd.
Exponent b = ln(learning rate) / ln(2)
80% → b = ln(0.80)/ln(2) = −0.3219
90% → b = −0.1520 70% → b = −0.5146
Unit model Tn = T₁ × nb effort for the nth unit
Cumulative average An = T₁ × nb average across n units
Total effort = An × n
Each doubling cuts effort by the same proportion, so absolute savings shrink rapidly. Most of the benefit is captured early.
Worked example
First migration wave takes 100 hours. Assume an 80% learning curve.
b = ln(0.80) / ln(2) = −0.2231 / 0.6931 = −0.3219Unit model — effort for a specific wave
Wave 1: 100 × 1^−0.3219 = 100.0 h
Wave 2: 100 × 2^−0.3219 = 80.0 h
Wave 4: 100 × 4^−0.3219 = 64.0 h
Wave 5: 100 × 5^−0.3219
= 100 × e^(−0.3219 × ln 5)
= 100 × e^(−0.3219 × 1.6094)
= 100 × e^−0.5181 = 100 × 0.5957 = 59.6 h
Wave 8: 100 × 8^−0.3219 = 51.2 hCumulative average model — total for 8 waves
A₈ = 100 × 8^−0.3219 = 51.2 h average per wave
Total = 51.2 × 8 = 409.6 hours
Without learning: 8 × 100 = 800 hours
Saving: 800 − 409.6 = 390.4 hours, 49%Budgeting implication
Estimating all 8 waves at the wave-1 rate overstates by 95%.
Estimating them all at the wave-8 rate understates by 21%.
Neither flat rate is defensible for repetitive work.
Solving for the learning rate from actuals
Wave 1 took 100 h, wave 4 took 72 h.
72 / 100 = 4^b → ln(0.72) = b ln(4) → b = −0.3285 / 1.3863 = −0.2370
learning rate = 2^−0.2370 = 84.8% — slower learning than assumed;
re-forecast the remaining waves at 85%, not 80%.
Exam trap. Be explicit about which model the question wants. The unit model gives the effort for the nth item; the cumulative average model gives the running average and must be multiplied by n to get a total. They produce very different numbers from identical inputs — 51.2 hours for wave 8 versus 409.6 hours for all eight waves.
F5 Critical chain and buffer sizing
Primary4.5.4 Time · KCI 4.5.4.3 Decide on schedule and stage approachAlso4.5.8 Resources
Removing the safety hidden inside individual task estimates and pooling it into explicit, managed buffers.
Critical chain assumes each task estimate already contains private safety that gets consumed anyway through Parkinson's law and student syndrome. You strip it out, schedule with aggressive durations, and place the recovered time in shared buffers at the points that actually need protecting.
Critical chain the longest path through the network after resource
constraints are applied — not the same as the CPM
critical path
Aggressive duration typically the 50% confidence estimate
Safe duration typically the 90% confidence estimate
Safety removed = safe − aggressive, per task
Project buffer protects the end date; placed at the chain's end
50% rule = 50% of the critical chain length
SSQ method = √(Σ safetyi²) less inflationary on long chains
Feeding buffer protects the chain from feeding-path delays
Resource buffer an alert, not time, that a critical resource is due
Control monitor buffer consumption against chain completion, in thirds:
green 0–33%, amber 33–67%, red above 67%
Worked example
Task
Safe (90%)
Aggressive (50%)
Safety removed
Safety²
Extract
4.0
2.0
2.0
4.00
Transform
5.0
2.5
2.5
6.25
Load
3.0
1.5
1.5
2.25
Reconcile
4.0
2.0
2.0
4.00
Sign-off
2.0
1.0
1.0
1.00
Total
18.0
9.0
9.0
17.50
Traditional schedule: 18.0 weeks, safety buried inside each task.
Project buffer, 50% rule
= 50% of the critical chain = 0.50 × 9.0 = 4.5 weeks
Committed duration = 9.0 + 4.5 = 13.5 weeks (25% shorter than 18.0)
Project buffer, SSQ method
= √(4.00 + 6.25 + 2.25 + 4.00 + 1.00) = √17.50 = 4.18 weeks
Committed duration = 9.0 + 4.18 = 13.2 weeks
SSQ gives a smaller buffer because it assumes the task overruns are
independent and will partly cancel — the same logic as PERT (A3).
Feeding buffer on a non-chain path with 3.0 weeks of removed safety
= 50% × 3.0 = 1.5 weeks, inserted where the path joins the chain
Buffer control at week 7
Chain complete: 5.0 of 9.0 weeks = 55.6%
Buffer consumed: 1.2 of 4.5 weeks = 26.7%
Consumption is behind progress → green, no action.
If instead buffer consumed were 3.4 of 4.5 = 75.6% at 55.6% chain
progress → red, recovery plan required.
Exam trap. The critical chain is defined after resource levelling; the CPM critical path is defined by logic alone. They can be different sequences. Second point: buffer status is judged by comparing buffer consumed against chain completed, not against elapsed time. A project 60% through its buffer at 80% chain completion is healthy; the same buffer position at 30% completion is not.
F6 Resource competence gap scoring
Primary4.5.8 Resources · KCI 4.5.8.5 Evaluate resource usage and take any necessary corrective actions
Where the team is short of the competence the work requires, how serious each shortfall is, and which shortfalls are single points of failure.
Required and actual competence are scored on the same scale for each competence the project needs, weighted by how critical that competence is to delivery. Gaps are floored at zero so that strength in one area cannot mathematically cancel a shortfall in another. Depth — how many people meet the required level — is tracked separately from level, because a team average conceals the single point of failure that actually threatens the schedule.
Gap gi = max(0, requiredi − actuali)
Weighted gap G = Σ (wi × gi) Σwi = 1
Coverage Σ min(actuali, requiredi) / Σ requirediDepth people at or above required level, per competence
Single point depth = 1 at required level, or 0 with a live gap
Closure cost min(train, hire, contract) subject to the date the
competence is first needed
Only contract law carries a live gap, and it is the one competence where nobody on the team reaches the required level. Coverage alone would not have surfaced that.
Worked example
Competence Weight Required Actual Gap Weighted
Structural analysis 0.35 4 3 1 0.35
Contract law 0.20 3 1 2 0.40
Cost control 0.25 4 4 0 0.00
Stakeholder facil. 0.20 3 3 0 0.00
---- ------
1.00 0.75Coverage Σmin(actual, required) / Σrequired
(3 + 1 + 4 + 3) / (4 + 3 + 4 + 3) = 11 / 14 = 78.6%Depth on contract law one person at level 1, nobody at level 3
→ depth 0 — single point of failureClosure options, competence first needed in 8 weeks
Train 8,000, ready in 12 weeks — misses the date
Hire lead time 6 weeks + salary — meets the date, permanent cost
Contract 40 days × 1,150 = 46,000 — meets the date, no tail
Coverage rises to 100% under any option; only two of the three
are feasible against the date, which is the actual decision.
Exam trap. Averaging competence across the team hides exactly what the analysis exists to find: an average of 3 can be one person at 5 and two at 2, and when the 5 leaves, the project stops. Score depth separately and never report a mean on its own. Second: floor every gap at zero. If negative gaps are allowed to net off, a team that is over-competent in cost control will appear to have no contract-law problem, and the arithmetic will have deleted the only finding that mattered.
G Procurement ICB4 4.5.9
G1 Make-or-buy analysis
Primary4.5.9 Procurement · KCI 4.5.9.1 Agree on procurement needs, options and processesAlso4.5.8 Resources
Whether to build a capability internally or acquire it, on a like-for-like financial basis.
Financial comparison discounted life-cycle cost of each option (C7)
Indifference volume the volume at which the two options cost the same
= (fixedmake − fixedbuy) / (variablebuy − variablemake)
Non-financial factors strategic control, capability retention, exit cost,
vendor concentration risk, speed to capability,
regulatory accountability (cannot be outsourced)
Worked example
From C7, over five years at a 10% discount rate:
Build PV = 649,970
Buy PV = 577,640 → buy is cheaper by 72,330Indifference volume, treating the platform as processing transactions:
Make: fixed 350,000 up front, variable 0.40 per transaction
Buy: fixed 60,000 up front, variable 1.10 per transaction
Indifference = (350,000 − 60,000) / (1.10 − 0.40)
= 290,000 / 0.70
= 414,286 transactions
Below 414,286 transactions → buy is cheaper
Above 414,286 transactions → build is cheaper
Forecast volume 350,000 over the period → buy, but with only
15% headroom before the decision flips. If volume growth exceeds
forecast, revisit at the next gate.
Weighted decision including non-financial factors
Criterion
Weight
Make score
Buy score
Make wtd
Buy wtd
Five-year cost
0.30
6
8
1.80
2.40
Speed to capability
0.20
4
9
0.80
1.80
Regulatory control
0.25
9
5
2.25
1.25
Exit / switching cost
0.15
8
4
1.20
0.60
Internal capability retained
0.10
9
3
0.90
0.30
Total
1.00
—
—
6.95
6.35
Financially, buy wins by 72,330.
On weighted criteria, make wins 6.95 to 6.35, because regulatory
control and exit cost together carry 40% of the weight.
The decision therefore turns on the weighting, which is a governance
judgement — not on the arithmetic.
Exam trap. Include the cost of managing the vendor on the buy side: contract management, service reviews, assurance and audit are real internal costs that make-or-buy comparisons routinely omit, and they typically run 5–15% of contract value. Also include exit cost on the buy side, even though it falls outside the appraisal period — that is exactly where lock-in hides.
G2 Contract type economics and the point of total assumption
Primary4.5.9 Procurement · KCI 4.5.9.3 Contribute to the negotiation and agreement of contractual terms and conditions that meet project objectivesAlso4.5.7 Finance
Who carries cost risk under each contract type, and where the buyer's exposure stops.
Risk gradient (seller risk highest on the left)
FFP → FPIF → FP-EPA → CPIF → CPAF → CPFF → T&M
buyer risk rises from left to right
Incentive share ratio written buyer/seller, e.g. 70/30
seller's fee adjustment = (target cost − actual cost) × seller share
underrun raises the fee, overrun cuts it
Final price (FPIF) = actual cost + adjusted fee, capped at ceiling price
Point of total assumption
PTA = ((ceiling price − target price) / buyer share) + target cost
above the PTA the seller absorbs 100% of every further cost
Worked example — fixed price incentive fee
Target cost 800,000
Target fee 80,000
Target price 880,000
Ceiling price 1,000,000
Share ratio 70 / 30 (buyer 70%, seller 30%)
PTA = ((1,000,000 − 880,000) / 0.70) + 800,000
= (120,000 / 0.70) + 800,000
= 171,429 + 800,000
= 971,429Case 1 — underrun. Actual cost 750,000
Underrun = 800,000 − 750,000 = 50,000
Seller's share = 50,000 × 0.30 = +15,000
Fee = 80,000 + 15,000 = 95,000
Final price = 750,000 + 95,000 = 845,000
Buyer saves 35,000 against target price; seller earns 15,000 more.
Case 2 — overrun below the PTA. Actual cost 850,000
Overrun = 50,000; seller absorbs 30% = 15,000
Fee = 80,000 − 15,000 = 65,000
Final price = 850,000 + 65,000 = 915,000 (below ceiling ✓)
Case 3 — at the PTA. Actual cost 971,429
Overrun = 171,429; seller absorbs 30% = 51,429
Fee = 80,000 − 51,429 = 28,571
Final price = 971,429 + 28,571 = 1,000,000 = ceiling ✓
Case 4 — above the PTA. Actual cost 1,050,000
Price is capped at the ceiling, 1,000,000
Seller's actual position = 1,000,000 − 1,050,000 = −50,000 loss
Every euro of cost beyond 971,429 comes entirely out of the seller.
Exam trap. The PTA formula uses the buyer's share in the denominator, not the seller's. Using 0.30 instead of 0.70 gives 1,200,000 — above the ceiling, which is impossible and should be your check that the formula was applied correctly. Second point: the PTA is a warning line, not a protection. A seller heading past it has a strong incentive to cut quality or claim scope change, so the PTA is a contract-management trigger as much as a financial one.
G3 Weighted supplier scoring
Primary4.5.9 Procurement · KCI 4.5.9.2 Contribute to the evaluation and selection of suppliers and partners
Converting a multi-criteria evaluation into a defensible single ranking.
Weighted score = Σ (criterion weight × supplier score)
weights sum to 1.0 and are fixed before bids are opened
Price scoring normalise so the lowest bid gets full marks:
score = (lowest bid / this bid) × maximum points
or the linear form: max × (1 − (bid − lowest) / lowest)
Gate criteria pass/fail thresholds applied before weighting;
a bid failing a gate is not scored at all
Worked example
Criterion
Weight
Alpha
Beta
Gamma
Alpha wtd
Beta wtd
Gamma wtd
Price
0.30
10.0
8.3
7.1
3.00
2.49
2.13
Technical fit
0.25
6
9
8
1.50
2.25
2.00
Delivery capability
0.20
7
8
9
1.40
1.60
1.80
Regulatory / security
0.15
5
9
8
0.75
1.35
1.20
Reference strength
0.10
6
7
9
0.60
0.70
0.90
Total
1.00
—
—
—
7.25
8.39
8.03
Price normalisation bids: Alpha 520,000, Beta 627,000, Gamma 730,000
Alpha = (520,000 / 520,000) × 10 = 10.0
Beta = (520,000 / 627,000) × 10 = 8.3
Gamma = (520,000 / 730,000) × 10 = 7.1Result Beta 8.39 > Gamma 8.03 > Alpha 7.25
The cheapest bid finishes last, because it scores 5 on regulatory fit.
Weight sensitivity — the question an assessor will ask
Raise price weight from 0.30 to 0.50, taking 0.10 each from technical
fit and regulatory:
technical 0.15, regulatory 0.05
Alpha = (0.50×10) + (0.15×6) + (0.20×7) + (0.05×5) + (0.10×6)
= 5.00 + 0.90 + 1.40 + 0.25 + 0.60 = 8.15
Beta = 4.15 + 1.35 + 1.60 + 0.45 + 0.70 = 8.25
Beta still wins, but by 0.10 instead of 1.14. The recommendation is
robust in direction but not in margin. Say so.
Exam trap. Weights must be set and documented before bids are opened, or the model can be reverse-engineered to produce a chosen winner — a procurement governance failure, not just a methodological one. Second point: always run the weight sensitivity. A recommendation that flips under a plausible reweighting must be reported as a near-tie, not as a clear winner.
G4 Total cost of ownership bid comparison
Primary4.5.9 Procurement · KCI 4.5.9.2 Contribute to the evaluation and selection of suppliers and partnersAlso4.5.7 Finance
Comparing bids on their whole-life cost rather than their headline price.
Bid TCO = purchase price + implementation + integration
+ annual licence and support × years (discounted)
+ internal effort to run and govern
+ training + change costs
+ exit and migration cost
− residual value
Compare on discounted TCO, and where lives differ, on equivalent
annual cost (C7)
Worked example
Element
Alpha
Beta
Gamma
Headline bid price
520,000
627,000
730,000
Integration effort (internal, t=0)
180,000
90,000
60,000
Annual support, yrs 1–5, PV @10%
341,172
265,356
227,448
Internal run and govern, PV
151,632
113,724
94,770
Training and change (t=0)
45,000
60,000
40,000
Exit / migration, yr 5, PV
74,508
37,254
18,627
Five-year TCO (PV)
1,312,312
1,193,334
1,170,845
Annual support: Alpha 90,000 × AF(10%,5) 3.7908 = 341,172
Beta 70,000 × 3.7908 = 265,356
Gamma 60,000 × 3.7908 = 227,448
Exit cost yr 5: Alpha 120,000 × DF₅ 0.6209 = 74,508
Ranking by headline price Alpha (520k) < Beta (627k) < Gamma (730k)
Ranking by five-year TCO Gamma (1,171k) < Beta (1,193k) < Alpha (1,312k)
The ranking reverses completely. Alpha's 210,000 price advantage is
wiped out by 90,000 a year of support, higher integration effort and a
120,000 exit cost — total 142% of its headline saving.
Combining with G3
Beta scored highest on weighted quality (8.39) and sits within 1.9% of
the lowest TCO. Gamma is 22,489 cheaper over five years but scores 0.36
lower on quality. On a 1,171,000 base, 22,489 is 1.9% — inside the
estimate's own margin of error, so the TCO difference is not decisive
and the quality score should carry the decision.
Exam trap. Internal cost belongs in the TCO. A cheaper product that consumes 0.5 FTE more of internal administration is not cheaper. Questions that give you supplier prices and an internal effort figure are testing whether you include the second. Also: when TCO differences fall inside the estimating accuracy range (C10), say the comparison is inconclusive rather than declaring a winner on a rounding difference.
H Scope ICB4 4.5.3
H1 WBS decomposition, the 100% rule and rollup
Primary4.5.3 Scope · KCI 4.5.3.2 Structure the project scope
Breaking scope into countable pieces whose costs and durations roll up without gaps or double-counting.
100% rule each level of decomposition contains exactly 100% of the
work of its parent — no more, no less, at every level
Rollup parent value = Σ children values, applied bottom-up
8/80 rule work packages sized between 8 and 80 hours (a guideline)
Control account the level at which EV is measured and a manager owns it
Planning package scope known but not yet decomposed — must be
decomposed before it can be baselined
Code of accounts the hierarchical numbering that makes rollup traceable
Rollup is only valid if the 100% rule holds at every level. A gap anywhere breaks the whole baseline.
Worked example
Rollup check, bottom-up
1.2.1 Extract 88,400
1.2.2 Transform 142,300
1.2.3 Load 140,200
1.2 subtotal = 370,900
1.1 Environment 95,000
1.2 Data migration 370,900
1.3 Test/cutover 264,100
1.0 total = 730,000 ✓ matches the C10 estimate
Common failure — the missing 100%
If project management effort (78,228 in C10) is not represented by a
work package, the WBS rolls up to 651,772 while the budget is 730,000.
The gap is 12% and it is invisible in the rollup because every level
is internally consistent. The 100% rule fails against the scope,
not against the arithmetic.
Sizing check, 8/80 rule
1.2.2 Transform = 142,300 at a blended 1,400 per person-day
= 101.6 person-days = 813 hours
Far above 80 hours → decompose further before baselining.
Split into 1.2.2.1 mapping rules, 1.2.2.2 build, 1.2.2.3 unit test.
Control accounts
Set at level 2 (1.1, 1.2, 1.3): three EVM measurement points,
three named owners. Setting them at level 3 gives nine measurement
points — better granularity, roughly triple the reporting effort.
Exam trap. The WBS is deliverable-oriented, not activity-oriented, and it contains work — not time and not organisational units. A "phase 2" node describing a period rather than a deliverable is a schedule artefact wearing a WBS label. Second trap: project management, quality assurance and change management are scope. If they are not in the WBS, they are not in the 100% and not in the baseline.
H2 Requirements prioritisation
Primary4.5.2 Requirements and objectives · KCI 4.5.2.3 Prioritise and decide on requirements and acceptance criteriaAlso4.5.3 Scope
Deciding what makes the cut when scope exceeds capacity, in a way you can defend.
MoSCoW Must / Should / Could / Won't this time
discipline: Musts should be ≤ 60% of effort, or there is no
room left to trade
Weighted scoring priority = Σ(criterion weight × score)
or value/effort = benefit score / effort estimate
Kano classify each feature by how satisfaction responds to it:
Must-be absence causes dissatisfaction, presence is neutral
One-dimensional satisfaction rises linearly with fulfilment
Attractive presence delights, absence is not missed
Indifferent no effect either way
Reverse presence causes dissatisfaction
Cost of delay / WSJF = cost of delay / job duration
Must-be features buy no credit when present but cost heavily when absent. Attractive features are where discretionary effort earns most.
Worked example
Requirement
MoSCoW
Kano
Benefit
Effort (d)
Value / effort
Rank
Regulatory audit trail
Must
Must-be
9
18
0.50
5
Automated reconciliation
Must
One-dim.
10
22
0.45
6
Bulk re-run tooling
Should
Attractive
8
7
1.14
2
Migration dashboard
Should
Attractive
7
5
1.40
1
Self-service rollback
Could
Attractive
6
6
1.00
3
Custom report builder
Could
Indifferent
3
14
0.21
7
Legacy UI theming
Won't
Indifferent
2
9
0.22
—
MoSCoW discipline check
Must effort = 18 + 22 = 40 days
Total in-scope effort (excluding Won't) = 72 days
Musts = 40 / 72 = 56% — inside the 60% guideline, so there is
genuine trading room. Above 60%, MoSCoW stops functioning as a
prioritisation tool and becomes a wish list.
The two rankings disagree, and both are right
Value/effort ranks the dashboard first (1.40). MoSCoW ranks it third
tier. The reconciliation requirement ranks last on value/effort (0.45)
and first on MoSCoW.
Resolution: MoSCoW governs what ships; value/effort governs the
order within each MoSCoW band. Musts are not optional however
poor their ratio, because the Kano classification says their absence
causes active dissatisfaction.
Kano insight
Custom report builder is Indifferent and costs 14 days — 19% of
in-scope effort for a feature nobody's satisfaction responds to.
Cut it and the two Attractive items both fit.
Exam trap. "Won't" means won't this time, not "never". Deleting Won't items from the backlog loses the record of what was consciously deferred, which is exactly what change control needs later. Second point: Kano classification decays — today's Attractive feature is next year's Must-be, so a classification more than a year old should be re-tested.
H3 Size estimating — function points and story points
Primary4.5.4 Time · KCI 4.5.4.2 Determine the work effort and duration of activitiesAlso4.5.3 Scope
Measuring the size of software scope in a unit that is independent of who builds it and how.
Function point counting
Count five component types and weight each as low / average / high:
EI external inputs 3 / 4 / 6
EO external outputs 4 / 5 / 7
EQ external inquiries 3 / 4 / 6
ILF internal logical files 7 / 10 / 15
EIF external interface files 5 / 7 / 10
Unadjusted FP = Σ (count × weight)
Value adjustment factor VAF = 0.65 + (0.01 × TDI)
TDI = sum of 14 general system characteristics, each rated 0–5
so VAF ranges 0.65 to 1.35
Adjusted FP = UFP × VAF
Effort = adjusted FP × hours per FP (organisational productivity rate)
Story points relative size, not time. Fibonacci scale 1,2,3,5,8,13.
Effort = story points / velocity (L2). Never convert points to hours
by a fixed ratio — that destroys their purpose.
Worked example — function points
Component
Low
Average
High
Weighted total
External inputs (EI)
4 × 3
6 × 4
2 × 6
48
External outputs (EO)
2 × 4
4 × 5
2 × 7
42
External inquiries (EQ)
7 × 3
6 × 4
2 × 6
57
Internal logical files (ILF)
1 × 7
3 × 10
2 × 15
67
External interface files (EIF)
1 × 5
2 × 7
1 × 10
29
Unadjusted function points
—
—
—
243
EI = (4×3) + (6×4) + (2×6) = 12 + 24 + 12 = 48
UFP = 48 + 42 + 57 + 67 + 29 = 243
Total degree of influence: 14 characteristics, average rating 3
TDI = 14 × 3 = 42
VAF = 0.65 + (0.01 × 42) = 1.07
Adjusted FP = 243 × 1.07 = 260
Effort at an organisational rate of 8 hours per FP:
260 × 8 = 2,080 hours = 260 person-days
At 1,400 per person-day = 364,000
— within 2% of the 370,900 bottom-up figure for WBS 1.2 (H1).
Story points, same scope
Backlog totals 340 story points.
Team velocity 42 points per two-week sprint (L2).
Sprints required = 340 / 42 = 8.1 → 9 sprints = 18 weeks
Note this gives duration, not effort, and only for this team.
A different team with a different velocity gets a different answer
from the same 340 points — which is the point.
Exam trap. Function points measure delivered functionality and are comparable across teams and technologies. Story points measure relative effort for one specific team and are not comparable across teams. Using story points to compare two teams' productivity is the most common misuse, and it reliably destroys the estimates by incentivising inflation.
H4 Scope baseline variance and scope creep
Primary4.5.3 Scope · KCI 4.5.3.4 Establish and maintain scope configurationAlso4.5.10 Plan and control
How much the scope has moved since baseline, how much of that movement was authorised, and what the unauthorised part is costing.
Two different quantities are routinely confused. Requirements volatility measures authorised churn — additions, changes and deletions that went through change control. Scope creep measures work delivered that never went through change control at all. Volatility is a planning-quality signal; creep is a control failure, and only creep is invisible to earned value.
Volatility (added + changed + deleted) / baseline count
Scope creep unauthorised items delivered / baseline count
Stability index 1 − (cumulative authorised churn / baseline count)
Creep cost unauthorised items × average unit cost
Authorised growth Σ approved change value / original BAC
Authorised change sits outside the baseline but inside the control system. Creep sits outside both, which is precisely why it does not appear as a scope variance.
Worked example
Baseline at approval: 240 requirements, BAC 500,000.
Months 1–4, through change control: 34 added, 18 changed, 6 deleted.
A scope audit finds a further 11 items built with no change request.
Authorised churn 34 + 18 + 6 = 58 items
Volatility 58 / 240 = 24.2%Stability index 1 − 0.242 = 0.758Scope creep 11 / 240 = 4.6%Creep cost 11 × 1,900 = 20,900 unfunded
20,900 / 500,000 = 4.2% of BAC
Effect on the indices
The 20,900 lands in AC. None of it lands in EV, because none of it
is in the performance measurement baseline.
CPI falls with no identifiable cost overrun on any baselined package
— the classic signature of creep rather than of poor productivity.
Exam trap. Deletions count towards volatility. They are churn, not a reduction in churn, because the analysis work was still spent — subtracting them flatters the figure. The bigger trap is diagnostic: a falling CPI with every baselined work package on budget does not mean the estimates were wrong, it means effort is going somewhere the baseline cannot see. A question that gives you healthy package-level performance and an unhealthy project-level CPI is asking you to name scope creep.
I Requirements, objectives and benefits ICB4 4.5.2
I1 Benefits quantification
Primary4.3.1 Strategy · KCI 4.3.1.3 Develop and ensure the ongoing validity of the business / organisational justificationAlso4.5.2 Requirements and objectives
Turning a stated benefit into a number that can enter an appraisal.
Cashable benefit a cost that actually leaves the budget
= unit cost × volume reduction
Non-cashable benefit capacity released but not removed from the budget
= hours saved × loaded rate (report separately)
Avoided cost a future cost that will not now be incurred
Revenue benefit = incremental volume × margin
Risk-reduction benefit = EMV before − EMV after (from D2)
Attribution benefit × attribution % where several initiatives
contribute to the same outcome
Worked example
Benefit
Type
Calculation
Annual value
Decommission legacy platform
Cashable
licences 148k + hosting 62k
210,000
Reconciliation effort released
Non-cashable
3,200 h × 46
147,200
Avoided regulatory remediation
Avoided cost
EMV 0.15 × 400k
60,000
Faster product onboarding
Revenue
6 products × 18k margin
108,000
Total gross annual benefit
—
—
525,200
Attribution. The onboarding benefit is shared with a separate
product-catalogue programme. Agreed attribution to this project: 40%.
108,000 × 0.40 = 43,200 (not 108,000)
Cashability discipline. The finance director will only accept
cashable and avoided-cost benefits in the business case:
Cashable + avoided = 210,000 + 60,000 = 270,000
Attributed revenue = 43,200
Business-case annual benefit = 313,200
Non-cashable capacity release, reported separately = 147,200
Using the C1–C5 machinery on the cashable figure over five years:
PV of benefits = 313,200 × 3.7908 = 1,187,278
Less five-year TCO from G4 (Beta) = 1,193,334
NPV = −6,056 — marginal on cashable benefits alone.
Include the non-cashable release at even 30% realisation:
147,200 × 0.30 = 44,160 additional annual benefit
PV = 44,160 × 3.7908 = 167,402
NPV = +161,346
The entire business case rests on whether released capacity is
genuinely redeployed. State that dependency explicitly.
Exam trap. Time saved is not money saved unless the headcount is actually removed or redeployed to funded work. Twenty people each saving one hour a week is 0.5 FTE spread so thinly that no post is ever removed. Classify it as non-cashable, quantify it separately, and never let it carry an investment case on its own.
I2 KPI definition, baselining and target setting
Primary4.3.1 Strategy · KCI 4.3.1.5 Determine, assess and review key performance indicatorsAlso4.5.2 Requirements and objectives
Making a benefit measurable before the project starts, so the claim can later be tested.
A complete KPI definition specifies
the metric formula, the data source, the measurement frequency,
the owner, the baseline value with its measurement date,
the target value with its target date, and the tolerance
Improvement = (current − baseline) / baseline
Achievement vs target = (current − baseline) / (target − baseline)
Index form = (current / baseline) × 100
Worked example
KPI
Baseline
Target
Month 12
Improvement
Achievement
Monthly reconciliation hours
267
80
131
−50.9%
72.7%
Batch cycle time (min)
18.4
12.0
12.4
−34.8%
93.8%
Production defect escapes / month
14
3
6
−57.1%
72.7%
Product onboarding lead time (days)
45
15
31
−31.1%
46.7%
Reconciliation hours:
Improvement = (131 − 267) / 267 = −136 / 267 = −50.9%
Achievement = (131 − 267) / (80 − 267) = −136 / −187 = 72.7%
Batch cycle time:
Improvement = (12.4 − 18.4) / 18.4 = −32.6%
Achievement = (12.4 − 18.4) / (12.0 − 18.4) = −6.0 / −6.4 = 93.8%Why both figures are needed. Onboarding lead time shows a 31%
improvement — presentable on its own. Against target it has achieved
only 46.7%, less than half the intended change. Reporting improvement
alone is the standard way benefits get overstated.
Baseline integrity. The 267-hour baseline was measured over three
months before go-live. If it had been measured in a single peak month
(say 310 hours), the same month-12 result would show a 57.7%
improvement rather than 50.9%. State the baseline period, or the
percentage is unfalsifiable.
Exam trap. A KPI without a baseline measured before the intervention cannot demonstrate anything. Reconstructing a baseline afterwards from memory or from a convenient period is the commonest benefits-management failure, and assessors probe for it. The second probe: who owns the measurement after the project closes? A KPI with no post-closure owner will not be measured.
I3 Benefits realisation tracking
Primary4.3.1 Strategy · KCI 4.3.1.3 Develop and ensure the ongoing validity of the business / organisational justificationAlso4.5.10 Plan and control
Comparing benefits actually delivered against the profile forecast in the business case.
Realisation rate = actual benefit / forecast benefit for the period
Cumulative gap = Σ forecast − Σ actual to date
Revised NPV recompute the appraisal on the actual profile
Benefit lag the delay between capability delivery and benefit
flow — must be in the forecast profile, not assumed
away
Realisation ratio at close = PV of actual benefits / PV of forecast
Worked example
Period
Forecast
Actual
Rate
Cumulative forecast
Cumulative actual
Yr 1 H1
78,300
0
0%
78,300
0
Yr 1 H2
78,300
44,000
56%
156,600
44,000
Yr 2 H1
156,600
121,000
77%
313,200
165,000
Yr 2 H2
156,600
148,000
95%
469,800
313,000
To date
469,800
313,000
66.6%
—
gap 156,800
Run-rate is fine; the profile was wrong.
Latest period realisation = 148,000 / 156,600 = 94.5%
Cumulative realisation = 313,000 / 469,800 = 66.6%
The steady state is nearly on plan. The cumulative shortfall of
156,800 came almost entirely from year 1, where the business case
assumed benefits began flowing at go-live and they in fact took
twelve months to ramp.
Benefit lag. Actual ramp: 0%, 56%, 77%, 95%.
The forecast assumed 100% from period 1. A realistic lag profile
(0%, 50%, 80%, 100%) would have cut forecast year-1 benefits by
117,450 and the business case would still have passed — but the
project would not now be carrying a 157k "shortfall" it never
actually caused.
Revised NPV on the actual profile, assuming 313,200 steady state
from year 3 at 10%:
Yr1 44,000 × 0.9091 = 40,000
Yr2 269,000 × 0.8264 = 222,302
Yr3 313,200 × 0.7513 = 235,307
Yr4 313,200 × 0.6830 = 213,916
Yr5 313,200 × 0.6209 = 194,466
PV of benefits = 905,991 against a forecast PV of 1,187,278
Realisation ratio = 905,991 / 1,187,278 = 76.3%
Exam trap. Benefits are realised after the project closes, so the project manager is accountable for delivering the capability and for handing over a measurable benefits profile with a named owner — not for the benefits themselves. A question asking who is accountable for benefits realisation wants the business change owner or sponsor, not the project manager.
J Organisation, information and stakeholders ICB4 4.5.5 / 4.5.12
J1 Communication channels
Primary4.5.5 Organisation and information · KCI 4.5.5.3 Establish infrastructure, processes and systems for information flowAlso4.5.12 Stakeholders
Why coordination cost grows faster than team size.
Channels = n(n − 1) / 2 n = number of people
Change when adding people Δ = nnew(nnew−1)/2 − nold(nold−1)/2
With a hub structure channels = n − 1 (everyone through one point)
Sub-team structure Σ within-team channels + between-team channels
Worked example
n = 6: 6 × 5 / 2 = 15 channels
n = 10: 10 × 9 / 2 = 45 channels
n = 15: 15 × 14 / 2 = 105 channelsAdding four people to a team of six
Δ = 45 − 15 = +30 channels
Team size rose 67%; coordination surface rose 200%.
This is why F3's warning holds: the marginal engineer adds less
than the last one.
Structural alternatives at n = 15
Fully connected = 105 channels
Hub (all through the PM) = 15 − 1 = 14 channels
but the PM becomes the bottleneck
Three sub-teams of 5, with one liaison each:
within teams 3 × (5 × 4 / 2) = 3 × 10 = 30
between liaisons 3 × 2 / 2 = 3
total = 33 channels
A 69% reduction against full connection, without a single bottleneck.
Including stakeholders
Core team 15 + steering group 6 + vendor 4 = 25 people
25 × 24 / 2 = 300 channels if unmanaged.
This is the arithmetic case for a communications plan.
Exam trap. The formula counts possible channels, not channels in use. Its value is comparative — showing how fast the coordination surface grows and justifying structure. Quoting 300 channels as though 300 conversations occur is a misreading; the correct use is "unmanaged, this configuration has 300 potential channels, so we are structuring it as follows".
J2 Power-interest grid scoring
Primary4.5.12 Stakeholders · KCI 4.5.12.1 Identify stakeholders and analyse their interests and influenceAlso4.3.4 Power and interest
Sorting stakeholders into engagement strategies using two scored dimensions.
Score each stakeholder power 1–5, interest 1–5
Quadrant high power / high interest → manage closely
high power / low interest → keep satisfied
low power / high interest → keep informed
low power / low interest → monitor
Engagement gap = desired engagement level − current level
(unaware / resistant / neutral / supportive / leading)
Position sets the strategy; the engagement gap sets the effort.
Worked example
Stakeholder
Power
Interest
Score
Quadrant
Current
Desired
Gap
S1 Group CRO
5
4
20
Manage closely
Neutral (3)
Supportive (4)
1
S2 Head of Operations
4
3
12
Manage closely
Resistant (2)
Leading (5)
3
S3 External auditor
4
2
8
Keep satisfied
Neutral (3)
Neutral (3)
0
S4 Reconciliation team lead
2
5
10
Keep informed
Supportive (4)
Leading (5)
1
S5 Facilities
2
1
2
Monitor
Unaware (1)
Unaware (1)
0
Where the effort goes.
Raw score ranks S1 highest (20). Engagement gap ranks S2 highest (3).
S1 needs one step of movement and already sits at neutral; S2 needs
three steps and is actively resistant while holding power 4.
Effort priority = power × gap
S1: 5 × 1 = 5
S2: 4 × 3 = 12 ← the real priority
S4: 2 × 1 = 2
S3, S5: 0
S2 is the stakeholder who can stop this project, is currently against
it, and is not the highest-scoring name on the grid. Position alone
would have missed that.
Exam trap. The grid is a snapshot and stakeholders move — particularly interest, which rises sharply as go-live approaches. A stakeholder in "monitor" during design routinely becomes "manage closely" during cutover. Re-score at each phase gate. Also: never write the grid into a document a stakeholder might read.
J3 Stakeholder salience
Primary4.5.12 Stakeholders · KCI 4.5.12.1 Identify stakeholders and analyse their interests and influenceAlso4.3.4 Power and interest
A three-attribute model that resolves cases the two-dimensional grid handles badly.
Three attributes
Power the ability to impose their will
Legitimacy a recognised right to make the claim
Urgency the claim is time-sensitive and important to them
Seven classes
One attribute — latent
Dormant power only Discretionary legitimacy only
Demanding urgency only
Two attributes — expectant
Dominant power + legitimacy Dangerous power + urgency
Dependent legitimacy + urgency
Three — Definitive: power + legitimacy + urgency
Salience score = number of attributes held (0–3), optionally weighted
Worked example
Stakeholder
Power
Legitimacy
Urgency
Class
Response
Group CRO
✓
✓
✓
Definitive
Immediate priority
Head of Operations
✓
✓
—
Dominant
Formal engagement, board seat
Regulator
✓
✓
—
Dominant
Formal, scheduled
Reconciliation team
—
✓
✓
Dependent
Needs an advocate — find them one
Legacy vendor
✓
—
✓
Dangerous
Monitor closely; can disrupt
Facilities
✓
—
—
Dormant
Monitor; could acquire urgency
What salience catches that the grid misses.
1. Dependent stakeholders — the reconciliation team has a legitimate,
urgent claim and no power. The power-interest grid files them under
"keep informed" and they get ignored. Salience says their claim is
valid and they need a powerful advocate, which is an action,
not a communication frequency.
2. Dangerous stakeholders — the legacy vendor has power and urgency
but no legitimate claim on the project's direction. They will act,
and their action will not be through governance channels. The grid
would place them high on power and moderate on interest, implying
"keep satisfied", which is the wrong instinct.
3. Dormant stakeholders — facilities have power (site access at
cutover) but neither legitimacy nor urgency today. Attributes
are transient: give them urgency by scheduling a weekend cutover
and they become Dangerous overnight.
Salience is dynamic. Re-assess when the project acquires urgency,
because urgency is the attribute that moves fastest.
Exam trap. Attributes are binary and, crucially, they are perceived rather than objective — a stakeholder is legitimate if management perceives the claim as legitimate. That perception can be wrong, and correcting it is itself a stakeholder-management action. Expect questions where a Dependent stakeholder's claim is dismissed and the project later fails because of it.
J4 RACI completeness checks
Primary4.5.5 Organisation and information · KCI 4.5.5.2 Define the structure, roles and responsibilities within the project
Testing a responsibility matrix for the structural faults that cause work to fall through.
R Responsible does the work — can be several per activity
A Accountable answers for the outcome — exactly one per activity
C Consulted two-way, before the decision
I Informed one-way, after the decision
Row checks exactly one A; at least one R; not too many C
Column checks no person with A on everything (bottleneck);
no person with only I (why are they on the chart);
no person with R on everything (overload)
Load count R + A per person against their available capacity (F3)
Worked example
Activity
PM
Sponsor
Data lead
Test lead
Ops
Row check
Approve mapping rules
C
A
R
C
I
OK
Execute migration run
A
I
R
C
R
OK
Sign off test exit
C
A
C
R
C
OK
Authorise cutover
R
A
C
C
A
Two A's — fail
Post-cutover reconciliation
I
I
C
C
I
No R, no A — fail
Decommission legacy
A
I
C
I
R
OK
Row failures
Authorise cutover: two Accountables. In a real cutover this resolves
itself at 03:00 as a standoff. One A — here the sponsor; Ops
becomes R.
Post-cutover reconciliation: nobody Responsible and nobody
Accountable. Four people are Consulted or Informed about work that
no one is doing. This is the fault that most often survives review,
because the row looks populated.
Column analysis
PM Sponsor Data Test Ops
A count 2 3 0 0 1
R count 1 0 2 1 2
C count 2 0 3 4 1
I count 1 3 0 1 2
Sponsor holds A on 3 of 6 — appropriate for decision gates.
Test lead has C on 4 of 6 and R on 1. Heavy consultation load with
little ownership: either they should be R somewhere, or several
C's should be downgraded to I.
Data lead: R on 2, C on 3. Reasonable.
Load check against capacity (F3)
Data lead R on two activities totalling 62 person-days over 4 months.
Available: 15.2 days/month × 4 = 60.8 days at 100% allocation.
62 > 60.8 — over-committed before any contingency.
Exam trap. Exactly one A per row is the rule most often broken, and shared accountability is the same as no accountability. The second-most-common fault is C inflation: every C is a two-way conversation that must complete before the decision, so a row with five C's is a decision that will not be made this week. If a question shows a RACI with heavy consultation, the expected observation is decision latency.
K Design and selection ICB4 4.5.1
K1 Weighted scoring model for option selection
Primary4.5.1 Project design · KCI 4.5.1.4 Select and review the overall project management approach
Choosing between delivery approaches when the criteria are measured in different units.
The mechanics match supplier scoring (G3), but the hard part here is normalising criteria that arrive in euros, months, headcount and judgement onto one comparable scale before weighting.
Normalisation — higher is better score = (value / best value) × 10
Normalisation — lower is better score = (best value / value) × 10
Min-max normalisation score = (value − min) / (max − min) × 10
Weighted total = Σ (weight × normalised score)
Robustness test re-run with weights shifted ±10 points and see
whether the ranking survives
Worked example — three delivery approaches
Criterion
Weight
Big bang
Phased by product
Parallel run
Cost (raw)
—
730,000
812,000
965,000
Duration (raw)
—
12 mo
17 mo
15 mo
Cutover risk (1–10, 10 best)
—
3
8
9
Business disruption (10 best)
—
4
7
6
Normalise
Cost, lower is better: 730/730 × 10 = 10.0
730/812 × 10 = 9.0
730/965 × 10 = 7.6
Duration, lower is better: 12/12 × 10 = 10.0
12/17 × 10 = 7.1
12/15 × 10 = 8.0
Risk and disruption already on a 1–10 scale.
Criterion
Weight
Big bang
Phased
Parallel
BB wtd
Ph wtd
Pa wtd
Cost
0.25
10.0
9.0
7.6
2.50
2.25
1.90
Duration
0.15
10.0
7.1
8.0
1.50
1.07
1.20
Cutover risk
0.35
3
8
9
1.05
2.80
3.15
Business disruption
0.25
4
7
6
1.00
1.75
1.50
Total
1.00
—
—
—
6.05
7.87
7.75
Result Phased 7.87 > Parallel 7.75 > Big bang 6.05
Robustness test. Shift 10 points of weight from cutover risk (0.35 →
0.25) to cost (0.25 → 0.35):
Big bang = 3.50 + 1.50 + 0.75 + 1.00 = 6.75
Phased = 3.15 + 1.07 + 2.00 + 1.75 = 7.97
Parallel = 2.66 + 1.20 + 2.25 + 1.50 = 7.61
Phased still leads and its margin widens. The recommendation is robust.
The margin between Phased and Parallel is 0.12 on a 10-point scale —
1.5%. Report those two as effectively tied and let a qualitative
factor break it, rather than presenting a false precision.
Exam trap. Direction of normalisation. Cost and duration are "lower is better" and must be inverted before scoring; risk and satisfaction scales are usually "higher is better". Mixing the directions inside one model silently ranks the worst option first, and the total still looks plausible.
K2 Analytic hierarchy process and pairwise comparison
Primary4.5.1 Project design · KCI 4.5.1.4 Select and review the overall project management approachAlso4.5.2 Requirements and objectives
Deriving criterion weights from a series of two-way comparisons instead of asking people to assign percentages directly, and testing whether their judgements were coherent.
Saaty scale 1 equal, 3 moderately more important, 5 strongly,
7 very strongly, 9 extremely; reciprocals for the inverse
Priority vector normalise each column (divide by its sum), then
average across each row
Consistency λmax = mean of (row of A×w) / wi
CI = (λmax − n) / (n − 1)
CR = CI / RI
RI: n=3 → 0.58 n=4 → 0.90 n=5 → 1.12 n=6 → 1.24 n=7 → 1.32
Accept if CR < 0.10 otherwise revisit the judgements
Worked example
Three criteria compared pairwise: cost, technical fit, regulatory compliance.
Cost
Technical
Regulatory
Cost
1
1/2
1/3
Technical
2
1
1/2
Regulatory
3
2
1
Column sum
6.0000
3.5000
1.8333
Step 1 — normalise each column, average each row
Cost Tech Reg row average
Cost 1/6=.1667 .5/3.5=.1429 .3333/1.8333=.1818 0.1638
Tech 2/6=.3333 1/3.5=.2857 .5/1.8333=.2727 0.2972
Reg 3/6=.5000 2/3.5=.5714 1/1.8333=.5455 0.5390
sum 1.0000 ✓
Step 2 — consistency compute A×w row by row
Row 1: 1(.1638) + 0.5(.2972) + 0.3333(.5390) = 0.4921
λ₁ = 0.4921 / 0.1638 = 3.004
Row 2: 2(.1638) + 1(.2972) + 0.5(.5390) = 0.8943
λ₂ = 0.8943 / 0.2972 = 3.009
Row 3: 3(.1638) + 2(.2972) + 1(.5390) = 1.6248
λ₃ = 1.6248 / 0.5390 = 3.014
λ_max = (3.004 + 3.009 + 3.014) / 3 = 3.009
CI = (3.009 − 3) / (3 − 1) = 0.009 / 2 = 0.0045
CR = 0.0045 / 0.58 = 0.008 → 0.8%, well below 10% ✓
Resulting weights cost 16.4%, technical 29.7%, regulatory 53.9%
What an inconsistent judgement looks like. If the assessor had also
said cost is more important than regulatory (a 3 in the Cost/Reg cell
instead of 1/3), the matrix would assert Reg > Tech > Cost > Reg —
a cycle. CR would rise well above 0.10 and the judgements would have
to be revisited rather than averaged into a meaningless weight.
Exam trap. The matrix must be reciprocal: if cell (i,j) is 3, cell (j,i) must be 1/3, and the diagonal must be all 1s. AHP's real contribution is the consistency ratio — it is the only method in this document that tests whether the human judgements feeding the model were coherent. Quoting AHP weights without a CR is quoting half the method.
K3 Complexity scoring
Primary4.5.1 Project design · KCI 4.5.1.3 Determine complexity and its consequences for the approach
Rating a project's management complexity against a defined indicator set — the basis for IPMA certification-level eligibility and for internal governance tiering.
IPMA's competence baseline treats complexity as the discriminator between certification levels, and certification bodies operationalise it as a scored indicator model. The indicators come from ICB4; the number of points and the pass thresholds are set by each certification body, so confirm your CB's published figures before relying on any specific number.
Typical model ~10 complexity indicators, each scored 0–4,
giving a maximum around 40
Indicator families
objectives and assessment processes, methods, tools
organisation and structure resources and skills
interfaces and dependencies time, cost and finance
stakeholder and political change and innovation degree
autonomy and leadership scope cultural and social context
Use score each qualifying project; compare the total against the
threshold for the level applied for
Thresholds are CB-specific — commonly around 16/40 for Level C
and 25/40 for Level B in the Project domain
Worked example
Indicator
Score 0–4
Evidence anchor
Objectives and assessment
3
Multiple conflicting success criteria across three business units
Interfaces and dependencies
4
Nine upstream systems, two external vendors, one regulator
Cultural and social context
2
Two countries, one language boundary
Organisation and structure
3
Matrix, no direct line authority over 11 of 15 staff
Processes, methods and tools
3
Hybrid delivery; new toolchain introduced mid-project
Established technology, novel to this organisation
Autonomy and leadership
3
Full delegated authority within an approved budget
Total
29 / 40
—
Total = 3+4+2+3+3+2+3+4+2+3 = 29 of a possible 40
Against a 25/40 Level B threshold: qualifies, with 4 points of margin.
Where the margin is fragile. Two indicators carry a 4. If an assessor
marks stakeholder complexity at 3 rather than 4 — a defensible reading —
the total falls to 28, still clear. Two such adjustments give 27. The
project survives normal assessor variation.
A project scoring 25 or 26 does not. For a portfolio of qualifying
projects, target a comfortable margin on each rather than a bare pass,
because the score is a judgement and judgements vary.
Evidence discipline. Each score needs a specific, checkable anchor.
"Complex stakeholder environment: 4" is not evidence. "Board-level
sponsor conflict escalated twice to the group risk committee, plus
direct regulatory correspondence: 4" is.
Exam trap. Complexity is not size. A large, repetitive, single-stakeholder rollout with a well-understood technology can be a €20m project with a low complexity score, while a €900k regulatory remediation with nine interfaces and a hostile board scores high. Arguing complexity from budget or headcount alone is the most common weakness in certification applications.
K4 Portfolio prioritisation under constraint
Primary4.3.1 StrategyAlso4.5.1 Project design
Choosing the set of projects that maximises value when the budget, or a scarce skill, will not fund everything.
Unconstrained accept every project with NPV > 0
Capital rationing maximise total NPV subject to Σ investment ≤ budget
divisible projects → rank by profitability index (C5), fill the budget
indivisible projects → evaluate feasible combinations; PI ranking
can leave budget stranded and miss the optimum
Multiple constraints budget and a scarce resource → check both
Must-do projects regulatory and mandatory work is committed
before optimisation; optimise the remainder
Worked example
Budget €1,000,000. Five candidate projects. Project R is a regulatory obligation.
Project
Investment
NPV
PI
Scarce data engineers
Status
R Regulatory reporting
300,000
−40,000
0.87
2
Mandatory
W Migration
400,000
54,896
1.137
3
Candidate
X Reporting platform
200,000
38,000
1.190
2
Candidate
Y Channel refresh
500,000
61,000
1.122
1
Candidate
Z Automation pilot
120,000
19,000
1.158
3
Candidate
Step 1 — commit the mandatory project.
R is negative-NPV but not optional. Budget remaining = 1,000,000 −
300,000 = 700,000. Data engineers remaining = 6 − 2 = 4.
Step 2 — rank the rest by PI
X 1.190 > Z 1.158 > W 1.137 > Y 1.122
Step 3 — PI-greedy fill
X 200,000 (2 eng) → remaining 500,000, 2 engineers
Z 120,000 (3 eng) → blocked: only 2 engineers left
W 400,000 (3 eng) → blocked on engineers
Y 500,000 (1 eng) → fits
Selection: X + Y. Cost 700,000, engineers 3.
Total NPV = 38,000 + 61,000 = 99,000Step 4 — test the feasible combinations (indivisible projects)
X + Y 700,000 3 eng NPV 99,000 ✓ feasible
W + X 600,000 5 eng — exceeds 4 engineers
W + Z 520,000 6 eng — exceeds 4 engineers
X + Z 320,000 5 eng — exceeds 4 engineers
Y + Z 620,000 4 eng NPV 80,000 ✓ feasible
W alone 400,000 3 eng NPV 54,896 ✓ feasible
Y alone 500,000 1 eng NPV 61,000 ✓ feasible
Optimum: X + Y, NPV 99,000. Here the PI-greedy answer happens to
be optimal, but only because Y's low engineer demand rescued it —
Z was rejected purely on the resource constraint, not the budget.
The lesson. With two binding constraints, PI ranking is a starting
heuristic, not the answer. You must enumerate feasible combinations.
Note also that 300,000 of the budget produced −40,000 of NPV: the
portfolio's economic return is 59,000 on 1,000,000, or 5.9%, and
that is the honest headline figure.
Exam trap. Two habits earn marks here. First, deal with mandatory work before optimising — a regulatory project with negative NPV is not a candidate for rejection, it is a constraint. Second, identify which constraint binds. In this example the budget was not the binding constraint at all; scarce data engineers were, and a question that only mentions money is often hiding a resource limit in the project descriptions.
L Agile and hybrid delivery
L1 Story points and relative estimating
Cross-cutting no single primary elementSupports4.5.4 Time · 4.5.3 Scope
Sizing work by comparison rather than by predicted duration, so that estimates stay stable while team speed changes.
Principle a story point expresses size relative to a reference story,
combining volume, complexity and uncertainty. It is not
a unit of time.
Scale modified Fibonacci 1, 2, 3, 5, 8, 13, 20, 40, 100
the widening gaps encode falling precision at larger sizes
Planning poker simultaneous reveal, discuss the outliers, re-vote
Anchoring pick one well-understood story as the 3 or 5 and size
everything against it
Splitting rule anything above 13 is split before it enters a sprint
Worked example
Reference story: "migrate a simple lookup table with validation" = 3 points
Migrate a second simple lookup table about the same 3
Migrate a complex table, 40 columns, 3 joins ~2× the work 8
Migrate reference data with manual mapping bigger and unclear 13
Add a progress indicator to the run screen much smaller 1
Build the reconciliation engine far too big 40 → split
Splitting the 40:
reconciliation rules engine 13
variance report 8
exception queue 8
automated re-run trigger 5
total after splitting 34
The split total is lower than the unsplit estimate. That is normal and
informative: the 40 encoded uncertainty that decomposition removed.
Why not just estimate in days?
Team A: 8 points takes 3 days. Team B: 8 points takes 5 days.
Both are correct. The story is the same size; the teams differ.
Points stay stable when the team changes, when someone is on leave,
and when a new tool speeds the work up — velocity absorbs all of
that (L2), and the backlog estimate does not have to be redone.
Exam trap. The moment a fixed conversion is published — "one point equals one day" — story points become hours with extra steps, and the team will inflate them under schedule pressure. Points are converted to time only through observed velocity, which is measured, not decreed. Any question proposing a points-to-hours ratio is testing this.
L2 Velocity and capacity planning
Cross-cutting no single primary elementSupports4.5.4 Time · 4.5.8 Resources
Forecasting how much a team will complete, from what it has actually completed.
Velocity = story points completed per sprint (only fully done items)
Average velocity = mean of the last 3–6 sprints
Sprints remaining = remaining backlog points / average velocity
Forecast range use the min and max observed velocity, not the mean alone
Capacity-adjusted velocity
= average velocity × (available person-days this sprint
/ normal available person-days)
Worked example
Sprint
1
2
3
4
5
6
Points completed
38
45
41
44
42
40
Average velocity = (38+45+41+44+42+40) / 6 = 250 / 6 = 41.7 points
Min 38, max 45, standard deviation 2.58 (see M1)
Release forecast remaining backlog 340 points
Optimistic 340 / 45 = 7.6 → 8 sprints
Expected 340 / 41.7 = 8.2 → 9 sprints
Pessimistic 340 / 38 = 8.9 → 9 sprints
At 2-week sprints: 16 to 18 weeks. Quote the range, not "8.2 sprints".
Capacity adjustment for sprint 7
Normal capacity: 5 people × 10 days = 50 person-days
Sprint 7: one person on leave 5 days, one at 50% on an incident
= 50 − 5 − 5 = 40 person-days
Adjusted velocity = 41.7 × (40 / 50) = 33.4 points
Committing 42 points to sprint 7 would over-commit by 26%.
Effect on the release forecast
If sprint 7 delivers 33 instead of 42, remaining after sprint 7
= 340 − 33 = 307, 307 / 41.7 = 7.4 → 8 more sprints.
Total 9 sprints, unchanged — the buffer in rounding absorbed it.
Exam trap. Velocity counts only items meeting the definition of done. Partial credit for unfinished stories destroys the metric's forecasting value, because the points get counted twice across two sprints. Second point: velocity is a forecasting input, never a performance target. The moment it is used to compare teams or set goals, it is inflated and stops forecasting anything.
L3 Burndown, burnup and release forecasting
Cross-cutting no single primary elementSupports4.5.10 Plan and control · 4.5.4 Time
Tracking remaining work against time, and separating genuine progress from scope growth.
Burndown plots remaining work falling toward zero
ideal line = total work × (1 − elapsed / total duration)
weakness: scope added and work completed both move the same
line, so they cancel and become invisible
Burnup plots completed work rising, with a separate scope line
scope growth is visible as the upper line rising
forecast completion = where the two trend lines converge
Forecast remaining work / current completion rate
The burnup separates the two signals: the team's rate is on plan, and the finish date has moved because scope grew by 12%.
Worked example
Release scope at sprint 0: 340 points. Plan: 9 sprints at 41.7.
Actual scope by sprint: 340, 340, 340, 356, 356, 356, 380, 380, 380
Completed cumulative: 42, 84, 126, 168, 210, 251, 293, 335, 377
At end of sprint 6
Completed 251 of 380 = 66%
Burndown reading: remaining = 380 − 251 = 129 points
Original remaining at this point should have been 340 − 250 = 90.
The burndown line looks 39 points behind and gives no reason why.
Burnup reading
Completion rate = 251 / 6 = 41.8 points per sprint — exactly on plan
Scope growth = 380 − 340 = 40 points, +11.8%The team is performing to plan; the scope grew.Forecast
Remaining = 380 − 251 = 129
Sprints needed = 129 / 41.8 = 3.1 → finish in sprint 9.1
If scope continues growing at 6.7 points per sprint:
convergence where 251 + 41.8s = 380 + 6.7s
35.1s = 129
s = 3.7 → finish at sprint 9.7, call it 10
Two-thirds of a sprint of the delay comes from future scope growth,
which is a change-control problem, not a delivery problem.
Exam trap. A flat burndown is ambiguous by construction: it means either that nothing was completed, or that exactly as much scope was added as was completed. The two situations demand opposite responses. Whenever a question presents a burndown that is not falling, the expected answer is that a burnup is needed to tell which case applies.
L4 Cycle time, throughput and Little's Law
Cross-cutting no single primary elementSupports4.5.4 Time · 4.5.10 Plan and control
The relationship between how much work is in progress, how fast it flows, and how long each item takes.
Little's Law WIP = throughput × cycle time
rearranged: cycle time = WIP / throughput
Lead time from customer request to delivery (includes waiting)
Cycle time from work starting to delivery (excludes the queue)
Throughput items completed per unit time
Flow efficiency = active work time / total lead time
typically 5–15% in unoptimised knowledge work
Queueing effect of utilisation
queue multiplier ≈ ρ / (1 − ρ) ρ = utilisation
ρ = 0.70 → 2.3 0.80 → 4.0 0.90 → 9.0 0.95 → 19.0
Worked example
Current state
Items in progress (WIP) = 24
Throughput = 6 items per week
Cycle time = WIP / throughput = 24 / 6 = 4.0 weeksHalve the WIP, change nothing else
WIP = 12, throughput unchanged at 6
Cycle time = 12 / 6 = 2.0 weeks
Same throughput, half the cycle time. Items are delivered twice as
fast without anyone working faster — they simply stop waiting.
In practice throughput usually rises too, because less context
switching. If throughput rises to 7:
Cycle time = 12 / 7 = 1.7 weeksLead time and flow efficiency
Lead time = 6.5 weeks (2.5 weeks queueing before work starts)
Cycle time = 4.0 weeks
Active hands-on time within the cycle = 0.8 weeks
Flow efficiency = 0.8 / 6.5 = 12.3%
Nearly 88% of elapsed time is waiting. Optimising the 12% — making
people work faster — addresses the smaller share by a wide margin.
Utilisation and queues (connects to F3)
At 70% utilisation, queue multiplier = 0.70 / 0.30 = 2.3
At 90% utilisation, queue multiplier = 0.90 / 0.10 = 9.0
Raising a team from 70% to 90% utilised increases queueing delay
fourfold. Full utilisation of a variable process guarantees queues;
this is the quantitative case against 100%-loaded resource plans.
Exam trap. Little's Law needs a stable system to hold — arrivals roughly equal to departures over the measurement window, and consistent definitions of what counts as WIP. Applied to a system where work is piling up, it understates cycle time. Second trap: lead time and cycle time are different quantities and the customer experiences lead time. Reporting a healthy cycle time while the queue grows is technically true and practically misleading.
L5 Cumulative flow diagram and WIP limits
Cross-cutting no single primary elementSupports4.5.10 Plan and control · 4.5.4 Time
Seeing where work accumulates, and capping it so the queue cannot grow.
A CFD stacks cumulative item counts by workflow state over time. The vertical thickness of a band is the WIP in that state; the horizontal distance between the top and bottom lines at a given height is the approximate lead time.
Band thickness = WIP in that state at that time
Horizontal distance = approximate lead time
Widening band = a bottleneck; arrivals exceed departures
Flat top line = nothing being delivered
Parallel bands = stable, healthy flow
WIP limit a hard cap per state. When the cap is reached, no new work
is pulled in — the team helps clear the constrained state.
Starting point: roughly 1–1.5 items per person in the state.
The testing band widens across the period while the others hold steady — the bottleneck is testing, not development.
Worked example
Reading the diagram
In progress band, week 1: 6 items week 8: 7 items stable
Testing band, week 1: 4 items week 8: 14 items growing
Done line slope: 6 items per week unchanged
Development is producing at 6 per week; testing is clearing fewer.
WIP in testing grew by 10 items over 8 weeks, so testing throughput
is 6 − (10 / 8) = 4.75 items per week.
Cycle time impact via Little's Law (L4)
Testing cycle time, week 1: 4 / 4.75 = 0.8 weeks
Testing cycle time, week 8: 14 / 4.75 = 2.9 weeks
Total lead time has grown by 2.1 weeks with no change in effort.
Setting WIP limits
Team: 4 developers, 2 testers.
In progress limit = 4 × 1.5 = 6
Testing limit = 2 × 1.5 = 3
With a testing limit of 3, the system would have stopped pulling new
development work at week 2, and the developers would have moved to
testing. Throughput would have equalised at roughly 4.75–5.5 per week
instead of accumulating a 14-item queue.
The counter-intuitive result. Capping WIP lowers apparent developer
utilisation and raises delivered throughput, because the constraint
sets the system's rate. Anything the non-constraint produces beyond the
constraint's capacity becomes inventory, not output.
Exam trap. A widening band identifies where work accumulates, which is downstream of nothing — it is the constraint. The instinct to add capacity to the busiest-looking upstream state makes the queue worse. Second point: a CFD with a flat "done" line and healthy-looking activity elsewhere means the system is producing inventory, not value.
M Underlying statistics
M1 Central tendency and dispersion
Cross-cutting no single primary elementSupports4.5.11 Risk and opportunity · 4.5.6 Quality
The four numbers that summarise any dataset, and when each one misleads.
Mean x̄ = Σx / n sensitive to outliers
Median middle value when sorted robust to outliers
Mode most frequent value useful for categories
Range max − min
Population variance σ² = Σ(x − μ)² / N
Sample variance s² = Σ(x − x̄)² / (n − 1) note n − 1
Standard deviation the square root of the variance
Coefficient of variation CV = s / x̄ comparable across scales
Worked example
Sprint velocities from L2: 38, 45, 41, 44, 42, 40.
Sorted: 38, 40, 41, 42, 44, 45
Mean = 250 / 6 = 41.67
Median = (41 + 42) / 2 = 41.5
Mode = none; every value appears once
Range = 45 − 38 = 7Deviations and squares
x x − x̄ (x − x̄)²
38 −3.67 13.47
45 3.33 11.09
41 −0.67 0.45
44 2.33 5.43
42 0.33 0.11
40 −1.67 2.79
Σ = 33.34
Sample variance s² = 33.34 / (6 − 1) = 33.34 / 5 = 6.67
Sample std dev s = √6.67 = 2.58
Population variance σ² = 33.34 / 6 = 5.56, σ = 2.36
Coefficient of variation = 2.58 / 41.67 = 6.2%Why CV matters. A second team averages 12.4 points with s = 1.9.
Raw comparison: team 1 is more variable (2.58 > 1.9).
CV comparison: team 1 = 6.2%, team 2 = 1.9/12.4 = 15.3%
Team 2 is two and a half times more variable relative to its own
output, and therefore the harder team to forecast.
Where the mean misleads. Add one sprint of 12 points (a holiday
sprint):
Mean falls to 250+12 = 262/7 = 37.4
Median falls only to 41
The mean now forecasts a release date the team will beat, on the
strength of one atypical sprint. Use the median, or exclude
known-atypical periods and say that you did.
Exam trap. The n−1 denominator applies when the data is a sample used to estimate a wider population; n applies when the data is the whole population. Six observed sprints used to forecast future sprints is a sample → n−1. Six sprints being described as a completed release is a population → n. The difference here is 6.67 against 5.56, roughly 20% in variance.
M2 Normal distribution, z-scores and confidence intervals
Cross-cutting no single primary elementSupports4.5.11 Risk and opportunity · 4.5.6 Quality
Attaching a probability to a value, and a range to an estimate.
Z-score z = (x − μ) / σ how many standard deviations from the mean
Empirical rule ±1σ ≈ 68.3% ±2σ ≈ 95.4% ±3σ ≈ 99.7%
One-tailed z values 80% 0.842 90% 1.282 95% 1.645 99% 2.326
Two-tailed z values 90% 1.645 95% 1.960 99% 2.576
Confidence interval for a mean
CI = x̄ ± z × (s / √n) s / √n is the standard error
use the t-distribution when n < 30 and σ is unknown
The 3σ band is why SPC control limits sit where they do: outside them, chance alone explains 0.3% of points.
Worked example
Z-score batch processing time μ = 12.0 min, σ = 0.6 min.
A batch took 13.5 minutes.
z = (13.5 − 12.0) / 0.6 = 1.5 / 0.6 = +2.50
P(Z > 2.50) = 0.0062 → 0.62% of batches exceed this by chance.
Within 3σ control limits, so not an SPC signal — but worth watching.
Confidence interval for velocity x̄ = 41.67, s = 2.58, n = 6
Standard error = 2.58 / √6 = 2.58 / 2.449 = 1.053
95% CI (using z = 1.96) = 41.67 ± (1.96 × 1.053)
= 41.67 ± 2.06
= 39.6 to 43.7 points
With n = 6 the t-distribution is more appropriate: t(0.025, 5) = 2.571
CI = 41.67 ± (2.571 × 1.053) = 41.67 ± 2.71 = 39.0 to 44.4
The small sample widens the interval by 31%.
Applying it to the release forecast
340 points remaining:
at the CI lower bound 39.0 → 8.7 → 9 sprints
at the CI upper bound 44.4 → 7.7 → 8 sprints
So "8 to 9 sprints, 95% confidence" — a defensible statement, unlike
the point estimate of 8.2.
Confidence and sample size
Standard error falls with √n, so halving it requires quadrupling n.
With 24 sprints of data: SE = 2.58 / √24 = 0.527, CI = ±1.03.
Exam trap. One-tailed and two-tailed z-values differ and get swapped constantly. "90% confidence of finishing on or before a date" is one-tailed → z = 1.282. "A 90% confidence interval around the mean" is two-tailed → z = 1.645. Using 1.645 where 1.282 belongs overstates the required buffer by 28%.
M3 Weighted averages, percentages, ratios and index numbers
Cross-cutting no single primary elementSupports4.5.10 Plan and control · 4.5.7 Finance
The arithmetic that carries most of the marks in a calculation paper, and most of the errors.
Weighted average = Σ(wixi) / ΣwiPercentage change = (new − old) / old × 100
Percentage point an absolute difference between two percentages
— not the same as a percentage change
Reverse a percentage original = final / (1 + rate)
Compound change final = original × (1 + r1)(1 + r2)…
Index number = (current value / base value) × 100
Deflating with an index real value = nominal × (base index / current index)
Worked example
Weighted average day rate
Senior 4 people at 1,850
Mid 7 people at 1,400
Junior 4 people at 950
Simple average of the rates = (1,850 + 1,400 + 950) / 3 = 1,400
Weighted average = [(4×1,850) + (7×1,400) + (4×950)] / 15
= (7,400 + 9,800 + 3,800) / 15
= 21,000 / 15 = 1,400
Coincidentally equal here. Change the mix to 2 senior, 4 mid, 9 junior:
simple average unchanged at 1,400
weighted = (3,700 + 5,600 + 8,550) / 15 = 17,850 / 15 = 1,190
A 15% difference on the same three rates. Always weight by headcount.
Percentage vs percentage point
CPI moved from 0.95 to 0.871.
Percentage-point change = 0.871 − 0.95 = −0.079, or 7.9 points
Percentage change = −0.079 / 0.95 = −8.3%
Both are correct statements of the same movement, and they are
different numbers. State which one you mean.
Reversing a percentage
A quote of 806,000 includes 24% VAT. The net amount is not
806,000 × 0.76 = 612,560.
net = 806,000 / 1.24 = 650,000
VAT = 806,000 − 650,000 = 156,000
check: 650,000 × 1.24 = 806,000 ✓
Compounding
Costs rose 8% in year 1 and fell 8% in year 2.
Net change = 1.08 × 0.92 = 0.9936 → −0.64%, not zero.
Index numbers
Construction cost index: 2022 = 100, 2024 = 118, 2026 = 131.
A 2022 contract of 450,000 escalated to 2026 money:
450,000 × (131 / 100) = 589,500
A 2026 cost of 589,500 expressed in 2022 money:
589,500 × (100 / 131) = 450,000 ✓
Real change 2024 → 2026 in a cost that rose from 520,000 to 600,000:
nominal change = +15.4%
index change = 131 / 118 = +11.0%
real change = (600,000 × 118/131) / 520,000 − 1
= 540,458 / 520,000 − 1 = +3.9%
Exam trap. Percentage changes are not additive and not symmetric. A 20% fall followed by a 20% rise leaves you at 96% of where you started, and a 50% overrun requires a 33% reduction to reverse. Any question involving a sequence of percentage movements is testing whether you multiply the factors rather than adding the percentages.
M4 Unit consistency and conversion
Cross-cutting no single primary elementSupports4.5.7 Finance · 4.5.10 Plan and control
The discipline that prevents most of the wrong answers in a timed calculation paper.
Effort units person-hours ↔ person-days ↔ person-months
use the organisation's stated conversion, not 8 and 20
Time units working days ≠ calendar days
working days ≠ elapsed days when availability < 100%
Rate units per hour ↔ per day ↔ per month — check the divisor
Money units thousands vs units; currency; nominal vs real (C12)
Rate periods annual r to monthly: (1 + r)1/12 − 1, not r / 12
Method carry units through the calculation and check they cancel;
estimate the order of magnitude before computing
Worked example
Conversions in this document
1 person-day = 8 hours (stated, not assumed)
1 person-month = 15.2 project-available days (from F3, not 21.7)
1 year = 260 working days = 215 productive = 182.75 project-available
Effort chain 2,080 hours of function-point effort (H3)
→ 2,080 / 8 = 260 person-days
→ 260 / 15.2 = 17.1 person-months
Using the nominal 21.7 days per month instead gives 12.0 person-months
— a 30% understatement, and the error is invisible in the answer.
Duration chain 260 person-days of effort, team of 3
Effort / headcount = 86.7 working days
÷ availability 0.70 = 123.8 working days
÷ 5 working days per week = 24.8 weeks
× 7/5 for calendar = 34.7 calendar weeks ≈ 8 months
The naive answer — 260/3 = 87 days ≈ 3 months — is out by 167%.
Rate period annual discount rate 10%, monthly cash flows
Wrong: 10% / 12 = 0.833% per month
Right: 1.10^(1/12) − 1 = 0.797% per month
Check: 1.00797¹² = 1.100 ✓ (1.00833¹² = 1.1047, a 0.47pt error)
Money units a bid sheet showing "812" against a budget of "798,000"
Almost certainly thousands. Confirm before comparing, and state the
unit in every table header — the assumption that both are in the
same unit is where six-figure errors originate.
Order-of-magnitude check before computing 340 / 41.7:
340 is roughly 8× 42, so expect about 8. Getting 81.5 or 0.12 means
a decimal or an inversion, caught in two seconds.
Exam trap. Annual rate divided by twelve is wrong for anything compounding, and it is the single most frequent finance error under time pressure. Second: person-months are not interchangeable between organisations, because the productive-days assumption differs — always state yours. Third: an answer with no unit attached earns no marks even when the arithmetic is right.
N Change and transformation ICB4 4.5.13
N1 Change readiness and adoption measurement
Primary4.5.13 Change and transformation · KCI 4.5.13.1 Assess the adaptability to change of the organisation(s)Also4.3.1 Strategy
Whether the receiving organisation is ready for the change, how far adoption has actually gone, and what proportion of the promised benefit that adoption is delivering.
Readiness is scored before deployment across weighted dimensions, on the same scale, so that the weakest dimension can be identified — it is the one that predicts where adoption will stall. After deployment, headcount adoption is measured against eligible population, and then discounted by proficiency, because a user who has logged in once is not a user delivering the benefit the business case assumed. The benefit run-rate follows proficiency-adjusted adoption, not licences issued.
Readiness index R = Σ (wi × si) s on 1–5, Σwi = 1
Adoption rate A = active users / eligible users
Proficiency P = observed throughput per user / target throughput
Adjusted adoption A′ = A × P
Benefit run-rate planned annual benefit × A′
Constraint the lowest-scoring readiness dimension caps adoption
far more reliably than the mean does
The gap that matters is not between plan and adoption, but between plan and proficiency-adjusted adoption. Benefits accrue at the lower line.
Worked example
Eligible population 480 users. Planned annual benefit 240,000.
Readiness, assessed two weeks before go-live
Dimension Weight Score Weighted
Sponsorship visibility 0.25 4 1.00
Awareness of the change 0.20 4 0.80
Training coverage and capability 0.25 2 0.50
Capacity to absorb (other change) 0.15 2 0.30
Reinforcement and incentives 0.15 3 0.45
---- ------
1.00 3.05
Readiness index 3.05 / 5 = 61%
Weakest dimensions: training (2) and capacity (2) — adoption will
stall on capability, not on willingness.
Adoption at month 3
Active users 312 / 480 = 65.0%
Proficiency observed 18 transactions/user/week
against a target of 30 = 60.0%
Adjusted adoption 0.650 × 0.600 = 39.0%Benefit run-rate 240,000 × 0.390 = 93,600 per year
Against a business case written on 240,000, the shortfall is
146,400 per year — and none of it appears in cost or schedule
performance, because the project delivered what it promised.
Exam trap. Licences issued, accounts created and attendance at training are not adoption, and adoption is not benefit. The business case pays out on proficiency-adjusted adoption, so a project reporting 65% adoption against a plan of 100% is understating the shortfall by roughly half. Second: readiness measured once, at launch, tells you nothing about where adoption will stall — the value is in the weakest dimension, which is why a mean readiness score reported without its components is not usable. Third: a project can close on time and on budget with every deliverable accepted, and still realise 39% of its benefit. Cost and schedule performance say nothing about whether the change landed.
IPMA publishes no official quantitative-methods syllabus, and each certification body sets its own exam format and weighting. This document covers the calculation methods that fall inside ICB4 practice competence elements. Confirm scope and format with your own certification body before relying on any part of it as an exam specification. All figures in the worked examples are invented and internally consistent; none represents a real project or a published benchmark.