大規模プロジェクトの上流工程（要件定義より前の、ゴール策定・現状分析・将来構想など）では、下流で慣れ親しんだWBSベースのプロジェクト管理を使うべきではない。上流は不確実性が100倍高く、精密なWBSは「管理できている風」の錯覚を生むだけ、という主張。
上流未経験者がチームを構成することが多く、以下のような管理をしようとする：
→ やめたほうがいい。弊害が多い割に効果が薄く、「一見きっちり管理できている様に見えて、本質的なプロジェクト状況は全然分からない」という状況に陥る。
プロジェクトという仕事には元々4つの特徴がある：
下流ですらスケジュールは本質的にブレやすいが、上流はこれが100倍ひどい：
上流では少しやってみないと先の展開が読めない：
・価格決定プロセスがガンだと思って3日調べたが、特に問題はなかった
・売掛金チームと相談したが揉めて、役員に説明しに行くことに
結果として工数を使わなくてよくなる時もあれば、予定していなかった作業がガバっと増えることもある。不確実性が大きい。
不確実性が高い状況では、80%終わった時点で40%分の仕事が発見されることが結構ある。
すると作業の総量は140%になり、80%だと思っていた進捗率は実は57%でしかない。
いきなりゴールラインが後ろにズレる。
さらにひどく、一切予定していなかった仕事の100%がポンと発生したりする。
| 階層 | 内容 | 粒度 |
|---|---|---|
| 階層1: ロードマップ | フェーズ展開。「今はこのフェーズ」の共通認識 | ざっくり |
| 階層2: アプローチ図 | タスクの順番と依存関係を示した図 | WBSより（あえて）粗い。柔軟に変更可能 |
| 階層3: セッションスケジュール | タスクごとにどんな検討を何回必要か、誰を呼ぶかを具体的な会議に落とす | 具体的 |
アプローチ図のタスク1つ1つについて、成果物やその精度を言語化する：
「このフェーズで"アーキテクチャ検討"といったら、こんな図を書ければOK」
「ただし適当に書くだけではNGで、裏付けとなる調査をこの精度でやっておかないとダメ」
ポイントは「ここまでやれば、後工程に着手できるよね」という観点。後工程ができるレベルまで検討できたなら、次に行っていい。そうしないと永遠に仕事を続けてしまう（それはもう「ホビー」の領域）。