Project Timeline vs Budget: Planner

Published by Bles Software, a custom software and AI company based in Yehud-Monoson, Israel, building web apps, AI agents and API integrations for clients in Israel, the US, the UK and the EU.

Trading timeline against budget, and what the trade actually costs

Every project plan is a bet on two numbers: the timeline and the budget. They move together, and asking for the same scope sooner pushes effort up rather than down. Ask for it cheaper and the calendar stretches. The useful question is not which one to pick, it is how much the exchange rate is, and there are published models and published outcome data that put a figure on it instead of leaving it to whoever is more confident in the room.

This page is a planner. Work down it in order and you will finish with a defensible position on what to compress, what to cut and what to leave alone.

Step one: know that compression costs effort, and by how much

The oldest result in this field is Brooks's law, stated as "adding manpower to a late software project makes it later", from The Mythical Man-Month (Addison-Wesley, 1975; anniversary edition 1995) [1]. It is quoted so often that it has stopped being read as what it is, which is a warning that people are not interchangeable with time.

COCOMO II puts a multiplier on it. In the model's published manual the required schedule driver, SCED, is rated at 75 per cent of nominal for Very Low, 85 per cent for Low, 100 per cent for Nominal, 130 per cent for High and 160 per cent for Very High, and the manual states that a schedule compression of 74 per cent is rated very low [2]. The model's schedule equation in that documentation is TDEV = 3.0 x PM^(0.33 + 0.2 x (B - 1.01)) x SCED% / 100 [2]. The manual also states that accelerated schedules produce more effort in the later phases [2].

Read that last sentence carefully, because it is the whole mechanism. Compression does not spread the same work over fewer weeks. It moves work later, into integration and test, where it is more expensive to do. We are quoting the 1997 and 1998 published model documentation here rather than the later calibrated figures, because the primary document for the 2000 calibration was not reachable from our network on 9 October 2026 and we do not publish numbers we have only seen reproduced elsewhere.

Step two: know which direction projects actually fail in

Flyvbjerg and Budzier analysed 1,471 IT projects and report an average cost overrun of 27 per cent, and that one in six projects was a black swan carrying a cost overrun averaging 200 per cent and a schedule overrun of almost 70 per cent [3].

The ratio inside that black swan group is the planning insight: cost ran away roughly three times as fast as the calendar [3]. Teams defend the date and pay in money, people and scope creep. If you are about to compress a schedule, the historical record says the date is the thing you will protect and the budget is the thing that will give.

PMI's 2025 Pulse of the Profession, drawn from its 2024 global survey of 2,254 respondents, reports budget adherence of 73 per cent among professionals with high business acumen against 68 per cent for the rest, schedule adherence of 63 per cent against 59 per cent, projects meeting business goals at 83 per cent against 78 per cent, and failure rates of 8 per cent against 11 per cent [4]. These are self-reported figures from practitioners, not audited project accounts, and the gap between the two groups is smaller than most people expect on every one of those measures.

Step three: price a week of the team honestly

The exchange rate needs a price per week, and public wage data gives you one nobody can argue with. The United States Bureau of Labor Statistics puts software developers at a mean hourly wage of $71.20 and a mean annual wage of $148,100 in its most recent occupational survey [5].

At that mean hourly figure a five-person team costs about $14,240 for a 40 hour week in wages alone [5]. That is the unit to hold in your head for the rest of this page: before benefits, overhead or management, a month of a five-person team is in the high five figures in wages. Decisions that save a week are worth that much, and decisions that add a week cost that much.

Step four: know where the cheap fixes are

The reason compressing a schedule is expensive is that it pushes defects later, and defects get costlier the later they are found. The only primary source we could read on that is NIST Planning Report 02-3, "The Economic Impacts of Inadequate Infrastructure for Software Testing", from 2002. Its Table 5-1 gives relative cost to repair by the stage the defect is found: 1x in requirements and design, 5x in coding and unit test, 10x in integration and system test, 15x at beta and 30x after release [6].

That table is headed "Example Only" in the report itself, so we present it as the report's own illustration rather than a measured curve [6]. The same report's measured figures are the economy-wide ones: it puts the annual cost of inadequate software testing infrastructure to the United States economy at $59.5 billion, with a feasible reduction of $22.2 billion, split as $21.2 billion on developers (reducible by $10.6 billion) and $38.3 billion on users (reducible by $11.7 billion) [6].

The widely repeated "100x after release" figure attributed to the IBM Systems Sciences Institute is deliberately absent from this page. We could not find its primary publication, and a number with no findable source is not evidence, however often it appears in slide decks.

Step five: do not solve a schedule problem by adding people

Brooks's law [1] has a modern measurement behind it. A study by DX, published and last updated 9 April 2026, covering 400 companies with 500 or more developers each between October 2025 and February 2026, puts the average time to a tenth merged pull request at 33 days as of April 2026, down from 39 days in the fourth quarter of 2025, and reports 91 days for developers with no AI tool use against 49 days for daily users [7].

Take the 33 day figure at face value and the arithmetic against step three is brutal: a new engineer added to save a deadline costs roughly a month of wages [5] before contributing at the rate you are paying for, plus the time of whoever answers their questions. This is a vendor's own study of its own customers, so treat the direction as more reliable than the exact number [7].

The planner: six moves, cheapest first

When the date cannot move and the budget cannot grow, these are the moves in the order they actually cost.

  1. Cut scope at the edges. Free, and it is the only lever that reduces both numbers. Name the three things that can ship in version two.
  2. Reduce quality targets you do not need yet. Also free, and reversible, and it has a published price. Dropping a database availability target from 99.95 to 99.5 per cent is the difference between Multi-AZ and Single-AZ on Amazon's own service levels [8], and its price list puts those at $0.342 against $0.171 an hour for a db.m5.large [9], so the target is the spend. Our SLA impact on cost page works that trade through in detail.
  3. Parallelise across seams that already exist. Cheap, if two parts genuinely do not touch. Expensive the moment they share a data model, which is where step one of COCOMO's warning bites [2].
  4. Pay for overtime on a short, bounded push. Buys days, not weeks, and you repay it in defects that land in the 10x and 30x stages [6].
  5. Add people. Costs a month before it pays [7] and risks making the date worse [1]. Only sensible if the deadline is more than a quarter away.
  6. Compress the schedule and accept the effort multiplier. The model says this adds effort and moves it to the expensive phases [2], and the historical record says your budget is what will absorb it [3].

What to ask for instead

The most useful thing we do on a late project is not resourcing, it is making the trade visible. Three numbers, measured rather than argued: what is actually done, what the remaining work is in team-weeks, and which of the remaining items are on the critical path because something else waits on them. With those, the conversation stops being about effort and becomes a choice between named features and a named date, which is a decision a business can actually take.

If a date is immovable, say so at the start and let the scope be the variable. The published evidence says that is the only version of this trade that ends well [3].

Sources

More Costs and Timelines from Bles Software