0

The title says it all really. If asked to produce an estimate for a project when is still very unclear what the system is, what do you do? Would you refuse to provide an estimate? Or inflate it massively? On this occasion it doesn't appear I'll have the opportunity to obtain clarity around the system.

marked as duplicate by Christophe, Doc Brown, gnat, Dan Pichelman, Becuzz Nov 12 '18 at 22:10

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • What is the purpose of the estimate? Will you have to commit to it? What is the consequences for you when the estimate is off? If you have to commit to it, just refuse. If the estimate is just informational and the audience understands how the estimate is a guess, just provide an honest best guess using large units, e.g, "1-2 years for a medium size team." – JacquesB Nov 12 '18 at 18:03
  • 1
    Possibly related: Estimating time costs in legacy codebase – Dan Pichelman Nov 12 '18 at 19:23
3

Many years ago, a drinking buddy of mine gave me some wisdom.

At the start of any project, before committing to anything, you need the answers to three questions:

  1. What is the problem we are trying to solve?
  2. What are the deliverables?
  3. How will we know we are finished?

If the answers to ALL THREE of these questions are not known, written down, and agreed upon by all parties, then the ONLY thing you can and should do is work to get the answers known, written down, and agreed. In particular, without those three answers, you cannot give any kind of estimate.

  • "...the only thing you can and should..." I agree with the can part under any circumstances. The should part depends on the circumstances. In a full-time salaried circumstances the should holds. In a freelancer circumstances should depends on the amount of effort. Example: it takes 40 hours over the course of 2 weeks to clarify, write down, agree the problem, deliverables, definition of done. Suck work is serious engineering akin to systems analysis. Should the customer pay for it? Should the freelancer do it free of charge? – Nick Alexeev Nov 12 '18 at 22:08
  • @NickAlexeev, the customer is the only one who knows the answers to the three questions, and it is quite possible that the customer hasn't figured them out yet. In a salaried environment, working with the customer to get those answers is of course legitimately billable time. In a freelance environment, the first thing the freelancer must do is send the customer a (possibly boilerplate) letter laying out the three questions, and, POTENTIALLY, offering to assist in their resolution on a straight up time-and-materials basis. (Continued on next comment.) – John R. Strohm Nov 12 '18 at 23:01
  • @NickAlexeev, in such a letter, the freelancer would answer the questions, as "1. Determine the detailed scope and goal(s) of the proposed project, in the form of written agreed-upon answers to the three questions. 2. Determine the deliverables for the project, in the form of a detailed list, again written and agreed-upon. 3. Determine, write down, and agree upon the completion criteria." – John R. Strohm Nov 12 '18 at 23:03
  • @NickAlexeev, should the customer decline to retain the freelancer for the proposed time-and-materials effort, the freelancer MUST decline to estimate the original project. This may mean that the freelancer had better have another customer on the hook, or have resources to take a short-notice vacation. That's part of the price of doing business as a freelancer. – John R. Strohm Nov 12 '18 at 23:05
  • Ask "What confidence level should we target for estimations? We can start estimating after you let us know". Make them aware that a high confidence level means large estimates and a lower confidence level means a high chance of being wrong. – David Plumpton Nov 13 '18 at 0:28
3

You can't. Someone is going to get burned, and probably, you.

I arranged with my clients to work for time and expenses to write the software spec, a process that included interviewing the project manager and others who had applicable information, and revising it spec until we all agreed that it described what they wanted. It would have been at this point that I'd have priced and signed a contract with them.

(Although, since my contracts were largely R&D contracts, most managers actually preferred to engage me for T&E, for the flexibility it gave them to quickly change direction as new information emerged.)

Not the answer you're looking for? Browse other questions tagged or ask your own question.