Skip to content

Lesson 5 — Schedule, Cost, and Debt Trade-offs

At a glance

Learning objectives

By the end of this lesson you should be able to:

  1. Explain why the scope–time–cost triangle is a simplification, and name the variables it hides.
  2. Cost a crashing decision using a cost slope, and state the conditions under which crashing cannot work at all.
  3. Reason about fast-tracking as a trade of schedule against rework risk, and quantify the trade roughly.
  4. Compare the cost of accelerating with the cost of delay, and recommend accordingly.
  5. Define technical debt precisely, distinguish deliberate from inadvertent debt, and explain what "interest" looks like in delivery measures.
  6. Record a debt decision with an owner, a repayment trigger, and an honest statement of interest — and say when taking on debt is the right call.

Prerequisites

  • Module 06 Lesson 2 — the critical path, float, and why only critical activities affect the finish date.
  • Module 07 Lesson 1 — estimates with a basis, so that any crash cost is comparable with the baseline.

Introduction

Every project faces the same request: can it be sooner? The honest answer is almost never "yes, by working harder". It is a set of specific trades, each of which moves cost, risk, quality, or scope — and the professional skill is not in finding a way to compress, but in naming what is being given up and getting agreement to give it up.

Technical debt is the same subject viewed from the other end. Compression usually buys time by accepting something unfinished, and the thing that is unfinished accumulates. This lesson treats the two together because they are one decision made twice: what are we willing to owe in order to be earlier?

1. The trade-off is between five things, not three

The familiar triangle — scope, time, cost — hides two variables that are usually the ones actually moving:

Variable What moving it looks like Who usually has authority to move it
Scope Dropping a feature, or reducing it to a simpler form Product owner, or sponsor above a threshold
Time Later delivery Sponsor
Cost More people, more overtime, external spend Sponsor
Quality Less testing, less review, accepted defects Business owner, with the consequence stated
Risk New or higher exposure, often from overlapping work Sponsor

Two properties make the trade-off harder than the triangle suggests. First, the time–cost curve is not linear: each successive week of compression costs more than the previous one, and past some point it cannot be bought at all. Second, compression rarely produces what it promises, because the extra people need onboarding, the overlap causes rework, and the overtime exhausts the people who are expected to work it — effects that are well described in the software literature (Frederick Brooks's The Mythical Man-Month is the canonical source for the added-people effect, and it remains accurate for work with high communication content).

2. Crashing: buying duration with money

Crashing adds resource to a critical activity to shorten its duration. It works only under specific conditions, and each is worth checking before you propose it:

  1. The activity is on the critical path. Speeding up a non-critical activity changes nothing — it merely increases its float.
  2. The activity can absorb more people without losing efficiency. Adding a third person to a two-person design task often slows it down.
  3. The work is decomposable so that additional people have something to do immediately.
  4. There is a known cost slope — the extra cost per day saved — and a limit beyond which further compression is impossible.

Cost slope = (crash cost − normal cost) ÷ (normal duration − crash duration).

Three checks that catch most errors:

  • After crashing one activity, recompute the network. Compression can create a second critical path, at which point spending more on the first path buys nothing.
  • Include the coordination cost: onboarding time, additional reviews, and the management attention the extra people consume. These rarely appear in the cost slope and often dominate the real cost.
  • Ask whether the constraint is even compressible. External review queues, regulatory waiting periods, procurement lead times, and clinical sign-off cannot be crashed by adding developers. Crashing a schedule whose critical path runs through someone else's queue buys nothing at all.

3. Fast-tracking: buying duration with rework risk

Fast-tracking overlaps activities that were sequential. It looks free — no money changes hands — and it is usually the more expensive option, because the cost appears as rework.

What is overlapped The rework it creates
Design and build Building against a design that changes
Build and test Testing an unstable build; defects found later and more expensively
Build and integration Integration work that assumes an interface not yet frozen
Development and data migration Migrating into a schema that is still moving

A rough way to make the trade explicit without any tooling:

Item Estimate
Days saved by overlapping n
Rework probability (your judgement, justified) p
Rework effort if it occurs r days
Expected rework = p × r x days
Net benefit = n − x n − x days, plus the variance you have just accepted

The arithmetic is not the point; the conversation is. Writing p and r down forces someone to say out loud that the overlap is a bet, and it gives you a figure to compare against the alternatives.

4. Cost of delay against cost of acceleration

Compression is not automatically worth having. The comparison is:

$$ \text{value of being } n \text{ days earlier} \;\; \text{versus} \;\; \text{cost of the } n \text{ days} $$

The left side is the cost of delay (see Lesson 2) — what is lost per day of delay: revenue, a regulatory window, a seasonal peak, the value of freed capacity. The right side is the crash cost, the fast-tracking rework risk, the quality given up, and the exhaustion of the people involved. Where the left side is unmeasurable, say so, and make the decision on the grounds you actually have — "we do not know the cost of delay here, and that is why the decision is being taken on the fixed window rather than on economics."

5. Technical debt, defined precisely

The metaphor is Ward Cunningham's (from his 1992 OOPSLA experience report), and it is worth keeping the original meaning: shipping a design that reflects your current understanding of the problem, and accepting that the next increment will require the code to be reshaped. That is not a defect; it is how incremental development works. Debt becomes a problem when it is neither known nor repaid.

A useful taxonomy distinguishes two axes:

Prudent Reckless
Deliberate "We will ship the simplest workable rule set now and generalise it when the second programme is added — owner: technical lead; revisit at the next major increment." "There is no time to design this properly."
Inadvertent "Now that we have built it, we can see a better abstraction." "What is layering?"

The two axes give four genuinely different situations, and only one of them — reckless and deliberate — is the common and damaging case, because it is a decision made without recording what was traded. (This quadrant is Martin Fowler's, published on his site and widely cited; the idea of managing debt explicitly is the subject of Philippe Kruchten, Robert Nord, and Ipek Ozkaya's Managing Technical Debt, part of the SEI series.)

Interest is what the debt costs: slower change, more defects, more time spent working around the shortcut, and reduced ability to make later changes. It is measurable, and the measures are the ones the DORA research programme popularised and Accelerate (Forsgren, Humble & Kim, 2018) describes: change lead time, deployment frequency, change failure rate, and time to restore service. A rising lead time with a stable defect count usually means the interest is being paid in friction.

Principal is the cost of repayment: the effort to redesign or rewrite. Debt is worth taking when the value of being earlier exceeds the projected interest plus the principal, discounted by the probability that the code survives long enough to matter. That last clause is the one most often forgotten: debt taken in a component that will be replaced next quarter is not debt at all.

6. Recording a debt decision

An unrecorded shortcut is not a decision; it is an accident that will be discovered by someone who is not you. A workable record has five fields, and it takes two minutes:

Field Example
The shortcut Pagination omitted; the list screen renders all rows
Why now The admission window opens in three weeks; the screen is not on the critical path for launch
The measure it constrains The screen must stay under the agreed response target; today it only works under about 500 records
Owner and repayment trigger Technical lead; revisit before the second programme is onboarded or when record volume passes 400
Interest observed Defect D-014 (timeout above 500 records); one report of a slow screen

The repayment trigger is the part that turns a note into a control. Without it, repayment tends to happen only when the debt becomes an incident — which is the expensive way to discover something you already knew.

Key terms

Term Meaning
Crashing Adding resource to a critical activity to shorten its duration, at extra cost
Cost slope Extra cost per unit of duration saved by crashing, within a known compression limit
Fast-tracking Overlapping activities that were sequential, buying time with rework risk
Cost of delay Value lost per unit of time that delivery is delayed
Technical debt A design or implementation shortcut whose later correction will cost more than doing it now
Principal and interest The cost of fixing the shortcut, and the ongoing cost of living with it
Deliberate debt A recorded trade-off with an owner and a repayment trigger
Inadvertent debt A shortcut nobody noticed taking, usually revealed by hindsight
Change lead time Time from a change being started to it being running in production

Worked example

Task: respond to a request to bring the admission portal forward by ten working days, at week 6 of a 40-day schedule. Figures are invented for teaching.

Step 1 — Establish whether compression is available at all. The critical path from Lab 10 is A → B → D → G → H → I → J, in which H is an external security review of ten working days and I is system testing. H cannot be compressed by adding developers, and the data-protection review that sits alongside it cannot be shortened by any legitimate means. So the available compression is in B, D, G, and I — and the first question to the requester is whether the ten days are needed, or whether a two-week delay on one non-critical path would do.

Step 2 — Price the crashing option. Crashing D (document upload build, 5 days) by adding a second developer for three days: extra cost = 3 days at the day rate, plus two days of coordination and review overhead that the cost slope does not include. Compressing I (system testing) is rejected outright: less testing buys schedule with defects, and the business owner has already stated that a public failure in the application window is unacceptable. Net saving: 3 days, not the 10 requested.

Step 3 — Price the fast-tracking option and its risk. Overlapping G (integration) with D saves four days. C (form build) finished 15, D starts 9, so integration can start on D's mid-point with a partial interface — rework probability judged at 0.5, rework effort 6 days if it occurs. Expected rework: 0.5 × 6 = 3 days. Net benefit: 4 − 3 = 1 day, with materially more variance. Stated that way, the option is clearly worse than crashing and should not be chosen for the sake of one day.

Step 4 — Combine, and state the real total. Three days from crashing, one from fast-tracking with variance, and a further two days from resequencing the admin console after the security review (options, not compression). Total: up to six days, of which only three are reliable. The honest answer to "can we have ten days?" is no — six at most, and I would commit to three.

Step 5 — Compare with the cost of delay before recommending. The window is fixed by policy and the consequence of missing it is a year's delay, so the cost of delay is high and a modest, reliable compression is worth paying for. The recommendation is to take the three reliable days and propose a reduced launch scope for the rest — dropping one deferrable requirement — rather than to gamble six days on a bet with a one-day expected return. Note that the decision is a scope decision as much as a schedule one, and it needs the product owner, not the project manager.

Step 6 — Record the debt the compression creates. To fund D's acceleration, the team defers pagination on the admin console — deliberately, with an owner, a trigger, and the observed interest written down (the pagination debt recorded in Lab 22). The record includes the constraint it places on the release: the console is acceptable at launch volumes and must be revisited before the second programme is onboarded. This is the difference between deliberate and reckless debt: both ship the same shortcut, and only one of them can be repaid on purpose.

Common misconceptions

“Adding people makes software sooner”

Sometimes, for decomposable work on the critical path, with onboarding time included. Often not, because the added communication between people exceeds the added capacity. The effect is well documented (Brooks, The Mythical Man-Month) and it is why crashing requires the four conditions in section 2 rather than an assumption that more is faster.

“Fast-tracking is free because it costs nothing”

It costs rework, which is the most expensive kind of effort because it is unplanned, arrives late, and often lands on people who were already committed. Writing down the rework probability and effort is what converts a free-sounding option into a comparable one.

“Technical debt is just bad code”

That is only its most visible form. Debt is any shortcut whose later correction will cost more than doing it now — including a deferred design decision, an unhandled edge case that is documented, a component written for one caller, and a test suite that will not run in the build pipeline. And not all of it is wrong: deliberate debt with a trigger is a legitimate way to buy time.

“We will pay the debt down in the next sprint”

Almost never true unless the repayment is a scheduled item with an owner, and the trigger is written down. Debt that is not on a plan is repaid when it becomes an incident, at which point the interest includes the incident.

Practical activity

Trade a schedule, and record the debt.

  1. Take a schedule you have built. Identify which activities could be crashed and, for one, compute a cost slope using your own day rate and a stated coordination allowance.
  2. Find one pair of activities to fast-track. Write down the rework probability, the rework effort, and the expected rework, then the net benefit including variance.
  3. Recompute the network after each change. State whether a second critical path appeared.
  4. Ask the requester what the cost of delay is. Record the answer, even if the answer is "unknown" — and say which grounds the decision therefore rests on.
  5. Write a five-field debt record for one shortcut your plan depends on, including a repayment trigger that could actually occur.

What "good" looks like: compression limited to the critical path, a cost slope with coordination included, a fast-tracking option whose net benefit is honestly small, at least one compression rejected because it is not physically possible, and a debt record with a trigger and an owner rather than an intention to fix it later.

Self-assessment

  1. Name two variables the scope–time–cost triangle hides, and say why hiding them is dangerous.
  2. Why must the network be recalculated after crashing an activity?
  3. A manager proposes overlapping design and build to save three weeks. What do you ask, and how do you present the answer?
  4. What distinguishes deliberate from inadvertent technical debt, and why is the distinction useful?

  5. When is taking on technical debt the right decision?

  6. Apply it — crashing decision. An e-commerce launch is four weeks late against a seasonal window. Two activities can be crashed: A, on the critical path, costs 40,000 per week saved and can be shortened by two weeks; B, on the critical path, costs 60,000 per week saved and can be shortened by three weeks. A third activity has three weeks of float. (Figures are illustrative.)

    Hint: A strong answer names what to crash, what it cannot do, and the check that must follow.

Show answers
  1. Quality and risk. They are dangerous to hide because compression almost always moves one of them, so if they are not named, the trade appears free and is agreed without anyone accepting the consequence. A schedule that improves because testing was reduced has not improved; it has moved the cost to a later date and a different owner.
  2. Because compression can equalise two paths, creating a second critical path — after which further spending on the first path saves nothing. The critical path is a property of the current network, so it must be recomputed after any duration or logic change.
  3. You ask for the rework probability and the rework effort if a design change lands after building has started, and present the net benefit as days saved minus expected rework, with the variance acknowledged. If that leaves little or nothing, the option is not worth taking; if it leaves a real saving, the comparison shows what has been accepted and by whom.
  4. Deliberate debt is a recorded trade-off: someone chose it, knows what it constrains, and has a repayment trigger. Inadvertent debt is a shortcut taken without noticing, and it is usually visible only in hindsight. The distinction matters because the responses differ — deliberate debt needs a trigger and an owner, whereas inadvertent debt needs a review or a design practice that surfaces shortcuts earlier.
  5. When the value of being earlier exceeds the projected interest plus principal, and when the code is expected to live long enough for that calculation to matter. Where the component will be replaced soon, or the shortcut constrains nothing you intend to do, the debt may never need repaying at all — and taking it deliberately, with the record and the trigger, is straightforwardly the right call.
  6. Crash the cheaper critical-path activity first: A at 40,000 per week, up to its two-week limit, which buys two weeks for 80,000. B is next at 60,000 per week if more is needed. Do not touch the activity with float — it is not on the critical path, so shortening it buys nothing. Three conditions decide whether this works at all: the work must be decomposable so extra people or money actually add parallel capacity; there must be someone available to do it (crashing a one-person task is impossible); and the coordination cost must be counted, because adding people adds communication as well as output. Two checks must follow: recompute the network, since crashing A can create a new critical path elsewhere and the two weeks are not guaranteed; and ask what the acceleration risks — compressed testing, a rushed migration, or debt in the form of shortcuts that are not recorded. Compare total acceleration cost against the cost of delay before approving it, and write down any debt decision with its owner and repayment trigger.

Summary

  • The real trade-off involves five variables: scope, time, cost, quality, and risk. Name the ones that move, or the trade appears free.
  • Crashing works only on the critical path, only for decomposable work, only up to a limit, and only when the coordination cost is counted. Recompute the network afterwards.
  • Fast-tracking buys time with rework risk. Quantify the probability and the rework, and the option usually stops looking free.
  • Compare any compression with the cost of delay; where delay is unmeasurable, say so and state the grounds the decision actually rests on.
  • Technical debt is any shortcut whose correction later costs more than doing it now, and deliberate debt with an owner and a repayment trigger is legitimate practice. Interest shows up in delivery measures — change lead time, defect rates, deployment frequency, time to restore service.
  • Record debt as a decision: the shortcut, why now, the constraint, the owner and trigger, the observed interest. Without the trigger, repayment waits for an incident.

Further learning

Verifiable sources for the ideas named above: Ward Cunningham's 1992 OOPSLA experience report for the debt metaphor's origin; Martin Fowler's published technical-debt quadrant for the deliberate/inadvertent and prudent/reckless axes; Philippe Kruchten, Robert Nord, and Ipek Ozkaya, Managing Technical Debt (SEI series) for managing debt deliberately; Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate (2018) for the delivery measures used as interest indicators; and Frederick P. Brooks Jr., The Mythical Man-Month, for the added-people effect.