How to cost a project before you quote: hours, rates and extras

Most quotes go wrong in the same place. The scope is understood, the team is capable, and the number at the bottom of the page is still short by a third. The gap is almost never in the work that was listed. It sits in the hours nobody wrote down, the rate that was copied from last year, and the extras that arrive after the client signs. Costing a project means closing those three gaps before the number leaves the building.

Turn scope into hours somebody will actually work

A cost estimate that starts from a price is a guess dressed up as arithmetic. Start from hours instead, and the price becomes a consequence.

Break the scope into deliverables small enough that one person can own each one. The useful size is a piece of work that takes between four hours and three days. Anything larger hides its own uncertainty: a line item called "design phase, 120 hours" carries no information about which part of it will overrun. Anything smaller turns the estimate into administration.

For each item, ask the person who will do the work how long it takes, then ask a second question that matters more: how long it takes including the parts that are not the work. Review cycles, waiting for an answer, setting up an environment, writing the handover note. On most professional services projects these non-production hours are a large share of the total, and they are the first thing a fast estimate leaves out.

Then add the hours that belong to nobody in particular. Someone runs the kickoff. Someone answers the client on Thursday afternoon. Someone writes the status report. Project management time is real labour and belongs in the estimate as a line, not as a vague uplift. A common practice is to carry it as a percentage of production hours, and the percentage is worth measuring from past projects rather than inheriting from a template.

Finally, check the calendar against the hours. Two hundred hours of work does not fit into a two week window with one person, no matter how the spreadsheet adds up. Availability is part of the cost, because compressing a schedule usually means paying for overtime, for a second pair of hands, or for the rework that speed produces.

One more habit is worth building into the method: write down the assumptions next to the hours, in the same document. An estimate of sixty hours for a data migration means something entirely different if it assumes clean source data than if it assumes the team will clean it. When the assumption is recorded beside the figure, a scope change becomes visible immediately, because the assumption stops being true before the hours run out. Quotes that carry their assumptions are also far easier to defend six weeks later, when the conversation has moved on and nobody remembers what was agreed.

Build a rate that survives the year

There are two rates in every quote, and confusing them is the most expensive mistake in this whole exercise. The cost rate is what an hour of that person costs the business. The billing rate is what the client pays. Margin lives in the difference, and margin cannot be defended if the cost rate is wrong.

The cost rate starts with salary, then adds everything that comes with employing somebody: statutory contributions, insurance, equipment, software seats, the share of rent and administration that the role consumes. The result is meaningfully higher than salary divided by hours.

The denominator matters just as much. A full time year at forty hours a week is 2,080 hours on paper, but nobody bills 2,080 hours. Subtract holidays, sick days, training, internal meetings, sales support and the weeks between projects. What remains is billable capacity, and dividing fully loaded cost by billable capacity rather than by paper hours is what separates a rate that holds up from one that quietly loses money on every engagement.

Contractors look simpler because the invoice is the cost, but they carry their own hidden weight. Onboarding time, the hours an internal person spends briefing and reviewing, and the risk that the engagement ends early all belong somewhere in the number.

A blended rate is convenient for a proposal and dangerous for an estimate. Blending assumes a mix of seniority, and the mix on a real project drifts toward the senior end when things get difficult. Estimate with role-level rates, present a blended figure if the client prefers one, and keep the role-level version for the internal review.

Pick an estimating method that matches what is known

Three methods cover almost every situation, and the honest choice depends on how much history exists.

Method	What it needs	Speed	Where it fails
Analogous	A finished project of similar shape	Fast	The comparison project was not as similar as remembered
Parametric	A measured rate per unit, such as hours per screen	Fast	The unit stops being comparable as scope gets unusual
Bottom-up	A full task breakdown with owners	Slow	Missing tasks, and false confidence from detail

Analogous estimating compares the new work to something already delivered. It is quick and surprisingly accurate inside a narrow band of repeat work. It fails the moment the new project differs in a way that was not obvious at the start.

Parametric estimating multiplies a measured rate by a count of units. Hours per page, hours per data source, hours per store location. It works when the unit is genuinely stable, and stability has to be measured rather than assumed.

Bottom-up estimating adds up the task list. It is the most defensible and the most laborious, and its weakness is not arithmetic but omission. A detailed estimate feels authoritative even when a whole category of work is missing from it.

For any task where the range is wide, a three point estimate is worth the extra two minutes. Take an optimistic figure, a most likely figure and a pessimistic figure, then weight them as (optimistic + 4 times most likely + pessimistic) divided by 6. The value is less in the number than in the conversation: asking for the pessimistic case out loud surfaces the risk that a single figure hides.

Price the extras before they arrive

The line items that wreck margin are rarely the ones in the scope document.

Pass-through costs. Stock imagery, cloud hosting during the build, printing, travel, testing devices, translation. These are usually known and usually forgotten. List them explicitly, note whether they are marked up, and say who pays if a third party raises a price mid-project.

Tools and seats. A project that needs a seat in three separate products for six people is a real monthly cost, and it repeats for the length of the engagement. This is worth checking before quoting rather than after, because per-seat pricing across several tools compounds quickly. It is also one of the few costs that can be removed by consolidating rather than negotiating, which is why the features a team already has access to affect the cost of the next project.

Rework. Every delivery model produces some. Pretending otherwise does not remove the hours, it just moves them out of the estimate and into the margin. Carry rework as an explicit allowance and tie it to the number of review rounds included.

Waiting. When a client owes content, an approval or access to a system, the team does not stop costing money. Idle time is a genuine cost and belongs in the assumptions: a quote can state how many business days of client response are assumed, and what happens beyond that.

Warranty and handover. Support after delivery, documentation, a training session, a bug fix window. If this is included, it needs hours. If it is not, the proposal should say so in a sentence the client will read.

Treat contingency as a decision, not a habit

A flat ten percent added to the bottom of every quote is not contingency. It is a superstition that happens to be arithmetic.

Contingency covers identified risk that has a probability attached. The disciplined version is short: list the three or four things most likely to go wrong, estimate the hours each would cost if it happened, assign a rough likelihood, and carry the weighted total. A dependency on a third party integration that would cost forty hours to work around and looks maybe fifty percent likely contributes twenty hours. That is a number with a reason behind it, which means it can be defended in a review and reduced by actually managing the risk.

Keep contingency separate from margin in the internal view. When the two are blended, the first difficult conversation about price eats the buffer without anybody deciding to spend it. Keep it separate and the question becomes explicit: is this discount coming out of profit, or out of the reserve set aside for a risk that has not gone away?

Padding individual tasks is the alternative most teams reach for, and it backfires twice. Padded tasks expand to fill the time available, and a padded estimate cannot be compared against actuals afterwards, so the organisation learns nothing from the project it just delivered.

A short note on discounts, since they interact with everything above. A discount granted at the top level is fine as a commercial decision, but it should never be pushed down into the hours. Reducing the estimate to reach a target price converts a costing exercise into a negotiation with the estimate itself, and the team still needs the hours the work requires. Hold the hours, hold the rate, and adjust scope or margin explicitly instead. A client who sees which deliverable came out to reach the number is better informed than one who receives the same scope for less and wonders what changed.

Check the estimate against reality while the work runs

An estimate is a hypothesis. It only becomes knowledge if hours are recorded against the same structure that was used to quote.

This is the step that decides whether the next quote is better than this one. If the proposal was built from eleven deliverables and the time records come back as one bucket called "project", there is nothing to learn. If the hours land against the same eleven items, the pattern shows up within two weeks: design ran twenty percent over, integration was fine, review cycles took double what anyone assumed.

The recording has to be easy enough that people do it while the memory is fresh. Weekly entry at a coarse grain, half hour steps against a project and a work type, gets filled in. Precise entry that demands ten fields per row does not, and a timesheet nobody completes is worse than none, because it produces confident numbers that are wrong.

Two checks are worth running while the project is live. Compare hours consumed against percentage of scope delivered, not against calendar time, because a project can be on schedule and forty percent over budget at the same time. And watch the ratio of non-production to production hours, since that is where overruns usually start.

Contractor hours deserve the same structure. Where invoicing depends on recorded time, the record needs to be something both sides can see and agree on before the invoice is raised, which is a different requirement from internal reporting. Tools differ a great deal in whether time tracking is included or sold separately, and the pricing page of any candidate is the place to check how the count is made before adding it to a project cost.

What to change first

Pick the last three finished projects and compare quoted hours to recorded hours, per deliverable rather than per project. The category that overran most is the number to fix in the next estimate, and it is usually review cycles or project management time rather than the production work everybody argued about.

Then make sure the next project records hours against the same breakdown used to quote it. Keeping the estimate, the board and the time record in one place is what turns a single project into data, and Pinateca is one way to hold all three without adding another seat to pay for.

Q1. How much contingency should a project quote include?

There is no correct percentage, and a flat uplift applied to every quote is a habit rather than an estimate. List the three or four specific risks, estimate the hours each would cost if it occurred, weight them by rough likelihood, and carry that total. Keep it separate from margin so that a discount does not silently consume it.

Q2. What is the difference between a cost rate and a billing rate?

The cost rate is what an hour of a person costs the business, including statutory contributions, equipment, software and overhead, divided by realistic billable hours rather than paper hours. The billing rate is what the client pays. Margin is the gap, and it cannot be managed if the cost rate is calculated from salary alone.

Q3. Should project management time be a line item or a percentage?

Either works, but it must appear somewhere. A percentage of production hours is easier to quote and should be measured from past projects rather than copied from a template. A line item is easier to defend when a client questions it. Leaving it out entirely is the common error, and it is rarely a small amount.

Q4. How do you cost a project with no similar past work to compare against?

Break the scope into pieces small enough to reason about, use three point estimates on the items with the widest range, and state the assumptions in the proposal so the boundaries of the number are visible. Then record hours against those same pieces during delivery, so the second project of that kind has history to work from.