How we estimate project timelines: two timeline types, granular task breakdown, and estimates grounded in historical data

Why project estimates miss

Time is the scarcest resource in most businesses. You can spend more money, you can hire more people, but you can't buy more hours in a day. So the ability to estimate how long work will take, and then deliver against that estimate, matters a lot.

The bad news: humans are systematically bad at it. Psychology research has a name for this, the planning fallacy. People consistently underestimate how long their own work will take, even when they've done similar work before and even when they've been burned by the same underestimation in the past. The fallacy isn't about being new at something. It's about how memory works. People remember the parts of past projects that went well and forget the interruptions, revisions, and unexpected blockers that slowed the actual finish.

The practical consequence: if you estimate based on memory, you'll underestimate. If you base your estimate on "how long I think this should take," you'll be wrong in the same direction almost every time.

The fix isn't better intuition. It's recording how long tasks actually take and using that data to ground future estimates. The teams we see estimating well aren't smarter. They're working from numbers instead of gut feel.

This article covers how we approach project time management at SUFFIX: two timeline types we work with, the granular task breakdown that keeps estimates honest, the historical data we use to calibrate, and the review loop that makes each project a better reference for the next.

Two timeline types, two failure modes

Every project runs on one of two timeline structures, and each has its own failure pattern.

Fixed timeline (externally set deadline)

The deadline is set by something outside the team's control. A product launch, a campaign window tied to a season or event, a client's board meeting, a regulatory requirement. Everyone knows the deadline from day one.

Upside: Easy to plan around. The team has a clear target and can work backwards from it. Stakeholders align on the date without negotiation.

Failure mode: When scope exceeds available time. The deadline can't move, so something has to give. Without deliberate scope management, the team ends up compressing quality at the end to hit the date, which is how campaigns ship with visible rough edges.

How we handle it: Trim scope deliberately rather than silently. If the full plan doesn't fit, name what gets cut, what gets simplified, and what gets deferred to a later phase. Common moves: reduce review rounds from three to two, consolidate phases that can run in parallel, cut features from a launch and schedule them post-launch, shift research to a shorter version that still informs direction. These are conversations, not surprises.

Collaboratively-set timeline (team and client agree together)

No external deadline forcing the timeline. The team and the client jointly set dates based on what the work requires. More common on longer, multi-phase engagements.

Upside: Flexible. Timeline can match what the work actually needs rather than being compressed to fit an arbitrary date.

Failure mode: Drift. Without an external forcing function, projects slip quietly. A week becomes two. Two becomes a month. Nobody notices until something downstream gets affected, and suddenly the project is months behind with no clear cause.

How we handle it: Milestone checkpoints that expose drift before it becomes catastrophic. Instead of one big deadline at the end, we agree on smaller interim checkpoints (design direction approved, wireframes complete, development alpha, etc.) with specific dates. At each checkpoint we check where we actually are versus where the plan said we'd be. If there's slippage, we name it, identify the cause, and adjust. Small corrections early beat big corrections late.

Work Task: why granularity prevents rolling disasters

A project estimate is only as good as the task breakdown underneath it. A single number ("this project takes three months") tells you almost nothing about what could go wrong, where dependencies sit, or how to adjust if something slips.

We break every project into work tasks: specific phases of work with their own estimates, owners, and dependencies. The granularity matters because it prevents a specific failure mode we see constantly: the rolling disaster.

Rolling disaster pattern: A task estimated at three days actually takes five. Nobody notices the two-day slip because the next phase hasn't started yet. The next phase inherits the delay and also runs long, because it had its own optimistic estimate. By the end of the project, a cascade of one-or-two-day slips has pushed the whole timeline weeks out, and no single slip looked big enough to flag.

Why granularity helps: When tasks are broken down to the phase level with their own estimates, a slip gets visible immediately. The project manager can see "Phase 2 ran two days over" on day five instead of discovering the cumulative delay at the end. Small, early, visible slips are manageable. Large, late, opaque slips are not.

A related effect worth naming: Parkinson's Law, the observation that work expands to fill the time available. Vague, large task blocks invite work expansion because the boundaries aren't clear. Granular task breakdown compresses this by making each phase's scope explicit.

Example: Marketing Strategy project

The work tasks on a typical Marketing Strategy engagement:

Project requirement and objective gathering: Align on what the client is solving for, what success looks like, and what constraints (budget, timeline, resources) we're working within.

Target audience definition: Who specifically the strategy is for. Usually drawn from client data plus our own category research.

Market research: Category trends, competitor analysis, audience insights. Depth depends on what the strategy phase actually needs.

Strategic plan: The strategic direction, including positioning, messaging, and what the campaign is trying to achieve.

Media plan: Channel mix, budget allocation across channels, flight dates.

Content plan: What content runs on what channels, with what frequency and message.

KPI definition: How we'll measure whether the strategy is working.

Some of these phases can run in parallel. Research and early strategic thinking often overlap. Content plan and media plan can develop together once the strategy is set. This parallelism is a source of time savings, but also a source of coordination complexity. Granular breakdown lets us plan the parallels deliberately rather than letting them collide.

Example: Website and Web App project

Website projects are more sequentially constrained than marketing strategy projects. One phase often has to finish before the next can start.

The typical phases:

Sitemap / information architecture: Define the site's content and navigation structure.

UX research (where applicable): User interviews, competitor audits, or analytics review to inform the design direction.

Wireframe: Low-fidelity layout of the site or app, validating flow and structure before visual design.

User Interface Design: Visual design layered onto the wireframe.

Front-end development: Building the user-facing interface from the design.

Back-end development: Building the server-side logic, database, APIs.

User Acceptance Testing (UAT): Systematic testing with the client team before launch to confirm everything works as expected.

Launch and handoff: Deployment, final QA, handover documentation.

Each phase depends heavily on the one before it. You can't design without a wireframe. You can't build without a design. You can't test without a build. This sequential nature makes website estimation more predictable than marketing estimation (fewer parallel tracks to manage), but also more vulnerable to rolling disasters (a slip in an early phase propagates forward with little room to absorb it).

Estimation accuracy on websites improves significantly when the team has a database of past projects with similar complexity to reference. A wireframe phase for a 20-page site has a typical range. A UI design phase for an e-commerce build has a typical range. Estimating from those ranges beats estimating from scratch every time.

How we actually estimate (historical data)

The single most useful thing we do for estimation accuracy is record how long tasks actually take, across every project, and reference that data when estimating future projects.

How it works in practice: Every project tracks time per phase. Wireframe took how long? Back-end development took how long? UAT took how long? These numbers get logged and accumulated. Over time, the team builds a reference database: design phases for this kind of project average around X days, with a range of Y to Z depending on complexity factors.

Why it beats gut feel: Memory is biased. It remembers the easy cases and forgets the hard ones. Data is neutral. It captures the average, including the interruptions, revisions, and blockers that gut feel edits out. Estimating from memory produces consistent underestimates. Estimating from data produces estimates that match reality.

The compounding benefit: The more similar projects the team has done, the more reliable the data gets. Thirty wireframe phases tracked across thirty projects gives a much more reliable baseline than three, and a team's estimation accuracy improves every year it keeps records.

How to start if you don't track yet: Pick one or two consistent phase names (like "design" and "development") and start logging hours or days against them on every project, even roughly. Even three or four data points beats no data at all. Over a year of projects, the database gets genuinely useful.

Common estimation traps

Even teams that estimate carefully fall into specific traps:

Forgetting review cycles: Most estimates budget for "the work" and forget that the client needs to review and give feedback between phases. Review cycles routinely add days or weeks that weren't planned for.

Underestimating the last 10%: QA, polish, handoff prep, final documentation. These always take longer than people think because they surface issues that weren't visible during the main work.

Not accounting for client-input dependencies: Your timeline assumes the client provides what they said they'd provide on the date they said they'd provide it. They often don't. We've written about this in detail in our article on chasing client inputs; the short version is: build input delays into the plan, because they will happen.

Treating best-case as likely-case: The estimate is usually closer to "how long if everything goes smoothly" than "how long on a realistic run." Smooth runs are the exception. Use midpoint, not best case.

Not buffering for known unknowns: Integration surprises, browser bugs, API changes, last-minute scope discussions. You won't know which specific issue will hit, but something almost always does. A 10 to 15% buffer on the overall timeline absorbs these without drama.

Naming these traps explicitly helps the team catch them in the estimate phase rather than discover them later.

Reviewing estimates after the project

The feedback loop that actually improves estimation over time: compare estimate to actual after every project, and note the patterns.

Did we estimate the design phase at 10 days and it took 14? Where did the extra time go? Was it revisions the client requested that we didn't budget for, was it scope creep mid-phase, was it a technical dependency we didn't see coming? Each of these has a different correction in the next estimate.

Over six to twelve projects, patterns emerge. Maybe the team consistently underestimates review rounds by about 30%. Maybe UAT always takes longer than the initial estimate because issues found there cascade into fix cycles. Maybe a specific project type (like messaging-platform integrations) has more variance than others.

These patterns become corrections in the next estimate. "Historical data says our design phase averages 12 days but we usually estimate 10. Let's estimate 12 this time." Small, data-backed corrections, applied consistently, make estimation dramatically more accurate over time.

Without this review loop, teams make the same estimation mistakes forever. With it, estimation is a skill that actually improves.

The core takeaway

Good time estimation isn't about being smarter. It's about a few deliberate practices applied consistently: distinguishing between fixed and collaboratively-set timelines so you know which failure mode you're managing, breaking work into granular tasks so slips get visible early, grounding estimates in recorded time data instead of memory, naming the common traps so you catch them before the estimate goes out, and reviewing estimate-versus-actual after every project so next year's estimates are sharper than this year's.

None of this is hard. The difficult part is doing it consistently. Teams that commit to the discipline produce dramatically more reliable timelines than teams that rely on gut feel, and over time, the reliability itself becomes a competitive advantage.