Pocket

■ 必ず進捗が遅れるのがプロジェクト

プロジェクトマネジメント(基礎編)
前回」は、「プロジェクト憲章」の必要性と内容について説明しました。最後に、「プロジェクト憲章」は絶対不変なのかについて、問いを投げかけさせていただきました。今回は、この問いに対して、筆者のこれまでの経験からくるひとつの見解を述べさせていただきたいと思います。
筆者の力不足なのでしょうが、いまだに当初の計画に寸分違わず、プロジェクトを進行させたことはありません。経験プロジェクト数は、事業会社から含めて二桁台に到達していますが、必ず途中で、課題が発生し、作業が遅れ、プロジェクト内容に修正を施しています。
「人間は生まれれば必ず死が訪れる」「朝になれば、必ず夜が来る」のと同じくらい、プロジェクト進捗が途中で遅れることは必至のことのように思えます。
筆者は、経験を通じて、「プロジェクト進捗が遅れないようにどうするべきか」を考えるより、「プロジェクト進捗が遅れた場合にどうするべきか」を考えるようになりました。

■ 進捗が遅れた時にまず考えること

まず、基本動作として、「進捗遅延」が発生した場合に、「原因追究」することは当たり前のようになっています。「原因追究」は当然やることにした場合、次に問われるのは、「原因の解決策」の立案です。
ごく一般論で申し上げると、「進捗遅延」が発生した場合、

  1. 「当初の見積もり」より作業時間が多くかかった
  2. 「当初の見通し」より課題解決の難易度が高かった

との反省の弁が陳述され、クライアントからコンサルタントが計画の甘さについて詰(なじ)られます。
次に、コンサルタントは、

  1. 「リカバリ」: 残業・徹夜をすること、メンバを増員すること
  2. 「リスケジュール(リスケ)」: 作業納期を遅らせること
  3. 「スコープ縮小」または「代替案の提示」: やることの量か質を減らすこと

のいずれかを提案して、クライアントに、これらの対応策(またはその組み合わせ)を泣く泣く呑んでもらいます。
最初の「リカバリ」策は、プロジェクトの受託者であるコンサルタントやITベンダーが無償(追加料金の請求をしないという意味)で対応することが多く、一見すると、プロジェクトの委託者であるクライアントにはなんら不利なことはないようにも見受けられます。しかし、そこはビジネス。無償ということはあり得ません。当初のプロジェクト委託費用には必ず「リカバリ」対応にかかるコストがサバを読んで織り込まれていることが通常です。
また、残業・徹夜での対応の場合、担当者の作業品質が落ち、かえって品質チェックの作業量が増えたり、作業目標水準を落とさざるを得なかったりと、クライアントにも不利益が発生することがあります。
プロジェクトにおいて、「作業遅延」が発生した場合、受託者-委託者双方に必ずマイナスが発生すると考えていた方がよさそうです。

■ シンプルに対応策を考える

前章のコンサルタントからの対策案は、必ず「課題解決能力」の増強か、「解決すべき課題の質・量」の軽減か、いずれかまたは双方の組み合わせです。
PM(基礎編)_プロジェクト課題と解決能力のバランス
「やるべきこと」と「やれる能力」とがアンバランスなことにより、「作業遅延」が発生すると考えるのです。
プロジェクトでは、「やってみないとわからない」ことが多いのも事実です。そういう場合のためにも、「コンティンジェンシー・プラン」を必ず作っておくことが肝要です。
どういう場合に、「やるべきこと」と「やれる能力」にギャップが発生するのかを明らかにしておくこと、そして、もしもの時が発生した時に、対応策の打ち手をすぐ打てるように「コンティンジェンシー・プラン」を予め用意しておくこと。
これらのことが、実際にプロジェクトを始める前に文章として、プロジェクト関係者間で合意されていることが大事になってきます。そのために、プロジェクト開始前(または開始直後)のタスクとして「プロジェクト憲章」を作成し、それらを「How」の箇所で記載することが必要だと考えています。

■ プロジェクト憲章の改訂

プロジェクト進行の遅延は不可避だと先述しましたが、入念にプロジェクト計画を立案し、「プロジェクト憲章」で全関係者により相互チェック、合意形成しておけば、遅延の発生頻度はかなりの確率で減少させることが可能です。さらに、遅延が発生した場合の、コンティンジェンシー・プランが記載されていれば、対応も素早く実施できます。
作業遅延が発生した場合に備えて、「プロジェクト憲章」を作成し、仮に作業遅延が発生した場合は、作成時の精神に立ち返り、落ち着いて対策をとるということになります。
それでは、「プロジェクト憲章」の何を確認して、遅延対応策を検討するべきなのでしょうか? そのためには、「プロジェクト憲章」には何が記載されているべきなのでしょうか?
PM(基礎編)_プロジェクト憲章で確認すること
筆者は、次の4つが最低でも記載されていれば、もしもの時の判断基準になると考えています。

  • Why: 何をすべきで、そのために何が達成されているべきかを示す目標
  • What1: プロジェクトスコープとして、何が実現されていなければいけないかの優先順位
  • What2: プロジェクト成果が発揮されるべき時間的制約
  • How: プロジェクトプランの見直し方法(見直し方針、予算変更幅、見直し策の準備)

「リカバリ」「リスケ」「スコープ縮小」「代替策の採択」のいずれが、プロジェクト目的の果たすために最も効果的か、この4つに照らして考えることをお勧めします。
予め、コンティンジェンシー・プランが「プロジェクト憲章」にビルトインされていれば、憲章自体の改訂は不要でしょう。しかし、予見できない変更が発生した場合、「プロジェクト憲章」の改訂が必要になります。
そして、筆者が一番大切にしている価値観は、「そもそもこのプロジェクトの目的を果たすために最も効果的な方法は何か」です。その価値観を確認するために、「プロジェクト憲章」に立ち返ることを常としています。そして、目的すら変更すべきケースにまで至った場合には、「プロジェクト憲章」の改訂にためらいは一切持ちません。
ここまで、「プロジェクトの進捗が思わしくないときどう対処すべきか」を説明しました。
PM(基礎編)_プロジェクトの進捗が思わしくないときどう対処すべきか

(Visited 177 times, 1 visits today)
Pocket

http://keieikanrikaikei.com/wp-content/uploads/2015/10/ea064d4a1905bbaeb9230f5380d383f6-e1443954128333.jpghttp://keieikanrikaikei.com/wp-content/uploads/2015/10/ea064d4a1905bbaeb9230f5380d383f6-150x150.jpg小林 友昭プロジェクトマネジメント(基礎編)■ 必ず進捗が遅れるのがプロジェクト 「前回」は、「プロジェクト憲章」の必要性と内容について説明しました。最後に、「プロジェクト憲章」は絶対不変なのかについて、問いを投げかけさせていただきました。今回は、この問いに対して、筆者のこれまでの経験からくるひとつの見解を述べさせていただきたいと思います。 筆者の力不足なのでしょうが、いまだに当初の計画に寸分違わず、プロジェクトを進行させたことはありません。経験プロジェクト数は、事業会社から含めて二桁台に到達していますが、必ず途中で、課題が発生し、作業が遅れ、プロジェクト内容に修正を施しています。 「人間は生まれれば必ず死が訪れる」「朝になれば、必ず夜が来る」のと同じくらい、プロジェクト進捗が途中で遅れることは必至のことのように思えます。 筆者は、経験を通じて、「プロジェクト進捗が遅れないようにどうするべきか」を考えるより、「プロジェクト進捗が遅れた場合にどうするべきか」を考えるようになりました。 ■ 進捗が遅れた時にまず考えること まず、基本動作として、「進捗遅延」が発生した場合に、「原因追究」することは当たり前のようになっています。「原因追究」は当然やることにした場合、次に問われるのは、「原因の解決策」の立案です。 ごく一般論で申し上げると、「進捗遅延」が発生した場合、 「当初の見積もり」より作業時間が多くかかった 「当初の見通し」より課題解決の難易度が高かった との反省の弁が陳述され、クライアントからコンサルタントが計画の甘さについて詰(なじ)られます。 次に、コンサルタントは、 「リカバリ」: 残業・徹夜をすること、メンバを増員すること 「リスケジュール(リスケ)」: 作業納期を遅らせること 「スコープ縮小」または「代替案の提示」: やることの量か質を減らすこと のいずれかを提案して、クライアントに、これらの対応策(またはその組み合わせ)を泣く泣く呑んでもらいます。 最初の「リカバリ」策は、プロジェクトの受託者であるコンサルタントやITベンダーが無償(追加料金の請求をしないという意味)で対応することが多く、一見すると、プロジェクトの委託者であるクライアントにはなんら不利なことはないようにも見受けられます。しかし、そこはビジネス。無償ということはあり得ません。当初のプロジェクト委託費用には必ず「リカバリ」対応にかかるコストがサバを読んで織り込まれていることが通常です。 また、残業・徹夜での対応の場合、担当者の作業品質が落ち、かえって品質チェックの作業量が増えたり、作業目標水準を落とさざるを得なかったりと、クライアントにも不利益が発生することがあります。 プロジェクトにおいて、「作業遅延」が発生した場合、受託者-委託者双方に必ずマイナスが発生すると考えていた方がよさそうです。 ■ シンプルに対応策を考える 前章のコンサルタントからの対策案は、必ず「課題解決能力」の増強か、「解決すべき課題の質・量」の軽減か、いずれかまたは双方の組み合わせです。 「やるべきこと」と「やれる能力」とがアンバランスなことにより、「作業遅延」が発生すると考えるのです。 プロジェクトでは、「やってみないとわからない」ことが多いのも事実です。そういう場合のためにも、「コンティンジェンシー・プラン」を必ず作っておくことが肝要です。 どういう場合に、「やるべきこと」と「やれる能力」にギャップが発生するのかを明らかにしておくこと、そして、もしもの時が発生した時に、対応策の打ち手をすぐ打てるように「コンティンジェンシー・プラン」を予め用意しておくこと。 これらのことが、実際にプロジェクトを始める前に文章として、プロジェクト関係者間で合意されていることが大事になってきます。そのために、プロジェクト開始前(または開始直後)のタスクとして「プロジェクト憲章」を作成し、それらを「How」の箇所で記載することが必要だと考えています。 ■ プロジェクト憲章の改訂 プロジェクト進行の遅延は不可避だと先述しましたが、入念にプロジェクト計画を立案し、「プロジェクト憲章」で全関係者により相互チェック、合意形成しておけば、遅延の発生頻度はかなりの確率で減少させることが可能です。さらに、遅延が発生した場合の、コンティンジェンシー・プランが記載されていれば、対応も素早く実施できます。 作業遅延が発生した場合に備えて、「プロジェクト憲章」を作成し、仮に作業遅延が発生した場合は、作成時の精神に立ち返り、落ち着いて対策をとるということになります。 それでは、「プロジェクト憲章」の何を確認して、遅延対応策を検討するべきなのでしょうか? そのためには、「プロジェクト憲章」には何が記載されているべきなのでしょうか? 筆者は、次の4つが最低でも記載されていれば、もしもの時の判断基準になると考えています。 Why: 何をすべきで、そのために何が達成されているべきかを示す目標 What1: プロジェクトスコープとして、何が実現されていなければいけないかの優先順位 What2: プロジェクト成果が発揮されるべき時間的制約 How: プロジェクトプランの見直し方法(見直し方針、予算変更幅、見直し策の準備) 「リカバリ」「リスケ」「スコープ縮小」「代替策の採択」のいずれが、プロジェクト目的の果たすために最も効果的か、この4つに照らして考えることをお勧めします。 予め、コンティンジェンシー・プランが「プロジェクト憲章」にビルトインされていれば、憲章自体の改訂は不要でしょう。しかし、予見できない変更が発生した場合、「プロジェクト憲章」の改訂が必要になります。 そして、筆者が一番大切にしている価値観は、「そもそもこのプロジェクトの目的を果たすために最も効果的な方法は何か」です。その価値観を確認するために、「プロジェクト憲章」に立ち返ることを常としています。そして、目的すら変更すべきケースにまで至った場合には、「プロジェクト憲章」の改訂にためらいは一切持ちません。 ここまで、「プロジェクトの進捗が思わしくないときどう対処すべきか」を説明しました。現役の経営コンサルタントが管理会計をテーマに情報発信します