プロジェクトを失敗させないヒント32『教訓の「活用」をいかに促すか』

目次

    『プロジェクトを絶対に失敗させない!やり切るための100のヒント』とは

    『プロジェクトを絶対に失敗させない!やり切るための100のヒント』とは

    本記事は、プロジェクトを成功させるために必要なノウハウを、数百の支援実績経験をもとに記述した『プロジェクトを絶対に失敗させない!やり切るための100のヒント』より、 1つずつヒントをご紹介していく企画です。プロジェクトマネジメントについて、何らかの気づきを得るきっかけになれば幸いです。

    当社はプロジェクトマネジメントの知識と経験を有し、皆様のプロジェクトが成功するお手伝いをさせていただいております。 プロジェクトマネジメントに関する疑問や課題がある方、成功への道筋をお探しの方、どうぞお気軽にご連絡ください。
    お問合せはこちらからどうぞ。

    ※『プロジェクトを絶対に失敗させない!やり切るための100のヒント』をPDFまたは電子書籍でダウンロードできます

     


     

    ※本文は書籍出版時のオリジナルのまま公開しております

    PMBOK(第4版)を通読した人はお分かりだと思いますが、9つの知識エリア(統合、スコープ、時間、コスト、品質、人的資源、コミュニケーション、リスク、調達)において、教訓の活用、および教訓の蓄積が述べられています。『[ヒント31]プロジェクト運営の「失敗学」』で解説したように、プロジェクト運営のなかでPMOは「良い失敗」から教訓を学び、「悪い失敗」を発生させないという重要な役割を担っています。ですが、システム開発の現場では、教訓の活用・蓄積が定着できていないのが実情です。

    失敗から教訓を学び、蓄積して活用せよと言われても、どうすればいいのか、PMBOKを読んでも具体的な答えは書かれていません。そこでPMOとして何を考え、どのように行動すべきかを述べたいと思います。

    PMOには進捗管理、課題管理、リスク管理など、プロジェクト運営における重要な仕事が多くあります。PMOがこのようなプロジェクト管理をしっかり行えば、プロジェクトが成功する確率は高くなります。

    しかし、そのプロジェクトが終わり、反省も総括もしなければ、そこで得られた経験や教訓はメンバー個人の中にしか蓄積されません。あるプロジェクトで大小様々な失敗を経験したとしても、そこでの教訓は他のプロジェクトには生かされず、当然ながら同じような失敗を繰り返す確率が高くなります。それは、会社全体から見ればとても非効率です。

    PMOのミッションの1つは、プロジェクト関係者の調整を行うことですが、それはプロジェクト内に閉じた話と考えるべきではありません。PMOは、プロジェクトをまたがった横断的な活動を行う組織です。蓄積された教訓を活用し、得られた教訓をさらに蓄積・昇華していくことは、PMOの一番大きな組織貢献活動だと言ってもいいでしょう。PMOのメンバーが、参画プロジェクトの成功のために貢献するのは当然ですが、将来のプロジェクトを成功に導くための貢献も必要という視点で行動できれば、これほど会社にとって素晴らしい組織はありません。

    教訓を活用・蓄積する7つのプロセス

    PMOとして教訓をどうやって活用・蓄積していけばよいのでしょうか。下図を見てください。(1)は教訓の活用プロセス、(2)~(7)は教訓の蓄積サイクルを表します。まずは教訓の活用プロセスから考えましょう。
    ヒント32画像

    組織によっては、教訓がまだ1つも蓄積されていない場合があります。そのような場合は、同じようなプロジェクトを経験したプロジェクトマネジャーや有識者へのヒアリングから始めることになります。教訓や有識者からのヒアリングを基に、PMOはプロジェクト管理プロセスを改善したり、プロジェクトリスクを抽出してリスク管理表にまとめたりします。

    この時に重要なのは、プロジェクト特性を考慮して教訓やリスクをチューニングすることです。チューニングをするとは、参加するプロジェクトにおいて、教訓や考えられるリスクをそのプロジェクトに当てはめて考え直してみるという作業です。

    例えば、「プロジェクトの開始前までには、該当業務を知っているメンバーを確保すること」という教訓があったとしましょう。あるいは、プロジェクトにおいて「該当業務を熟知しているメンバーがいない」というリスクが抽出されたと仮定します。この時のチューニングの要素として、「期間が短く、専門性が非常に高い」というプロジェクト特性があったら、どう考えるべきでしょうか。このケースでは「該当業務に精通している協力会社を探す」とか、「ユーザーに、プロジェクトへの専任要員を要請する」などがリスクへの対応策になります(厳密には既に発生したリスクと考えられるため、課題とみなされます)。

    もし、チューニングの要素として、「期間が長く、研修を受ければ専門知識を学習できる」というプロジェクト特性の場合はどうでしょうか。「プロジェクトに該当業務を理解するための学習期間を設ける」、または「外部の専門

    的な研修をメンバーに受講させる」といった対応策になると思います。

    全く同じプロジェクトというものは、1つとして存在しません。従って、蓄積された教訓を他のプロジェクトに生かすには、プロジェクトの特性を考慮してカスタマイズすることが必要です。チューニングの要素には、プロジェクトの「開発規模」や「業務の難易度」、プロジェクトマネジャーの「経験」など、様々な要素があります。しかし、教訓に対してこれらの要素がどのように影響し、どうチューニングすべきなのかは、それこそプロジェクト運営のなかで検証を繰り返しながら、地道に蓄積する以外に方法がありません。