Advanced Labs Answer Key — Labs 16–25¶
Instructor material — and not secret
Published in a public repository. Treat it as a self-study reference, not a secured key.
Labs 16–25 combine arithmetic with judgement. Every calculation is worked below; where the deliverable is a recommendation or an agreement, the reasoning that must be present is stated, along with the range of defensible positions.
Lab 16 — Schedule Compression Trade-offs¶
Task 1 — baseline
| Activity | ES | EF | Float |
|---|---|---|---|
| A | 0 | 3 | 0 |
| X | 3 | 11 | 0 |
| Y | 3 | 9 | 2 |
| Z | 3 | 10 | 1 |
| I | 11 | 15 | 0 |
| R | 15 | 17 | 0 |
Duration 17 working days. Critical path A → X → I → R. Compressible candidates: X, Y, Z only. A, I, and R cannot be compressed — A is already minimal, I cannot shrink without reducing test coverage, and R is a fixed external process.
Task 2 — cost per day
| Activity | Normal | Compressed | Days saved | Cost | Cost per day |
|---|---|---|---|---|---|
| X | 8 | 6 | 2 | 90,000 | 45,000 |
| Y | 6 | 4 | 2 | 120,000 | 60,000 |
| Z | 7 | 5 | 2 | 80,000 | 40,000 |
Y and Z have float (2 and 1 day). Compressing an activity with float saves nothing for the project until the float is exhausted, so their apparent cost per day is irrelevant as a starting point.
Task 3 — first day
Compress X by one day: X becomes 7 days, EF = 10. Forward pass: I starts at max(X 10, Y 9, Z 10) = 10 → I 10–14, R 14–16. Duration 16 days. X and Z are now both critical — the critical path has split into two parallel chains. Cost of the first day: 45,000.
Task 4 — second day
The second day cannot come from X alone: compressing X again to 6 days makes X's EF 9, but Z still completes at 10, so the project remains at 16 days. Both X and Z must be compressed by one day to reach 15.
| Action | Cost |
|---|---|
| X from 7 to 6 days | 45,000 |
| Z from 7 to 6 days | 40,000 |
| Total for the second day | 85,000 |
New duration: 15 days. Y still has float (EF 9 against a start of 10 at I, later 9) and remains non-critical.
Task 5 — totals
- Total cost of saving two days by crashing: 130,000 (45,000 + 85,000).
- The marginal cost of the second day (85,000) is nearly double the first (45,000). The pattern is characteristic: once one chain is compressed, the compression must be applied to every parallel critical chain, so each further day costs the sum of the cheapest option on each chain.
- Consequence for the other programme: its delivery slips by the periods during which specialists were borrowed — a real cost that appears in no compression budget.
Task 6 — alternatives
| Option | Days saved | Direct cost | Risk | Scope/quality consequence |
|---|---|---|---|---|
| Fast-track X and I | up to 2 | 0 direct + expected rework: 40% × 1 day of integration testing | 40% chance of one day of rework in the payment path | Reduced test coverage on the highest-severity path |
| Descope card blocking | 2 | 0 | Feature removal, possible customer complaints | Scope reduced; the feature returns in phase 2 |
| Second test path | 2 | Cost of a second environment | Environment drift, split attention | None direct, but requires an environment that does not exist |
| Report the date as unachievable | 0 | 0 | Sponsor may direct compression anyway | Honest; preserves quality |
Task 7 — Recommendation. The strongest answers recommend descoping card blocking (free, certain, and reversible in a later release) or crashing for 130,000 if the feature cannot be removed, and explicitly refuse fast-tracking the payment path — the one place where rework risk is least acceptable. A good recommendation also states what it will not do and names the information that would change the decision (for example, whether card blocking is on the regulatory critical path).
Common errors: compressing Z first because it is cheapest; assuming the second day costs 45,000; omitting the other programme's consequence; treating fast-tracking as free.
Lab 17 — Risk Response Strategies and Contingency¶
Baseline exposure
| Risk | Calculation | Exposure |
|---|---|---|
| R1 | 0.70 × 120,000 | 84,000 |
| R2 | 0.80 × 260,000 | 208,000 |
| R3 | 0.30 × 180,000 | 54,000 |
| R4 | 0.50 × 200,000 | 100,000 |
| R5 | 0.30 × 150,000 | 45,000 |
| R6 | 0.10 × 400,000 | 40,000 |
| Total | 531,000 |
Dominant three: R2 (208,000), R4 (100,000), R1 (84,000) — together 392,000, or 74% of the total.
Strategies. R1 mitigate · R2 mitigate · R3 avoid (scope removal) · R4 mitigate (knowledge transfer) · R5 accept · R6 transfer (contractual commitment).
Two deserve scrutiny:
- R3 is the unusual one: it changes the plan rather than probability or impact, removes the scope entirely for this release, and therefore requires a change request. It also reduces impact as well as probability, because the risk can no longer occur in this phase.
- R5 is unusual in the opposite way: it is a genuine acceptance with zero response cost, which makes its return on investment undefined. That is not a flaw — it is the correct treatment for a risk whose response would cost more than the exposure.
Residual exposure
| Risk | Residual | Avoided | Cost | Avoided per unit spent |
|---|---|---|---|---|
| R1 | 0.30 × 120,000 = 36,000 | 48,000 | 30,000 | 1.60 |
| R2 | 0.40 × 150,000 = 60,000 | 148,000 | 80,000 | 1.85 |
| R3 | 0.05 × 180,000 = 9,000 | 45,000 | 25,000 | 1.80 |
| R4 | 0.20 × 200,000 = 40,000 | 60,000 | 25,000 | 2.40 |
| R5 | 0.30 × 150,000 = 45,000 | 0 | 0 | — |
| R6 | 0.10 × 80,000 = 8,000 | 32,000 | 40,000 | 0.80 |
| Total | 198,000 | 333,000 | 200,000 |
Worth it?
- Expected reduction: 333,000
- Cost: 200,000
- Net position: 133,000 better off in expected terms
- Best return: R4 at 2.40 (and R5's is undefined at zero cost but zero benefit). Worst: R6 at 0.80 — it costs 40,000 to avoid 32,000 of expected exposure.
- R6 should not simply be dropped. The ratio misses two things: R6's impact is a go-live outage with reputational consequences not captured in the figure, and the response buys a manual fallback path that has value independent of the risk. A defensible answer keeps R6 but reduces its scope (for example, the documented manual export path without the contractual amendment).
Contingency (Task 5).
- Baseline total: 531,000. Residual total after responses: 198,000.
- The figure to request is 198,000, because 333,000 of the exposure has been dealt with by spending 200,000 — budgeting 531,000 as well as spending 200,000 would double-count the responses.
- Response cost and contingency do not overlap: response cost is spent now to reduce exposure; contingency is held for what survives.
- Contingency is not for unidentified work or scope changes. That is the management reserve, controlled by the sponsor.
Task 7 — the sponsor's remark. A good answer uses at least three figures, for example: "we expect to lose about 531,000 of exposure if we do nothing; spending 200,000 reduces it to 198,000; the programme is 133,000 better off in expected terms." Then one line on a project with no reserve: it funds every surprise from the delivery schedule, which converts a cost problem into a date problem and a quality problem.
Common errors: treating mitigation as free; omitting the change request for R3; double-counting response cost and contingency; dropping R6 on the ratio alone without noting what the ratio omits.
Lab 18 — Earned Value Management¶
Task 1 — PV check. An even profile over 20 weeks gives PV at week 6 = 480,000 × (6 ÷ 20) = 144,000, but the given figure is 180,000. At week 10 an even profile gives 240,000 against the given 300,000. Both given values are higher, implying the baseline is front-loaded — it scheduled more value in the early weeks than the project has been able to earn. This is a real project condition and it makes SPI look worse than a level profile would; the honest treatment is to say so.
Period 1 (week 6)
| Indicator | Calculation | Value |
|---|---|---|
| SV | 144,000 − 180,000 | −36,000 |
| CV | 144,000 − 160,000 | −16,000 |
| SPI | 144,000 ÷ 180,000 | 0.80 |
| CPI | 144,000 ÷ 160,000 | 0.90 |
| EAC | 480,000 ÷ 0.90 | 533,333 |
| VAC | 480,000 − 533,333 | −53,333 |
| ETC | 533,333 − 160,000 | 373,333 |
Period 2 (week 10)
| Indicator | Calculation | Value |
|---|---|---|
| SV | 240,000 − 300,000 | −60,000 |
| CV | 240,000 − 270,000 | −30,000 |
| SPI | 240,000 ÷ 300,000 | 0.80 |
| CPI | 240,000 ÷ 270,000 | 0.889 |
| EAC | 480,000 ÷ 0.889 | 540,000 |
| VAC | 480,000 − 540,000 | −60,000 |
| ETC | 540,000 − 270,000 | 270,000 |
Interpretation. Behind schedule in value terms by 36,000 then 60,000; over budget by 16,000 then 30,000; earning 80 paise of value per unit of planned work; spending to obtain 89–90 paise of value per unit spent; forecast final cost 533,000 then 540,000 against a budget of 480,000.
Task 3 — SV in value, not time. SV is in currency because EV is a value measure: the units only reconcile if schedule variance is expressed the same way. Converting SV into days requires an assumption about the rate at which the project earns value, which changes as the work changes — it is unreliable and should be presented as an indication, not a date.
Task 5 — trend. SPI is unchanged at 0.80 — but that is not stability, because PV has been rising by 30,000 per week while EV rose by only 24,000 in the same interval. The project is falling behind at a roughly constant rate, not holding position. This is exactly the reading that a snapshot cannot give. The problem was recoverable at period 1 (a 53,000 forecast overrun against 10 weeks remaining); at period 2 the forecast overrun has grown to 60,000 with 10 weeks remaining, and CPI is slightly worse, so it is less recoverable than it was.
Task 6. The question earned value cannot answer: "of the value earned, how much is value the planning office can actually use?" If the accepted features are the integration and the data model, with nothing user-visible, then the position is worse than the indicators suggest, because no benefit has yet been realised. Pairing EVM with a product-level measure — features released and used, or a burn-up of user-visible capability — covers the gap.
Task 7. The variance breaches a ±5% cost tolerance at period 2 (CV of 30,000 against a 480,000 budget is 6.25% of the budget; against the 300,000 of PV it is 10%). That calls for replanning — not merely corrective action — because the forecast finish cost now exceeds tolerance and the cause (front-loaded baseline plus sustained rework) cannot be fixed by working harder. The escalation should state the fact (CPI 0.89, forecast 540,000), the assessment (overrun of 60,000, 12.5% of budget, with SPI at 0.80), and the request (approve a re-baseline of the remaining scope or authorise the overrun).
Common errors: dividing when SPI should use PV; computing ETC as EAC − EV; reporting "no change" on SPI because the index is flat; failing to notice the PV discrepancy.
Lab 19 — Evaluating a Change Request¶
Task 2 — current position (week 5)
| Indicator | Calculation | Value |
|---|---|---|
| SV | 1,035,000 − 1,150,000 | −115,000 |
| CV | 1,035,000 − 1,120,000 | −85,000 |
| SPI | 1,035,000 ÷ 1,150,000 | 0.90 |
| CPI | 1,035,000 ÷ 1,120,000 | 0.92 |
| EAC | 2,715,000 ÷ 0.92 | ≈ 2,951,000 |
| VAC | 2,715,000 − 2,951,000 | ≈ −236,000 |
Cost variance as a percentage of the approved budget: 236,000 ÷ 2,715,000 = 8.7%, which breaches the ±5% tolerance before CR-07 is even considered. That finding must be reported independently.
Task 3 — cost of the change
- 24 person-days × 25,000 = PKR 600,000
- As a percentage of the approved budget: 600,000 ÷ 2,715,000 = 22.1%
- Capacity consumed: 24 ÷ 4 = 6 weeks of the entire team
- New forecast if approved: ≈ 2,951,000 + 600,000 = PKR 3,551,000, a variance of ≈ −836,000, or about 31% over the approved budget
A strong answer states whether the productivity factor was applied. It should not be applied on top of the given person-days, because those are already project working days; applying 0.8 would double-count. Stating the choice is the mark of a good answer either way.
Task 4 — schedule. Up to 6 weeks on a 12-week baseline — a 50% extension, far outside the ±3-day milestone tolerance. Reduction option: start the offline work on a single component (submission only, not gradebook), which would reduce scope but also reduce the value of the feature; it saves perhaps 2 weeks at the cost of a partial feature.
Task 5 — quality and risk.
- Caching marks on a device risks stale or incorrect marks being shown as authoritative, and the person harmed is the student, who may act on a wrong mark; the lecturer and the records office then have a dispute to resolve.
- Risk statement: "Because grades may not lawfully be cached on a device, and the records office has not answered the question, there is a risk that the offline feature is built and then cannot be enabled, which would result in 24 person-days of wasted work." Probability high (the question is unanswered), impact ≈ 600,000.
- Secondary risks: the offline data store becomes a second source of truth requiring reconciliation; and the mobile client creates a maintenance obligation the department has no capacity for.
- What survives a decision to proceed: the scheduling and cost findings. What does not: the quality and legal objections, if the records office answers favourably.
Task 6 — the exclusion conflict. CR-07 requires a mobile client, which is a baselined exclusion. A change that removes an approved exclusion is not merely larger — it changes what the project is, and it invalidates the assumptions on which the budget and the scope statement were approved. Procedurally, the exclusion must be removed by the same authority that approved it, in writing, before the change can be assessed as a normal scope change.
Task 7 — authority. The impact (22% cost, 50% schedule) exceeds the ±5% and ±3-day tolerances, so the decision is above the project manager and above the sponsor's delegated authority for routine change: it goes to the sponsor with the department head as the business owner. The project manager must not decide it.
Model options.
| Option | Consequence |
|---|---|
| Approve as requested | +600,000 and up to +6 weeks; budget 31% over; two exclusions removed; unresolved legal question |
| Approve with a trade | Remove the notifications component (about 5 person-days) and the timetabling integration entirely; still leaves a large overrun and exclusions unchanged issue |
| Defer to phase 2 | Nothing changes now; the students' connectivity problem remains; requires a phase 2 commitment |
| Reject | Same as defer, without a commitment |
The strongest recommendation is usually defer to phase 2 as a separate project, on the grounds that at 22% of the budget and a 50% schedule extension it is not a change at all — it is a second project — and that the unresolved data-protection question must be answered before any estimate is meaningful.
Common errors: approving on the basis that the request is reasonable; missing the exclusion conflict; failing to report the pre-existing 8.7% overrun; treating "defer" as a non-decision.
Lab 20 — Quality Planning and the Cost of Quality¶
Task 3 — cost of quality
| Approach | Person-days | Labour | Defects to production | Failure cost | Total |
|---|---|---|---|---|---|
| A — Test-heavy | 50 | 1,000,000 | 28 | 11,200,000 | 12,200,000 |
| B — Balanced | 75 | 1,500,000 | 9 | 3,600,000 | 5,100,000 |
| C — Minimal | 30 | 600,000 | 45 | 18,000,000 | 18,600,000 |
- Lowest total: B, by 7,100,000 against A and 13,500,000 against C.
- Lowest labour cost: C (600,000), then A (1,000,000), then B (1,500,000). The two questions have different answers because labour is only one of four cost categories.
- Failure cost as a multiple of labour: A 11.2× · B 2.4× · C 30×.
Task 5 — sensitivity
| Defect cost | A total | B total | Cheaper |
|---|---|---|---|
| 100,000 | 3,800,000 | 2,400,000 | B by 1,400,000 |
| 400,000 | 12,200,000 | 5,100,000 | B by 7,100,000 |
| 1,500,000 | 43,000,000 | 15,000,000 | B by 28,000,000 |
Break-even: solve 1,000,000 + 28c = 1,500,000 + 9c → 19c = 500,000 → c ≈ PKR 26,300. Below that figure — roughly one and a third person-days — approach A would be preferable. Since a production defect in a banking application cannot plausibly cost that little, the decision is robust across the entire realistic range. That is the conclusion worth drawing: stop arguing about the defect-cost estimate, and implement the plan.
Task 4 — the reply. Must concede the correct part (A does cost 500,000 less in labour), state the total-cost comparison (5,100,000 against 12,200,000), and name what the difference buys in customer terms (9 incidents rather than 28 in a regulated, publicly noticed service). A good answer also states the condition under which the board member would be right — if production defects were cheap and invisible, which they are not here.
Task 7 — metrics. Expected set: review coverage (leading), automated check pass rate (leading), defect escape rate (lagging), mean time to restore service for production incidents (lagging). Counter- measures for escape rate: report at team level, pair it with the review coverage figure so that under-reporting shows up as an inconsistency rather than a success.
Common errors: choosing B without the arithmetic; treating labour cost as total cost; claiming prevention "always" pays; publishing per-developer defect counts.
Lab 21 — Resource Allocation Conflicts¶
Task 1 — variance table (assigned − capacity)
| Person | Week 1 | Week 2 | Week 3 | Week 4 |
|---|---|---|---|---|
| Aisha | 0 | 0 | +2.0 | 0 |
| Bilal | 0 | 0 | 0 | −1 |
| Chen | −2 | 0 | 0 | −1 |
| Dania | −3 | −2 | −2 | 0 |
| Omar | −0.5 | −2.5 | +0.5 | +0.5 |
Three over-allocations: Aisha week 3 (2 days), Omar weeks 3 and 4 (0.5 day each).
Task 2 — Omar's arithmetic. Nominal capacity 2.5 days; the contractual data-warehouse commitment is 1 day in each of weeks 3 and 4, so effective capacity is 1.5 days. He is assigned 2 days — an over-allocation of 0.5 day in each week. Recording him as "50% available" and planning 2 days hides the conflict, because 2 days looks smaller than the nominal 2.5 and only the contractual commitment makes it an overload.
Task 3–4 — resolution.
| Conflict | Technique | Action | Cost |
|---|---|---|---|
| Aisha week 3 (+2.0) | Smoothing + substitution | The requirements specification has zero float and cannot move. UAT support preparation has 2 days of float: delegate 2 days to Dania (2 days spare in week 3), or move it 2 days later and consume all its float | ≈ 0.5 person-day of handover, or 0 (float, but no remaining protection) |
| Omar week 3 (+0.5) | Smoothing | Omar has 0 days assigned in week 2; pull half a day of schema work forward | 0 |
| Omar week 4 (+0.5) | Smoothing or substitution | Shift half a day into the free week 2 slot, or substitute Chen for the schema portion | 0, or ≈ 0.5 person-day of ramp-up |
Effect on the end date: none. Every conflict is resolved inside float or by substitution.
Substitution rejected: substituting a developer for Aisha on the requirements specification is not viable — the work is requirements analysis, not code, and a developer without clinical-process context would produce a specification that the clinic rejects.
Task 5 — leveling. Aisha's zero-float specification work in week 3 is the driver: leveling delays it by 2 days, which is on the critical path, so the 20-week plan extends by 2 days — about 1%. Holding the additional resources for those days costs roughly 2 days × 4 people × 22,000 ≈ 176,000. Leveling is often correct because it removes the overload entirely and reduces burnout; here it is wrong because the end date is fixed by a board decision and a 1-day handover is cheaper than a 2-day extension.
Task 6 — key-person risk. Statement: "Because only Omar has the schema knowledge required by the integration, there is a risk that his unavailability stalls the critical path, which would result in a delay of up to 5 days at the integration milestone." Probability moderate (he is shared with another programme and at 50%), impact 5 days. Transfer: Chen is paired with Omar for two days in week 2 to document the schema and shadow the work; cost ≈ 2 person-days (1 from each); secondary risk: Chen's own integration work starts later, absorbing float. Worth doing even if Omar never becomes unavailable, because it also removes the project's single largest concentration of knowledge and makes ordinary illness non-critical.
Task 7 — committee paragraph. Must state: three over-allocations found and resolved; techniques and cost (about 1 person-day, no effect on the end date); the remaining unmitigated item (Omar's 50% availability as a structural condition, mitigated by transfer but not eliminated); and what is needed from the committee (nothing, unless they wish to fund a second DBA — which would remove the structural risk).
Common errors: planning Omar at 2.5 days; trying to smooth Aisha's specification work; treating the substitution as free; ignoring that a resolution can create a new conflict downstream.
Lab 22 — Monitoring and Corrective Action¶
Earned value at week 4
| Indicator | Calculation | Value |
|---|---|---|
| SV | 96,000 − 120,000 | −24,000 |
| CV | 96,000 − 105,000 | −9,000 |
| SPI | 96,000 ÷ 120,000 | 0.80 |
| CPI | 96,000 ÷ 105,000 | 0.91 |
| EAC | 360,000 ÷ 0.91 | ≈ 393,750 |
| VAC | 360,000 − 393,750 | ≈ −33,750 |
Cross-check: cumulative completed = 4 + 5 + 3 + 4 = 16 of 20 planned = 80%, which matches SPI exactly. Two independent measures agreeing is a useful confirmation that the data is trustworthy.
Cost variance against the ±5% tolerance: 9,000 ÷ 360,000 = 2.5% of the increment budget — inside tolerance. Against current PV (120,000) it is 7.5%, which is outside it. The tolerance is defined against the budget, so the correct verdict is inside tolerance, but deteriorating — and the trend is what should drive the escalation decision, not the level.
Schedule: 4 items behind at 5 items per week = about 0.8 weeks ≈ 4 working days, which is outside the ±3-day milestone tolerance. This escalates.
Diagnosis (model). Primary cause: the single reviewer on the complaints routing module — work touching routing queues, which raises WIP and lowers throughput. Secondary cause: the integration environment being unavailable for two and a half days, which blocked work directly. The stakeholder dependency on municipal categories is a third, separate cause and is not a technical problem at all. The distinction matters because the reviewer can be fixed inside the project (add a second reviewer) while the environment requires a booking process, and the stakeholder dependency requires escalation and an interim decision.
Leading signal: rising WIP against a fixed limit was visible in week 2, while throughput was still on plan. Watching WIP against the limit — not throughput against plan — would have given a week's warning.
Corrective actions (model).
| Cause | Action | Owner | Due | Verification |
|---|---|---|---|---|
| Single reviewer | Add a second reviewer for routing changes; document the review checklist so a second person can apply it | Tech lead | End of week 5 | Items in review fall to ≤1 and throughput returns to ≥4/week by week 6 |
| Environment unavailability | Book the integration environment against the schedule, with a named owner and a shared calendar | Project manager | Week 5 | Zero unplanned environment outages in weeks 5–6 |
| Municipal categories | Escalate with a default set proposed for confirmation, so work can proceed | Project manager | Week 5 | Categories confirmed or defaults formally accepted by week 6 |
Corrective vs replanning: all three are corrective action — the plan, scope, and baseline are unchanged. If the municipal categories slip past week 6, it becomes replanning, because the scope would have to be re-cut to work with assumed categories.
Verification design. Watch items in review (currently 3); expect ≤1 within two weeks; a value of ≥3 would mean the action failed, which implies the constraint is not the reviewer alone but the review checklist or the volume of changes; judge on the end of week 6.
What not to do. Asking for more items to be started at once would push WIP further above the limit (already 6 against a limit of 4), lengthen the queue for the single reviewer, and lower throughput further. The correct counter-request is to give the project the environment booking authority and to confirm the municipal categories — both of which are things the sponsor can actually do.
Common errors: reporting the cost variance as out of tolerance against the wrong base; attributing the dip to the developer's one day of production support; failing to specify verification; recommending more parallel work.
Lab 23 — Agile versus Predictive Planning¶
Task 2 — cost of change
| Change | Points | Predictive (1.4×) | Adaptive (1.0×) |
|---|---|---|---|
| C1 Live chat | 8 | 11.2 | 8 |
| C2 Payment provider | 13 | 18.2 | 13 |
| C3 Consent capture | 5 | 7.0 | 5 |
| Total | 26 | 36.4 | 26 |
As a fraction of the 68-point capacity: predictive 54%, adaptive 38%.
Consequence under Proposal P. The 8-point buffer absorbs C3 alone. The remaining 28.4 points of consumption cannot be absorbed without either a two-sprint (four-week) slip — which misses the winter season by the whole of its most valuable trading period — or the removal of roughly 28 points of baselined scope, which is more than the three features the owner said she insists on combined (5 + 3 + 8 = 16 points, or 21 points if reviews are included). Because the change rate has been stable at three changes per two months for a year, this is not a tail risk; it is the expected case.
Consequence under Proposal A. The date holds. Roughly 26 points of lower-value work is deferred — for example the recommendation strip (13, value 2) and loyalty points (13, value 3), or gift cards (13, value 2) plus one of those. The owner can see precisely what she traded away, which is the mechanism that makes the trade-off a decision rather than an accident.
Task 4 — the dimensions that do not favour either approach in general.
- Cost confidence: depends on requirement stability. Fixed requirements make predictive costing reliable; volatile ones make it fictional.
- Cost of absorbing change: depends on the change rate, which is measurable for this business (three per two months) and is the single most decision-relevant fact in the scenario.
- Date confidence: depends on whether the date is externally fixed and whether scope is adjustable. If scope is genuinely adjustable, adaptive gives higher date confidence.
- Suitability for a fixed-price contract: depends on the contract, not the methodology — a fixed-price contract forces a predictive baseline, and the risk simply moves to change-request disputes.
Task 5 — gift cards. Under P, 13 points against a buffer already consumed by C3 means either removing a baselined feature or accepting the slip; there is no room. Under A, the promotion is admissible by deferring items of comparable size, and the decision is purely commercial: is 13 points of gift cards worth more than 13 points of whatever is displaced? A strong answer states the value ratings and answers the commercial question rather than the methodological one.
Task 6 — recommendation. The strongest answers recommend A, for reasons that are this project's specifics: the change rate is known and high; the date is commercially critical and the owner can tolerate scope variation; and value is unevenly distributed (38 of 43 value units sit in 61 of 100 points), so deliberate scope selection is worth more than scope protection. Reversal conditions should be concrete, for example: (i) the retailer signs a fixed-price contract for the build; (ii) the change rate falls below one per two months; (iii) a regulatory requirement enters with a legislated date and no discretionary scope.
Hybrid verdict. A hybrid is defensible here and often the best answer: a predictive envelope (fixed date, fixed budget, and a baselined "must-ship" set of 16 points covering the owner's three insistent features) with adaptive delivery inside it. It is better than a compromise because the predictive part covers exactly what the contract and the season require, and the adaptive part covers exactly what is genuinely uncertain. It is worse if nobody owns the seam, which is why the answer must name who owns it.
Task 7 — reporting. For A, expect: throughput or points completed per sprint with a threshold at about 15; deferred-item count, threshold rising; defect escape rate, threshold 0.2; and value delivered against plan. Deliberately not reported: velocity as a target number, because publishing it as a target converts a diagnostic into a goal and produces point inflation.
Common errors: recommending A or P on general principle; ignoring the 1.4× multiplier; not naming reversal conditions; a hybrid with no owner of the seam.
Lab 24 — Managing a Distributed Team¶
Task 6 — coordination overhead
| Practice | Calculation | Hours/week |
|---|---|---|
| Daily written update | 9 people × 15 min × 5 days = 675 min | 11.25 |
| Two coordination sessions | 6 attendees × 1 h × 2 | 12.00 |
| Weekly interface review | 4 attendees × 1 h | 4.00 |
| Handoff artefact authoring | 1.5 h × 4 handoffs ÷ 8 weeks | 0.75 |
| Total | 28.00 |
- As a fraction of an FTE: 28 ÷ 40 = 0.70 FTE
- Over the 40-day plan (8 weeks): 28 × 8 = 224 hours, or 5.6 FTE-weeks
Which practice to question. The two coordination sessions are the largest single line at 12 h/week — more than the written updates, which most people assume dominate. That inverts the usual intuition and justifies reserving live sessions for disagreement and negotiation rather than status, with status handled in writing.
If the time difference were 8 hours with no overlap: no synchronous practice survives; both coordination sessions must be replaced by written decision proposals with explicit deadlines and a ratified decision log, and the interface review becomes an asynchronous written review with a stated response window.
Visibility correction. Change the fortnightly review so that Site B presents its own work — not the project manager, who is at Site A and cannot represent Site B's reasoning. Under-recognition matters beyond motivation: work that is not seen is not resourced when it needs help, and risks inside it are not surfaced until integration, which is exactly the failure the API divergence already demonstrates.
Task 2 — the two diagnoses.
| Problem | Underlying cause | Artefact that would have prevented it |
|---|---|---|
| API divergence | No owner and no change process for the interface; each site optimised locally | An interface contract with a named owner and a written change process |
| Unrecorded design "agreement" | A decision taken in the only synchronous window, with no written record | A decision log with a 24-hour recording rule and a written decision template |
The API divergence is the more serious of the two: it is already producing two incompatible representations, and the cost appears at integration, which is on the critical path and cannot slip.
Task 3 — working agreement. Any eight checkable clauses are acceptable. The strongest answers name the decision-recording clause as the one to enforce first, because every other clause depends on there being a durable record: without it, ownership, handoffs, and disagreement-closing all revert to conversation.
Task 8 — security review. Risk: "Because the security review team does not know that Site B changed the interface representation, there is a risk that approval is granted against an obsolete interface, which would result in the approval being invalidated after integration, delaying launch." Corrective action: notify the review team in writing immediately, with the changed interface definition, and rebook the review if the change is material. Prevention: interface ownership (Task 4) — a change process would have required notifying the review team.
Common errors: forgetting the reading time in the daily update; assuming the written updates are the largest cost; a working agreement with unverifiable clauses; naming the project manager as Site B's presenter.
Lab 25 — Project Recovery Scenario¶
Task 1 — position at week 14
| Indicator | Calculation | Value |
|---|---|---|
| SV | 315,000 − 420,000 | −105,000 |
| CV | 315,000 − 357,000 | −42,000 |
| SPI | 315,000 ÷ 420,000 | 0.75 |
| CPI | 315,000 ÷ 357,000 | 0.88 |
| EAC | 480,000 ÷ 0.88 | ≈ 545,000 |
| VAC | 480,000 − 545,000 | ≈ −65,000 |
| Remaining budget | 480,000 − 357,000 | 123,000 |
| ETC | 545,000 − 357,000 | ≈ 188,000 |
- Value earned: 315,000 ÷ 480,000 = 65.6%, with 6 of 20 weeks (30%) remaining.
- Behind schedule and over budget: SPI 0.75, CPI 0.88.
- The funding gap is about 65,000 — and the management reserve of 40,000 does not close it even if released.
- The forecast is optimistic. EAC = BAC ÷ CPI assumes the recent past predicts the future, and the recent past has just lost two people, gained a licensing block, and lost review discipline. A bottom-up estimate of the remaining work (Task 3) is more reliable here, and the honest presentation is a range with the trend at the pessimistic end.
Task 2 — causes and symptoms.
| Event | Classification | Reason |
|---|---|---|
| 1 Resignations | Cause, partly a symptom | A cause of the current position; also partly a symptom of a project under pressure, if the departures were related |
| 2 Licensing pause | Cause, external | Owned by the procurement office; blocks a defined work package |
| 3 Unapproved scope | Cause, self-inflicted | 25 person-days built with no change request |
| 4 Defect escape rate | Symptom | A consequence of reduced review under schedule pressure |
| 5 Fixed deadline | Constraint, not a cause | It limits options; it did not cause the variance |
- Outside the project's control: the licensing pause (and, partly, the fixed deadline as a constraint).
- Self-inflicted: event 3; the control that would have prevented it is a change control process with a published tolerance and a visible change log.
- Amplified by the others: event 4 — reduced review is a direct response to the capacity loss from event 1 and the pressure from event 3.
- There is no single root cause, and a strong answer says so. Three independent causes converged; the only shared factor is that each was absorbed silently rather than escalated when it appeared.
Task 3 — what is left. ETC ≈ 188,000 (in budget terms). Remaining capacity is 75 person-days, which is not the binding constraint: the binding constraints are the licensing dependency (an external block on the visualisation layer) and the quality debt, plus a forecast shortfall in budget terms. Must ship: the data integration (already largely built), the core views that the funding review will look at, and the export scheduler if it is required for the review. Can wait: the visualisation layer (blocked anyway) and the second data source's enhanced views.
Disposition of the unapproved scope. It is out of the recovery plan unless it is accepted, and it must be processed through a retrospective change request — documenting what was built, what it cost, and whether it is retained — so the record is truthful rather than quietly erased.
Task 4 — options (model).
| Option | Date | Cost | Scope | Quality | Risk |
|---|---|---|---|---|---|
| R1 Descope to a defensible core | Week 20 held | Within the remaining 123,000 if review is restored | Cut the visualisation layer and the unapproved data sources | Review restored, escape rate falls | Funding tranche protected; sponsor loses visible polish |
| R2 Extend and complete | Week 26–28 | Requires ≈ 65,000 plus the cost of the extension | Full original scope | Review restored | Funding tranche lost; the ask may be refused |
| R3 Stabilise and stop | Week 20 handover of a smaller product | Within budget | Core views only, documented | Highest quality per unit delivered | Tranche at risk; the dashboard is less useful, but reliable |
Each option's unverifiable assumption: R1 assumes the core views are useful without the visualisation layer; R2 assumes the funding tranche is worth more than the extension cost; R3 assumes the sponsor will accept a smaller product.
Task 5 — quality. 20% of 75 person-days = 15 person-days — about 1.2 weeks of team capacity. R1 and R3 can absorb it (R1 by cutting scope, R3 because stabilisation is the review work); R2 can absorb it only with the extension. Not restoring review means the escape rate stays near 0.4, and roughly two of every five defects reach users — in a service whose incidents are publicly visible. Restoring review is therefore not negotiable, at whatever throughput cost.
Task 6 — recommendation. The strongest answers recommend R1 — descope to a defensible core, restore review, re-baseline honestly, and present the funding review with a smaller dashboard that works rather than a larger one that does not. The recommendation must include one explicit refusal: for example "we will not release the visualisation layer untested, nor claim the original scope was delivered."
What to approve versus decide. Approve: the re-baselined scope, date, and cost. Decide: whether to release the 40,000 management reserve, and whether to pursue the licensing block with procurement at director level. Declining everything leaves the sponsor owning an undisclosed outcome, which the answer must state.
Task 8 — controls. Expected: a change control threshold with a visible change log (prevents event 3); restored review requirement in the definition of done (prevents event 4); documented sync engine and pairing (reduces event 1's impact); and a reporting change — weekly leading indicators rather than fortnightly status, so WIP and licence blockers surface in days rather than weeks.
Common errors: presenting EAC as a reliable forecast without qualifying it; blaming the planning office for the unapproved scope; recommending extension without stating what the sponsor loses; treating restoring review as optional; a recommendation with no refusal in it.