Delivery Risk

Schedules have slipped and quality has suffered for as long as people have written software. What was missing for a long time was a vocabulary for it. After a release landed three weeks late, the retrospective usually produced one sentence: "things were a bit rushed this time." The follow-up was equally predictable: "let's give ourselves more room next time."

Neither sentence points at anything a team can change. Being rushed is a symptom, not a cause, and giving yourself more room is a resolution, not a rule. So the next cycle plays out the same way in the same order, and by the third quarter the team treats planning as paperwork.

The shift came from noticing that these failures are not fresh accidents every time. They arrive in a small number of recognizable shapes: a date fixed before the scope is settled, a stretch of long hours right before a deadline, a cycle where urgent breakage eats every hour that was supposed to go to planned work. Once each shape had a name, the retrospective sentence changed. "We were rushed" became "forty percent of our time went to unplanned incident work," and that version tells you what to adjust.

Delivery risk is the label for that collection of named failures. A team can pick a methodology, layer a framework on top of it, split the roles, size the work, and build a plan — and the gap between the plan and reality still exists. This is where the other parts of how a team works come apart.

None of it appears out of nowhere. Scope creep, where the boundaries of the work quietly expand without anyone agreeing to it, starts two months earlier with someone saying "sure, we can throw that in." Technical debt, the accumulated cost of cleanup postponed in order to move faster, is last quarter's saved day coming back as three days this quarter. So the terms in this area read less like incident reports and more like a checklist for decisions a team is about to make.

Naming also changed who can raise the issue. Two weeks before a deadline, an engineer saying "there won't be time to test this" sounds like one person complaining. The same engineer saying "we're under deadline pressure, and at this rate the next cycle fills up with firefighting" is pointing at something the whole team already recognizes. A word moves the conversation from a person's character to the shape of the work.

The term earns its keep in two places. In planning, it turns into a question about what to reserve: if firefighting has taken a fifth of every cycle for six months, a plan that assumes zero unplanned work is already wrong on the day it is written. In a retrospective, it separates the one-off from the pattern — a single bad week is noise, while the same shape three cycles running is a structural problem worth spending a cycle to fix.

The terms grouped under delivery risk fall into two families. One covers the situations a team lives through when a plan comes apart (the types), and the other covers long-standing observations about why those situations repeat (the laws). The first family describes symptoms; the second explains why the usual cures for those symptoms fail.

The types are what a team feels directly. There are three, and they rarely appear alone — most often they arrive in sequence.

1. Deadline pressure — the date is fixed first and the amount of work doesn't shrink to match. A feature estimated at four weeks gets a launch event three weeks out, and a week of work has to come from somewhere. What goes first is usually testing or code review, the work that costs nothing visible today. Once the date is treated as immovable, quality is the only remaining adjustable input.
2. Crunch — when the pressure doesn't let up, the only lever left is hours. Two weeks of staying until eleven every night is the standard form. For a week or two it genuinely works. But the code that ships that way carries shortcuts, and after the third week, attention doesn't come back over a weekend. If it reaches burnout, the load that person was carrying gets redistributed to everyone else while they recover. Two weeks of it before a launch is a choice a team can make with its eyes open; two months of it is a staffing decision nobody ever made out loud.
3. Firefighting — whatever shipped in a hurry produces incidents and support tickets, and the next cycle goes to handling them. Planned work slips again, and the slip turns the following date into pressure of its own. After one full loop, nobody on the team remembers what this cycle was supposed to deliver. When half of every weekly plan gets erased, people stop planning seriously, and the estimates for the next cycle get worse.

Strung together, the sequence reads: the date pushes, people pay with hours, and the next cycle pays the debt. That's why fixing one piece in isolation usually fails. Announcing a ban on late nights while the pressure stays in place just moves the same work to people's laptops at home.

The laws explain the repetition. There are three. They are observed tendencies rather than proven formulas, so exceptions exist, but knowing them keeps a team from reaching for the wrong remedy.

1. Parkinson's Law — work expands to fill the time available for it. Give a two-week task four weeks and it tends to take four, because the start slides and there is always one more thing worth polishing. This is why padding the schedule, on its own, doesn't remove any of the three types above.
2. Brooks's Law — adding people to a late project makes it later. New arrivals have to learn the context, and the person best placed to explain it is the one who is already busiest. Add two engineers to a team of three and the team's output usually drops for the first few weeks.
3. Conway's Law — the structure of a system ends up mirroring the communication structure of the organization that built it. If billing and notifications belong to separate teams, a seam shaped like that team boundary shows up between the two features. When the schedule slips at the same point every time, the cause may be the line drawn through the org chart rather than the skill of whoever owns that area. The fix there is merging the two sides or agreeing on a contract between them, not replacing a person.

The two families only work together. Looking at the types alone produces one of two answers: try harder, or add people. Brooks's Law explains why the second answer backfires, and Parkinson's Law explains why the opposite of the first answer — simply allowing more slack — doesn't help either. What's left is cutting scope or changing how the work is structured. None of the three laws says a team is helpless. They say which levers are fake — padding the estimate, adding headcount, and asking for more effort are the moves that feel like action and change the outcome least.

Telling those apart takes records. A team working in fixed cycles, such as a sprint, can write down three numbers each time: what was planned, what actually finished, and how much time went to work that was never in the plan. Three cycles is enough to show whether this quarter's problem sits on the pressure side or the firefighting side. "We planned twenty items, finished twelve, and spent eight days on unplanned work" changes the next plan in a way that "things were rushed" never does. Without those numbers, every conversation about why the quarter went badly becomes a contest of impressions, and the loudest impression wins.

"Looking at last quarter, unplanned work was forty percent of our time. Let's leave that much open this time instead of pretending it won't happen."

Firefighting shows up at a steady rate every cycle, so it should be planned as a constant rather than treated as an exception.

"Adding people right now makes next month later, not earlier. Let's cut scope instead."

Brooks's Law used as the argument for trimming the work rather than staffing up.

"If the date can't move, someone is going to suggest pulling all-nighters — and that costs us the entire next cycle."

A warning that crunch doesn't remove the bill, it just moves it one cycle out.

At Pagedeck this comes up during quarterly planning. Mia lays out the records from the last three cycles and walks through where the gap between planned and finished work came from. If most of it was incident handling and customer escalations that were never on the plan, that gap isn't evidence of a lazy team. The accurate response is to reserve that much capacity up front next quarter.

Theo usually adds one thing: if the incidents cluster around the same feature every time, that feature has a structural problem rather than a scheduling one. Then the next quarter's plan gives one slot to cleaning it up instead of to a new feature. Grace, rather than insisting on the date, asks what comes out. Without forcing a choice among date, scope, and quality, teams always sacrifice quality — it's the only one nobody in the room objects to on the spot. Move the date and sales reacts; cut scope and customers react; skip the tests and nothing makes a sound until an incident weeks later.

The most common mistake is reading all of this as a problem of diligence or skill. One team missed the deadline and another made it, so the difference looks like it lives in the people. But all three types arise where dates, scope, and headcount meet. Put the same people under different conditions and the outcome changes. Blaming individuals narrows the available remedies to encouragement and performance reviews, and pushes teams toward hiding problems instead. The later a blocked task gets mentioned, the less time there is to respond, and the next cycle gets worse. An organization where slippage surfaces two days before the deadline usually doesn't have unreliable people; it has a history of the first person to speak up paying for it.

The second mistake is treating a written risk list as risk management. Once the items are in a document with owners and dates next to them, the work looks done. In practice, the moment something lands on that list it tends to stop moving. What actually changes outcomes is deciding in advance what gets dropped when the plan is built, and who is allowed to decide what when something breaks. Teams that only write things down end up opening the document after the incident and confirming that yes, that was indeed the risk. A milder version of the same error runs the other way: treating delivery risk as something that only afflicts badly run companies. Every team that commits to dates carries some of it. What separates teams is not whether the risk is there but whether it gets named early enough to trade against, while there is still scope left to cut. For a list to change behavior, each item needs a trigger attached — for example, if unplanned work exceeds thirty percent for two cycles running, the next cycle's planned volume drops by that much.