On August 28, 2025, Interfax reported a contractor's revised completion timetable for Krasnodar's new airport terminal, alongside equipment difficulties and design changes. Those statements did not disclose the project's task network.
The GAO guide distinguishes delay affecting a successor from delay affecting final completion. Sequential activities share float.
Five activities and one final handover
Consider a fictional project containing five activities, identified only by letters. A takes four days, and B takes six days after A finishes. Separately, C takes three days, followed by D taking five. E takes two days and cannot begin until both B and D are complete. The project is finished when E finishes. These are invented durations, not construction estimates or observations from a named company.
Start the clock at zero. A and C can begin together because they have separate teams and equipment. Every day is a working day in this example. The work cannot be interrupted, all durations are known exactly, and there are no delivery windows, holidays, approvals or externally imposed dates. Each predecessor must finish before its successor begins. The letters do not stand for actual airport engineering packages.
Under these assumptions, A occupies zero to four and B occupies four to ten. C occupies zero to three and D occupies three to eight. E must wait for ten, because D being ready at eight is insufficient while B remains unfinished. E then occupies ten to twelve. The earliest completion in the stipulated case is therefore day twelve, rather than the sum of every activity's duration.
An earlier finish is impossible under these assumptions: A and B require ten successive days, after which E requires two more. The displayed schedule reaches twelve, so that lower bound is attained.
Adding four, six, three, five and two gives twenty activity-days. That sum records the five durations, including work performed simultaneously. It is neither twenty elapsed days nor a count of labour hours: the example does not specify how many people each team contains. The difference between twenty and twelve does not represent saved expenditure. It follows from the allowed overlap between the two branches.
The baseline has three distinct observations
- A followed by B reaches the handover at day ten.
- C followed by D reaches the same handover at day eight.
- E waits for both branches and then finishes at day twelve.
A later handoff need not move the final date
Now make C take four days instead of three, leaving all other durations unchanged. D cannot retain its original start at three: its predecessor is still working. D moves to four through nine. B still finishes at ten, so E can keep its original interval from ten to twelve. The project end is unchanged, but the handoff between C and D has moved by one day.
A report saying only “no delay” would miss that movement. It is correct only if the thing being measured is final completion. Someone expecting D to start at three would see a different result. In this example there is no conflicting booking for D's team, so the later start is possible. We have deliberately not given that team another commitment that would introduce a second scheduling problem.
The arithmetic also distinguishes extending C from postponing E. An extra day in C first moves D; it does not automatically add a day after E. Inserting another day at the end of the project would describe a different schedule from the one created by the stated dependencies. To find the actual change here, we follow the altered finish through D and compare it with B again.
With C taking five days, D occupies five through ten. E still begins at ten and finishes at twelve. The two-day extension has now used the entire difference between the original branch finishes. If C instead takes six days, D finishes at eleven, making E run from eleven to thirteen. The first two extra days leave the end unchanged; the third moves it.
Two separate tests can spend the same interval twice
Return to the baseline before conducting another test. Keep C at three days and make D take seven instead of five. D then occupies three through ten, and E still finishes at twelve. Thus extending C by two days passed one isolated end-date test, and extending D by two passed another. Neither test, conducted separately, changed the project's final completion.
It would be a mistake to grant both extensions together on that evidence. If C takes five days and D takes seven, the second branch now reaches twelve. E must run from twelve to fourteen. The individual proposals each appeared compatible with the original end date only because each was tested while the other activity retained its baseline duration. Combining them changes the premise of both tests.
There were two days between the branch finishing at eight and the other branch finishing at ten. There were not two days reserved for C plus another two reserved for D. Both extensions lengthen the same sequence before the same handover. One day added to C and one added to D do fit: four plus six brings that branch to ten, leaving E at ten through twelve.
This is shared float, not separate allowances. A successor can move while the final date remains unchanged, and separate delay allowances should not be added without checking their common sequence.
The distinction is particularly clear if the requests arrive one after another. Approve an extension of C from three to four, and D's unchanged five days now end at nine. There is one day left before the other branch finishes. A later request to extend D by two cannot rely on its earlier isolated two-day result: that result described a schedule which no longer exists.
No uncertainty is necessary for this disagreement to occur. Every proposed duration is exact. The error comes from evaluating the second request against an outdated combination, not from a forecast turning out badly. Nor does naming one activity more important change the calculation. In the stipulated network, both additions reach E through the same C-to-D branch, regardless of who requested them.
Removing three days of work can save only two elapsed days
Return to the baseline again, and now shorten B from six days to three. A still finishes at four, so B runs from four to seven. C and D retain their original combined eight days. E consequently starts at eight and finishes at ten. Three days have been removed from B's duration, but final completion advances by only two, from twelve to ten.
The missing third day has not been lost in arithmetic. B is ready at seven, yet E still needs D, which is ready at eight. The revised schedule contains a one-day interval in which the first branch is complete and the second is not. Starting E at seven would violate a dependency we explicitly retained. It would not be a faster version of the same five-activity plan.
We can see the change one step at a time. Reducing B from six to five brings its branch to nine and final completion to eleven. Reducing B to four brings its branch to eight and completion to ten. Reducing B to three brings its branch to seven but leaves completion at ten. The same one-day local reduction has different consequences at successive stages of this exact example.
This sequence is not a statement about the price or practicality of accelerating B. The model has granted each changed duration without specifying an engineering method. It calculates the consequence if that duration becomes possible while everything else remains fixed. There is no assumed overtime rate, labour saving or benefit per day, so the calculation cannot rank the proposals by financial return.
At a tie, one improvement is no longer enough
Take the intermediate case where B lasts four days. A plus B totals eight, exactly matching C plus D. E occupies eight through ten. Shortening B by one day alone leaves D at eight. Shortening D by one day alone instead leaves B at eight. In either isolated change, the project still finishes at ten, although one of the predecessor branches now finishes sooner.
Shorten both B and D by one day in that tied case, and the result differs. A plus B becomes seven, and C plus D also becomes seven. E can then occupy seven through nine. Each change alone produced no earlier project finish; together they advance it by a day. Adding the two isolated end-date effects would incorrectly predict no change at all.
This is the opposite accounting mistake to adding the isolated delay allowances. Previously, separate tests appeared to offer more room than existed jointly. Here, separate acceleration tests appear to offer less improvement than becomes possible jointly. Both errors arise from keeping the other branch fixed in each test and then treating the isolated results as if that condition still held when changes were combined.
The comparison also explains why we must state the starting schedule every time. A one-day reduction in B from six to five advances the baseline finish. A one-day reduction from four to three does not advance the tied schedule's finish. The activity has the same letter and the reduction has the same length, but the competing branch reaches the handover at a different relative moment.
One downstream change has a different reach
E sits after the two branches have already joined. If E could take one day instead of two, the baseline would finish at eleven rather than twelve. The tied case would finish at nine rather than ten. The case with B shortened to three would likewise finish at nine rather than ten. In each of these specified comparisons, reducing E by one advances the final finish by one.
The reason is visible in the timelines rather than in a ranking of teams. E is the final activity in every one of those variants, and no other completion remains to be awaited after it. This does not prove that reducing E is cheaper, safer or technically possible. It gives E a different position in the arithmetic, not a recommendation to accelerate a particular real-world commissioning task.
Nor can the same reduction be counted twice merely because E has two predecessors. In the baseline, E runs once from ten to twelve, not separately after B and again after D. Shortening that single final activity by one day changes one finish. The existence of two incoming requirements does not turn the change into two days of project acceleration.
Keep the dependency statement intact when comparing plans
Suppose someone proposes starting E at eight in the original baseline because D is ready then. E would finish at ten, apparently matching the improved schedule reached by shortening B. But B is still running until ten in this new proposal. The apparent gain depends on dropping E's requirement to await B. It therefore changes the dependency structure rather than the duration of an activity.
Those are different proposals, even though both display the number ten at the end. The duration-change case preserves the requirement and completes B at seven. The early-start case retains B's six-day duration and begins E before B finishes. A comparison that records only the final date would hide which premise changed. The distinction matters before anyone asks whether either proposal is feasible outside the example.
A resource change would also require a new calculation. Our A-to-B and C-to-D branches can overlap because their teams and equipment are separate. If B and D instead needed the same indivisible resource, the two baseline intervals would conflict. We could not keep the original schedule merely by retaining its arrows. The original calculation answers the explicitly parallel case, not every interpretation of the same five letters.
The useful result is a set of traceable changes
The constructed project gives several precise comparisons. Two separate two-day extensions can overrun one shared two-day interval. Removing three days from B can remove only two days from final completion. At a tie, shortening either predecessor alone changes no final date, while shortening both does. Reducing the single final activity has a different reach from reducing one branch before the handover.
Each result follows from a named starting schedule and a stated change. None requires an estimate of the airport's remaining construction time or a claim about the causes of its revised timetable. The value of the exercise is that proposed changes can be traced through the complete invented schedule, rather than treating every day saved or delayed inside one activity as an interchangeable day at the end.