学んだこと - 目標、ワークショップ、実践的なヒント

広告

Lessons Learned(教訓)とは、人々がプロジェクトの過程で得た経験、知識、洞察力、理解を表しています。教訓は、さまざまなレベル(技術的、内容的、感情的、社会的、プロセス的)のポジティブな側面とネガティブな側面の両方を扱います。

特に問題に対処する際、プロジェクトではポジティブな経験もネガティブな経験も継続的に収集されます。このような知識を他の人が利用できるようにすれば、将来のプロジェクト成功の確率が高まり、失敗やエラーを防ぐことができます。

方法-教訓

"Lessons Learned "とは、プロジェクトで行われた経験(ポジティブなもの、ネガティブなもの)を体系的に収集し、そこから結論を導き出すことで、今後の計画やプロジェクトの取り扱いを改善するための手法である。この手法は、プロジェクトマネジメント手法のツールボックスの一般的な構成要素となっている。

この手法は、プロジェクト・レトロスペクティブと呼ばれることが多く、ナレッジマネジメントの古典的なアプローチです。

通常、「教訓」という手法は、プロジェクト終了後の文脈で実施されます。プロジェクト終了時に「教訓」を実施することは多かれ少なかれ確立されていますが、この貴重な知識を実際に新しいプロジェクトに活用することは、残念ながらまだ非常に限られています。

広告

目標-教訓

Lessons Learned」の目的は、獲得した経験や知識を体系的に収集、統合、文書化し、同様の課題に直面している社員がアクセスできるようにすることです。将来のプロジェクトチームは、これらの経験から恩恵を受けるべきであり、すでに犯した過ちは避けるべきです。また、プロジェクトの成功確率を高めるために、実績のある方法を用いるべきです。

  • プロジェクトで得た知識の確保
    - ポジティブな経験とネガティブな経験
    - 技術的な知見
    - プロセスはどうだったか
  • プロジェクトで得た知見を他の人にも見えるようにする
  • ライン組織のためのインサイトの可視化
  • 得られた知識は、どこに改善の余地があるかを明確に示してくれるので、企業内のプロジェクトマネジメント基準を(さらに)発展させるための優れた基礎となる。

想定される状況としては、まず

  • プロジェクトは完成し、ラインに引き渡されました。
  • プロジェクトは最終段階に入っています。
  • 内容的には、いくつかの残務を除いて、ほぼすべてのプロジェクト活動が完了しています。
  • プロジェクトチームの雰囲気は、すべての目標が合意された通りに達成されたことによる幸福感や安心感、あるいはプロジェクトで何か問題が発生したことによるフラストレーションや感情的なものである。

教訓のための適切な時期

レッスン・ラーンド・プロセスの詳細な計画を立てる前に、2つの重要な質問をする必要があります。

  • Lessons Learnedを実行するタイミングは適切か?
  • 現在の状況に照らし合わせて、どのようにして実装を最適に設計することができるか。

プロジェクトはそれぞれ異なるため、この2つの質問に一概に答えることはできません。基本的には、プロジェクトがどのように進行したか、プロジェクト期間中のチームの雰囲気はどうだったか、そして現在どうなっているかによって判断しなければなりません。

ムードパラメータがかなり冷え込んでいることを示している場合、「教訓」は延期すべきである。少し時間が経てば、多くのことをより感情的にならずに見ることができます。しかし、時間をかけすぎてもいけません。目安としては、プロジェクトが完了してから6週間以内に教訓集を完成させるべきです。

古典的には、「教訓」はプロジェクト完了後にプロジェクト完了文書の一部として収集されます。

アプローチと質問

プロジェクトチームやその他の主要なプロジェクト参加者と一緒に作業することが重要です。この作業は、プロジェクト完了時に行うこともできるし、プロジェクト完了後(最大で6週間後)にワークショップや個別インタビューなどで行うこともできる。後の開発では、従業員がすでにいくつかの物事をより感情的でない方法で見ることができるという利点があります。

疑問点は2つあります。

広告
  • 何が良かったのか?
  • 何が悪かったのか?

この2つの質問に答えた後、うまくいかなかった点について、具体的な改善案を作成します。すぐに実行できるものばかりではありませんが、今後のプロジェクトを継続的に改善していくための良い基盤となります。

さらに考えられる質問の例

  • 一人ひとりがプロジェクトの中で自分自身に何を学んだのか。
  • どの結果がライン組織にとって重要なのか?
  • 今後のプロジェクトで何を変えていくべきか?
  • 今後のプロジェクトで残すべきものは?

レッスン・ラーンド・ワークショップ

最も一般的なアプローチは、関連するプロジェクト参加者を一堂に集め、ワークショップの形でプロジェクトの開発プロセスを一緒に見直すことです。その際、得られた経験や知識を体系的に文書化する必要があります。グループでの作業は、常に創造的で共同作業的なプロセスであり、自動的に質の高い結果が得られます。

ワークショップの準備

  • どのような目標を達成するのか?
  • 何を詳細に検討するのか?
  • 技術やコンテンツに関わる部分に焦点を当てるのか、それともプロセスの経過を振り返ることが重要なのか。それとも両方?
  • 社会性と情動のレベルも反映させたいのであれば、より多くの時間を計画しなければなりません。
  • お客様との調整。彼のアイデア、希望、提案が考慮されないままであってはならない。
  • 誰がワークショップのモデレーターを務めるのですか?特に、納期や予算が大幅に超過し、チーム内の大きな緊張感が明らかになっているプロジェクトでは、「外部」の人間によるモデレーションが推奨されます。
  • ワークショップに参加すべき人を決める。プロジェクトチームだけでなく、プロジェクトクライアントや外部のプロジェクトスタッフも貢献できます。
  • ワークショップの手順を示すプロセスデザインの作成。プロセスデザインは台本に例えると、誰が何をどのようにして、どのくらいの時間をかけなければならないのかをポイントごとに記録したものです。考察のための典型的な質問は以下の通りである。
    - プロジェクトでうまくいったこと、うまくいかなかったことは何か?
    - 今後、プロジェクトでは何を違った方法で行うべきか?何を変えるべきか、変えなければならないか?

部屋の予約

  • ワークショップに必要な備品の手配(フリップチャート、ピンボード、ビーマー、モデレーションケースなど
  • アジェンダを作成し、イベントの大まかな流れと時間構成を確認します。
  • アジェンダを送信することで、参加者全員をタイムリーに招待することができます。ヒントワークショップへの参加が特に重要な人たちと事前に日程を調整する。

ワークショップの実施

ワークショップの実行は、脚本のデザインにかかっています。事前によく考えられて計画されたものが、1対1で実行されます。小さな軌道修正は、必要に応じて、もちろん許されます。次のような模範的な手順が実証されています。

  • 参加者の歓迎
  • ワークショップの目標、スケジュール、時間構成の提示
  • ワークショップの「ゲームのルール」についての合意。何が許され、何が許されないのか。参加者の輪の中からの提案は、それが支持的で建設的なものであれば、受け入れるべきである。
  • 振り返りは、参加者全員が課題を理解してから始めてください。全員が何をすべきかを知っていることが重要です。
  • すべての結果が構造的で読みやすい方法で文書化されていることを確認する。
  • 遅くとも2時間後には休憩を取るべきである。コーヒーと小さなスナックを食べながら、内省を続け、時には構造化されたユニットよりも集中的に行う。
  • 反映が完了したら、どのように進めていくか、結果をどうするかを詳細に合意する。
  • 最後には、参加者のグループに建設的なフィードバックの機会を設ける。

ワークショップでの後処理

  • ワークショップの成果を写真で記録し、フォトプロトコルを作成して、参加者全員にタイムリーに送付する。
  • 将来のプロジェクトが豊富な経験にアクセスし、その恩恵を受けられるように、結果やデータ資料を社内の責任者に引き渡す。
  • 企業内の責任ある組織単位としては、「プロジェクトマネジメントオフィス」、「組織部」、「品質管理」などが考えられます。
  • もし、あなたの会社にこれらの「責任」が存在しないのであれば、適切な人にその問題を指摘し、プロジェクト・マネジメントをさらに発展させるための経験、知識、ノウハウが、ここの砂の中にどれだけ使われずに眠っているかを指摘してください。

現場からのお役立ち情報

  • 教訓は、プロジェクトチームだけでなく、プロジェクトのクライアントや外部のプロジェクトスタッフ(相互の影響を排除するために、場合によっては個別に)に対しても実施されるべきである。
  • 主な調査結果は、すべての参加者がアクセスできるようにする。
  • 少ないことは多いことです。特に、価値を証明したものと、うまくいかなかったものがあります。このようにして、重要な情報を一目で把握することができます。
  • この教訓には、将来の同様のプロジェクトに対する提言も含まれます。
  • 例えば、すべてのプロジェクトの教訓(または少なくともそのコピー)を集中的にアーカイブすることで、結果の検索性を保証する必要があります。
  • プロジェクトで同じ問題が何度も発生するようであれば、全社的、エリア的な改善策を講じる理由になります。

レッスンを成功させるための一般的な条件

これまでの経験から、獲得した知識が他の人に再利用される確率を高めるには、3つの基本的な条件が必要であることがわかっている。

  • 失敗や問題点を率直に話し合える社風
  • 社内のプロジェクトを処理するための標準化された手順で、「学んだ教訓」の文書化が義務付けられている
  • このノウハウを収集して文書化し、そこから得られた知識を使ってプロジェクト作業を最適化する責任を負う企業内の担当者または部署(プロジェクトマネジメントオフィスなど)。

これらの基本的な条件が満たされていれば、過去のプロジェクトで得た情報や経験が宝の持ち腐れになるのではなく、将来のプロジェクトに活かされたり、過去の失敗が活かされたりする可能性がかなり高くなります。なぜなら、失敗は許されるからである。そこから学び、同じ失敗を繰り返さない限り。

獲得した知識はなぜほとんど使われないのか?

レッスン・ラーンド」は、比較的簡単に実施できる方法です。それにもかかわらず、このような知識活用の方法が使われることは非常に少ない。プロジェクトで得た経験を文書化しようとしないことが非常に多い。しかし、たとえプロジェクトの終わりに文書化されたとしても、将来的にその情報を緊急に必要とする従業員が、その情報にアクセスしたり、その情報を利用したりできるかどうかは定かではありません。

非常に少数の組織では、獲得した知識を、緊急時(それは多くの場合、もっと後になる)に従業員が利用できるような方法で収集し、処理することが可能です。失敗の理由については推測するしかありません。

  • 情報を収集するはずのプロジェクトチームには、通常、直接的な利益はなく、逆に当面は追加費用が発生するだけである。
  • それをしなければならない義務(全社的なPM基準など)はありません。
  • 人は、ポジティブな成果や結果については話したがりますが、ネガティブな結果については黙っていたがります。
  • 多くの場合、プロジェクトが成功し、時には比較的面倒な作業を終えた後、関係者はそれが終わったことを喜んでいます。もう一度、すべてを「ウォームアップ」するモチベーションは非常に低い。
  • 情報が収集されたとしても(プロのプロジェクトマネージャーはそれを強く要求する)、書類は紙のアーカイブや会社のサーバーのハードディスクの無限の広がりの中に消えてしまうことが多い。そこでは毎日バックアップが取られているが、誰もその存在を知らないし、必要なときに情報を見つけることもできない。