Name: How Big Things Get Done
ISBN: 9780593239513

How Big Things Get Done

Este livro contém segredos para planear e executar com sucesso planos de qualquer escala, e partilhados pelo maior especialista do mundo em megaprojetos. Nada é mais inspirador do que uma grande visão que se torna uma nova e triunfante realidade. Pense em como o Empire State Building passou de um esboço a uma joia no horizonte de Nova Iorque em 21 meses, ou em como o iPod, da Apple, passou de um projeto com um único funcionário a um lançamento de produto em onze meses. De acordo com as estatísticas, porém, 92 % dos megaprojetos ultrapassam o orçamento ou o prazo, ou ambos. Mesmo os esforços mais modestos, como a criação de uma pequena empresa, falham frequentemente. Porquê? Bent Flyvbjerg, professor da Universidade de Oxford, dedicou a vida a compreender o que distingue os poucos triunfos de tantos insucessos. Em Como Fazer Grandes Coisas, Flyvbjerg identifica os erros de julgamento e as más decisões que levam ao fracasso de projetos, grandes ou pequenos. Mostra, também, como é provável que os seus próprios planos sejam bem-sucedidos se aplicar os princípios que ele investigou durante décadas.

What Hacker News says

moringSep 2026

The point of small modular reactors is not the cost of the first one, but that the cost goes down with each subsequent one. The cost of the first one is expected to be high. IMHO this is very well explained in "How Big Things Get Done" by Bent Flyvbjerg.

thread

moringFeb 2026

The book "How Big Things Get Done" by Bent Flyvbjerg nicely answers all the concerns mentioned in this thread. I'll answer here to avoid littering replies everywhere.

> But I do still think there's a lot of value into coming up with a good plan before jumping in.

Definitely, with emphasis on a _good_ plan. Most "plans" are bad and don't deserve that name.

> be specified up-front, planned on JIRA

Making a plan up-front is a good approach. A specification should be part of that plan. One should be ready to adapt it when needed during execution, but one should also strive to make the spec good enough to avoid changing.

HOWEVER, the "up-front specification" you mentioned was likely written _before_ making a plan, which is a bad approach. It was probably written as part of something that was called "planning" and has nothing to do with actual planning. In that case, the spec is pure fiction.

> estimates provided

Unless this project is exceptional, the estimates are probably fiction too.

> and Gantt charts setup

Gantt charts are a model, not a plan. Modeling is good; it gives you insight into the project. But a model should not be confused with a plan. It is just one tiny fragment you need to build a plan, and Gantt charts are just one of many many many types of models needed to build a plan.

> before they even sign the contract for the next milestone

That's a good thing. Signing a contract is an irreversible decision. The only contract that should be signed before planning is done is the contract that employs the planners.

> Anyone who claims upfront specs are the solution

See bove. A rigid upfront spec is usually not a plan, but pure fiction.

> My approach, especially for a project with a lot of unknowns, is usually to jump in right away and try to build a prototype.

Whether this is called planning or "jumping in" is a difference in terminology, not in the approach. The relevant clue is that you are experimenting with the problem to understand it, but you are NOT making irreversible decisions. By the terminology used in that book, you are _planning_, not _executing_.

> after the 2000 pages specification document was written, and passed down from the architects to the devs

If the 2000 page spec has never been passed to the devs while writing it, it's not part of a plan, it's pure fiction. Trying to develop software against that spec is part of planning.

thread

shooJan 2026

Your story reminded me of Bent Flyvbjerg and Dan Gardner's book "How Big Things Get Done". It's a pop science book communicating the research of Flyvbjerg & collaborators who collected data of actual schedule & budget outcomes for many large projects, along with recording the estimated schedule and budgets from the time the go/nogo decision was made to invest in the projects.

For accurate schedule and budget estimates, Flyvbjerg strongly recommends figuring out which broader class of projects your project belongs to, then going and looking at accurate historical data with actual schedule and budget outcomes for projects in that class, and using historical averages as your estimates.

There's a great table in an appendix at the back of the book, offering statistics for each category of project, ranking them by mean cost overrun.

The absolute worst category of project, for mean cost overruns, is nuclear storage, with a mean cost overrun of 238%.

IT projects are the 5th worst category of project, with a mean cost overrun of 73%, behind nuclear storage, olympic games, nuclear power and hydroelectric dams.

The table also has statistics on "what percentage of projects has a cost overrun of 50% or greater" and "of those projects with a cost overrun of 50% or greater, what is their mean cost overrun". For nuclear storage projects, 48% of them have a cost overrun of 50% or greater, and of those, the mean cost overrun is 427% (!).

For IT projects, 18% of them have a cost overrun of 50% or greater, and of those, the mean cost overrun is 447% (!!).

Some of the chapters in the book discuss some of the structural or political pressures that set projects up to fail --- e.g. in some fields its an open secret that estimates are always wildly optimistic, as if the estimates were actually realistic, no one would ever agree to fund a project.

thread

cadamsdotcomJan 2026

This sort of stuff has parallels outside software - the book “how big things get done” is amazing, and one interesting thing it implies is that solar installations tend to go the best because they’re modular and lessons learned can be applied to the next phase of a project.

Whereas the worst overruns are nuclear power plants; which are either switched on and working, or completely useless and taking up space!

So my takeaways were: try to make estimates modular and work out how to carry learnings as your project goes on, and you’ll have an easier time hitting your estimates - and probably get a great reputation for delivering!

thread

moringJan 2026

This is the right point to mention "How Big Things Get Done" by Bent Flyvbjerg. You can iterate your design without putting lives into danger.

"I spent weeks planning" -- using the terminology from that book: No, you didn't spend weeks planning, you spent weeks building something that you _thought_ was a plan. An actual plan would give you the information you got from actually shipping the thing, and in software in particular "a model" and "the thing" look very similar, but for buildings and bridges they are very different.

thread

moringSep 2025

I feel like this is the time to mention "How Big Things Get Done", by Bent Flyvbjerg. "Long planning vs. start prototyping" is a false dichotomy. Prototyping IS planning.

Put another way, refining tickets for weeks isn't the problem; the problem is when you do this without prototyping, chances are you aren't actually refining the tickets.

Planning stops when you take steps that cannot be reverted, and there IS value in delaying those steps as much as possible, because your project then becomes vulnerable to outside risk. Long planning is valuable because of this; it's just that many who advocate for long planning would just take a long time and not actually use that time for planning.

thread