6

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?

Phil.Wheeler
  • 1,298
  • 3
  • 12
  • 20
  • "intent behind an estimate is clear"? What is the intent? Can you be more specific? I find that estimates are political creatures and the intent is often shrouded in mystery. Can you explain what you mean? – S.Lott Oct 06 '11 at 21:04
  • Essentially, I'm trying to say that I want the estimate to be very explicit about what functionality, UI, etc has been factored into the delivery time/cost and what is being assumed for any cases or factors that are not specifically included. – Phil.Wheeler Oct 06 '11 at 21:11
  • 2
    Possible duplicate: [How to respond when you are asked for an estimate?](http://programmers.stackexchange.com/questions/648/how-to-respond-when-you-are-asked-for-an-estimate) –  Oct 06 '11 at 21:28
  • I read that possible duplicate question, but felt it was asking about the estimate creation process and what should be included in one. Most answers on that question say "you should include your assumptions". They don't actually say what assumptions are generally included. – Phil.Wheeler Oct 06 '11 at 21:38
  • "I want the estimate to be very explicit about what functionality". That's what the question appeared to imply. That, however, does not touch on "intent behind an estimate" at all. What do you think "intent behind an estimate" means? Can you define this, please? [I'm not being dismissive of your question. I already asked once, and I'm aware that this is tending toward the forbidden "extended discussion". If you don't want to define your terms, that's okay.] – S.Lott Oct 06 '11 at 23:43
  • Rephrased. Does that improve the question? – Phil.Wheeler Oct 07 '11 at 00:44

7 Answers7

7
  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.
Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • Really?! You would not include unit tests / UAT tests as part of the estimate and then tell the client you'll be charging them for it all the same? – Phil.Wheeler Oct 06 '11 at 22:40
  • That said, including an assumption that work beyond the scope defined in the requirements and explicity itemised on the estimate is probably a good idea. – Phil.Wheeler Oct 06 '11 at 22:41
  • What? No, I specifically stated that unit tests and acceptance tests are part of the time and cost estimate. The customer doesn't have to know about every little detail of your inner workings; they just need to know how much it's going to cost. – Robert Harvey Oct 06 '11 at 22:41
  • 3
    You break down the required work yourself so that you can give an accurate estimate; you don't necessarily specify all of that detail on the estimate. – Robert Harvey Oct 06 '11 at 22:47
5

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.

S.Lott
  • 45,264
  • 6
  • 90
  • 154
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.

psr
  • 12,846
  • 5
  • 39
  • 67
1

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

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

Dominique McDonnell
  • 1,273
  • 11
  • 14
  • Despite the author's grin, it is a useful point to make that scope creep never makes a project smaller. Also, most people are pretty ineffective at writing (or reading!) scope documents so there is no reasonable chance that you are going to have well defined specs. For that matter, agile methodologies proceed on the assumption that you have no real specs to begin with at all - just a vague idea of where you want to go, a grasp on what constitutes a reasonable small scale deliverable, and the discipline to stop spending when your product is good enough. – Joel Brown Oct 07 '11 at 00:25
1

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.

JeffO
  • 36,816
  • 2
  • 57
  • 124
0

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.

Bryan Oakley
  • 25,192
  • 5
  • 64
  • 89
0

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.

JoelFan
  • 7,025
  • 4
  • 38
  • 53