[segmondy]

You need to separate the R & D. The research is unknown and you can't estimate. The development is known, and if you can use prior experience to estimate.

Give estimates in DURATION never as a date. Treat it as a stop watch, anytime interruption happens, the stop watch stops. So 2 weeks can actually take 6 actual weeks. If there's no research and interruption, then you should be able to give a +/- 10% estimate.

[claytonjy]

Love the "treat it as a stopwatch" idea; do you do anything specific to convey that to the customer? Even if you avoid and "end date", I assume they'll infer it from the start time and duration, and consider that internally.

Do you have any experience/advice for R&D estimates? This is something I struggle with alot. We try to bill per _project_ rather than per _hour_, but I'm thinking R&D perhaps necessitates hourly billing, which sucks.

[segmondy]

You have to put a cost to the interruptions. If they can interrupt you for free then they will. So let's say you agree to a one hour meeting per week, any extra time must cost extra. At the beginning of every meeting, you announce that the time will be adjusted due to the meeting.

If there are new features that are a must have, assuming they are well known problems with solutions. You must state that the complete date is now undetermined till these are sized. You must charge for these features, you must communicate this verbal and in writing. You must be like a lawyer. Imagine how a GPS always re-calibrates any time you diverge from a trip, this is how vocal you must be.

As for research, don't do it. Do only what you know, unless you are being made crazy amount of money and you can't lose. Replace the unknowns/research with knowns.

Someone wants an ML system but you don't know it? Well, maybe you will figure it out in 2 weeks or maybe you won't. Replace it with a expert system if you know that. Perhaps you don't know that, replace it with simple SQL queries and rules if that's the best you can do.

They want a cassandra store? But you have no experience? replace it with MongoDB. They want kafka but you have no experience, and you know RabbitMQ? Use rabbit. Being optimistic almost always comes back to bite you, be paranoid. Abstract away the unknowns with clean interfaces so when the first version is done and the research is done, the new components can hopefully be plugged in with less friction.