『プロジェクトを絶対に失敗させない！やり切るための100のヒント』とは
本記事は、プロジェクトを成功させるために必要なノウハウを、数百の支援実績経験をもとに記述した『プロジェクトを絶対に失敗させない！やり切るための100のヒント』より、 1つずつヒントをご紹介していく企画です。プロジェクトマネジメントについて、何らかの気づきを得るきっかけになれば幸いです。
当社はプロジェクトマネジメントの知識と経験を有し、皆様のプロジェクトが成功するお手伝いをさせていただいております。 プロジェクトマネジメントに関する疑問や課題がある方、成功への道筋をお探しの方、どうぞお気軽にご連絡ください。
お問合せはこちらからどうぞ。
※『プロジェクトを絶対に失敗させない！やり切るための100のヒント』をPDFまたは電子書籍でダウンロードできます
『［ヒント32］教訓の「活用」をいかに促すか』では教訓の活用に焦点を当てましたが、次は教訓の「蓄積」にフォーカスします。
プロジェクトが始まるとまず、PMOは教訓のデータベースからリスクを抽出し、プロジェクト管理プロセスを改善するなどして、その成果物をプロジェクトマネジャーに提供します。プロジェクトマネジャーは、これらの成果物を基にプロジェクト計画書を作成し、プロジェクトを正式に開始します。これが教訓を活用するプロセスでした。
PMOとして重要な仕事は、教訓の蓄積サイクルをプロジェクト計画書に明記しておき、教訓の蓄積サイクルは非常に重要なプロジェクト管理プロセスだということをメンバーに周知徹底することです。その土壌があってこそ、様々な問題への対処を通じて得られた「教訓」を形式知にして残そう、という活動につながります。下図の（2）は、こうした活動そのものと、それを支援するための土壌作りを指しています。
（3）と（4）は、リスク管理や課題管理プロセスの中から教訓を抽出・検証する作業を指します。一般に、プロジェクトの計画フェーズではリスクを洗い出し、リスク管理を実施します。また、実施フェーズのなかでリスクを発見すれば、それをリスク管理表に追加し、課題が発生すれば課題管理表に記入して管理していきます。さらに、リスクが顕在化したら、それを「課題」と捉えて課題管理表に移し、対策を立てて実施します。
一連のプロジェクト管理プロセスにおけるPMOの重要な仕事は、「新たに発生したリスクは、計画フェーズで予見可能だったか」を検証することです。検証の結果、予見できなくても仕方がないリスクの場合は、それを新たに教訓として追加します。同様のリスクが教訓として存在していたにもかかわらず、今回リスクとして抽出できなかった場合は、「どうしてそのリスクを事前に予測できなかったのか」を検証する必要があります。そのような活動を通して、教訓をためるだけでなく、「どうすれば教訓を生かせるか」という重要な“教訓”が蓄積されていくのです。
次にPMOとして重要なタスクは、（5）のように、課題に対する対応の実績を整理することです。プロジェクトの課題管理表には課題とその対策、対応方法が記述されていますが、その結果がどうなったのか、きちんと書かれているでしょうか。私が経験してきたプロジェクトでは、単に「完了」とだけ記入されているケースが多く見られました。メンバーから見れば、「課題が解決すれば、それで完了」という気持ちが強いのはよく理解できます。
しかし、課題に対応する作業のなかにも教訓は含まれています。「最初の対応方法が失敗したのはなぜか」とか、「こう対処していれば、もっと短時間で済んだ」などです。
課題管理表に対応結果や気づきが記述されていれば、そこから教訓を抽出して蓄積できます。PMOは、対応結果から得られる教訓の重要性を周知し、メンバーをナビゲートする必要があります。
教訓の蓄積はリアルタイムがベスト
プロジェクトが終了すると、メンバーが集まって振り返りを実施し、その内容を含めた完了報告書を作成します。これが（6）です。さらに、振り返りから新たな教訓を抽出して形式知にするのが（7）です。ここで、重要なポイントが2つあります。
1つは、振り返りの場で話す内容です。プロジェクトの最中に整理してきた教訓の候補に対し、本質的な原因を探ったり、より効果的な改善策を検討したりすべきです。
避けてほしいのは、「さあ、みなさん。プロジェクトを振り返って、教訓を出してください」という問いかけです。メンバーは思い出すのに時間がかかり、教訓があまり出てこない恐れがあります。しかも普通のプロジェクトでは、終盤に向かうに従ってメンバーが減っていきます。振り返り時にはメンバーがほとんど残っていない可能性もあるのです。
実のある振り返りを実施するには、PMOが中心となってリアルタイムに教訓を蓄積していくべきです。振り返り時には、メンバーが生の教訓から「他のプロジェクトに伝えるべき教訓」を導き出せるよう、準備しておくのです。
もう1つは、振り返りに参加するメンバー構成です。協力会社を含めた現場担当者全員に参加してもらいましょう。参加メンバーが多い場合は、プロジェクトを離れる際に教訓になるべきことがなかったか、アンケートを行うのも手です。
なぜ、そうするのか、理由は簡単です。元請けや一次請けのメンバーのみで振り返りをすると、実際に現場で何が起こっていたのか、詳細を把握できていないケースが多いからです。
ましてや、元請けのメンバーが「協力会社の管理能力が悪かったので、協力会社の管理能力を事前に厳しくチェックする」といった教訓を挙げてしまうと、単なる責任転嫁になってしまいます。なぜ協力会社の管理能力が悪かったのか、本当の原因が分かりません。もしかしたら、元請けが仕様変更をコントロールできなかったため、協力会社の管理が混乱してしまったのかもしれないのです。
真の原因が分かっていないのに、それを教訓とするのは危険です。教訓を生かそうとする将来のプロジェクトで、かえってリスクを高めてしまう可能性があります。これを避けるには、PMOが中立的な立場で、その教訓の妥当性を厳しくチェックする必要があります。
プロジェクトを完了に導いた後、その成功体験や失敗体験から教訓を導き出し、蓄積し続けていくことは、根気と労力がいる仕事です。だからこそ、PMOが日々のプロジェクト運営に仕組みとして組み込んでしまい、教訓が自動的にたまっていくようにするのです。教訓はプロジェクトの事例が多ければ多いほど蓄積され、信頼性も高くなっていきます。