How to When Planning or Predicting: - Check Past Outcomes: How Often Have Things Gone as (Cognitive Biases)

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‑sceneMicro‑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 Brali LifeOS 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.

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.

We open Brali LifeOS 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 Brali: 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.

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‑sceneMicro‑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.

• 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.

• 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 Brali. This pivot corrected our next three forecasts by about 20% better alignment with actuals.

Mini‑App Nudge Add a Brali 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.

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 Brali LifeOS with milestones and triggers.

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.

• 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 Brali LifeOS that ask for progress every 48 hours.

Micro‑sceneMicro‑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:

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

• Step A (5 minutes): Open Brali LifeOS. 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 the app or by quick math.
• Step D (10 minutes): Add contingency triggers and actions as separate sub‑tasks.
• Step E (2 minutes): Add a Brali 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.

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.

• 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.

We habitually want to feel we are flexible; instead we will get better outcomes by being disciplined in measurement. In Brali LifeOS, 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.

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.

• "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 Brali LifeOS.
• 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.

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‑sceneMicro‑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.

• 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 Brali LifeOS 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 Brali LifeOS and run a 10‑minute ritual:

These small, regular updates compound into better forecasts.

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.

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.

• 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 Brali LifeOS.
• Set one Brali check‑in at planned + buffer days.

We can make that checklist a habit by scheduling it as a pre‑planning ritual in Brali LifeOS: 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.

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.