Estimations are always wrong, and the larger the scope, the more wrong they will be. Yet estimates are unavoidable. Nobody signs a blank check, and in consulting this often turns estimation into a stressful and risky exercise. Fixed-price projects, in particular, have a way of keeping people awake at night.

In this talk, I won’t focus on estimating user stories or backlog items. Instead, we’ll look at something much harder: estimating entire software projects, early on, often with limited information, and in cold, hard man-days.

Drawing from my years of experience in consulting, I’ll share how I approach these situations in practice. We’ll cover the goals of such estimates, common traps, do’s and don’ts, and how to structure an estimate so it remains honest, defensible, and useful, even when the context is far from ideal.

The aim is not to make estimates accurate, but to make them responsible: estimates that support decision-making, expose uncertainty, and reduce the risk of putting teams, or your own job, on the line.