How to estimate how long a project will take

By SoloWOS teamPublished October 19, 2026

IN SHORT

Estimate a project by splitting it into tasks, giving each an optimistic, likely and pessimistic time, and using (O + 4L + P) ÷ 6 per task. Add 10% to 20% for client communication and revisions, then check the total against tracked hours from similar jobs. People underestimate their own work, so trust past data over memory.

Prices and limits as of October 26, 2026.

Key takeaways

Break the project into tasks small enough to estimate, ideally under 2 days each.
The three-point (PERT) estimate per task is (optimistic + 4 × most likely + pessimistic) ÷ 6; a simple average of the three is a more cautious alternative.
In the worked example, six tasks with 49 most-likely hours give a 52.3-hour PERT estimate, and 60 hours once communication is added.
In a 1994 study, students predicted their theses would take 33.9 days on average; they took 55.5. Your tracked hours from past jobs correct for that.

Every quote and every timeline starts with an estimate, and most estimates are a single number someone felt was right. This guide replaces the feeling with a method you can show your work for. It is part of the time and projects hub; how to price a freelance project covers turning the hours into a price.

Why estimates come out short

People are optimistic about their own tasks, even when they know their past ones ran late. In the study that named the planning fallacy, Buehler, Griffin and Ross (1994) asked 37 students when they'd finish their honors theses: the average prediction was 33.9 days, the average actual was 55.5, and only about 30% finished by the date they predicted. Thinking about how similar past projects actually went reduced the bias. For a freelancer, that past is your tracked time.

Step by step

List the deliverables from the brief or proposal.
Break each deliverable into tasks you could finish in under 2 days. "Website" can't be estimated; "wireframes for 5 pages" can.
For each task, write three numbers: optimistic (everything goes right), most likely, and pessimistic (the realistic bad case, not a disaster).
Compute the expected hours per task: (O + 4 × L + P) ÷ 6. Add the tasks up.
Add client communication and revisions as their own line, typically 10% to 20% of the total.
Compare the total with the tracked hours of your last two or three similar projects. If they disagree, believe the tracked hours.
Convert to business days at the hours per day you really give this client, and build the timeline.

The three-point formula

Three-point estimating comes from PERT, developed for the US Navy's Polaris program and published by Malcolm, Roseboom, Clark and Fazar in 1959. The weighted version gives the most likely value four times the weight of each extreme: E = (O + 4L + P) ÷ 6, with a spread of roughly (P − O) ÷ 6. A simple average, (O + L + P) ÷ 3, gives the pessimistic case more pull and suits tasks you have never done before. The GAO's Cost Estimating and Assessment Guide uses minimum, most likely and maximum values per element in the same way, typically modelled as triangular distributions.

Worked example: a 6-page small business website. Hours per task.
Task	Optimistic	Most likely	Pessimistic	PERT estimate
Discovery and sitemap	3	4	8	4.5
Wireframes	4	6	10	6.3
Visual design	8	12	20	12.7
Build	14	20	32	21.0
Content entry	3	4	8	4.5
QA and launch	2	3	6	3.3
Total	34	49	84	52.3

WORKED EXAMPLE

From 52.3 hours to a quote

PERT total: 52.3 hours. Add 15% for client communication and revisions: 52.3 × 1.15 = 60.2, call it 60 hours. Check against history: your last two similar sites took 58 and 63 tracked hours, so 60 holds. At a $90 target rate, the price is 60 × $90 = $5,400. At about 5 focused hours a day for this client, the work is 12 business days before review rounds are added.

Note what the single most-likely number would have said: 49 hours, or $4,410 at $90. The extra 11 hours come from the pessimistic tails and the communication line, which is exactly where real projects overrun. The project cost calculator takes hours per phase plus a buffer and shows the effective rate after discounts and expenses.

How much padding is reasonable?

Padding by how well you know the work. Apply it to the PERT total, not to every task.
Situation	Communication and revisions line	Extra contingency
Repeat work for a repeat client	10%	None
Familiar work, new client	15%	None to 10%
New type of work or unclear brief	20%	10% to 20%, or quote discovery separately
Many stakeholders on the client side	20% or more	Add a review round

Padding every task and then the total double-counts. Put the uncertainty in the pessimistic numbers and the communication line, and if the brief is too vague to estimate at all, sell a short paid discovery phase first and quote the rest afterward.

Use your own data

Estimates get good when you compare them with what happened. Track every project, fixed-price included, with the same task names you estimated with; tracking time on fixed-price projects shows how a 30-hour estimate became 43 hours and what to change. After a few projects, divide actual by estimated hours: that ratio is your personal correction factor. Then turn the hours into dates with a client project timeline.

In SoloWOS

When you track billable hours, name entries after the tasks in your estimate. Time Tracking > Reports for a finished project's dates shows hours by project, and the CSV export lists every entry with its description, so you can total each task and compare it with the estimate. Put the final estimate in the proposal's pricing so the client accepts the proposal online with the scope it was built on.

Questions

What is the PERT formula?

Expected time = (optimistic + 4 × most likely + pessimistic) ÷ 6. For a task estimated at 8, 12 and 20 hours, that is (8 + 48 + 20) ÷ 6 = 12.7 hours. The standard deviation is roughly (pessimistic − optimistic) ÷ 6, here 2 hours.

Is three-point estimating worth it for small projects?

For a project under about 10 hours, a single honest estimate checked against a similar past job is usually enough. Three-point estimates pay off on projects with several phases or work you haven't done before, where one surprise can double a task.

Should I tell the client my estimate in hours?

On hourly work, yes: give a range, such as 55 to 65 hours, and say what would push it higher. On fixed-price work, give the price and the scope; the hours are your internal working.

How do I estimate work I've never done before?

Break it into the smallest tasks you can, use a wide pessimistic number, and prefer the simple average (O + L + P) ÷ 3 over the weighted PERT formula. If you still can't estimate it, sell a paid discovery or prototype phase first.

Sources

Facts checked against these sources on October 18, 2026. Rules and amounts change, so confirm them at the source before you file or sign.

Last reviewed: October 18, 2026

SoloWOS tools mentioned here

Run your client work from one account

14 days free, no card needed · Then Basic for $2/month.

Start your free trial