← Back to blog

Project Estimation Methods: Choose, Combine, Defend

October 25, 2026
Project Estimation Methods: Choose, Combine, Defend

The main project estimation methods are analogous, parametric, bottom-up, top-down, expert judgment and three-point estimating. PMI's estimating standard treats analogous, parametric and bottom-up as the three fundamental strategies and describes the rest as techniques commonly combined with them. No single method wins. Freelancers who quote well usually build a bottom-up estimate, cross-check it with a second method, and give the client a range with stated assumptions instead of one hopeful number.

This guide walks through each method with a worked example, shows how to pick and combine them, and lays out a workflow you can use on your next quote.

The Freelance PM Club
Build Estimates That Support Your Career
The Freelance PM Club helps independent project managers develop skills, find curated roles and connect with a supportive community.
Explore the Freelance PM Club

TL;DR

  • Use bottom-up when scope is defined well enough to break into tasks. It is usually more accurate than top-down, but slower, and it can miss whole parts of the work.
  • Use analogous or parametric estimates early, or as a cross-check on your bottom-up number.
  • Use three-point estimating to turn uncertainty into a range. Set the optimistic and pessimistic bounds before you pick the most likely case.
  • Write down assumptions, exclusions and sources, and agree how changes will be handled, so the estimate protects you when scope moves.

Table of Contents

Why the method matters less than the process

Most freelancers don't lose money because they picked the wrong formula. They lose it because the scope was fuzzy, the risks went unnamed and last year's actuals were never recorded. PMI makes this point in its article on estimation as a process rather than an event: new tools can't make up for unclear scope, unidentified risk or poor historical data.

So treat each method below as a lens on the same question. Different lenses disagree, and that disagreement is useful information.

The six methods at a glance

MethodBest used whenMain weaknessTypical freelance use
Bottom-upScope is defined and can be broken into tasksSlow; can omit entire work elementsFixed-fee proposals, detailed plans
Top-downYou have a total budget or deadline and need to split itCan hide the real effortClient-set budgets, early scoping
AnalogousYou have comparable finished projectsOnly as good as the comparisonQuick quotes for repeat project types
ParametricWork has countable units and known ratesNeeds comparable units and conditionsPages, screens, interviews, test cases
Three-pointUncertainty is high and you need a rangeInputs are guesses if you anchorRisky tasks, schedule risk
Expert judgmentLittle data exists, specialists are availableBias, hard to auditNovel work, sanity checks

Bottom-up estimation

Bottom-up means you estimate small pieces and add them up. PMI guidance says these estimates are made at the work breakdown structure (WBS) level and become most detailed at the work-package level, as described in its paper on the practice standard for estimating. A Virginia Department of Transportation training deck lists six steps: develop the WBS, assign resources, estimate durations, estimate costs, aggregate the results and refine.

Six steps in bottom-up project estimation

The quality of the WBS decides the quality of the estimate. If you need a refresher on structure, this work breakdown schedule example shows how to decompose a project into deliverables and tasks.

A worked example

Say a client wants a website migration managed over six weeks. Your WBS might look like this:

Work packageEstimate (hours)
Kickoff and scope confirmation4
Content inventory and mapping12
Vendor and developer coordination20
QA and issue triage16
Stakeholder reporting (six weeks)12
Launch planning and cutover10
Total74

This is a made-up illustration, not a benchmark. The point is the shape: each line is small enough to reason about, and you can see what is missing. Where is the client review time? Where is the post-launch support? Gaps like these are exactly where bottom-up estimates fail. The PMI paper cited above notes that the method generally beats top-down when scope is defined, but it takes more time and can still leave out entire WBS elements.

Top-down estimation

Top-down starts with the total and divides it. A client says the budget is $12,000 or the launch is in eight weeks, and you allocate that across phases. It is fast, and it matches how many clients actually think.

The risk is that the total comes from the client's hopes, not from the work. Use top-down as a test: if the budget is $12,000 and your bottom-up number is far above it, you have found a scope conversation to have before signing, not a number to quietly absorb.

Analogous estimation

Analogous estimating uses the actual results of comparable finished work, adjusted for differences in scope, complexity, team and conditions. For freelancers, this means your own time logs. If your last two vendor-selection projects took 55 and 62 hours, and the new one has twice as many stakeholders, you start near 58 and adjust upward, with a stated reason.

The strongest version borrows from the outside view. PMI published a case study on reference-class forecasting, which compares a project with a database of similar projects and their actual overruns. It is aimed at countering optimism bias and strategic underestimation. A solo practitioner's version is simple: keep a spreadsheet of every project, your estimate, the actual, and the ratio between them. After ten projects you will know how optimistic you are.

Parametric estimation

Parametric estimating multiplies a quantity by a rate. The University of Waterloo's task estimating guide gives a clean example: 1,000 feet of cable at 25 feet per hour is 40 hours. It works best when units, production rates and conditions are comparable.

Freelance work offers plenty of units:

  • Pages or screens to review or document
  • Integrations to coordinate
  • Stakeholder interviews to schedule and summarize
  • Training sessions to run
  • Test cases to track
  • Hours per recurring weekly workflow, such as status reporting

If your records say a stakeholder interview takes you about 90 minutes including scheduling, notes and follow-up, then 14 interviews is 21 hours before risk. The rate is yours, drawn from your own history, which is why logging time pays off.

Three-point estimation

Three-point estimating uses an optimistic value (a), a most likely value (m) and a pessimistic value (b). The common PERT weighted formula is E = (a + 4m + b) / 6. A simple triangular version is E = (a + m + b) / 3. Both are laid out in Martin Hopkinson's brief guide to three-point estimates.

Worked example

For the QA and issue triage package above, suppose you think 10 hours is optimistic, 16 is most likely and 30 is pessimistic.

  • PERT: (10 + 4 × 16 + 30) / 6 = 17.3 hours
  • Triangular: (10 + 16 + 30) / 3 = 18.7 hours

The weighted number sits close to your most likely case. The triangular one is pulled further toward the pessimistic tail. Neither is magic. The same guide stresses that the result is only as credible as the three inputs, and that the formula doesn't replace identifying the uncertainty that creates the range.

Avoid the anchoring trap

Hopkinson also warns against letting your planned number automatically become the most likely value, because that carries planning bias straight into the range. A better order:

  1. Name the sources of uncertainty (a slow client approver, an unknown legacy system, a vendor with a history of delays).
  2. Set plausible best and worst bounds based on those.
  3. Only then decide where the most likely case sits.

If your range is suspiciously narrow, you probably started from the middle.

Expert judgment

Expert judgment draws on specialists: a developer who has done a similar migration, a former colleague, a mentor. It is often the only option for new kinds of work. Its weakness is traceability, since "I've done this before" can't be audited. Ask the expert for a range and the reasons behind it, and write both down. Use judgment to challenge your numbers, not replace them.

Accuracy versus precision

John R. Schuyler, writing for PMI on expected value in decision analysis, separates accuracy from precision: a set of forecasts can cluster tightly and still be biased. For a freelancer, the lesson is practical. A tidy 74.0-hour total is not more trustworthy than "70 to 95 hours." What matters is whether your estimates run consistently high or low against actuals. Check that, and correct for it.

Combine methods: a workflow for freelancers

The US Government Accountability Office's cost estimating guide is written for large programs, but its logic scales down. It recommends cross-checking major cost elements with alternative methods, documenting assumptions, running sensitivity and risk analysis, and giving a confidence level rather than relying on a single point value. Here is how that looks on a freelance quote:

  1. Clarify the decision. Is the client choosing whether to proceed, setting a budget or comparing bids? The answer changes how detailed you need to be.
  2. Define scope. List deliverables, exclusions, assumptions, dependencies and the deadline.
  3. Build the WBS down to pieces you can reason about.
  4. Pick your data. Pull comparable past projects or unit rates from your own logs.
  5. Estimate each task bottom-up.
  6. Add risk ranges with three-point estimates on the uncertain tasks only.
  7. Cross-check the total with an analogous or parametric figure. If the two differ by more than about a quarter, find out why before quoting. That threshold is a rule of thumb, not a standard.
  8. Document the basis. Record assumptions, exclusions, formulas and sources so you or anyone else can reproduce the number.
  9. Agree change rules with the client in writing.
  10. Update the forecast as actuals arrive.

Separate effort from elapsed time

The same GAO-based workflow distinguishes hours of hands-on work from calendar duration. Review cycles, client decisions, holidays, parallel work and dependencies stretch the schedule without adding effort. A 74-hour project can take eight weeks if the client takes four days to approve each milestone. Quote both, and say which assumptions the calendar depends on. If you need a schedule next, our guide to creating a project timeline in 30 minutes picks up from here.

Contingency and scope changes

Contingency covers identified uncertainty and planned risk responses. It is not a bucket for unapproved extras. PMI's material on contingency and Monte Carlo simulation lists expert judgment, predetermined guidelines, Monte Carlo and other simulation, and parametric modeling among the agreed ways to estimate contingency. When the client asks for something new, the right response is a change decision with a revised estimate, not a quiet draw on your buffer. Our five-step scope creep control guide has templates for that conversation.

For larger or murkier engagements, expect wide early ranges. A PMI article cited in GAO's guidance gives plus or minus 50% as an example of probable outcomes for early large-project estimates when little is defined. That is an early-phase illustration, not a universal accuracy rule, but it explains why a firm fixed fee on vague scope is a gamble.

Our perspective

We talk with independent project managers and consultants every day, and the same pattern shows up: the quote is where margin is won or lost. Newer freelancers tend to under-quote because they price what they hope the work will take. Experienced ones sometimes over-engineer a model for a two-week job.

Our perspective — overview diagram

Our view is simple. Match the effort of estimating to the size of the decision. For small, repeat work, an analogous figure from your own logs and a short list of assumptions is enough. For anything over a few weeks, build the WBS, add ranges where you are unsure, cross-check, and write down the basis. Then price on the value of the outcome, not only on hours: estimates tell you cost to deliver, and your fee can reflect more than that. Our post on value-based pricing for freelance PMs and the one on negotiating fees with three packages cover that step.

The habit that separates professionals is closing the loop. Every finished project should feed the next estimate.

— Ashanti

Get help turning estimates into paid work

A good estimate only matters if you have clients to send it to. The Freelance PM Club combines curated freelance PM opportunities, courses, templates, coaching and a community of independent project managers. Membership starts with Job Board Access at $5 per month, with Freelancer Pro at $10 per month and Freelancer Elite at $20 per month. You can compare the tiers on the membership plans page, or look at coaching if you want someone to review your estimating approach with you.

Common estimating mistakes to avoid

  • Estimating before scope is written down. Every number depends on assumptions, and unwritten assumptions can't be defended.
  • Skipping non-delivery work. Meetings, reporting, onboarding and review rounds are real hours.
  • Using one method only. A second method is the cheapest insurance you have.
  • Narrow ranges. If best and worst cases are close, you probably anchored.
  • Never comparing to actuals. Without feedback you repeat the same bias.

FAQ

Which project estimation method is most accurate?

None is accurate in every situation. Bottom-up is generally more accurate than top-down when scope is well defined, but it takes longer and can miss work elements. Using bottom-up plus an analogous or parametric cross-check is the most defensible everyday approach.

What is the difference between bottom-up and top-down estimation?

Bottom-up adds up estimates for individual tasks or work packages to reach a total. Top-down starts with a total budget or time limit and divides it across the work. Use top-down to test whether a client's number is realistic, and bottom-up to build your own.

How do I use three-point estimation?

Estimate an optimistic, a most likely and a pessimistic value for a task. Then apply (a + 4m + b) / 6 for the PERT weighted result, or (a + m + b) / 3 for the triangular one. Set the best and worst bounds from named risks first, so your most likely value isn't just your original plan.

How should I handle changes after the estimate is accepted?

Treat them as scope changes. Agree in advance that new requests trigger a revised estimate or a separate change budget, and keep contingency for the risks you identified, not for extra requests.

Sources