# Thinking, Fast and Slow: why FDE estimates miss in the same direction > Daniel Kahneman's 2011 book explains why you keep promising earlier dates than you deliver, and offers a fix that is simpler than it sounds. Original: https://fdetimes.net/en/books-courses/thinking-fast-and-slow-fde-estimates/ In 1979 Daniel Kahneman and Amos Tversky documented something every FDE who has missed a go-live date already knows: people consistently underestimate the cost, completion time and risk of their own work, and they err in the same direction every time. More than three decades later, Kahneman described the optimism bias behind this as perhaps the most significant of the cognitive biases. For an FDE, this is not a philosophical matter. *Thinking, Fast and Slow* explains why that number is so often wrong, and wrong in the same direction. More importantly, the book gives you a tool to correct it. ## What to read closely, and what to skim Kahneman was an Israeli-American psychologist. He published this popular science book in 2011 through Farrar, Straus and Giroux. The 512-page paperback was released on 2 April 2013. The whole book revolves around two systems of thought. System 1 is fast, intuitive and emotional. System 2 is slower, more deliberative and more logical. Applied to FDE work, the number you blurt out after a discovery session can be seen as a System 1 answer: quick and fluent, but not yet thought through. 512 pages is a lot, so read the chapters on judgement under uncertainty and on optimism closely. Skim the priming material and keep a sceptical eye on it. Some of the priming studies in the book have been called into question during the replication crisis, and Kahneman himself acknowledged that he had placed too much faith in studies with samples that were too small. ## Idea one: discovery does not show you everything Kahneman calls this WYSIATI, short for "What You See Is All There Is": the mind works with the information in front of it and ignores what is missing. Picture this: after discovery, you have seen a tidy schema, a documented API and highly enthusiastic stakeholders. System 1 immediately builds a smooth story from that and produces a number. What you have not seen does not enter the estimate, simply because it is not in your head at the time. That might be the process for getting access to production data, a few dirty tables, or a security reviewer who has never attended a single meeting. The first step is simple. Before you say any number out loud, write a list of the parts of the customer's system you have not seen with your own eyes. The length of that list alone is enough to dent your confidence. ## Idea two: use past projects as the yardstick The book describes the planning fallacy as the tendency to overstate benefits and understate costs. Its root is the inside view: you focus only on the specific challenges of the project at hand. The cure is the outside view: using the average outcome of similar past projects to anchor the forecast. Try a hypothetical calculation. You judge that integrating with the customer's system will take 3 weeks. On your five previous deployments, each was also planned at 3 weeks, but they actually took 5, 6, 4, 7 and 8 weeks. The average is 6 weeks, double the plan. Those five deployments are your reference class. The sensible starting point is 6 weeks. Only then do you adjust for the genuine differences in this project, rather than taking 3 weeks as the baseline and adding a little for safety. **Key point:** A promise to a customer should rest on past projects, not on the best demo. ## Idea three: sometimes the number is dressed up on purpose In HBR in July 2003, in the article "Delusions of Success", Kahneman and Dan Lovallo argued that the evidence is clear: most large business initiatives fail to meet expectations, and the cause lies in optimism during decision-making. The article is far shorter than the book and makes an ideal next read. Bent Flyvbjerg wrote a commentary on the article, published on arXiv in 2013. He credited the two authors with correctly diagnosing the causes of the planning fallacy through their analysis of overoptimism, anchoring, competitor neglect and the role of the outside view in forecasting. But he also pointed to a source of error they underplayed: people deliberately adjust forecasts to look good so that projects get started. For an FDE, this critique hits close to home. Pressure from sales, or from the customer, can push you to promise a number you know is too rosy. That is no longer a cognitive error; it is a choice about how you negotiate. So always keep two numbers separate: the reference-class estimate, and the level you agree to commit to. Write the estimate down before you join the call. ## Who should read it, and in what order The book suits people who give customers dates directly, or who are about to take on that job for the first time. Read in this order: the chapters on judgement and optimism in the book, then the 2003 HBR article, and finally Flyvbjerg's commentary. The lesson also works in interviews, provided you have the numbers to tell it. Record the planned date and actual completion date of each deployment, so that when asked about a late project you can tell a story like this: the first time you promised 3 weeks and it took 6; the next time you started from the average of past projects, flagged to the customer the parts you had not yet seen, and delivered on time. When reading job descriptions, treat phrases such as "scoping" or "managing customer expectations" as a signal to have a story like that ready. Next time a customer asks "how long?", don't answer straight away. Look at your past projects first. **Try this week:** - List your or your team's 3-5 most recent deployments, note the planned and actual completion dates, then work out the average overrun. - Before your next date-setting call with a customer, write down two separate numbers: the reference-class estimate and the level you are willing to commit to. - After your next discovery session, write a list of the parts of the customer's system you have not seen before giving any number. ## Sources - [Thinking, Fast and Slow - Tradebook for Courses (Macmillan)](https://academic.macmillan.com/academictrade/9780374533557/thinkingfastandslow/) - [Thinking, Fast and Slow (Wikipedia)](https://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow) - [Delusions of Success: How Optimism Undermines Executives' Decisions (HBR)](https://hbr.org/2003/07/delusions-of-success-how-optimism-undermines-executives-decisions) - [Delusions of Success: Comment on Dan Lovallo and Daniel Kahneman (arXiv)](https://arxiv.org/abs/1305.0741) - [Looking Outside: A Fresh Approach to Project Management (strategy+business)](https://strategy-business.com/blog/Looking-Outside-A-Fresh-Approach-to-Project-Management)