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.
Conclusion
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.