プロジェクト・マネジャーが知るべき97のこと
できるだけ早期にユーザーを巻き込む - Barbee Davis
 モグラたたき開発を避けよう - Venkat Subramaniam
 ローカライゼーションのせいで締め切りに遅れる - Pavel Simsa
 プロジェクト・オーナーは強力なプロジェクトサポーター - 武谷 美世子
 複雑よりもシンプルな方がいい - Scott Davis
 負債を支払う - Brian Sletten
 スキルでなく素質のある人を加えよう - Richard Sheridan
 シンプルにいこう - Krishna Kadali
 あなたは特別ではない - Jared Richardson
 スクロールから学んだこと - Kim MacCormack
 問題にかかるコストを削減する - Randy Loomis
 すぐれた開発者を見つけるには - James Graham
 熟練と並の開発者の生産性 - Neal Ford
 大きさが重要 - Anupam Kundu
 手順を文書化して、守られているか確かめよう - Monte Davis
 さあ、プラクティスを投げ捨てよう - Naresh Jain
 要求と仕様 - Alan Greenblattアラン・グリーンブラット
 成功はビジネス価値で評価される - Barbee Davis
 休暇をキャンセルしない - Joe Zenevitch
 集中する時間を取る - James Leigh
 プロジェクトマネジメントはプロブレムマネジメント - Lorin Unger
 開発者を活かす - Ken Sipe
 巧妙なコードはメンテナンスが困難 - David Wood
 人的要素を管理する - James Graham
 Wikiを使う - Adrian Wible
 ミッシングリンク - Paul Waggoner
 見積もって見積もって見積もる - Richard Sheridan
 PMOの導入：開発者の足並みをそろえる - Angelo Valle
 労力ではなく結果を評価する - Venkat Subramaniam
 プロジェクトの失敗は組織の失敗 - Brian Sletten
 顧客からの声 - Marty Skomal
 物事を正しくとらえる - James Graham
 「完了」をどう定義するか - Brian Sam-Bodden
 60／60ルール - David Wood
 我々は敵に出会った。それは我々自身だ - Barbee Davis
 サイクルで働く - James Leigh
 自らに誠実であれ - William J. Mills
 ミーティングはコードを書かない - William J. Mills
 変化のための道筋を描く - Kathy MacDougall
 ITプログラムの管理 - David Diaz Castillo
 現実を考慮して計画する - Craig Letavec
 完全な実行という誤った考え - David Wood
 アジャイルなコミュニケーションシステムを導入する - Brian Sam-Bodden
 方法論を崇拝しない - Fabio Teixeira de Melo
 人的問題にスプレッドシートを持ち込まない - Anupam Kundu
 ひとつの成果物にひとりの責任者 - Alan Greenblatt
 完全な知識という誤った考え - David Wood
 スプリントでなくマラソンのためのチームづくり - Naresh Jain
 プロジェクトマネジメントの三位一体 - Paul Waggoner
 ロードマップを作ろう - Kathy MacDougall
 プロジェクトスコープ記述書の重要性 - Kim Heldman
 ビジョンと期待される成果に合わせる - David Diaz Castillo
 アリスはもうここにはいない - Barbee Davis
 契約紛争を避ける - Jorge Gelabert
 評価指標に基づいて行動する - Naresh Jain
 「自前主義」に陥るな - Paul Giammalvo
 「もうすぐ」よりも「今」を大切に - Scott Davis
 スピードこそ命、速ければ速いほどいい？ - Matt "Boom" Daniel
 チームのモラルづくり - David Bock
 プロジェクトはチームワーク次第 - Lelio Varella
 チームのために働く - Karen Gillisonカレン・ギリソン
 大きな丸いボールという誤った考え - David Wood
 危機への対応 - James Graham
 インテグレーションポイントを知る - Monte Davis
 分散したプロジェクトにおける積極的なコミュニケーション - Anupam Kundu
 結果を想定して始める - Luis E. Torres
 約束事が明確なら友情も長続きする - Matteo Becchi
 一番うまく見積もれるのはその仕事をする人である - Joe Zenevitch
 コミュニケーションが重要 - Gennady Mironov
 プロジェクトは解決策の追求である - Cynthia A. Berg
 鍵は人間にある - Adrian Wible
 ドキュメントは手段であり目的ではない - Patrick Kua
 アーンドバリューとベロシティは共存できるか - Barbee Davis
 スコープ変更に慣れよう - Pavel Simsa
 既製のソフトウェアを購入するということ - Ernani Marques da Silva
 よいスポンサー、わるいスポンサー、ひどいスポンサー - Jorge Gelabert
 約束以上にすべきか、約束以下にすべきか - Joe Zenevitch
 プロジェクト・マネジャーは契約管理者である - Fabio Teixeira de Melo
 重要だが緊急ではないこと - Alex Miller
 プロセスについて教える - Richard Sheridan
 ステータスという間違った考え - Udi Dahan
 みんなが聞きたいことは何ですか？ - Martha Legare
 モラルの重要性を認識する - David Bock
 ステークホルダーをずっと参加させる - Lukeman Lawal
 計画の価値 - Derry Simmel
 「メッセンジャー」にならない - Matt Secoske
 成果物を効果的に管理する - Ernani Marques da Silva
 私たちはスーパーヒーローではありません - Angyne J. Schock-Smith
 頻繁に即座にミーティングする - Richard Sheridan
 柔軟性がプロジェクトマネジメントをシンプルにする - Krishna Kadali
 Web が道を示す（今のところは） - David Wood
 ステータスレポートは開発者に嫌がられ、マネジャーに愛される - Pavel Simsa
 あなたはコントロールしていない - Patrick Kua
 ビジョンを共有する - Jared Richardson
 真の成功にはサポートする組織が必要 - Cynthia A. Berg
 ガバナンスを確立する - Ernani Marques da Silva
 あなたのWebサイトが嫌いな9.7の理由 - Barbee Davis

日本を中心に活躍するプロジェクト・マネジャーによる知っておくべき11 のこと
 自分に対する約束をどう守るか - 冨永 章
 プロジェクトの目的と成功の条件 - 芝尾 芳昭
 「正しい判断」にこだわるな - 重木 昭信
 「見積り＝不幸の始まり」にしないために - 初田 賢司
 プロジェクトによる人材育成 - 芝尾 芳昭
 「しなければならないこと」と「できること」 - 奥沢 薫
 まずプロジェクトの「目的」を確認せよ - 重木 昭信
 人を従えるのか、人が従うのか - 神庭 弘年
 予防的なプロジェクト管理のすすめ - 重木 昭信
 踏み込めば権限がついてくる - 冨永 章
 プロジェクトの条理と不条理 - 林 衛