Here are notes from recent conversations and the past year's experiences in providing and/or interpreting project estimations.
Although the topic is infamous in software engineering, it applies just as well to other fields.
Blanket estimates are blatant lies.
- Always express your confidence level (as a probability) along with the estimation. Promising "project X will take Y months" is a sure way of painting yourself into a corner of overworked staff or outright failure to deliver on time and budget.
- 100% confidence is always a lie. Do not provide it, and do not assume it if someone promises it to you.
- Provide ranges of estimations ("2-year completion with 80% confidence, 1-year completion with 50% confidence") to external teams
- Plan based on checkpoints when possible: "project X can begin when project Y is at Z percent completion"
Higher confidence needs a bigger pocket.
80% confidence is about the maximum promise you should really make. 90% confidence is very aggressive. Reserve your high confidence estimates for:
- Known work to be tackled by a established team (i.e. a trained and focused team).
- Projects with high and consistent support from your manager(s)
- Failing those, for relatively short term goals which are achieveable by a relatively small team.
Confidence tapers over time. Plan accordingly.
The bigger the project, the longer the timeline, the harder it is to estimate it. Confidence falls over time.
- Aim to keep a buffer of milestones (smaller projects) within the green (high confidence) zone.
- Define future projects but communicate them carefully.
Project dependencies must consider, and plan for, the amount of confidence in estimations. Be pleasantly surprised rather than hedging all your bets on a project's success. All of this matter less if you're working in a small team with well-isolated goals.