Proposal assumptions: the short list that protects your estimate

Every estimate rests on things you expect to be true: the client will send content on time, one person will approve changes, the logins will work. When one of them turns out to be false, the project costs more. If those expectations were never written down, you absorb the cost. This post shows how to list your assumptions, attach a trigger and a price to each, and calculate your exposure.

What an assumption is

An assumption is a condition that must hold for your estimate to be correct. It is different from scope. Scope says what you will deliver. Assumptions say what has to be true for you to deliver it at that price and time.

If you already write a clear scope statement and a statement of work, assumptions are the next layer. They cover the things neither document controls: what the client does, what exists already, and what stays the same.

Find your assumptions by looking at past projects

You probably already know your assumptions, even if you have never written them. Look at the last three projects that ran over and ask what went differently from the plan.

These sources are worth checking:

• Client inputs. Content, images, approvals or access arriving on time.
• People. Who gives feedback, and how many people are involved.
• Existing work. The condition of a site, a file or a system you are building on.
• Volume. The number of pages, items, revisions or meetings the estimate allows for.
• Timing. Start dates, review windows and fixed deadlines.

List each one as a plain sentence in the form "We have assumed that...".

Give each one a trigger and a price

An assumption without a consequence is only a wish. For each, state what happens if it turns out to be false.

Say the project is an 80-hour build at $100 an hour, so the price is 80 x 100 = $8,000. Your assumptions might look like this:

• Content arrives by day 10. If it is late, rescheduling and restarting costs 4 hours, which is $400.
• Two revision rounds. Each extra round is 6 hours, which is $600.
• One person consolidates all feedback. If several people send separate comments, add 5 hours, which is $500.
• Hosting access is supplied on day one. If not, add 3 hours for setup and chasing, which is $300.

The hours here are examples. Use your own figures from past projects.

Add up your exposure

Total the hours if every assumption broke: 4 + 6 + 5 + 3 = 18 hours. At $100 an hour, that is $1,800.

As a share of the project price, 1,800 / 8,000 = 0.225, or 22.5%. In this example, a project with four unwritten assumptions could lose nearly a quarter of its price if everything went wrong.

That is the worst case, and it is unlikely all four happen. The point is to see the size of the risk. If the exposure is high for a small project, either reduce it by clarifying the assumptions or price some of it in.

Write them into the proposal

Put the assumptions in a short section near the end of the proposal, right after the scope. Keep each item to one or two lines.

Introduce the list in a friendly way: "To keep the schedule and price as quoted, we have assumed the following. If any change, we will let you know and agree the next step before going ahead."

That sentence matters. It makes the list a shared plan, not a trap. It also commits you to speak up early, instead of raising the issue only on the final invoice.

Use them during the project

Assumptions are only useful if you check them. When one breaks, respond as soon as you notice, in writing, and quote the line from the proposal.

• Name the assumption. "We assumed content by day 10."
• State what happened. "It arrived on day 17."
• Offer options. Move the end date, pay for the extra time, or reduce something else.

For late content in particular, see what to do when a client goes quiet mid-project. For extra revision rounds, see handling feedback rounds without endless revisions.

When the request is new work, not a broken assumption, use the approach in how to say no to out-of-scope requests.

Improve your estimates over time

After each project, review which assumptions broke and what they cost. Add the common ones to your template and remove those that never matter. Over several projects, your list becomes a sharper picture of where your estimates fail, which also helps when you estimate hours without guessing.

HireOrSell can record actual time against projects and milestones on its paid plans, which makes it easier to see which stage ran over. Check the pricing page for current plan details. A simple spreadsheet works too.

This post is general information, not legal advice. Have a qualified person review the wording of any clause you add to a contract.

Next step

Pull up your last project that ran over and write down the three things that went differently from your plan. Turn each into an assumption with a trigger and a price in hours. Add them to your proposal template, and use the template on your next quote.