How to estimate project costs before agreeing the budget

Estimate the resources required, not the price you hope to charge

Estimate project costs by breaking the proposed work into manageable tasks, estimating the effort for each role, multiplying that effort by internal cost rates, and adding project expenses and consistently allocated overhead. Record the assumptions and uncertainty with the total. The result should explain what delivery is likely to consume before anyone approves a budget.

Cost is not the client’s fee. A client billing rate may include profit and recovery of non-selling time; using it as a labor cost rate can distort the estimate. A cost estimate informs an approved internal budget and a separate pricing decision. It is not automatically a binding sales quote.

Atlassian distinguishes bottom-up estimation, which adds work-package estimates, from analogous estimates based on similar projects and three-point estimates that expose uncertainty. For small client projects, a task-level estimate with a few carefully examined uncertain items is often easier to maintain than an elaborate model.

Make a work list someone can challenge

Describe outputs first, then the work needed to make them acceptable. “Build an assessment” is too broad to review. Preparation, configuration, content entry, testing, revisions and handover let the person doing the work spot missing effort. Include client meetings and coordination when they consume delivery time, whether or not they are separately billable.

Keep effort and elapsed time separate. A client taking three working days to review a draft does not necessarily create three days of labor cost. It may still cause rebooking, extra coordination or another month of a dedicated subscription. Estimate those actual consequences instead of multiplying every waiting day by a full-day rate.

1. Write the proposed outputs, acceptance conditions, quantities and revision limits.
2. Break delivery into tasks with an accountable role and an effort unit, usually hours.
3. Ask the likely delivery people to estimate; compare with relevant completed work where available.
4. Attach cost rates, dated supplier quotes and project-specific purchases to the correct tasks.
5. Record exclusions, unknowns and what new information would require a revised estimate.

Choose a consistent labor and overhead basis

For employees, use an internal labor-cost basis that reflects the employment costs you intend to include. For subcontractors, use their expected charge to your business. For your own time, choose and label an internal compensation or replacement-cost assumption rather than assigning zero cost just because no hourly wage leaves the bank.

State whether the rate includes overhead. Either use a rate that already allocates the relevant shared costs, or add a separate allocation using a documented basis. Do not do both for the same expense. A project-only testing subscription belongs with direct expenses; the same subscription should not also appear in the shared overhead allocation.

Keep currencies and tax treatment consistent. The following fictional figures use dollars and exclude sales taxes and income taxes. They are management-planning assumptions, not tax deductions, employee-pay guidance or recommended freelance rates.

Worked bottom-up estimate: a small online assessment

Fictional consultant Amara is configuring a short assessment using an existing platform. The client supplies approved questions and branding. The scope includes one consolidated revision round, functional checks and a handover session; it excludes custom software, translation and recruitment of test participants.

Amara estimates 6 hours for requirements and setup, 18 for configuration, 8 for testing, 5 for revisions and 3 for handover. That is 40 hours. At an internal owner-labor cost of $45 per hour, labor is $1,800. This rate excludes overhead.

A specialist accessibility review costs $600, the project license costs $120, and the chosen overhead allocation is $200. These are separate from Amara’s hours and from each other. The initial bottom-up total is $1,800 + $600 + $120 + $200 = $2,720. No client selling price or profit allowance is included.

Use three points to examine the uncertain task

Configuration is the uncertain item. Amara records an optimistic 12 hours if existing components fit, a most likely 18 hours if ordinary adjustments are needed, and a pessimistic 30 hours if the supplied branching logic needs substantial correction. These describe the same scope under different conditions, not three different products.

For this estimate, Amara uses the common weighted three-point formula: (optimistic + 4 × most likely + pessimistic) ÷ 6. The result is (12 + 4 × 18 + 30) ÷ 6 = 19 hours. Replacing the original 18-hour task with 19 gives 41 total hours, not 59. Revised labor is $1,845 and the central cost estimate becomes $2,765.

Holding every other input fixed, the low configuration scenario gives 34 total hours and $2,450 total cost; the high scenario gives 52 hours and $3,260. This is a scenario range, not a confidence interval or a promise that the real result cannot exceed it. The weighted average is a planning convention, not measured certainty.

Separate uncertainty from missing scope

Do not apply a blanket contingency on top of pessimistic task estimates without explaining what extra risk it covers. In Amara’s example, the three-point treatment already addresses configuration variability. A further allowance for that same variability could count the risk twice.

Other assumptions can move independently. If the specialist quote rises by $180 while the central labor estimate stays unchanged, total cost becomes $2,945. If configuration problems also expand testing, the earlier high scenario is incomplete because it held testing fixed. Record that dependency and estimate the combined case rather than pretending task risks are isolated.

Unknown custom functionality is not merely a larger contingency. Clarify it, exclude it explicitly, or propose a bounded paid discovery phase before estimating implementation. A precise total cannot repair an undefined deliverable.

Hand over the estimate with its reasoning intact

Copyable estimate note: “Scope version: [reference]. Prepared on: [date]. Labor basis: [roles, hours and cost rates]. Other costs: [quotes and allocations]. Central estimate: [amount]. Scenario range: [amounts and conditions]. Exclusions: [items]. Unresolved assumptions: [items, owners and decision dates]. Refresh when: [trigger].”

Before approval, compare the task totals with a genuinely similar completed project and explain differences in complexity, tooling or review requirements. Check that supplier prices will still be valid when ordered. Round the communicated estimate to sensible precision rather than implying accuracy the inputs do not support.

Once a budget is approved, keep this original estimate. During delivery, update the forecast without rewriting the starting assumptions. Afterward, compare estimated and actual effort by task, identify the largest causes of variation, and use those observations in the next estimate. Better evidence is more useful than simply adding an unexplained percentage every time.