What you are asking for
A commitment is announced to the customer. Then the team that has to deliver it is asked to estimate it.
What the system hears
“The date is already promised. They want a yes from us.”
What that produces
An estimate asked for after the promise is a request for confirmation. The team knows it, and either answers what is expected or keeps quiet.
The people who build see what the promise ignores: a dependency, a smaller version that would do, a capability already available. That information is worth a lot before the commitment, and almost nothing after.
An order of magnitude, the assumptions and the unknowns are enough for most ideas. The heavier the commitment, the deeper the look.
A call or a message commits as much as a contract. If you promise on the phone, you decided without the team. If the promise already exists, the estimate is still useful: it measures the gap. Deal with the gap, without making it the team’s fault.
The decision
→ Before you confirm a date, a cost or a scope, ask the people who will build it for the options and the unknowns.
→ If you have to answer sooner, say what is confirmed, what is not, and when you will come back.
→ Have the running load estimated with the build: upkeep is part of the cost.
→ If the estimate contradicts the promise, you renegotiate with the customer.
→ After delivery, compare the assumptions to reality, and adjust how you promise.
To discuss
Which date did we promise recently before asking the people who will hold it?