私は計画のポイントを「ＯDISQ（オーディスク）」と表現します。
Ｏ 俯瞰する（overlook）
Ｄ 決める（determine）
Ｉ 想像する（imagine）
Ｓ 構造化する（structure）
Q 問い掛ける（query）
今回は「俯瞰する（Overlook）」を深堀します。
プロジェクトにおける計画の欠如は、往々にしてコストオーバーランや納期遅延につながります。ところが、きちんと計画を立てたつもりでも、これと似たような状況に陥ることがあります。計画が全体を俯瞰していない場合です。
計画することに慣れていない人は目の前の具体的な出来事に目がいきがちで、全体を俯瞰することが苦手です。手を付けやすい箇所から具体的な計画を立て始めます。できあがった計画には先の見通しがなく、部分最適で、戦略性の欠片もありません。
大きなプロジェクトほど、この傾向は際立ちます。知識エリアや技術分野が広範に及ぶため、プロジェクトマネージャは全体を統制することを半ばあきらめてしまう傾向があり、現場のリーダーたちに計画を委譲してしまいがちです。
計画を引き受けた各領域のリーダーたちは、プロジェクト全体のバランスや関係者への配慮を欠いたまま、自身の勘と経験で、自分たちの都合を優先した計画を立てます。こうしてできあがった計画は部分最適で、プロジェクトが始まると周囲と不協和音を奏ではじめ、それが無駄な調整や手戻りを生みます。どんなプロジェクトでも課題として上位に挙がる「飛び込み業務」も、これが原因となっている場合が多いようです。
私が以前に関わった組織は、まさにそんなプロジェクトを多数抱えていました。
収益性の悪化に苦しんでいた彼らが直面していた課題は、飛び込み業務の多発による現場の混乱でした。プロジェクトは複数のサブチームから構成されており、マネジメントは各サブチームのリーダーに任されていました。この組織はもともとガバナンスが脆弱で、その体質はプロジェクトにも引き継がれていました。
リーダーたちの計画手法は属人的で、大雑把でした。自分本位で検討された計画はチーム間のつながりが考慮されておらず、しかも他のチームには非公開でした。
この組織のプロジェクト運営はもともと段取りが悪く、いつもドタバタしていましたが、チームを跨ぐとなおさらでした。ギリギリになって「これが必要になった」「今日中にやってくれ」と大騒ぎするのが普通でした。人によっては、作業工数の半分以上が飛込み対応に費やされていました。
プロジェクトはお互いへの不信感で爆発寸前でした。なぜなら、飛込みを嘆いていた本人が、次の瞬間には飛び込ませる側に回るという「加害者＝被害者」の地獄の様相を呈していたからです。
このような状況を引き起こさないためには、プロジェクトが始まる前に、全体を俯瞰した計画（＝全体計画）を立てておくべきです。優秀な計画者は計画の序盤に現場のリーダーたちを参加させ、プロジェクト全体を俯瞰します。皆で大雑把に流れを描き、イメージを膨らませます。これがリーダーたちの当事者意識につながります。
各リーダーは全体計画を持ち帰り、実行計画へと詳細化します。このやり方であれば部分最適問題は発生しません。
私たちは、プロジェクトがキックオフする前にリーダーたちと計画を議論する場を設けることにしました。プロジェクト全体を俯瞰しながら喧々諤々と意見を出し合い、マスタープランと呼ばれる全体計画を作成しました。この会議は「フロントローディング・ミーティング」と呼ばれ、営業や生産管理部門、製造現場なども参加するようになりました。
この取り組みは参加者にも好評で、定着するにつれ、飛び込み作業は目に見えて減少していきました。
計画では、全体を俯瞰することを心掛けるべきです。
★★★ 概念化.com を立ち上げました ★★★
★★★ ぜひ、お立ち寄りください ★★★
