Non-techies creating functional specifications.

Question

Ok, I'm a lowly developer just minding my own business.

Suddenly, I'm thrust into the crazy situation where I'm being handed a piece of paper, consisting of hastily written point notes from a client meeting. From this, I'm supposed to estimate development time on a short software project (3 - 6 weeks). The notes range from fairly useful to koans like "Implement search".

My estimation is then used as a final quote to get the project. Approximate time given to me = 2 hours.

The people handing me the "notes" are not technical. They are both kind of a client, and a partner to our business. However, they are the only ones with access to the client.

Thankfully, we've flagged a problem with the partner- that is we never get any of the jobs because our quotes are too "safe". When pressed, the partner could only give "we don't have enough time" as the reason for the format. If another engineer gave me the same information, I would beat them - but where do you start for non-techies?

So my question is - how can I coach our non-technical partners to provide me an accurate idea of the work involved?

Answer 1

Deliver a cheap quotation so you get the work, then overrun on your estimates due to specification changes by the client.

Obviously, if the specification is vague, the estimate must also be vague. But when the client is demanding exact estimates from vague requirements, just give them a figure that is short enough to get the work. Then if you manage to do it in shorter time, everyone is happy. More likely you will take longer than your estimate, but by that time the client is committed and you can point to the vagueness of the spec. as the reason why the work is taking longer.

Seriously, this is how the big consultancies do it.

Answer 2

It depends on your situation.

Will it be your problem if the estimates are wrong?

If it will be, then consistently estimate far more time than you think is needed, just to be on the safe side. If they want correct estimates, ask them to give you precise tasks.

If it won't be your problem, just estimate the best you can, and work the best you can. Again, if they want correct estimates, ask them to give you precise tasks.

Answer 3

Give a f*cking huge confidence interval, like "the estimate is between a week and two years", when they ask you to be more precise, you can tell them the same about the requirements...

Hmmmmmmmmmm... Do this only if you want to change your job xD

Answer 4

In a situation like that I would think about how long it would take to complete the task if it were very specific and then tack on an additional 50-75% on top of that estimate. So the final estimate would be 1.5-1.75x the initial estimate. Sometimes I would even double it, just to ensure that the estimates were close. It's better to overestimate than underestimate.

Answer 5

Rewrite the "hastily written point notes" into a detailed specs, issue a time estimate and let the client sign this. After that, any spec changes by the client will result in reevaluation of the time requirements. This way it will be clear and transparent to both parties.

Answer 6

I think three point estimates are going to be your friend here: don't just say "three days" say, for example, "between one day and ten days with a most likely of three."

You have a situation where some requirements are detailed enough to make a decent estimate to absurdly vague. By providing a range you're giving the client information about how good their specification is and your confidence in being able to deliver it. If they ask why your estimate varies between a day and two weeks (in the above example) you have an opportunity to explain your reasoning. If not then, over time, they should be able to spot a pattern.

(People do sometimes need coaching in three point estimate. Some just pick the small number!)

"Software Estimation: Demystifying the Black Art," by Steve McConnell is a great book about not just estimation but in presenting estimates to other people.

Answer 7

I would look at some of the XP ideas of stories, and just have the client write out a little story of the functions being used.

Ask them to just be complete so you can give a better estimate. Then, as you work with them on this, they will get better.

So, on the search, the story should express who is doing the search, if they want auto-suggest and what the format of the results will be.

It is easier for people to think in terms of stories than specifications, and the advantage is that the story should have nothing about how it is implemented.

Then when you give your estimate, at least double the development time for debugging and testing, as that is the time sink.