Managing project timelines without compromising quality: buffers, limits and the scope trade

What does managing project timelines without compromising quality take?#

Managing project timelines means treating the date as a forecast with a known error, sizing a buffer from comparable work, capping work in progress and trading scope, never testing. Each of those four moves has a number behind it. First, the error: comparable past work tells you how far your plans usually run over. Then the buffer: you add that error once, at the end of the plan. You do not pad every task.

Next comes the cap on work in progress. Little's law dates from 1961. It says the items in flight equal throughput times the time each item spends in the system. So with fewer items in flight, each one finishes sooner at the same pace.

Finally, the trade. In 2019, Kuutila and colleagues at the University of Oulu reviewed 102 papers on time pressure. Most of the strong studies report "productivity and decreased quality under time pressure". In practice, quality gives first unless someone decides otherwise. So decide in advance: scope gives, and tests stay.

What does managing timelines mean, and what is a timeline constraint?#

Managing timelines means planning, sequencing and re-forecasting work so a committed date holds, and a timeline constraint is a fixed date or duration the plan must fit inside. The first part is ongoing work, not a plan you write once. To manage timelines well, you re-forecast from actual progress every week. In December 2015, the US Government Accountability Office published its Schedule Assessment Guide, GAO-16-89G. It calls a schedule the means "to gauge progress, identify and resolve potential problems". Also, the 2015 guide says a schedule's reliability decides how credible its dates are.

Timeline constraints come in two forms. A hard date is set from outside, such as a launch event or a contract milestone. A fixed duration is a box of time, such as a six-week release window. Either way, the date is fixed, so the plan has to flex in what it delivers. Therefore, "can we hit the date?" is never the whole question. Instead, ask what you can deliver by the date at the quality you need.

How often do software project schedules slip?#

The Standish Group's 1994 CHAOS figures, drawn from 8,380 applications, put 16.2% of software projects on time and on budget and 52.7% challenged. The other 31.1% were cancelled, in that same 1994 survey of 365 respondents. So in 1994, a plan with no room for slip was a plan for the minority case.

These are 1994 figures, and they describe 1994. The Standish Group still runs the CHAOS series, but its current editions are sold. So the public 1994 report is the one anyone can check. In it, challenged and cancelled projects ran to 222% of their original time estimate on average. Methods have changed a great deal since then. However, the newer studies below still find one pattern: most slips are small, and a few are huge. In a paper posted on 29 August 2014, Bent Flyvbjerg called it an iron law for large projects: "Over budget, over time, over and over again."

Why is the average overrun the wrong number to plan around?#

Flyvbjerg and Budzier measured a 27% average cost overrun across 1,471 IT projects, but one in six overran cost by 200% and schedule by almost 70%. Bent Flyvbjerg and Alexander Budzier published the study in Harvard Business Review in September 2011. In their words, "Fully one in six of the projects we studied was a black swan". So a buffer sized from the average covers small slips and leaves you open to the large ones.

Meanwhile, a later study explains why the tail exists. In 2022, Flyvbjerg, Budzier and four co-authors studied 5,392 IT projects completed between 2002 and 2014. Cost overruns, they found, follow a power law: many small ones, plus a fat tail of extreme ones. Their proposed cause is how parts depend on each other. As the 2022 paper puts it, "a problem in a single technological component can lead to chain reactions". In short, software slips cascade, because one late piece holds up every piece that needs it.

What causes timeline pressure in the first place?#

Timeline pressure usually starts with the estimate: in a 1994 study, 37 students took 55.5 days on theses they estimated at 33.9 days, beyond even their worst case. In that study by Buehler, Griffin and Ross, their worst-case guess was 48.6 days. So reality beat the darkest plan they could picture. In the same 1994 study, only about 30% finished in the time they predicted, as the planning fallacy entry reports.

Software teams, for example, do the same thing. The 2019 Oulu review of time pressure in software work found that "time pressure is usually caused by errors in cost estimation". Because people plan from the best version of the task, they picture it going as intended. Then they leave out the review that bounces and the dependency that arrives late. They also leave out the bug that eats a day.

After that, the pressure lands on testing. The NASA Software Engineering Handbook, dated 30 September 2025, warns that "Unrealistic timelines force teams to rush development and testing". In its words, the rush raises "the likelihood of missed defects, unverified requirements, or incomplete functionalities". So an optimistic date is not a harmless hope. Instead, it is a quality decision made early, by default.

What are the common project delivery challenges, and which ones move the date?#

The common project delivery challenges are unclear requirements, ineffective communication, unrealistic timelines and expectations, scope creep and resource constraints, and the ones that move the date change the work after it is estimated. The Project Management Institute's Pulse of the Profession 2018 asked 4,455 practitioners to name up to three primary causes of failed projects.

In PMI's 2018 survey, the top three causes all change the work after the plan is set, while an inaccurate task time estimate was named by 25%.

Each one maps to a lever below. First, unclear requirements. In a 2016 survey of 228 companies in 10 countries, Méndez Fernández and colleagues found 109 ranked incomplete or hidden requirements among their five most critical problems. A buffer sized from past releases already holds the requirements those releases missed. Unrealistic timelines and expectations get the same answer, because your own record is hard to argue with.

Second, ineffective communication. In May 2013, PMI reported that "56 percent of dollars spent on projects are at risk due to ineffective communications". The weekly buffer chart below gives everyone one view of the date. Third, scope creep, which PMI's 2018 report says "causes money to be wasted, decreases satisfaction, and delays project benefits". The answer is to trade scope, never testing. Finally, for resource constraints, a work in progress cap keeps stretched people from starting more than they can finish.

How big should a schedule buffer be?#

Size a schedule buffer from how far comparable past work overran, because in the thesis study the work took 1.64 times the estimate and 1.14 times the worst case. That method has a name. Reference class forecasting predicts "by looking at similar past situations and their outcomes". It does not rebuild the task list and hope.

Your own team is the best reference class. First, list your last five to ten releases of a similar size. Second, divide each one's actual time by its planned time. Then take a high ratio from that list, not the average. Because the tail is what hurts, as the 2011 Flyvbjerg and Budzier study shows, the high end is the safe end. The gap between that ratio and 1.0 is your buffer.

There is a limit, though. The Project Management Institute's article on the planning fallacy notes that published uplifts are "highly institution and domain specific". For example, a ratio from bridge building says little about your web platform. Also, a known buffer can invite padding, which the same PMI article calls a perverse incentive. For that reason, the buffer belongs to the whole plan. It sits at the end, where no single task can quietly spend it.

How does limiting work in progress hold a schedule?#

By Little's law, average cycle time equals work in progress divided by throughput, so halving the items in flight halves how long each item takes. John Little proved the law in 1961. It holds for any stable system: work in progress equals throughput times time in the system.

For example, take a team that finishes 2 items a week. With 8 items in progress, each takes 4 weeks on average from start to done. With 4 in progress, each takes 2 weeks. The team ships at the same pace in both cases. However, the second team hears about a problem in 2 weeks, not 4. And an item started late can still land before the date.

In addition, a cap steadies the forecast. With fewer items open, less work sits waiting on reviews and on other people. As a result, the throughput you forecast from stays steady from week to week. In practice, set the cap near the number of people on the critical work. Then start nothing new while the cap is full.

How do you run a buffered schedule week by week?#

Plan tasks at 50% estimates, pool the removed safety into one project buffer at the end of the critical chain, and act only when buffer burn outruns progress. That is the core of critical chain project management, from Eliyahu Goldratt's 1997 book. In that method, the date at the end of the buffer is the one you promise. The chain itself is the longest run of dependent work. It is the critical path with people's time included.

Here is a worked schedule you can copy. Its numbers are an illustrative example, not a measured team. Say a team commits to a release of 20 work items. It finishes 2 items a week, so the chain at 50% estimates is 10 weeks. Since its last releases ran about 1.4 times their plans, the buffer is 4 weeks. So the committed date is week 14, and the team splits the buffer into green, yellow and red thirds.

• Week 6, green. Ten items are done, half the chain. At 2 a week the other ten take 5 more weeks, so the forecast is week 11. One week of buffer is used, a quarter of it, against half the chain finished. Do nothing.
• Week 9, yellow. Thirteen items are done, 65% of the chain. The forecast is week 12.5, so 2.5 weeks of buffer are used, about 63% of it. Pick the items you would drop, and agree on them now.
• Week 10, red. Still thirteen items done, and the forecast is week 13.5. With 3.5 weeks of buffer used, about 88% of it, almost no safety is left. Drop the two lowest-value items, and the forecast returns to week 12.5.

The rule behind this is simple. Compare the share of buffer used with the share of the chain finished. While progress keeps pace with buffer burn, the team need not act, however late one task runs.

How do you keep quality when the date cannot move?#

When the date is fixed, cut scope rather than testing, because a review of 102 papers on time pressure found productivity rises while quality falls. The same 2019 Oulu review found the effect shows up most often during quality assurance. In other words, testing is where a squeezed schedule quietly takes its time back.

To keep quality under time constraints, build three habits. First, write the definition of done before work starts, tests included. Then a test is never an optional extra. Second, rank scope by value at the start, so the item to drop in the red third is already chosen. Third, if test time must shrink, aim it by risk at the parts most likely to fail. The guide to risk-based testing shows where to keep that effort.

1. Write the definition of done first

   Tests included, before work starts, so a test is never an optional extra.

2. Rank scope by value at the start

   The item to drop in the red third is already chosen.

3. Aim test time by risk

   If test time must shrink, keep it on the parts most likely to fail.

Ranking scope early matters because scope tends to grow. In PMI's 2018 Pulse of the Profession, 52% of projects completed in the past 12 months had scope creep, up from 43% five years earlier.

Adding people is the other tempting fix, and it rarely works late in a project. In his 1975 book, Fred Brooks wrote: "Adding manpower to a late software project makes it later." The Brooks's law entry gives two reasons. First, new people need ramp-up time, and they take it from the people doing the work. Second, communication paths multiply with each person added. One exception holds: people added to a clearly bounded task, such as documentation, need far less ramp-up time.

What can project management software catch, and what can it not?#

A timeline view catches broken dependencies, slipped dates and overloaded people, but it cannot catch an optimistic estimate, unrecorded work or quality cut to hit a date. Any tool sees only what is recorded in it. When the data is current, a timeline view shows which task blocks which. It also shows whose week is overbooked and which date has already moved.

Some tools go further and re-forecast from progress. In 2023, Kula and colleagues at TU Delft studied 4,040 epics from 270 teams at ING, a Dutch bank. They showed that delay builds up in patterns over time. Their model, updated as work moved forward, predicted delays more accurately than earlier methods. So a tool can warn you that a date is drifting, and warn you sooner than a gut feel would.

However, three things stay outside any tool. First, it cannot tell you the estimate was optimistic, because it has no reference class unless you give it one. Also, it cannot see work nobody logged, such as a support request that took an afternoon. And it cannot see that tests were skipped to keep a bar green. So ask any tool, whoever makes it, for dependency views, a forecast view and history you can export. The calls on estimates, buffers and scope stay with the team.

The problems teams rank highest sit in that blind spot. In the 2016 NaPiRE survey by Méndez Fernández and colleagues, 109 of 228 companies ranked incomplete or hidden requirements among their five most critical problems, and 93 ranked communication flaws with the customer.

When is a buffered forecast the wrong tool for a timeline?#

A buffered forecast is the wrong tool when no comparable past work exists to size a buffer from, or when scope and date are both fixed by contract or regulation. After all, reference class forecasting needs a reference class. For a first product in a new domain, there are no past ratios to read. So a short product discovery phase is the better first step, because it narrows scope until an estimate means something.

When scope and date are both fixed, a buffer has nothing to spend. Then the honest move is a fixed time box with scope agreed inside it, in writing, before work starts. If even that is refused, say early that the plan does not fit. Saying it at the deadline helps no one plan. And if the open question is how long each phase should take, start with the phase-by-phase timeline guide. Then come back to holding the date.

What should you read next to hold a timeline?#

Read the phase-by-phase timeline guide to set the date, then the team communication and methodology guides to choose where buffers and limits live. The custom software development timeline covers how long each phase usually takes. Next, the guide to cross-functional team communication shows how to decide who talks to whom, so one view of the date reaches everyone. Then software development methodologies compares the methods that host a buffer and a work in progress limit.

If you would rather have a team build to a dated release and keep its tests, the custom software development page describes how that work runs. Still, everything above works on its own. A ratio from your last releases, a cap on work in progress and a buffer you watch weekly are enough to start managing project timelines tomorrow.