A client you really want needs one thing before they sign. One feature, the one that makes your product fit the way they work. You ask your lead how long. Six weeks, he says. Mid-March.
You tell the client the end of March. You have been here before, so you add two weeks and call it a date. They say fine, and they wait.
The end of March comes and the feature is nearly there. You call the client. Whether they keep waiting is now their decision, not yours.
So the next time your lead says mid-March, you say end of May to your client. They go with someone who said April.
A tight date can cost you the client's trust. A safe date can cost you the deal.
Only one of those two bills ever arrives. The moved date comes with a call, a discount, a client who leaves. The date that was safer than it needed to be comes with nothing at all. The prospect who chose the shorter date is "lost to a competitor" in your pipeline. When no bill comes, you can't tell whether you paid nothing or paid the one nobody sends.
So I looked at what each date would have cost for one team.
I took a team of six to seven developers with public records. For almost two years, at every Monday, I gave them the same feature, a month’s work for all of them, and dated it from the pace of the three months before. That gives the usual date: the one as likely to hold as not, about four weeks on a typical Monday, and the one most leads hand you as the date.
The usual date broke about half the time, as a 50% date should. When it broke, the team was typically a week late, and one miss in four was two weeks or more. That is the first bill, the one you get: the call.
You wouldn’t hang a client you really want on a coin toss, so you take the safe date, the one that would have held 85% of the time on this team’s record. It sat two weeks past the usual one. The work doesn’t care which date you pick. It lands when it lands. What changes is the risk.
The chance that you’ll have to call and disappoint the client drops from 50% to 15%. To get there, you put two weeks on every quote, and it takes about three of those quotes to spare you a single call. All three clients heard six weeks instead of four. If one of them goes with someone who said four, you lost a deal to save a call. That is the second bill. It never arrives. In your pipeline, that deal just says “lost to a competitor.”
A week late half the time, or never getting the deal at all. The bills are not the same size, and the bigger one is the one nobody sends.
So which side are you on? If your dates hold, you don't know whether the padding you added was right or too much. If you don't finish before the deadline, you blame the estimate. Either way, nobody sized the padding you added. The weeks between the usual date and a safe one are a price. Leave them out and you pay it, on the call. Put them in and the client pays it, in waiting, and some clients refuse to.
You don't need to guess. Ask your lead for two dates: the one that holds 50% of the time and the one that holds 85% of the time. The distance between them is what the deal is paying for. Set it against what the deal is worth and choose with both numbers in front of you. If the distance is a week, give the safe date. If it is a month, the problem isn't this deal.
Before you give the client a date, ask your lead for both dates.
I work out the chance behind your next date from the work your team has already finished, before you promise it. No workshop, no new estimate.
See the chance behind your next date
The small team is Appcelerator Studio's, six to seven developers from March 2011 to May 2013, chosen as the smallest of the three teams in the public TAWOS records, the same projects as in Finish dates don't exist. Odds do. and Your team was on time. Your roadmap wasn't.. The feature is twenty items, the team's typical month. At every Monday of that stretch, 92 in all, the usual date is the day the team's pace over the three months before gave a 50% chance of being done, and the actual is the day the record got there. The safe and very safe dates are the usual date plus the extra time that would have held 85% and 95% of the time over the whole stretch, read off afterwards. The usual date broke 49 times in 92, half of those by more than 8 days. The safe date sat 14 days past the usual one and held 79 times, half of those with more than 17 days to spare. The very safe date sat 25 days past and held 87 times, half of those with more than 24 to spare. MongoDB's Evergreen team in 2018, about twice the size, needed the same 14 days for its safe date and 17 for its very safe one. Historical outcomes, not a guarantee for any team.