When Planning or Predicting: - Check Past Outcomes: How Often Have Things Gone as

Background snapshot

• Origins: The approach comes from research on planning fallacy, hindsight bias, and forecasting error—fields that date back to Kahneman and Tversky’s work in the 1970s and have since spread across project management, behavioral economics, and clinical decision‑making.
• Common traps: We ignore base rates (how things usually go), overvalue unique details, and anchor on the best‑case scenario. Optimism colors our estimates by about 20–50% in time and resource misestimation in many contexts.
• Why it fails: We prefer stories to statistics; a vivid plan feels actionable, while statistical context feels cold. Also, data about our own past is often messy or unrecorded.
• What changes outcomes: Deliberately checking past outcomes, quantifying how often ideal plans succeeded, and adjusting upfront for realistic setbacks can reduce late changes and overrun by measurable percentages (often 20–40% improvement in predictability).

We begin by opening a notebook or a tracker and making one simple choice: which kind of plan are we making today? A work project deadline, an exercise routine, a household repair, or a social commitment? The first micro‑task is immediate and short: spend five minutes locating the most recent comparable episode in the last 6–12 months. If we can’t find one, we widen the window to 24 months. This small decision—pick a comparable case—starts the habit of checking reality rather than leaning on whim.

Why this matters now

When we imagine the future, we use past scripts without checking the script’s track record. A new project looks like yesterday’s ideal, but yesterday’s reality included delays: sick days, unclear requirements, vendor hiccups, or software bugs. If we assume perfection, we set brittle expectations. If we instead ask, "How often did events go as planned?" we create a probability-informed buffer. We will demonstrate how to do that in practice.

Micro‑scene: planning a 6‑week project We sit at a kitchen table with a mug cooling beside a half‑opened notebook. Our task is a six‑week product spec for a small team of three. We have a calendar with six sprint blocks and a confident note: “Feature delivered by X.” We pause. We Open your task list or tracker and find three prior projects in the last 18 months. Two ran late; one hit the deadline but only with extended hours from one team member. We assumed: X → observed: Y → changed to: Z. We assumed a straight six‑week flow (X) → observed two late projects and one burnout shortcut (Y) → changed to: add 20% time buffer, two explicit contingency tasks, and a shared "stop‑gap" fund of 4 hours/week of paid overtime that we could use or not (Z).

Read on to build that habitual question into our planning.

The core idea, in one sentence

When we predict an outcome, check similar past outcomes and use the observed success rate to set buffers and contingency actions; celebrate optimism but add realism.

Step 1 — Choose a comparable past outcome (≤10 minutes) We often skip this step because it feels tedious. It’s not. It’s decisive. If we want to know whether a two‑day estimate is realistic, pick the last 2–3 tasks that resembled this one. The quick rule: choose tasks that match on at least two of these dimensions—people involved, complexity, external dependencies, and timespan.

How we do it now

We Open your task list or tracker or a notebook, and write:

• Case name or identifier (e.g., "Website update 2024‑03").
• When it occurred (date).
• Planned duration (e.g., 2 days).
• Actual duration (e.g., 4 days).
• Short note on cause of drift (e.g., "API downtime; scope creep: added 1 page").

Three minutes, two choices, one outcome. We keep repeating until we have three comparable cases, if possible. If we have zero comparable cases, we extend the search to similar tasks in our team or personal life and treat them as proxies—document that proxy relationship. This practice forces us to use base rates (our personal or team track record) rather than a single rosy projection.

Trade‑offs and small decisions We face a decision: be strict about similarity and possibly have no data, or be flexible and allow more noisy evidence. If we are launching a first‑ever activity (no personal data), we must use external base rates (industry norms) and default to conservative buffers. If we are repeating a routine task, we can use precise local data and be tighter with buffers.

Mini‑scene: counting the errors We scan our calendar and find three deliverables labeled "Completed": two stretched by more than 50% of their expected time; one took roughly the expected time but required two late evening interventions. We tally in your tracker: planned 36 hours total, actual 62 hours total. That simple tally gives us a rate: 0 successes out of 3 ideal completions (0/3) where "success" means delivered within planned scope, time, and without extra hours. The number stings, but it is actionable.

Step 2 — Translate the past into a probability or buffer We now convert outcomes into something we can use: a probability of “goes as planned” or a multiplier for time/resources.

Two pragmatic modes:

• Probability mode: If 3 comparable past projects succeeded out of 10, success rate = 30%. We then ask whether we will accept a 30% chance of on‑time completion or adjust.
• Multiplier mode: If past projects took 1.6× planned time on average, we plan time ×1.6.

Which mode to use depends on context. For short, personal tasks, multiplier mode often feels simplest; for larger, risk‑sensitive projects, probability mode helps us decide whether to add contingency plans.

A calculation example

We planned a 5‑day sprint. Our three comparable projects took 8, 6, and 11 days versus planned 5, 5, and 5. Actual/planned ratio = 8/5 (1.6), 6/5 (1.2), 11/5 (2.2). Mean multiplier = (1.6+1.2+2.2)/3 = 1.67. Median = 1.6. We choose multiplier 1.6 and plan 8 days. We note that one outlier had vendor downtime; further steps will cover vendor contingencies explicitly.

Reflective sentence: This is not pessimism. It is a reallocation of optimism into planning currency—time and alternative actions.

Step 3 — Specify contingencies, not just buffers Adding 30% time is useful, but time alone hides the actions we will take if things go sideways. We'll instead write contingency triggers and concrete actions:

• Trigger: task still incomplete after planned + buffer days.
• Action A: pause and triage scope (remove nonessential items).
• Action B: add paired programming for 4 hours to unblock critical task.
• Action C: activate vendor escalation with allocated 2 hours of account manager support.

These are specific, measurable, and actionable. When we prepare only a time buffer, we often fritter the extra hours across minor fixes. When we prepare explicit triggers and actions, we reduce wasted buffer consumption.

Micro‑scene: variant planning for social commitments We plan a garden party for 20 with a two‑hour cook window. After checking last three events, we notice rain forced one cancellation and late supply arrival delayed another by 90 minutes. We add a contingency: rent a 3×3 m gazebo + pack two spare gas burners. Cost: $45 rental + $30 spare fuel. We mark a trigger: if weather forecast shows >20% chance of rain within 48 hours, deploy gazebo order. That small plan shifts anxiety into a purchase and a check‑in.

Trade‑offs: money versus time versus stress Every contingency costs something—time, money, or both. We make explicit choices: pay $75 now (low stress, higher reliability) or keep $0 contingency and accept a 40–60% chance of extended work the day of. There is no single correct choice; the method makes the trade‑off visible.

Common cognitive traps and how we counter them

• Planning fallacy: We believe our best estimate. Counter: use base rate of past outcomes; default multiplier 1.2–2.0 depending on variability.
• Hindsight bias: After a success, we believe it was predictable. Counter: record causes and mark uncertain drivers separately.
• Overfitting to unique details: We imagine today’s plan as unique and solvable. Counter: force at least three comparable cases or declare we are using external base rates.
• Optimism bias in teams: The “we’ll make it” groupthink. Counter: require one dissenting forecast or the "pre‑mortem" where a team lists ways they could fail.

Practical short tools to use now (all actionable today)

• The 3‑case scan (≤10 minutes): find three comparable past tasks and record planned vs actual durations and a short cause note.
• The multiplier conversion (≤5 minutes): compute average actual/planned ratio and choose the 50th–70th percentile as our multiplier.
• Contingency list (≤10 minutes): write 2–4 triggers and actions associated with our buffer.

We assumed we could remember project histories reliably → observed that our recall overoptimistically underestimated delays by 30% → changed to: use an explicit three‑case scan and record in your tracker. This pivot corrected our next three forecasts by about 20% better alignment with actuals.

Optional nudge Add a tracker check‑in module titled "Three‑Case Scan" with a 10‑minute timer and three quick fields: "Case", "Planned time", "Actual time", "Drift cause". Run it before any new estimate; sync the multiplier to the task estimate. This tiny module reduces guesswork and increases calibration.

Sample Day Tally (how a reader could reach the target today)

Target: Produce a realistic deadline for a 5‑day deliverable.

• Step 1: Three‑case scan (3 items): actual/planned ratios 1.6, 1.2, 2.2 → mean 1.67 (rounded to 1.6) = 8 days.
• Step 2: Contingency actions: 4 hours paired work + vendor escalation 2 hours = 6 hours reserved.
• Step 3: Small buffer for morning interruptions: 30 minutes/day × 8 days = 4 hours. Totals: Planned work = 5 days (40 hours), adjusted plan = 8 days (64 hours), reserved contingency = 6 hours + 4 hours = 10 hours. Final allocation = 64 + 10 = 74 hours of planning currency. We put the 74‑hour plan into your tracker with milestones and triggers.

Quantifying benefits and constraints

We often cite numbers: many teams observe 20–40% improvement in meeting deadlines when using base rates and contingency triggers consistently for 3–6 months. That does not mean we will eliminate overruns. It does mean we can reduce the frequency of emergency work and late surprises by making predictable moves. The trade‑off is that planning will use more upfront time and sometimes money for contingencies that aren’t needed. Statistically, that is often cheaper than urgent, high‑cost rescue efforts.

Edge cases and risks

• No comparable past cases: Use industry benchmarks, ask peers, or start with a conservative default multiplier (1.5–2.0) and treat early phases as data collection.
• High‑uncertainty, novel tasks: Consider probabilistic planning (P50/P80 estimates) or split the project: plan a short discovery phase to reduce uncertainty and collect base rates.
• Routine tasks with low variance: Don’t overbuffer. If past tasks show 95% hit rate at planned time, a small 5–10% buffer is sensible.
• Behavioral risk: Recorded buffers mean we may procrastinate because we feel we have extra time. Counter this by setting intermediate milestones and using small check‑ins in your own tracker that ask for progress every 48 hours.

Micro‑scene: a discovery pivot We plan a six‑month pilot study but have zero internal precedent. We decide to split: an initial 3‑week discovery to define variables and collect local base rates, then a scheduled reassessment. The decision: spend 3 weeks and 40 hours to reduce uncertainty from "high" to "moderate." We accept the upfront cost because the discovery will likely reduce our multiplier later.

How to hold a short "pre‑mortem" that works (≤20 minutes) Pre‑mortems are a diagnostic ritual: imagine failure and trace its causes. We do a short, effective version:

4 — For each top risk, write one mitigation action and a trigger (3 minutes).

This process turns vague fears into concrete mitigations and often surfaces base‑rate knowledge the team already carries.

Practice script for personal use (today)

• Step A (5 minutes): Use your task list or tracker. Create a task “Estimate X” with planned duration.
• Step B (10 minutes): Run the Three‑Case Scan (enter 3 past items).
• Step C (5 minutes): Compute multiplier in your tracker or by quick math.
• Step D (10 minutes): Add contingency triggers and actions as separate sub‑tasks.
• Step E (2 minutes): Add a tracker check‑in scheduled at planned + buffer days.

We practice these steps once today and then set a check‑in to repeat the habit next time we plan.

A worked example: the freelance client job We accept a freelance job to redesign a client's landing page. We estimate 10 hours. Brali three‑case scan reveals past similar jobs with actuals: 12h, 18h, 9h. Ratio to planned 10h = 1.2, 1.8, 0.9 → mean multiplier 1.3. We plan 13 hours. We add a contingency: fixed‑price acceleration for last‑minute requests (price = $40/hour for extra work), and a trigger: if client asks for more than two revisions, pause and renegotiate scope. We add specific time blocks: 3 hours discovery, 6 hours build, 4 hours review & revisions. The 3 hours discovery reduces the risk of scope creep and the contingency guard rails limit open‑ended requests.

Why we choose discrete actions and pricing as mitigation

Money and explicit rules create friction that protects our time. If we only add time, the client’s requests can still expand the scope. If we add a per‑hour fee and a revision cap, we convert vague expectations into a transparent contract. That is a behavioral nudge to constrain unplanned work.

Quantitative rule of thumb (starting points)

• Individual short tasks (≤8 hours): multiplier 1.2–1.5 if you have 3+ comparable cases; otherwise 1.5–2.0.
• Small team projects (≤4 weeks): multiplier 1.3–1.8 depending on external dependencies.
• Projects with heavy external dependencies: add explicit 10–20% external buffer beyond the in‑house multiplier.
• Novel high‑uncertainty projects: plan a discovery phase (10–20% of total planned time) before committing to full schedule.

Practicing measurement discipline

We habitually want to feel we are flexible; instead we will get better outcomes by being disciplined in measurement. in your own tracker, tag each task with “planned_time” and “actual_time” and review monthly. Over time, our own base rates become richer, and our multipliers more accurate. In six months, many teams report cutting their average multiplier down from 1.6 to 1.2 as they improve estimation and dependency management.

Quantify effects and expectations

If our initial mean multiplier is 1.6 and we adopt these practices, we should expect an initial increase in planned time but a decrease in emergency time later. Empirical observations: teams that consistently use base rates and explicit contingencies report a 10–30% reduction in last‑minute overtime after 3 months. This is not guaranteed; it requires consistent check‑ins and adjustments.

Addressing misconceptions

• "This is just pessimism": No. We retain optimistic goals but create realistic pathways. Optimism motivates; realism makes the path usable.
• "We will waste buffer hours": Only if we don't attach triggers and actions. Unused buffers are the price of predictable workflows.
• "This is extra work to collect data": Initially yes, but the time cost is low (5–15 minutes per plan) and yields compounding benefits.
• "We can't be precise with human work": Correct. The goal is not precision but calibration. We reduce gross misestimates that disrupt flow.

One simple alternative path for busy days (≤5 minutes) If we are rushed, use this micro‑hack:

• Open your task list or tracker.
• Quickly list the last comparable task and note planned vs actual time (one item).
• Apply a default multiplier of 1.5.
• Add one contingency trigger: "If >50% of planned time used, pause and triage scope." This 3‑minute routine is better than no calibration and preserves the habit.

How to handle disagreement in teams

When forecasts differ, require both a "best estimate" and a "base‑rate adjusted estimate." If one person believes 5 days and the team median using base rates is 8 days, keep both on the record and adopt the base‑rate estimate unless you explicitly fund the optimism (e.g., with overtime budgets or paid contingency). This preserves accountability and makes disagreements explicit.

Micro‑scene: the negotiation with a manager We planned a two‑week launch. Our base‑rate analysis yields 3 weeks. A manager insists on two weeks. We present both numbers and a plan: we can hit two weeks only by adding one contractor for 40 hours at $X, or by cutting scope Y. The manager chooses. This approach converts an argument into a resource allocation decision instead of burying risk in a false schedule.

Tracking and learning cycle

• Record. For each plan, log planned_time, adjusted_time, actual_time, and top 2 drift causes.
• Review weekly. Spend 10 minutes reviewing tasks that drifted; note patterns (vendor issues, unclear specs).
• Adjust multiplier monthly and revise default contingency actions. This cycle lets us learn from data instead of repeating unspoken assumptions.

Check‑in Block (for use in your own tracker and paper) Daily (3 Qs): sensation/behavior focused

• Q1: How confident are we about today’s plan? (1–5 scale)
• Q2: What has already taken more time than expected today? (single line)
• Q3: Did we activate any contingency action today? (Yes/No; details if Yes)

Weekly (3 Qs): progress/consistency focused

• Q1: How many planned tasks were completed within the planned + buffer time? (count)
• Q2: What were the top two causes of drift this week? (short list)
• Q3: Which contingency actions were most useful? (short list)

Metrics (1–2 numeric measures to log)

• Metric 1: Planned vs Actual time ratio (count: actual_hours / planned_hours)
• Metric 2 (optional): Number of contingency activations per month (count)

Practice prompt: log these three fields after finishing any planned task this week. Over four weeks, we will have a base rate.

Weekly ritual: the 10‑minute calibration Once a week, we Open your task list or tracker and run a 10‑minute ritual:

4 — Schedule one short experiment next week to test a mitigation (2 minutes).

These small, regular updates compound into better forecasts.

How to start with no team data

If we are flying solo, use public benchmarks or ask a friend in the same role for their typical multiplier. Use that as a temporary default and move quickly to collect personal data. Remember: even a single data point is better than none when recorded transparently.

Safety, limits, and a concluding caution

This hack improves predictability by making trade‑offs explicit. It is not a promise to remove uncertainty. We must be honest about constraints—legal, regulatory, and external shocks (e.g., pandemics, supply chain collapses) can overwhelm even the best buffers. The practice is resilience building, not omniscience.

Checklist for today (one page)

• Pick a plan to calibrate.
• Run Three‑Case Scan (or single case if busy).
• Compute multiplier and set adjusted plan.
• Add 2–3 contingency triggers and actions.
• Log planned_time in your own tracker.
• Set one tracker check‑in at planned + buffer days.

We can make that checklist a habit by scheduling it as a pre‑planning ritual in your own tracker: every time we create a task greater than 2 hours or a project greater than 1 day, run the Three‑Case Scan module first.

Closing micro‑scene: relief and a small pivot We finish the day having adjusted three upcoming estimates. The relief is small but real—a sense of alignment between what we hoped to do and the path we will take. We did not remove optimism; we redistributed it into concrete actions: a buffer day, a contingency vendor call, a small budget. We assumed perfect flow (X) → observed messy reality (Y) → changed to structured buffers and triggers (Z). That pivot feels almost experimental: small, testable, and humane.

Hack Card

• Hack №: 1041
• Hack name: When Planning or Predicting: - Check Past Outcomes: How Often Have Things Gone as
• Category: Cognitive Biases
• Why this helps: It turns optimistic guesses into evidence‑informed plans by using past outcomes to set realistic buffers and specific contingency actions.
• Evidence (short): In many teams, applying base‑rate adjusted estimates reduced late emergencies by ~10–30% within 3 months (observational reports).
• Check‑ins (paper / your tracker): Daily and weekly blocks included above; small Brali module "Three‑Case Scan" recommended.
• Metric(s): Planned vs Actual time ratio (count), Contingency activations per month (count)
• First micro‑task (≤10 minutes): Run the Three‑Case Scan—find three comparable past tasks and record planned vs actual time and one cause of drift.
• Open in your own tracker (tasks • check‑ins • journal)

We will practice this together: pick one task today, run the three‑case scan, and add a buffer and two contingency actions. Then check in at planned + buffer days and log the actual/planned ratio. Over four weeks we will have clearer base rates and better forecasts.