プログラムはインターフェースでつまずく
研究開発プログラムがヨーテボリ、東京、上海にまたがる場合、各チームが非常に優秀でもプログラム全体は失敗することがあります。問題は作業が拠点をまたぐところに集中します。サブシステム間のインターフェース、フェーズ間の引き継ぎ、誰も書き留めなかった前提です。
作業を分散する前に、システムアーキテクチャ、そのインターフェース、それぞれの責任者を明確に定義しましょう。責任者のいないインターフェースは統合上の問題になります。
時差を味方にする
中央ヨーロッパ時間と日本・中国の業務時間が重なるのは、朝のわずかな時間帯だけです。深夜や早朝の会議でこれに抗えば、チームは疲弊します。
- ·重なる時間帯は進捗報告ではなく、意思決定と障害の解消に充てましょう。
- ·進捗報告は書面による非同期の更新に移しましょう。
- ·待ち時間が生じず、時差をまたいで作業が続くよう引き継ぎを設計しましょう。
早期に統合する
分散型プログラムが、各チームが同じ要求を異なって解釈していたと気づくのは遅い統合の段階です。シミュレーション部品を使ってでも早期の部分統合を計画し、統合結果をすべての拠点に見えるようにしましょう。
軽く、明確なガバナンス
重いガバナンスは全員の足を引っ張り、暗黙のガバナンスは声の大きい拠点に決定を委ねてしまいます。誰が何を決めるか、リスクをどう提起するか、要求・決定・スケジュールの唯一の情報源がどこにあるか、少数の明確なルールを維持しましょう。
すべての関係者から信頼され、技術面と文化面の両方で橋渡しができる経験豊富なプログラムリーダーが、最も重要な要因となることが少なくありません。