Why Costs Increase When Projects Accelerate
Compression does not buy time at a flat price. A 1989 practitioner source names four independent causes of the acceleration penalty, and three of them have nothing to do with adding people to the team.
The shape the penalty takes
R4 is a practitioner review and synthesis article from 1989. It reviews a known tradeoff, offers a causal theory for it, and converts published estimates into a single comparable metric. It opens on a case rather than a model.
A large manufacturer of document-imaging equipment began developing a copier model on a deliberately accelerated schedule, to hold competitive position against overseas manufacturers that had taken market share from it. The product moved quickly into pilot production before a serious quality problem surfaced: a wire harness holding together the wires connecting internal components did not meet quality standards. The harness was quickly redesigned — and then the automatic manufacturing equipment that assembled the harness would not function properly. The manufacturing problem was corrected at a reported cost of $1 million.
- Schedule compressed
- Task handed on early
- Defect found in pilot production
- Redesign
- Downstream tooling fails
- Correction cost
What follows is the article's causal account. Read the four mechanisms as independent contributors, because the practical mistake is to notice one of them, price it, and call that the cost of speed.
Mechanism 1 — every task starts with less information
R4 describes R&D as very much a heuristic process, where each step builds on the information gained in previous tasks. That dependency is the mechanism. When a project is compressed, some steps begin to overlap, and each task is begun with less information than it would otherwise have had.
The immediate consequence is mistakes and rework. The consequence that matters for the shape of the curve is the second-order one: as the project is compressed further, greater penalties are exacted, because tasks are initiated under increasing uncertainty. The penalty is not a fixed toll for overlapping — it grows with the degree of overlap.
This is the mechanism the opening case illustrates. Nobody was careless. A task was started before the information that would have prevented the defect existed, and the cost surfaced two handoffs downstream. Where that uncertainty comes from in the first place is treated separately, in sources of uncertainty in R&D projects.
Mechanism 2 — diminishing returns, the one everybody already reaches for
This is the conventional mechanism, and R4 states it conventionally. As more technical people are added to the same R&D project, the marginal contribution of each additional person begins to decline. It happens principally because communication and training burdens grow. R4 identifies this as essentially the familiar software-engineering result about adding people to a project.
Communication is quantified. Assuming pairwise communication requirements between each R&D group, the total communication burden is roughly proportional to the square of the number of groups — or, exactly, proportional to n(n − 1)/2, where n is the total number of groups. That assumption of pairwise communication is stated, and it is what the formula rests on.
Training carries the part of the mechanism that ties specifically to acceleration. New personnel absorb the time of experienced team members who must train them. Add new personnel more rapidly and the effect is more severe, because the ratio of new to experienced people is greater. The rate of addition matters independently of the headcount — which is why a team that could have absorbed six people over a year suffers when it absorbs them over a quarter.
Mechanism 3 — paying for approaches serial search would have spared you
The third mechanism is probabilistic and has nothing to do with staffing levels. R4 sets it up as a small model. A single task can be approached in a number of different ways, but in advance you can only assign success probabilities to the various approaches. For convenience, assume each approach has the same success probability, the same cost, and that all are independent of each other.
Serial search — minimises cost
- R4's illustration uses ten alternative approaches to one task
- Attempt each of them in sequence, quitting when one is found to be successful
- You expect to find a successful approach before trying all ten
- You pay only for the approaches you actually attempted
- This is the minimum-cost strategy, and it is slow
Parallel search — minimises time
- If a successful approach must be found more quickly, several approaches are tried concurrently
- More approaches must therefore be paid for
- Under extreme time compression all ten might be tried simultaneously — and all ten paid for
- The premium is the expected number of approaches you would never have had to fund
- This is the fastest strategy, and it is strictly worse on cost
The ten approaches are an illustrative figure, not a typical number. The transferable point is the direction of the trade: running everything in parallel is a time strategy that is worse on cost by construction, and the convexity comes from the fact that each further step towards full parallelism buys less time for more money.
Mechanism 4 — the critical path, and a network that gets denser
The fourth mechanism appears when a complex R&D project is viewed as a network of tasks. It is the cleanest single explanation of why the curve is convex, and it requires no assumption about people or uncertainty at all.
How compression proceeds through a task network
Find the critical path
The earliest normal completion time is estimated by finding the critical path through the network of tasks.
Crash the cheapest task first
To compress the critical path, a manager would first choose a relatively easy — and therefore inexpensive — task to accelerate.
Then the next cheapest
If further compression is required, the least expensive remaining task is chosen.
Then the expensive ones
If increasing compression is required, more expensive choices have to be exercised in order to shorten the critical path. The cheap options are gone.
And the network thickens
With increasing compression the network becomes denser, with more overlap between tasks, so compression may require simultaneous acceleration of several tasks rather than one.
Under these conditions, R4 concludes, total project cost increases with acceleration. Note what this mechanism does to extrapolation: the price of the first month of compression is drawn from the cheapest option on the network, so using it to forecast the price of the fourth month understates that price by construction.
Why the curve is convex, not linear
THE FOUR MECHANISMS SIDE BY SIDE
| Mechanism | What acceleration actually changes | What you pay for | Why the penalty accelerates |
|---|---|---|---|
| 1. Information dependency | Steps overlap, so each task begins with less information | Mistakes and rework | Further compression means tasks start under greater uncertainty, so the rework penalty grows |
| 2. Diminishing returns | More technical people are added, and added faster | Communication and training burden — pairwise communication scales as n(n − 1)/2 | The ratio of new to experienced people rises with the rate of hiring |
| 3. Parallel approaches | Uncertain technical tasks are attacked concurrently rather than in sequence | Approaches that serial search would never have needed | Each further move towards full parallelism buys less time for more approaches |
| 4. Network compression | Critical-path tasks are crashed, and the network grows denser | Progressively more expensive crashing options, then several at once | You spend the cheap options first; only expensive ones remain |
Only mechanism 2 is the familiar diminishing-returns story. An estimate built on it alone accounts for one of four causes.
The practical consequence is that the intuitive linear model — buy ten percent of the time for ten percent more money — is wrong in a specific direction. The same ten percent costs progressively more the closer you already are to the minimum feasible duration.
What this changes about an acceleration estimate
A crashing figure arrives as a single number, and the four mechanisms are the questions that number has to survive. The same interrogation applies to any R&D cost estimate — see risk and uncertainty in R&D financial analysis for why cost-outcome distributions in R&D carry a long tail on the bad side rather than sitting symmetrically around the estimate.
Before you accept a crashing figure
- Ask which of the four mechanisms it prices. A figure built from staffing costs alone has covered one of four.
- Ask whether rework from earlier task starts is in it, and at what rate of overlap it was assumed.
- Ask how many parallel technical approaches will now be funded that a serial search would have avoided.
- Ask whether the estimate extrapolates from the first increment of compression — if so, it is anchored on the cheapest option in the network.
- Ask what the people being moved onto the project would otherwise have delivered. That number is excluded by R4's own accounting and will not be in the ledger.
- Ask where on the curve you already sit. The same compression costs more the nearer you are to the minimum.
How large the penalty actually is, which project and firm characteristics make the curve steeper, and how to price a specific acceleration decision are handled on the companion page, managing acceleration: complexity and trade-offs. This page is the causal account; that one is the estimate and the response. If the answer is that the project cannot carry the price of the schedule it has been given, the decision in front of you is a continuation decision — see making better project termination decisions.
What to carry forward
- Four mechanisms, not one. Information dependency, diminishing returns, parallel approaches and network compression each push cost up independently.
- Only diminishing returns is the familiar story. An acceleration estimate that prices staffing alone has priced a quarter of the problem.
- Each mechanism produces convexity by itself, which is why the curve bends rather than tilts. The last month of compression is never priced like the first.
- Serial search minimises cost, parallel search minimises time. Choosing speed here means paying for attempts you would not otherwise have made.
- The number in the ledger is a floor. What the reassigned people would have produced elsewhere is excluded by design.
Frequently asked questions
Is this just the old rule about adding people to a late project?
That rule is one of the four mechanisms R4 names, and R4 says so. The other three operate even if headcount never changes: tasks begin with less information and generate rework, uncertain technical tasks get attacked in parallel rather than in sequence, and crashing the critical path runs through the cheap options first. Treating the staffing effect as the whole story is the specific error the page is written against.
Why does the curve bend instead of sloping straight down?
Because each mechanism gets worse as compression increases, rather than charging a flat toll. Overlapping tasks start under greater uncertainty; new people arrive at a higher ratio to experienced ones; more approaches must be funded in parallel; and the remaining crashing options are the expensive ones. R4's own summary is that costs grow at an increasing rate under further compression.
Was the $1 million in the opening case a typical acceleration penalty?
No. It is a cost reported in the business press for one specific case, quoted by R4 to illustrate the cascade — rushed handoff, design defect, downstream tooling failure. R4 presents the cascade as common; it does not present the figure as typical, and neither should you.
Does parallel development not reduce risk?
It reduces schedule risk, which is why it is used. R4's point is about the cost side: under serial search you expect to find a workable approach before exhausting the alternatives, so you pay for fewer of them. Running them concurrently means paying for approaches you would never have needed. It is a time strategy that is worse on cost by construction.
Our first month of compression was cheap. Does that mean the rest will be?
The opposite, on R4's account. Compression proceeds by crashing the cheapest task on the critical path first, then the next cheapest. An early crashing success is drawn from the cheapest option available, so extrapolating from it understates every increment that follows.
How should I present the cost of acceleration to a sponsor?
State which mechanisms your figure covers and which it does not, and say explicitly that the opportunity cost of the people being moved is excluded — R4 excludes it and notes it will not appear in accounting figures. A number offered without that boundary will be read as complete when it is a floor.
References and source attribution
- R4 - why costs increase when projects accelerate. Practitioner review and synthesis article in a journal for research and technology management, March-April 1989; 3 printed pages; 7 references; one table and one figure. Reviews a known tradeoff, proposes a causal account of it, and synthesises published estimates into a common metric. Not itself an empirical study.
- The econometric and software-engineering studies whose estimates R4 recomputes, and the business-press report of the accelerated copier programme, are cited within R4 and were not supplied to this library. They are recorded as R4 describes them.
- Eleven copyrighted journal articles on R&D project management, supplied as a reading set for a literature review and profiled for this library. Front matter, abstracts, framework sections, tables and figures were read; article bodies were not reproduced, and all content here is paraphrase. The set is a reading list, not a systematic survey of the field.
- Supplied teaching source for this library (research methods and research process materials). Used here for page conventions and voice only; it does not treat schedule compression.
Suggested questions for Ask KEVOS
- Take our crashing estimate and tell me which of the four mechanisms it has priced.
- Explain the difference between serial and parallel search on a technical task, using our own project.
- How do I quantify the rework we should expect if two phases overlap by six weeks?
- Draft the wording that tells a sponsor our acceleration figure excludes opportunity cost.
- Why does the communication burden scale with the square of the number of groups?
- Our first increment of compression was cheap. Help me work out what the next one will cost.