What assumptions / disclaimers should be included with a software estimate?

Question

I'm writing a lot of estimates lately and I'm finding that quite often, a client might argue scope, deliverables or (most often) cost.

In an effort to ensure that the breadth of coverage (of client requirements and mutually understood scope) for the estimate is clear (and given most clients will view an estimate as a fixed quote from Moses himself), what common assumptions do you include with your estimates such that expectations are clearly set with clients and disagreements around what is being delivered or charged are minimised?

Answer 1

1. Agree on clear, specific requirements with the customer.
2. Agree on what constitutes meeting each requirement, in a way that is clear, measurable and unambiguous (i.e. it passes an acceptance test).
3. As part of your internal estimation process, break down all of the required work into smaller sub-tasks. Keep doing that until you have tasks that are small enough to accurately estimate. Add up all of the smaller estimates for a total time and money estimate. Make sure that you include the time it will take to write unit tests, acceptance tests and refactoring.
4. Add at least 20% padding to your resulting time estimate calculation.
5. Make it clear in the estimate that work beyond the scope of #2 above is not part of the estimate, and will cost extra.

Answer 2

what common assumptions do you include with your estimates

Every single "fact" provided by the customer is listed as an assumption.

Those are the common assumptions.

Everything else is just fluff. You can write down lots of fluffy things like you assume that plague doesn't break out, and zombies don't arise and eat our brains, but none of that makes any sense to a customer.

Taking their "facts" about the development effort, and relabeling each "fact" as an assumption makes it clear that everything is fanciful.

Then.

Study up on Agile methods and be sure to identify that -- really -- it's a matter of priorities and budget. You'll build things from most important to least important and they can stop you at any time.

---

There are several -- irreconcilably different -- "intents" for an estimate.

1. It could be a firm, fixed price that will establish an upper limit on the budget and a lower limit on delivered functionality.

2. It could be a ballpark price used to reverse engineer an hourly rate used to qualify you as a resource.

3. It could be a cost number that goes into a cost/benefit decision.

Until you know what the "intent" is, the nature of the assumptions will vary. There's no single right answer until you actually define the customer's intent.

Answer 3

Well, most clients will view an estimate with a host of disclaimers as an estimate from Moses himself plus a bunch of irrelevant noise, but I can give you some suggestions (and I'm sure there are lots of legal ones I don't know about):

1. You are assuming the client will give you what you need, depending on the project. If they can't answer your questions promptly, give you needed network access, test system, test data - whatever, then at minimum the schedule slip is their fault.

2. Well, obviously you have some agreed on work that you are doing for that estimate. You are assuming that work doesn't get changed or added to.

3. You are assuming that the product will not be bug free. If it passes the agreed upon acceptance tests then you are done.

4. If there are pictures or mock-ups, you are assuming they don't require the product to look exactly like those pictures or mock-ups.

5. When you estimated there were probably lots of assumptions specific to the project that should be spelled out. Like the user interface elements will be drawn from the .NET standard library and will not have to be customized or used outside of industry standard uses for the project.

Answer 4

How about an estimate is an approximation and cannot be entirely accurate?

Or how about error range +%150/-%10? :p

Answer 5

There have been several questions on this site about delivering code and not getting paid. Make it very clear that they can assume if they don't pay you, code will not be delivered in a usable format. Any attempt to use the code without payment is a breach of contract. You should be upfront about any technology you plan on implementing to achieve this.

The other details can come from some standard agreement or whatever the client will let you get away with.

Answer 6

The best assumption is, assume tne estimate is way off. Software development is too complicated to estimate more than about two or three weeks out. At least, if your're creating something new.

If you're estimating making your 100'th website off of the same template, perhaps you can extend that out a bit.

Answer 7

It should go without saying that they should sign a Limitation of Liability... you don't want to be in a situation where you risk potentially millions of dollars of damages due to "lost profits" or "consequential damages" in exchange for a $5000 project.