How We Estimate a Project Before Anyone Signs

Nobody enjoys writing an estimate and everybody has been burned by one. The arithmetic is rarely the problem. The problem is that an estimate is a prediction about work that has not been decomposed yet, is published with a number attached, and is then remembered as a commitment rather than as a hypothesis.

So here is how estimation works at SmartEdge IT Solutions before anything is signed: what goes into the number, what we deliberately leave out of it, and how we handle the near-certainty that it will be wrong in some direction nobody could have predicted.

An estimate is a list of assumptions with numbers attached

The first thing we produce is not a number. It is a short list of statements of the form “this holds, and this is what it implies”. Most of them are dull. The entire value of an estimate is that its assumptions are visible, so that when reality differs, the difference has a name and can be discussed without anybody losing face.

A list from a recent style of project looks roughly like this:

• The existing data can be exported in a usable format and does not need cleansing beyond normalisation.
• One named person can make decisions within a working day, and is contactable during UK business hours.
• No third-party system needs to change. Where it does, that work sits outside this estimate.
• Designs exist, or are produced by somebody else and delivered as finished assets.
• Copy, images and product data are supplied by you. We do not write or source them unless that is a line item.
• Staging and production environments exist, or their setup is included as a separate item.
• Acceptance criteria are what we both believe them to be at the point of signing.
• Nothing is added mid-project without being discussed first, in the same way it was scoped.

None of these are conditions we invent to protect ourselves. They are the things that, when they turn out to be false, generate most of the overrun. Naming them converts an argument about whether the price was fair into a short conversation about which premise failed.

Decompose before you price anything

A single figure for “build a customer portal” is not an estimate. It is a mood. Before any hours are counted, the work is broken into deliverables, then into tasks that somebody could pick up and finish. Only then do we size them.

The part most estimates omit is everything that is not writing code. On a typical build that is a substantial share of the effort:

• Analysis, workshops and the documentation that follows them.
• Design, or the review of a design produced elsewhere.
• Data extraction, transformation, import and verification.
• Testing, including on real devices and with realistic data volumes.
• Environments, deployment pipelines and the release process itself.
• Project management and the stakeholder meetings that go with it.
• Handover: documentation, training, and the first period of fixing your own team’s mistakes.
• Content of any kind, if it was not going to be supplied.

One item on that list deserves emphasis: time spent waiting for other people. Waiting on a design, a content sign-off, API access, a decision or a third party’s test environment. It is not padding to include it, and an estimate that assumes instantaneous answers from a busy client is an estimate that will be wrong.

A range, its conditions, and how confident we are

We publish three things rather than one. A range, which reflects genuine uncertainty in the areas that are uncertain. The conditions under which that range holds, drawn from the assumptions list. And a plain-language statement of confidence per area, naming where the risk actually sits.

The confidence note usually reads something like: comfortable on the application work, because we have done this shape many times; cautious on the third-party integration, because we have not seen that partner’s API documentation; and unable to price the data migration at all until somebody has looked at the source.

That is more useful to a client than a figure with a decimal place, because it tells you where to spend your own attention. A number pretending to be precise invites anchoring — the first figure you see becomes the number you argue about, regardless of what the document says underneath it.

Where the contingency goes

Some slack is real and should be somewhere visible. Some is imaginary, and padding every line hides accountability: if every task is overstated, nobody can say which line absorbed the overrun, and the overrun becomes a general argument rather than a specific lesson.

Our preference is to hold contingency in named buckets at the estimate level rather than distributed through the lines:

• Unknowns about the existing system — code without documentation, data nobody has looked at, infrastructure nobody owns.
• Unknown third parties — slow responses, sandbox access that takes a fortnight, undocumented APIs.
• Unknown content and data volume — a site with forty items behaves differently from one with forty thousand.
• Unknown performance or compliance requirements — these often arrive late and are rarely small.

Where a bucket is large enough to worry us, we would rather spend a short technical spike investigating it than carry the unknown into delivery. That is often the whole argument for a scoping or consulting phase before a build quote: two days spent finding out the answer is cheaper than two weeks of contingency covering it.

Fixed price, time and materials, or phased

Three commercial models, and the honest answer is that the choice should follow how well the work is understood rather than which one sounds safer.

Fixed price moves delivery risk onto the supplier. It suits work with a stable, testable scope. It is priced higher than the same work done on an hourly basis, because somebody is carrying the downside, and it requires a formal change process because any variation has to be paid for by someone.

Time and materials moves risk onto the client, but gives full visibility: you see the hours, who spent them and on what. It works when you have the appetite and the internal discipline to steer scope, because nothing stops it growing.

Phased — a fixed first phase with a defined deliverable, then a decision point, then a fixed-price build for what is now known — is usually the right answer for anything with genuine unknowns. It costs more in project management than a single phase, and it is the model we recommend most often.

What we decline is a fixed price on undefined work. It can be agreed, it is frequently agreed, and it produces a relationship where the supplier wants the work to end early. Naming that mechanism is more useful than pretending it does not exist.

Estimates go out of date, and that is not a failure

Every estimate carries a validity date, and we would rather say so than let it sit. It expires because assumptions become facts, and some of them stop being true in week three.

So the estimate document also lists what triggers a re-estimate, agreed before signing rather than invented afterwards. The usual ones: a definition changes from what was written; an assumption proves false; a third party changes their timeline or their API; a stated deadline moves; or a new regulatory or internal requirement appears.

When a trigger fires, the work is restated and the difference is explained. What matters is the framing: the estimate was a hypothesis that has been tested, and the answer moved. That is not a failure by either side. The failure mode is the opposite — a number that is quietly out of date, that everyone knows is out of date, and that nobody is willing to raise because raising it feels like an argument. We have seen projects run for months in exactly that state, and the cost is much higher than the conversation would have been.

Change requests without blame

Every project gets changes. Some were always going to happen and were not in the original scope; some were in scope and got lost in a long document. The distinction matters, and blurring it is what turns a normal project into an argumentative one.

If a change arises because an assumption proved false, that is not a change request. It is the estimate being wrong, and it should be priced and handled as exactly that. If it is genuinely new work that nobody asked for, it is a change request and it gets a description, a reason, an effort, a schedule effect and a decision — recorded once, in one place, visible to both sides. That single habit prevents the majority of the arguments we have been called in to settle.

Our process page describes how that sits alongside delivery, and DevOps consulting is where we often get involved specifically to make releases small enough that the question rarely arises.

Warning signs in an estimate you did not write

Having read a lot of these from both directions, these are the things that make us cautious:

• One number, no range, no conditions.
• Effort quoted in hours before anybody has described the work as tasks.
• No exclusions list. If nothing is excluded, nothing has been examined.
• No assumption about who makes decisions or how fast.
• Cost and timeline presented as two separate certainties, as though they were independent.
• “As required”, “TBC” or “negotiable” appearing in a scope section.
• Nothing at all about data, content, documentation or handover.
• A fixed price attached to work that was still vague when it was signed.
• Large stretches of text that read like a template with a name substituted.
• An estimate produced the same day as the first conversation.
• Pressure to start before the estimate has been read by anyone who will be accountable for it.

The last two are the ones worth weighing most heavily, and they often come from the same place. An estimate produced in a hurry is not usually dishonest — it is usually a decision to win the work and sort out the detail later, which transfers a specific amount of pain to a specific person on the client side. When SmartEdge IT Solutions sends a proposal, the assumptions and exclusions travel with it rather than living in a separate document, because an estimate without them is a sales tactic rather than an engineering artefact.

Where a paid spike is the honest answer

Some work cannot be estimated responsibly until somebody investigates. Old codebases nobody can build reliably, integrations with an undocumented partner, machine-learning or AI features where the achievable quality is unknown until it is tried, and data migrations from a system with no current owner all fall into this group. For those, the correct first purchase is a short piece of work with a defined question and a written answer — not a build quote with a large contingency.

Our legacy software modernisation and AI integration work are the two areas where we most often recommend it, and in both cases the spike usually reduces the eventual estimate rather than adding to it, because the unknown gets replaced by a number.

What a good proposal should always contain, whichever firm you are talking to: the deliverables, the assumptions, the exclusions, the milestones, what we need from you and when, the commercial model, and what happens when something changes. If one of those is missing, that is a reasonable thing to ask for before signing. Our terms and conditions are public, and we would rather be compared on the detail than on a headline figure.