- the way to manage this risk is to include buffer in the project timeline, and, critically, to use that buffer not for development tasks that were harder than

- the way to manage this risk is to include buffer in the project timeline, and, critically, to use that buffer not for development tasks that were harder than expected, but for re-planning and re-negotiating the deliverables with stakeholders, to un-explode the project. Agile builds this re-evaluation into the project lifecycle, which is the main (maybe only?) thing is does really right. This is the only right answer. Unfortunately, engineering leadership is too detached from understanding how software works. They think of projects like contractor painting jobs. So easy to estimate - sq. ft * number of people * number of hours. But software is not like that. Software is constantly changing every hour, every day. As a result, any estimation is changing every hour every day. The best thing is for leadership to start acknowledging the realm they are dealing with. If they can't they should step down. But realistically, engineers should always give 400% padding with estimates. The root cause of this estimation is poor leadership. It is not engineering team's problem that detached management doesn't understand software.