Why forecasts beat deadlines

A deadline is a promise. A forecast is a measurement. Here's how we're building forecast dates into TaskD, and why they'll sit right next to your plan.

Each bar keeps its planned end date. When the forecast lands later, the gap shows past the bar.

Every plan starts with dates somebody wanted. That's fine — a plan needs targets. The problem starts when the target stays on the chart long after the work tells a different story.

A forecast answers a different question: given the hours left on this task and the time its owner actually has, when will it finish? It updates every time someone logs time, changes an estimate, or goes on vacation.

How we calculate it. For each task we take the remaining estimate and walk forward through the owner's calendar, skipping weekends, holidays, time off, and hours already booked on other tasks ahead in their queue. Where the walk ends is the forecast. Dependencies push the start of a task to the forecast of whatever it waits on, so a slip early in the chain shows up at the end of it right away.

What you'll see. On the Gantt, each bar keeps its planned end date. When the forecast lands later, a thin extension appears past the bar with the number of days. The project header shows two dates: planned and forecast. If they match, nothing to discuss. If they don't, you know which task caused the gap.

What forecasts are not. They're not a judgment of anyone's speed. They use the team's own estimates. If estimates are off, the forecast will be too — which is useful information in itself.

Why not just move the deadline? Because the deadline is often a real commitment to a client or a launch. Keeping both visible lets you choose: cut scope, add people, or talk to the client early. What you can't do is make that choice if the chart only shows the date you hoped for.

Forecast dates are in testing with beta teams now and will ship with TaskD 1.0.