Chapter 17: Design Schedules and Manage Flow

The question that has two answers

It is month nineteen at BlueLine, and the schedule review has turned into an argument about what the word “on time” means. The corridor’s target opening is month twenty-four, the mayor’s promise to the council, and the completion obligation Lena Voss accepted at the second-half authorization is month twenty-five. The civils manager has the network diagram on the table, a drawing of the eastern flood-plain segment with its chain of physical dependencies: the drainage approval, the culvert works, the deck pours, then the systems, then the ticketing. The approval landed last week, finally, with conditions, and the conditions add ten weeks of culvert and flood-mitigation works to the longest chain in the corridor. The civils manager does the arithmetic aloud, from the network, not from a feeling: approval to culverts, culverts to pours, pours to systems, systems to ticketing, the eastern segment cannot be open before month twenty-seven, and the corridor cannot be open before the eastern segment is.

Across town in a different project, the same question is being asked of a different instrument. It is month twenty-one at KijaniPay, and the delivery standup has the flow board up: fourteen items in progress, three of them at or past thirty days, twenty-eight items in the ready column, and a completion count for the week of six against a four-week run of nine, eight, five, and six. The settlement pilot closes on 15 October, four weeks away. The board shows a team that is clearly working: twelve engineers, high utilization, requests moving from left to right. Zanele Dlamini, the delivery lead, knows what the board is really showing, and it is not progress. It is a queue that is growing because the system is full. Kwame Mensah, head of risk, asks the question the standup is circling: “When will the pilot actually be ready?” Zanele answers from the flow data, not from the calendar: “The median puts us right at the pilot close. The honest range is a few days early to ten days late. The calendar is not the problem. The queue is.”

Two projects, one question, two answers, two instruments. The corridor’s schedule is a network, a map of what must happen before what. The platform’s schedule is a flow system, a map of how much work is in the system and how fast it moves. Both are called schedules, and both answer “when will it be done,” and they are different models of time that fail in different ways. Chapter 15 gave the work honest numbers, and chapter 16 built the plan that holds the commitments together. This chapter builds the schedule itself, and its whole argument is one sentence: a schedule is a model of time, and the project that does not know which model it is using is forecasting with the wrong instrument. The network is the right model when the sequence is the truth, when the work must happen in an order that physics, regulation, or acceptance will enforce. The flow system is the right model when the work is a queue, when many small items compete for capacity and the question is not what must happen first but how much is half-done and how long done takes. Most scheduling failures are not failures of arithmetic. They are failures of model choice, a network drawn for work that was really a queue, a board run for work that was really a chain, and the dates that follow, confident and wrong.

Two models of time

The two models have different histories, and the difference is a clue to what each one is for. The critical-path method emerged at DuPont in the late 1950s, published by James E. Kelley Jr. and Morgan R. Walker in 1959, to schedule chemical-plant construction and maintenance turnarounds, where the sequence of physical work was knowable and consequential: you cannot pressure-test a vessel before the welds are done, and you cannot weld before the steel arrives. PERT, the Program Evaluation and Review Technique, was created the year before for the U.S. Navy’s Polaris missile program, with Booz Allen Hamilton, to coordinate thousands of contractors whose activity durations nobody had yet measured. Where CPM assumed durations and computed the schedule, PERT admitted that the durations themselves were uncertain and worked with ranges. Both treated time as a logic problem: activities arranged in a chain of causes, with a longest path that decided the end date. That model is a dependency network, and it answers one question precisely: given this sequence and these durations, when does the last activity finish, and which activities, if they slip, move that date?

The second model came from a different tradition. In 1909 and 1917, the Danish engineer A. K. Erlang, working at the Copenhagen Telephone Company, published the analyses of telephone traffic that gave queueing theory its founding results: calls arrive, wait for a free operator, and the waiting time depends on how full the system is. The mathematics grew through manufacturing, through production lines and inventory, into software and product work, where John Little proved in 1961 the law that now carries his name, tying the number of items in a system to how fast they enter and how long they stay. That model is a flow system, and it answers a different question: given the work in progress, the arrival rate, and the observed cycle time, when will the backlog clear, and what happens to the system when it fills up? A dependency network has no queue; it has an order. A flow system has no critical path; it has a utilization. A project that needs both answers, and most do, needs both models, and the discipline of this chapter is knowing which question the schedule must answer at any given moment.

The test of which model belongs is the decision it improves. The network answers “what must be true before what, and where is the longest chain that decides the date”: use it when the sequence is stable and consequential, when the evidence of completion is physical or regulatory, when the cost of getting the order wrong is rework or a missed acceptance gate. The BlueLine corridor is the textbook case: the fare gates cannot be installed before the station shell is closed, and the shell cannot be closed before the civils are done; the sequence is physics and contract. The flow system answers “how much work is in the system, and how fast does it actually move”: use it when the items are many and small, the demand is variable, the sequence is flexible, and the constraint is capacity. KijaniPay is the case in the other direction: the question is not which item precedes which but how many half-done items are clogging the stream so that nothing finishes. The common error is choosing by habit instead of by the work: the network drawn for work that is really a queue is a schedule of wishful sequencing, the backlog laid out in dependency rows that add up to a date; the board run for work that is really a chain is a queue with a fake order, the eastern segment laid out as columns when the culverts cannot start until the approval conditions are designed. The primary picture of this chapter is the same stream of work seen through both models, because mastery is not choosing one and discarding the other; it is seeing both at once and knowing which one the decision needs.

Figure 17.1: The settlement stream at KijaniPay, two lenses. The
network above answers "what must be true first": a chain of
dependencies whose longest thread decides the pilot date. The flow
system below answers "how much is in the system and how fast does done
happen": a board with a backlog, a work-in-progress column that is
over its limit, and aging items that the network view cannot see. The
same work, two models of time; they agree about the constraint when
read together, and disagree about everything when one is forced to
answer the other's question.

  NETWORK
  contract signed --> sandbox provisioned --> settlement integration
      --> end-to-end rehearsal --> pilot close (15 October)
      --> license filing and decision --> launch (30 November)
      *  the long chain: sandbox --> integration --> rehearsal,
         marked * on the diagram, decides the pilot date

  FLOW
  READY          IN PROGRESS            DONE
  28 items       14 items (limit 8)     6 this week
                 aging: integration item 41 days
                 exception-handling item 33 days
                 onboarding-data item 30 days

The schedule as a logic model

The network is built from a small number of facts, and the discipline of building it is keeping them apart, because each one has a different owner and a different evidence standard.

An activity is a piece of work with a defined output, the thing that must be done: the culvert works, the fare-gate install, the end-to-end rehearsal. A duration is the calendar time the activity takes from start to finish, measured in working time on the project’s calendar: the culvert works take six weeks. An effort is the person-time the work consumes, measured in hours or person-weeks: the culvert works take twelve person-weeks. The two are not the same number, and the schedule is built on durations, not efforts, because the calendar cares about when things finish and the resource plan of chapter 19 cares about how much capacity the work consumes. The confusion of the two is where schedules first lie. An estimate of effort, eight person-weeks, quietly becomes a duration of eight weeks, as if one person and one calendar were the same thing, and the schedule then assumes a level of staffing the resource plan never approved. The check is a simple question for every activity: how long does it take from start to finish on the calendar, how many person-hours does it consume, and which number did this schedule use?

The calendar is a separate fact, and it is usually missing from the first draft. A calendar is the set of working days the schedule counts: the wet season on the flood plain, the night-works restrictions in the central segment, the regulator’s review windows, the shared leave weeks in December. The same activity has different durations on different calendars, and the schedule that ignores the calendar is the schedule that discovers in December that the month it planned was not a working month. The eastern segment is a pure calendar problem: the approval conditions require the culvert works to be completed outside the wet season, and the wet season runs from November to March, so a ten-week culvert package that starts in October finishes in May, not in December. The duration is ten working weeks, and the elapsed time is six months, and the schedule that reports the shorter number is not optimistic, it is wrong.

The constraints are the fences around the work: the window when the drainage authority receives applications, the license decision queue the regulator publishes, the season when the access-standard federation can survey stations, the permit that expires, the grant that ends. Constraints behave like activities with fixed dates and no float, and they belong on the network as nodes, not as notes in the margin, because a constraint that is not on the network cannot delay anything. The KijaniPay license filing is a constraint in exactly this sense: the filing must name the settlement provider, the provider must be signed, and the regulator’s published processing time is eight weeks, so the filing date on the network is not a wish, it is the consequence of a chain that ends in the regulator’s queue.

The dependency logic is the glue, and it has four forms, though most projects live on one. Finish-to-start is the default and the overwhelming majority: the successor cannot start until the predecessor finishes, the culverts cannot start until the design is approved. Start-to-start means the successor can start when the predecessor starts, with the lead expressed in the offset: the systems installation can start two weeks after the deck pours begin, not after they end, because the first pours free the first bay. Finish-to-finish means the successor cannot finish until the predecessor finishes: the commissioning cannot finish until the ticketing integration finishes, regardless of when it started. The fourth form, start-to-finish, is rare and usually a sign that the model has been contorted to fit a date; it exists, and its rarity is the point. The lag is the waiting time written into the logic: concrete must cure before the next load, twenty-eight days of cure for the deck pours to full strength, and the cure is a lag, not an activity, because no one works on it. The lead is the overlap allowed by the logic: the fit-out can start two weeks before the shell is fully complete, because the finished floors follow the poured ones. Leads and lags are where the schedule expresses physical truth, and also where it is silently compressed. A lead is set to the number the date needs instead of the number the work requires, and the concrete is “allowed” to cure in eight days because the calendar says so.

The longest chain

The network’s payoff is the critical path, and it is worth working the arithmetic once by hand, because the pattern is the whole discipline and the vocabulary is the whole conversation. Take the station-four chain at BlueLine, the central-segment station where the chapter 14 seams all land. Six activities govern its opening: the civils shell, six weeks; the fit-out and finishes, four weeks, after the shell; the fare-gate and ticketing hardware, five weeks, after the shell; the ticketing software integration, ten weeks, after the hardware, using the expected value from chapter 15’s arithmetic, which rounded 9.7 weeks to ten for this pass; the access-standard modifications co-authored with Grace Njoroge’s federation, three weeks, after the fit-out; and the systems commissioning and acceptance, two weeks, after both the integration and the access-standard work finish.

The forward pass walks the chain from the start: each activity’s earliest start is the latest of its predecessors’ earliest finishes, its earliest finish is its earliest start plus its duration, and the project’s earliest finish is the last activity’s earliest finish. The backward pass then walks back from the finish: each activity’s latest finish is the earliest of its successors’ latest starts, its latest start is its latest finish minus its duration, and the float is the latest start minus the earliest start.

The forward pass is the left half of the table. The civils shell starts at week 0 and finishes at week 6. The fit-out and the ticketing hardware both start at week 6, because both depend only on the shell; the fit-out finishes at week 10, the hardware at week 11. The ticketing integration starts at week 11, after the hardware, and finishes at week 21. The access-standard modifications start at week 10, after the fit-out, and finish at week 13. The commissioning starts when both the integration and the access-standard work are done, which is the later of week 21 and week 13, so week 21, and finishes at week 23. The project’s earliest finish, for this station’s chain, is week 23.

The backward pass walks back from the finish. The commissioning must finish by week 23 and so starts by week 21. The ticketing integration must finish by week 21 and so starts by week 11. The hardware must finish by week 11 and so starts by week 6. The access-standard work must finish by week 21, the commissioning’s start, and so must start by week 18. The fit-out must finish by week 18, the access-standard work’s start, and so must start by week 14. The shell must finish by the earlier of the fit-out’s start, week 14, and the hardware’s start, week 6, so by week 6, and so must start at week 0. The float is the difference between the latest start and the earliest start, or equivalently between the latest finish and the earliest finish: the shell, the hardware, the integration, and the commissioning have zero, and the fit-out and the access-standard work have eight weeks each. The activities with zero float form the critical path, and its length, 23 weeks, is the station’s earliest credible opening. It is the longest chain, not the sum of everything: the total work in the six activities is 30 weeks, and the chain that matters is 23, because the fit-out and the access-standard work run in parallel with the integration, and their eight weeks of float are the reason the project is not the sum of its parts.

Three interpretations make the pass worth doing at all, and each one is a decision, not a definition.

First, the critical path is a fact about the plan, not a fact about the world. It says, given the logic and the durations as written, this chain decides the date. It does not say the chain is correct, and it does not say the durations are true; it says the chain is where the plan is exposed. The most valuable question the pass produces is not “what is the critical path” but “what would have to change for this chain to be wrong,” and the answer is the assumptions log of chapter 15 applied to time: the integration duration of ten weeks, the approval conditions, the access-standard scope. When the world disagrees with the critical path, the plan changes, and that is the plan working.

Second, float is project property, not a personal allowance. The eight weeks of float on the fit-out and access-standard chains belong to the project’s ability to absorb delay; they are not eight weeks of permission to start late or to spend. The owner of an activity with float is its steward, not its beneficiary, and the discipline is the question the look-ahead asks: “What are you doing with your float?” The answer “we are holding it” is the schedule hiding a private buffer; the answer “we are using it to protect the chain” is the schedule doing its job. Float spent early is gone when the chain slips into it.

Third, the near-critical path is where schedule risk hides. The critical path is the longest chain as written, and the risk is the chain that is nearly as long, because a small slip on a near-critical activity turns it into the critical path. The access-standard chain is the warning at BlueLine: at three weeks it has eight weeks of float, and at the pessimistic case from chapter 15’s estimate, where the final scope of the access standard is not signed and the work runs to ten weeks, the chain becomes six plus four plus ten plus two, twenty-two weeks, one week short of critical. One scope decision, the unsigned access standard, moves a chain from eight weeks of float to the edge of the critical path, and the schedule that reports only the critical path is the schedule that will be surprised by the access standard. The near-critical chains are reviewed at the same cadence as the critical path and owned the same way, because the distinction between critical and near-critical is a snapshot, and the snapshot changes weekly.

Time is not the same as people

The network says when the sequence can finish. The resource plan says who is available to do it, and the two statements rarely agree, because duration and effort are different facts and the schedule’s arithmetic has a third dimension that the longest chain ignores: people cannot be in two activities at once, and the same person cannot be two people.

The resource-constrained schedule is the honest version: when two critical activities need the same scarce specialist, they cannot run in parallel, however the logic allows it, and the constrained chain is longer than the logic chain. This is where the KijaniPay resource plan from chapter 16 becomes a schedule fact: the schedule assumes fourteen engineers from October, the resource plan lists twelve, and the two QA specialists are allocated full-time to the pilot closure and full-time to the fraud volume test in the same two weeks. The network does not see the double-booking, because the network has no people in it. A schedule built from the network alone plans two full-time QA allocations in one calendar; a schedule built from the resources first shows the pilot closure slipping a week before anyone asks why. The check is the leveling discipline: resource leveling moves activities within their float to fit the available capacity, and resource smoothing shifts work without moving the critical path. They are different instruments, not rivals: leveling changes the end date, and smoothing protects it.

The second fact about people is the one Frederick Brooks named in The Mythical Man-Month (Addison-Wesley, 1975; anniversary edition 1995), and it is the oldest and most violated rule in scheduling: effort and duration do not scale together, because people are not interchangeable and because adding people to a late project makes it later. The arithmetic looks seductive: the integration is ten weeks with one team, so twenty people can do it in five. The reality is that new people must be onboarded, and onboarding consumes the existing team’s time; that work must be partitioned, and partitioning creates interfaces; and the number of communication paths grows much faster than the number of people, so the coordination cost rises with every addition. Brooks’s law is stated for software, and it transfers to every kind of knowledge work and to most physical work that has a sequential spine: the deck pours cannot be compressed by more gangs beyond the space available on the pour front, and the integration cannot be compressed by more engineers beyond the rate at which the partner’s sandbox produces evidence. The man-month is a myth because a month of calendar is not a month of person, and a person added late is not a person, it is a tax on the people already there.

The third fact is the cost of switching. Multitasking is the resource plan’s quiet lie: a person split across three streams contributes a fraction to each, and the fractions do not add to one person, because every switch carries a setup cost, every half-finished item carries context that must be reloaded, and every reload is time no schedule ever booked. The KijaniPay board is the visible proof: the completion count has drifted down, nine, eight, five, and six, not because the team is working less but because the growth team’s urgent requests keep pulling people off the pilot items, and each pull leaves a half-done item in progress. Capacity and throughput are different things, and utilization is not either of them.

When the date no longer fits, the schedule offers four moves, and the craft is choosing among them with the network and the resources in the room. Add people, which the man-month myth says to do only where the work actually partitions and where the onboarding cost is paid from float, not from the critical path. Reduce scope, which is the most underused move and the one that always exists, because the schedule is a model of the plan and the plan is a choice, and the choice can change. Resequence the work, which is the network’s own move, changing the logic or the leads where the work genuinely permits, the fast-track that overlaps the integration with the civils instead of waiting for the whole segment. Or accept a later date, which is not a failure but a forecast, the re-baseline decision that chapter 16 built, made under governance with the evidence on the table. The four moves are the entire menu of schedule recovery, and the mastery drill at the end of this chapter is a choice among them under pressure: which of the four moves, in what combination, and at what cost to the other dimensions of success from chapter 2.

Buffers and compression

The schedule’s tolerance for being wrong is designed, not discovered, and the design has two instruments, buffers and compression, and the discipline is knowing which one is being used when.

A buffer is time placed deliberately to absorb variation, and its placement is a judgment about where the variation will come from. The standard advice from the buffer-management tradition, built by Eliyahu Goldratt in Critical Chain (North River Press, 1997), is to place the buffer where it protects the whole: a project buffer at the end of the longest chain, sized to absorb the chain’s uncertainty, and feeding buffers where other chains join it, sized to keep the joining chains from stealing the longest chain’s float. The idea transfers without its jargon: the schedule protects its one date by concentrating the uncertainty in named pockets instead of hiding it in every activity. The failure the tradition diagnoses is the opposite pattern: every activity padded by 20 percent, a schedule that looks comfortable and is, in fact, a lie, because the padding is spent, a padded estimate signals slack to its owner, and the total padding is never enough, since the padded activities are the ones nobody checks. The chapter 15 vocabulary applies whole: a buffer is explicit contingency on the calendar, owned, triggered by evidence, released by decision, exactly like the money pockets, and a hidden pad is the same corruption in time that a hidden contingency is in money.

Compression is the attempt to make the chain shorter, and it has two honest forms and a theater. Crashing adds resources to critical activities, more gangs on the pours, a second integration team, and it works only where the work partitions and the resources exist, and it costs money, so crashing is a cost decision made against the budget of chapter 18, not a scheduling trick. Fast tracking overlaps activities that were sequential, starting the ticketing integration before the whole eastern segment is poured, and it works only where the overlap is real, where the interface is known and the rework risk is priced, because the overlap buys time by borrowing it from certainty: the integration that starts early against an unfinished design is the integration that may be redone. The theater is the fake compression: the weekend overtime, the holiday cancelled, the “working harder” directive, presented as a schedule move when it is actually a draw on the team’s recovery and a guarantee of the defect spike that chapter 21 will teach. Overtime has a real yield for a few weeks and a negative yield after, and the schedule that books permanent overtime as a compression strategy is not compressed, it is broken, and it is hiding the break from the four moves that would fix it. The honest question for any compression proposal is the one the network answers: does this shorten the critical path, or does it shorten everything except the critical path? A plan that accelerates ten non-critical activities and leaves the chain untouched has spent money and morale to produce the same date, and the network is the only instrument that can prove it.

The work as a queue

The flow view starts where the network view ends: the network assumes the order is the truth and asks when the last activity finishes; the flow view assumes the capacity is the constraint and asks how the system behaves when the work exceeds it. The vocabulary is small and precise, and it is worth naming each term because the words are routinely used as if they were interchangeable when they are four different measurements.

Work in progress, WIP, is the number of items started and not finished: the fourteen items on the KijaniPay board, the three at or past thirty days. Cycle time is the calendar time an item takes from the moment work on it starts to the moment it is done: the settlement integration item, once started, has been in progress for forty-one days, so its cycle time, so far, is forty-one days and counting. Throughput is the rate of completion, items per week: six this week, five last, eight the week before. Aging work is the distribution of cycle times among the items in progress: three items at or past thirty days, one older than forty, and the age of the oldest item is the board’s most honest number, because it is the one no one can spin. The four measurements answer four questions: how full is the system, how long does done take, how fast does done happen, and which items have been waiting longest. A project that measures only utilization, how busy the people are, is measuring the one number that says the least, because utilization measures the input to the system, and the system’s output is completion, and the two are connected in a way that is almost always misunderstood.

The connection is Little’s Law, and it deserves its arithmetic here, with its assumptions spoken aloud, because it is the most useful and most abused number in flow work. John Little proved in 1961, for a stable queueing system, that the average number of items in the system equals the average arrival rate times the average time an item spends in the system: L = λW. In project vocabulary, average work in progress equals average throughput times average cycle time, or equivalently, throughput equals WIP divided by cycle time. The KijaniPay numbers work it out: the average WIP is twelve items, the average cycle time of completed items is about nine working days, so the throughput is twelve divided by nine, about 1.3 items per day, about 6.7 items per five-day week, and the observed completions, averaging about seven, agree. The law reconciles the board: twelve items in progress, nine days to complete each, seven finished a week, and no one is lying. The law is an identity among averages in a system in steady state, and its assumptions are the ones every forecast must state: the system is not emptying or filling forever, items are counted the same way at entry and exit, and the numbers are averages over a period, not snapshots. The law does not predict which item finishes when; it predicts what the system can sustain. That is the whole point: it turns three measured facts into a fourth fact that was not measured, and it makes the trade-offs visible that the calendar was hiding.

The trade-off that matters most is the utilization trap, and it is the flow view’s critical-path lesson. In a queueing system, as utilization approaches capacity, waiting time grows without bound: the system that is 50 percent busy has short queues, the system at 90 percent has long ones, and the system at 98 percent has queues that lengthen at every arrival, because any variability, a person out, a request that takes twice as long, a partner’s delay, has nowhere to be absorbed when every resource is already working. The team at 92 percent utilization is not a team that is nearly done; it is a team that has almost no slack, and a system with no slack and real variability is a system that builds queues. The KijaniPay board is the trap in action: the engineers are busy, utilization is high, and the completion count is falling, because the team is spending its time switching among fourteen items instead of finishing them. The counterintuitive consequence, which the law makes visible, is that the way to raise throughput is usually to lower WIP: cap the number of items in progress, force the team to finish before it starts, and cycle time falls, and the completion count rises, not because the people worked harder but because the system stopped wasting their work on half-done items. The law does not promise the cap will raise throughput; it promises that the cap makes the mechanism visible, and the mechanism, less switching and faster completion, is what the team verifies empirically, from its own data.

Aging work is the report that makes the queue visible as individual people and promises, and it is the minimum viable instrument of the flow view. The report lists the items in progress, ordered by age, with the oldest at the top, and it is reviewed at every standup, because the oldest item is the project’s most likely failure in progress: it has consumed the most attention, it is usually the most important thing someone avoided, and it is the item whose owners have, without deciding to, stopped talking about it. The three items at or past thirty days include the settlement integration item at forty-one days, and the board shows why aging work is a leading indicator, not a lagging one: the integration item is blocked on the partner’s sandbox, and a blocked item left in progress is not a delay, it is a decision deferred, because it consumes the team’s attention, skews the cycle-time data, and hides in plain sight while the network view reports a chain that cannot start. The aging-work discipline is the pair of the milestone dictionary from chapter 16: the dictionary names what becomes true and how we will know, and the aging report names what is taking too long and who owns the decision to pull it out, finish it, or abandon it. A blocked item is pulled out of the progress column, moved to a named waiting state with its own owner and its own review date, because a queue measures active work, and blocked work is not active, it is a risk wearing a work item’s coat.

Forecasting from evidence

The flow view’s forecast is built from the measured past, and the method is the throughput-based forecasting that chapter 15 introduced and this chapter operationalizes. The numbers at KijaniPay are small enough to work by hand. The last eight weeks of completions, oldest to newest, are seven, six, eight, seven, nine, eight, five, and six; sorted, they are five, six, six, seven, seven, eight, eight, nine. The median, the 50th percentile, is seven items per week. The 85th percentile, interpolating between the seventh and eighth values, is about eight and a half. The backlog to the pilot close is twenty-eight items, and the pilot closes in four weeks: at the median throughput, twenty-eight divided by seven, the backlog clears in four weeks, exactly the pilot date; at the 85th percentile, twenty-eight divided by eight and a half, about 3.3 weeks, inside; at the worst recent week, the five-item week, twenty-eight divided by five, 5.6 weeks, ten days late. The honest forecast is the range, not the point. The pilot lands on time if the system holds its median, and it slips by ten days if the system has another bad week. The difference between the two is the queue discipline the standup controls: the five-item week was the week the urgent requests arrived and the WIP rose.

Three disciplines make the forecast honest, and each one is a small decision. First, the forecast is revised from the data on a fixed cadence, the weekly look-ahead from chapter 16, and it is never “revised” to comfort a stakeholder; the forecast is the current evidence-based expectation, in the vocabulary of chapter 15, and its history is the learning record. Second, the percentile is chosen deliberately. The 50th says “the middle of the distribution”; the 85th says “I want to be wrong only one time in seven.” The choice belongs to the decision: a private pilot can live with the median, a public launch with the 85th, a regulatory deadline with the tail. The discipline is reporting the range with the percentile named, so “on time” and “ten days late” are both on the table before anyone chooses. Third, the aging items are worked before the backlog, because the distribution of cycle times is the forecast’s accuracy: if the oldest items are the ones with the longest tails, the median is optimistic about them, and the forecast that ignores aging work is the forecast the aging report will defeat.

The reconciliation of the two models is where the chapter’s two lenses finally meet, and it is the moment the work becomes a decision instead of an argument. The network view at KijaniPay says the settlement stream’s chain is contract, sandbox, integration, rehearsal, and the chain decides the pilot date. The flow view says the integration item is forty-one days old and blocked, the WIP is over its limit, and the system is completing six items a week against a backlog of twenty-eight. The two views disagree about almost everything, and they agree about the one thing that matters: the integration, and the partner dependency underneath it, is the constraint, the network sees it as the chain, the board sees it as the oldest item, and the schedule that reads either view alone will act on half the evidence. The reconciliation is not a compromise between the two numbers; it is the recognition that they are the same constraint measured by two instruments, and the decision that follows, resolve the sandbox, protect the integration team, pull the blocked item out of the queue, is the decision neither view could make alone. The projects that manage time well are not the ones with the best schedules; they are the ones whose schedules and boards point at the same constraint, because the two models are not rivals, they are two eyes, and the depth comes from the difference between them.

Choosing the lens

The choice between the models is a delivery design decision, made in the vocabulary of chapter 13, and the three delivery families use them differently.

The predictive project runs on the network, because its sequence is the truth: BlueLine’s civils, systems, and ticketing must happen in an order that physics and acceptance enforce, the evidence is physical and regulatory, and the changes are expensive. Its schedule is a network with a critical path, float, gates, and a baseline, and its rhythm is the stage plan, the near-term wave detailed and the far term a direction, the rolling wave from chapter 16. The discipline is keeping the logic honest: dependencies with owners, durations from the estimate, float as project property, and progress measured by evidence, the rule of evidence that chapter 31 builds.

The adaptive project runs on the flow system, because its truth is capacity and demand: the KijaniPay backlog is many small items, the sequence is flexible, and the constraint is how much the system can finish, not which item precedes which. Its schedule is a board with explicit policies, a WIP limit, a definition of done, and an empirical forecast from throughput, and its rhythm is the iteration and the standup. The discipline is the WIP cap, the aging report, and the definition of done that never moves, because the definition of done is the flow system’s baseline, and a baseline that moves to fit the date is a forecast that lies to itself.

The hybrid project runs both, and its craft is the seam. The Meridian clinics are the standing case: the construction runs on a network, the clinic shell, the fit-out, the certificate, because the building’s sequence is physical truth, and the platform rollout runs on a flow system, the workflow slices, the training waves, because the clinicians’ feedback is the constraint. The seam is where the two must speak: the network’s milestone, “clinic two certificate by month twenty-two,” becomes the flow system’s service target, “the onboarding wave for clinic two must complete by the certificate date,” and the flow system’s forecast becomes the network’s evidence for the training gate. The failure is the hybrid that never translates: the network’s dates reported in one room, the board’s forecast in another, and nobody owning the translation between them. The BlueLine corridor is itself a hybrid waiting to be designed: the civils run on a network, and the depot’s turnaround flow, the ticketing integration queue, the exception handling at opening, are flow problems that will eat the network’s date if they are scheduled as if they were chains.

The re-decision discipline from chapter 13 applies to the lens itself: the model is a hypothesis with a review date, and the evidence that should trigger re-examination is the model’s own failure mode. When the network’s near-critical chains start moving faster than the critical path, when float stops meaning anything because the sequence is no longer the truth, the project is telling the room that it is really a flow problem wearing a network’s clothes. When the flow board’s items start arriving in a strict order, when the WIP limit stops helping because the work no longer parallelizes, the project is really a chain wearing a board’s clothes. The model is re-decided, not defended, and the schedule review that asks “are we still using the right model of time” is a schedule review doing its job.

Four ways the schedule lies

The failure patterns deserve to be named as characters, because each one is produced by competent people doing what the room rewarded, and each one has a signal that reveals it.

The calendar contractor builds the schedule from dates instead of from work: every row has a date, no row has a dependency, and the schedule’s authority comes from the calendar that printed it. It is the KijaniPay roadmap from chapter 16 restated at activity level, the plan that hid the Savanna contract because the dates were arranged first and the work arranged around them. The tell is the question the room cannot answer, “What happens if this activity finishes a week late?” There is no logic to propagate the delay, and the schedule evaporates at the first slip, because it was never a model, only a hope with a header row.

The float hoarder is the owner who treats float as personal property: the activity starts late, the buffer is spent early, the private reserve is hidden in the duration, and the chain is defended until the float is gone. It is the schedule version of the hidden contingency from chapter 15, the padding that signals slack to its owner and is spent on comfort instead of absorbed on the chain. The tell is the look-ahead question “What are you doing with your float?” answered as if the float were already spent. The cost is the chain that slips into the spent float, and the gate where the buffer is gone.

The utilization idolater runs the schedule by busyness: utilization high, WIP high, completion flat, and the board celebrated as proof of effort. It is the team at 92 percent busy with a growing backlog, the sixteen-hour days presented as commitment, the utilization number reported where the throughput number belongs. The tell is the standup that reports work started and never work finished, and the aging report nobody looks at. The cost is the queue, because the idolater has confused the input to the system with its output.

The stage manager reports progress without evidence: “the integration is 90 percent complete,” held at 90 percent for six weeks, because the number was set to look good and nobody defined what 90 percent means. It is the percent-complete theater that chapter 38 will measure and this chapter pre-empts: percent complete is only as real as its measurement rule, and the rule is evidence, a tested interface, an accepted handover, a checked milestone, never a feeling and never a percentage that moves by faith. The tell is the completion report that improves without any artifact changing hands; the cost is a forecast that is a performance.

The four characters share a root, and it is the chapter’s thesis restated: each one replaced a model of time with a performance of it, the calendar contractor the date, the float hoarder the buffer, the utilization idolater the effort, the stage manager the progress. The controls that keep each one honest are the chapter’s instruments used as designed: the dependency logic with owners, the float as project property reviewed in the look-ahead, the WIP limit and the aging report, and the evidence rule from chapter 16’s milestone dictionary, that nothing is complete until it is checked and nobody reports a percentage without a measurement rule. The schedule that serves decisions needs none of the performances, and it needs all of the substance.

The arithmetic the machine may do

The assistant has a genuine and bounded place in scheduling, and its boundary is the same as the book’s standing boundary. It can compute the forward and backward passes from a provided logic file, checking the arithmetic of the critical path and the float and flagging what does not reconcile. It can draft what-if scenarios from the four moves, “add one engineer here, remove this scope item, overlap these two activities,” each computed against the provided durations and logic, labeled as a draft. It can read the board data and produce the aging-work report, the cycle-time percentiles, and the throughput forecast with its assumptions stated, and it can cross-check the flow forecast against the network’s dates and flag the reconciliation gap, the constraint the two views should agree on. The source data is the approved, non-confidential schedule and board content, redacted before prompting; the outputs are drafts until a named owner verifies them; and the audit record says what was generated, from what, checked by whom, and decided by whom.

Four boundaries matter, because scheduling is where the machine’s confidence is most seductive. First, the dependency logic is human: the machine’s critical path is exactly as real as the logic it was given, and the corridor conversations, the partner’s silence, the approval conditions nobody wrote down, are not in the file, and the hidden dependency from chapter 16 is not discoverable by computation; the machine’s “no contradiction found” means only that the provided documents agree. Second, the durations are human evidence: the machine will happily compute a critical path through durations that chapter 15’s estimate would call fiction, and the estimate maturity and the assumptions log are the human’s check, not the machine’s. Third, the decision among the four moves is human: the machine can compute the schedule consequences of adding people, reducing scope, resequencing, or accepting a later date, and the choice is a judgment about value, politics, and people that no what-if can make, because the four moves change the other dimensions of success from chapter 2. Fourth, the data is sensitive: contract terms, partner commercial arrangements, merchant settlement data, and regulator timing do not belong in unapproved systems, and the schedule’s commercial content stays on the project’s owned infrastructure. The verification is the room: the leader walks the logic with the owners, tests the machine’s flags against the corridor conversations, and makes the four-move decision in the light, while the machine accelerates the arithmetic and the flagging, and the logic, the durations, and the decisions stay human.

Practice

One. A quick classification. For each project, say which model of time the schedule should run on, the dependency network or the flow system, and the question that decides the choice. (a) A hospital wing: structural steel, then services, then fit-out, then clinical commissioning, with an inspector’s certificate between phases. (b) A support backlog of 300 incoming tickets of varying size against a team of eight. (c) A product launch whose forty-item backlog is mostly independent features competing for the same four engineers. (d) A railway opening: track, signaling, trains, station staffing, and a safety case, each with a regulatory evidence gate. (e) A migration of twenty legacy reports, independent of each other, against one data analyst who has a fixed calendar.

(a) and (d) are networks: the sequences are consequential and enforced, by physics, inspection, or regulation, and the question is what must be true first. (b), (c), and (e) are flow systems: many small items competing for constrained capacity, a flexible order, and the question is how much is in the system and how fast it moves. The common error is choosing by habit, an agile shop running a board for a railway safety case, a plan-driven shop scheduling every ticket for a support backlog; the choice belongs to the work, and the deciding question is whether the sequence or the capacity is the constraint.

Two. A numbers drill: the pass you can check by hand. Verify the station-four arithmetic from this chapter, then do the second pass yourself. The BlueLine fit-out chain: civils shell, six weeks; fit-out, four weeks, after the shell; ticketing hardware, five weeks, after the shell; ticketing integration, ten weeks, after the hardware; access-standard modifications, three weeks, after the fit-out; commissioning, two weeks, after the integration and the access-standard work. (a) Confirm the forward pass, the backward pass, the float of eight weeks on the fit-out and access-standard chains, and the 23-week critical path. (b) Suppose the access-standard scope is signed next week and its duration falls from three weeks to two. What happens to the critical path, and what happens to the float? (c) Suppose instead that the integration’s pessimistic case, 17 weeks from chapter 15, is realized. What happens to the critical path and the float?

(a) The pass is reproduced in the table: the critical path A-C-D-F is 23 weeks, and B and E carry eight weeks of float each. (b) With E at two weeks, the B-E-F chain becomes 6 + 4 + 2 + 2, fourteen weeks, and its float grows from eight to nine; the critical path is unchanged, because shortening a non-critical chain buys nothing for the date. (c) With D at 17 weeks, the critical path A-C-D-F becomes 6 + 5 + 17 + 2, thirty weeks, and the earliest finish moves a full seven weeks; every downstream milestone shifts, and the B-E chain’s float grows to fifteen weeks, because float is measured against the chain, not against the calendar. The lesson is the chapter’s: the critical path is where the uncertainty matters, and the near-critical chain becomes the danger only when its own pessimistic case closes the gap.

Three. A field drill: build both lenses for your own work. Take the next deliverable your project must produce. (a) Draw the dependency network: the five to eight activities that must happen before the deliverable can be accepted, with durations from the estimate, the calendar, and the constraints written on the diagram, and run the forward and backward passes to find the critical path and the float. (b) Draw the flow board: the items in your backlog, the items in progress, the items done this week, and the aging-work report of the in-progress items, ordered by age. (c) Write the reconciliation: which constraint do the network and the board point at, and what is the one decision that unblocks it?

The drill succeeds when the network’s critical path and the board’s oldest item point at the same constraint, because that agreement is the chapter’s whole point, and when the reconciliation names one decision, not five. The common failures: the network drawn from the milestone dictionary instead of from the work, dates copied onto activities, the calendar contractor in drill form; the repair is to ask of each arrow “why must this precede that” and delete the arrows with no answer. The aging report with no oldest item, items listed by name instead of by age; the age is the point. The reconciliation that lists everything and decides nothing; the decision is the deliverable.

Four. A decision room: the board that measures motion. It is month twenty-one at KijaniPay, four weeks before the pilot closes on 15 October. The evidence: twenty-eight backlog items, fourteen in progress, three at or past thirty days, the settlement integration item forty-one days old and blocked on the partner’s sandbox; completions of nine, eight, five, and six over the last four weeks; the two QA specialists double-booked in November between pilot follow-up and the fraud-control volume test, from chapter 16’s resource plan; and the growth team’s urgent requests arriving daily. The options on the table: hire two contractors this week, the schedule’s assumed fourteen engineers; cap the work in progress at eight and refuse new requests until the pilot closes; pull the blocked integration item out of the progress column and force a partner decision; or move the pilot close to 31 October and report the forecast. Decide what Zanele should do first, what she should refuse, and what the forecast should say at this week’s look-ahead.

The defensible answer combines the cap, the pull-out, and the honest forecast: cap the WIP at eight, refuse new requests until the pilot closes, pull the blocked integration item into a named waiting state with an owner and a decision date, and report the range, 15 October at the median, ten days late at the worst recent week, with the percentile named. The cap is the flow discipline working: the system is full, switching has replaced finishing, and the cap forces the team to finish before it starts, the mechanism that raises throughput, verified empirically in the weeks that remain. The refusal is the two contractors: the man-month myth applied to a stream whose constraint is not capacity but focus and a blocked partner, and their onboarding would consume the team’s attention in the weeks the pilot needs it. The pull-out is the hardest move: the blocked item is not active work, it is a risk wearing a work item’s coat, and leaving it in progress skews the cycle-time data and lets the partner’s silence pass as the team’s problem. Moving the pilot close outright, without the cap and the pull-out first, is premature: the date moves by evidence, and the evidence is four more weeks of throughput, which the cap is designed to improve. The unsafe choices: the silent hold, the cap without the refusal, and the contractors with the WIP unchanged, which adds capacity to a system that cannot use it.

Five. The mastery drill: four moves, one corridor. It is month nineteen at BlueLine. The eastern flood-plain drainage approval has landed with conditions that add ten weeks of culvert and flood-mitigation works to the eastern segment, and the network now says the corridor cannot open before month twenty-seven, against the mayor’s target of month twenty-four and Lena’s completion obligation of month twenty-five. The evidence in the room: the eastern segment’s chain, approval, culverts, pours, systems, ticketing, is the corridor’s critical path; the civils are space-bound on the pour front; the ticketing integration, ten weeks at its expected value, can start as soon as the systems design is frozen, which is independent of the eastern civils; the central and northern segments are complete and ready to commission; and the council’s next public commitment is the opening. The four moves are on the table: add people to the eastern civils; reduce scope by opening the corridor in phases, the central and northern segments at month twenty-five and the eastern segment when it is ready; resequence the work by starting the ticketing integration and the systems commissioning early, against the frozen design; or accept a later date and renegotiate the obligation. Choose the combination, defend the trade-off, name the evidence that would change your answer, and say what the milestone dictionary should show for the eastern segment.

The defensible answer combines resequencing with a phased opening. The eastern segment is on the critical path, so the ten weeks land on the chain, and every downstream date moves by the full ten unless the chain itself shortens. Adding people is the weakest move: the pour front is space-bound, the culvert works are seasonal, and the man-month myth applies to civil works as much as to software; extra gangs buy days, not weeks, at a cost chapter 18’s budget would carry. Resequencing is the strongest network move: the ticketing integration and the systems commissioning depend on the frozen systems design, not on the eastern civils, so starting them now moves work off the critical path without adding people, and chapter 15’s 9.7-week expected value becomes a scheduling opportunity instead of a threat, provided the fast-track risk, rework against a design that later changes, is priced and owned. The phased opening is the scope move that fits the politics: the central and northern segments carry the corridor’s passenger volume and are ready to commission, so opening them at month twenty-five, with the bus service on that half of the corridor, preserves the mayor’s promise where the city feels it, and the eastern segment opens when its chain genuinely completes, month twenty-seven or twenty-eight, reported as a forecast, not a failure. Accepting a later date alone surrenders the schedule’s real options before they are priced; accepting it after the other moves, for the eastern segment only, is the responsible close of the renegotiation, under the governance of chapter 8 and chapter 16’s re-baseline discipline: the obligation moves by decision, with the forecast and the range on the table. The evidence that would change the answer: the true duration of the approval conditions, whether the culvert works can run through the wet season, whether the systems design freeze can hold, and the political cost of the phased opening versus the renegotiation; each is an assumption with a test date and an owner in the milestone dictionary. The unsafe choice is the compound promise, add the people, keep the single opening, and hold month twenty-four, because it converts the four moves into a fifth, denial. A defensible alternative is the full resequence without the phase, if the central and northern segments cannot be operated independently, and credit belongs to any combination that names the chain, prices the moves, and makes the obligation move by decision.

Six. The transfer question. Look at the schedule your project is carrying. Which model of time is it, and is that the model the work needs? Where is your utilization number and where is your completion count, and which one does the room look at? If your work is a network, who owns the float on your near-critical chains, and what is the evidence rule behind your percent complete? If your work is a queue, what is your WIP limit, and which item on your board is older than it should be, and who owns the decision to do something about it? The one artifact you add this week, the aging report, the network’s float check, the evidence rule, which one would change the next schedule decision more?

The durable principle: a schedule is a model of time, the network for work whose sequence is the truth and the flow system for work whose constraint is capacity, and mastery is choosing the model the work needs, reading it honestly, and re-deciding the choice when the work tells you it changed. The longest chain and the oldest item are the same insight in two languages: find the thing the whole waits on, and protect it. The most common next failure is quieter than the four characters named here: the schedule gets built, the critical path gets drawn, the WIP cap gets set, and then the evidence rules decay, the percent complete returns by feel, the float becomes private again, and the schedule returns to a calendar with a story attached, while the real model of time runs in the heads of the people who are too busy to write it down. The schedule must be carried into execution itself, the look-ahead, the standup, the aging report, the evidence check, the weekly re-forecast, because the schedule is not finished when it is drawn; it is finished when the project’s time decisions are made on it, every week, in the light. And time is only half of the plan’s arithmetic: the same network that decides when the corridor opens decides when its money must flow, and the schedule’s forecast becomes the cash-flow curve of chapter 18, where a project can be exactly on schedule and completely out of cash, and the financial fluency to see that coming is the next chapter’s craft.

Notes

• The composite cases remain author-created illustrative material. The BlueLine month-nineteen schedule review, the eastern flood-plain drainage approval conditions, the station-four network, the ticketing integration expected value, the access-standard pessimistic case, and all named characters are the author’s teaching constructions consistent with the facts established in earlier chapters: the corridor’s four segments, twenty-four stations, target opening of month twenty-four, and Lena Voss’s month-twenty-five completion obligation from chapters 3, 7, and 15; the 5-9-17 week three-point estimate for the ticketing integration and the unsigned access-standard scope from chapter 15; the KijaniPay month-twenty-one timeline, the twenty-four-hour settlement promise, the 15 October pilot close, the 28-item backlog, the twelve engineers and double-booked QA from chapters 12 and 16; and the Savanna sandbox dependency from chapters 12 and 16. The pilot arithmetic is reproducible from the text: 28 backlog items at a median throughput of 7 per week is 4 weeks; at the 85th percentile of about 8.5, about 3.3 weeks; at the worst observed week of 5, 5.6 weeks. Cycle-time percentile conventions vary by method, nearest rank versus interpolated inclusive versus interpolated exclusive, and the chapter rounds to about 8.5; the forecast conclusion, on time at the median and about ten days late at the worst observed week, does not depend on the convention. The station-four pass is reproduced in the chapter’s table; the duration of 10 weeks for the integration rounds the 9.7-week expected value from chapter 15 for the worked pass. The corridor totals (the 2,400 million-unit envelope, the 1,150 million units committed, the 1,390 million-unit forward base) are unchanged from chapter 15.
• The critical-path method follows its standard history: James E. Kelley Jr. and Morgan R. Walker published “Critical-Path Planning and Scheduling” at the Eastern Joint Computer Conference in December 1959, describing the method developed at DuPont for construction and turnaround scheduling; PERT was developed in 1958 for the U.S. Navy’s Polaris program with Booz Allen Hamilton, as noted in chapter 15. The terminology of activities, durations, calendars, dependency logic, leads and lags, forward and backward passes, total float, critical path, crashing, fast tracking, resource leveling, and resource smoothing follows the general practitioner usage codified in the Project Management Institute’s Practice Standard for Scheduling, third edition (2019), and the related vocabulary of the PMBOK Guide, Eighth Edition (Project Management Institute, November 2025), which treats scheduling as part of its performance domains; this book describes the ideas in its own words and remains independent of PMI and the PMBOK Guide. The term “slack” appears in the older CPM literature as the equivalent of float; this book uses “float” consistently.
• The man-month argument follows Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering (Addison-Wesley, 1975; anniversary edition 1995), which argued that adding manpower to a late software project makes it later, because of onboarding, partitioning, and communication overhead; the concept is described here in the author’s own words and applied to civil works and knowledge work beyond software, which is the author’s extension.
• Little’s Law follows John D. C. Little, “A Proof for the Queuing Formula: L = λW,” Operations Research 9(3), 1961, the same source cited in chapter 15; the practitioner treatment of cycle-time percentiles, aging work, and throughput-based forecasting follows Daniel S. Vacanti, Actionable Agile Metrics for Predictability: An Introduction (Neptune Township, NJ: DZone, 2015). The treatment of queues, utilization, and variability follows the general queueing-theory results whose origins include A. K. Erlang’s 1909 and 1917 telephone-traffic papers and the production-science treatment in Wallace J. Hopp and Mark L. Spearman, Factory Physics, third edition (Waveland Press, 2011), where waiting time grows nonlinearly as utilization approaches capacity under variability; the utilization trap and the WIP-cap mechanism are the author’s synthesis of that literature in project vocabulary.
• The buffer-management treatment follows the concept introduced by Eliyahu M. Goldratt, Critical Chain (Great Barrington, MA: North River Press, 1997), described here in the author’s own words: buffers placed to protect the longest chain and the feeding chains, with explicit sizing and ownership, as an alternative to per-activity padding; the book is a commercial work and its prose is not reproduced. The explicit-buffer vocabulary is consistent with chapter 15’s contingency and management-reserve discipline applied to the calendar.
• The queue-length, batch-size, and flow-economics ideas attributed to product development follow Donald G. Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development (Celeritas Publishing, 2009), described here in the author’s own words; the book is a commercial work and its prose is not reproduced. The chapter’s four moves, add people, reduce scope, resequence, or accept a later date, and the named failure patterns, the calendar contractor, the float hoarder, the utilization idolater, and the stage manager, are the author’s own constructions, consistent with the failure-aware teaching style established in chapters 13 through 16.