ソフトウェア開発責任者である同僚が，この本のことを教えてくれた。
どうして大きなプロジェクトは往々にしてデッドラインまでに完了せず予算も大幅に超過してしまうのか，それに対してどういう対策を講じればいいのか，というテーマについて，多くの具体例をあげながら説明している。
たとえば建築プロジェクト。平均予算超過額は当初予算の62%。だから10-20%のバッファーを設けても全然足りないし，さらにその超過の分布はファットテイルになっている。
プロジェクトにはふたつのフェーズがある：計画と実行。多くの場合，甘い計画のままゴーサインがでて，実行のフェーズになって課題が噴出する。著者はそうではなくその逆，つまり計画はじっくりと時間をかけて行ない，そして実行段階になったら素早く行なうべきだという。なぜなら，実行のフェーズにかかる金額は計画段階よりはるかに大きく，そこでの問題発生は致命的になるから。著者はこれを「Think Slow, Act Fast」というフレーズで表現している。アブラハム・リンカーンは「木を倒すのに5分間かけるとして，最初の3分は斧を研ぐのに費やす」と語ったとか。
そして重要なのは，実験（experiment）と経験（experience）。実はこの二語，どちらもラテン語の〈experiri〉に由来しているという。実験はもちろん計画の段階で行なうもの。印象的だったのはPixarの話。ラフなかたちでストーリーを動画にまとめて，それを社内で品評して改良に改良を重ねる。もちろん手間はかかるけれど，実際のアニメの制作が始まってから修正するのに比べれば，手間も予算もはるかに抑制できる。経験については言わずもがな。あるとなしとでは大違い。本書の最終章でも，Better Project Leadershipのカギのひとつとして「Hire A Masterbuilder」と述べている。
もうひとつ印象に残ったのは「Modularity」。大きなプロジェクトでも，細分化してモジュール化する。モジュールの代表例はソーラーパネル。だからソーラーパネル関連のプロジェクトは，時間とコストのオーバーランがもっとも少ない。モジュールを繰り返し作り上げることで，経験も蓄積され，さらなるスピードアップが期待できる。エンパイアステートビルもその例。各フロアの構造をできるだけ同じにすることで，それを作る人たちは上のフロアになるにつれて作業が効率化し，作業スピードも向上していった。
最後に，見積もりの問題。プロジェクトにかかる時間や予算について人は見積もりを立てるけれど，おうおうにしてそれはベストケースを想定している。だけど，物事が理想的な状態の中で進むことはほとんどない。身近な例としては，週末の仕事。だいたい邪魔が入る。予想してなかった予定が入る。身体的にも疲れていて，思ったように集中力が保てないかもしれない。とかとか。といったかたちで，見積もりはつねにunderestimateになる要素を孕んでいる。
