プログラム管理
プログラムは、チーム内ではなく、チーム間の「継ぎ目」で失敗します。仕事はその継ぎ目にあります。
セットアップ
- 1つの成果を、日付を伴うビジネス結果として明記します。複数の同等の目標を持つプログラムには、実質的な目標はありません。
- 指名された責任者 — 委員会ではなく、1人の人物です。プログラムマネージャーが推進し、責任者が決定します。
- スコープは、含むものと含まないものとして記述します。 「含まないもの」が実質的な定義であり、文書化されていない除外事項は前提条件として立ち現れます。
- 依存関係は、それを負っているチームによってマッピングされ、合意されなければなりません。 また、実際にコミットした日付も含まれます。担当チームが合意していない依存関係を計画に含めることは、願望に過ぎません。
順序付け
チームの都合ではなく、依存関係とリスクに基づいて順序付けます。計画を無効にする可能性のあるもの — 技術的な不明点、ベンダーの決定、得られないかもしれない承認 — を優先的に処理します。4ヶ月目に計画が不可能だったと判明するのが、典型的なプログラムの失敗です。
余裕は、最後ではなく、統合ポイントに組み込みます。最後にまとめて確保したバッファーは、早い段階で、かつ黙って消費されます。
読む価値のあるステータス
毎回、3つのことだけを報告します：期日に対して順調か、前回から何が変わったか、どのような決定またはブロック解除が必要か。それ以外は付録です。
ステータスは、コミットした日付に対して追跡し、労力に対して追跡してはいけません。「80%完了」は情報ではありません。「統合は完了、移行は月曜開始、承認がリスク」という報告こそが情報です。
早期かつ具体的にエスカレーションします。必要な決定と期日を明示したエスカレーションは解決されますが、漠然とした懸念の表明は認識されるだけで何も起こりません。
遅延が発生した場合
問題がスコープの問題、キャパシティの問題、または依存関係の問題のいずれであるかを特定します — それぞれの是正方法はまったく異なり、間違ったものを適用すると状況は悪化します。
次に、結果を伴う選択肢を提示します：スコープを削減する（何を削るか明示）、期間を延長する（どの程度延長し、他に何に影響するか明示）、またはキャパシティを追加する（後半では効果が薄く、むしろ悪影響を与えることが多い）。
毎週少しずつ遅らせるのではなく、一度だけ明確にベースラインを再設定します。連続した小さな遅れは、一度の正直なリセットよりもはるかに早く信頼を損なわせます。
絶対に行わないこと
- 未解決のブロッカーがあるプログラムを「グリーン（順調）」と報告すること。
- 担当チームが確認していない依存関係の日付を受け入れること。
- 遅延しているプログラムに人を追加して、それが加速すると想定すること。