私は最近、『The Declassification Engine』という素晴らしい本を読み終えました。この本は、一見プロジェクト管理とは 関係もないように見えました (私は分野を広げようとしていたのです 🙄)。しかし、3分の1ほど読み進めたところで、著者のマシュー・コネリーが「我が国の歴史を分類しない問題」と表現していたこととの類似性に驚愕した。 何の 私の人生とこの本のサブプロットが結びついているのは、教訓から得た優れた戦略が組織だけでなく国家 (つまり米国) に何ができるのかという現実です。コネリー氏は、「歴史を知らない者は歴史を繰り返す運命にある」という格言のきっかけとなりかねない事実を見事に提示している。 (-エドマンド・バーク)。 私たちが確実に同期していることを確認するために、コネリーの本のクイック バージョンを以下に示します。「機密解除エンジン」では、コネリーは、彼と彼のチームが米国政府の機密扱いと機密解除のシステムをどのように調査したかについて説明し、特に過度の機密性と機密扱いによる悪影響について言及しています。歴史的記録の破壊。 この秘密と破壊の文化が民主主義を弱め、過去に対する私たちの理解を妨げていると彼は主張する。 それ この部分は、まさに私たちがプロジェクトマネージャーとして、プロジェクトから得た教訓を活かすための計画を実行するという単純な作業に集中していないときに起こることです。チームが解散するか、別のプロジェクトを開始する場合は、書き留めていない場合は情報を破棄すると考えたほうがよいでしょう。新しいプロジェクトに着手したとき、なぜ誰も学んだ教訓を追跡しないのかと不思議に思いました... 下線付き 大きな秘密は何ですか? 教訓を追跡する理由 プロジェクト管理やプログラム管理、あるいは長期にわたるタスクであっても、学んだ教訓を文書化して適用するプロセスは、継続的な改善と将来の取り組みの成功にとって非常に重要です。学んだ教訓は、組織が成功を活かし、過去の間違いを回避し、非効率な領域を特定し、 防ぐのに役立ちます。この情報を取得することは、ベスト プラクティスの開発やビジネス プロセスの改善にも貢献できます。 エラーの繰り返しを 政府の歴史家でもプロジェクトマネージャーでも、透明性、文書化、過去の経験から学ぶことの重要性が明確に強調されています。コネリー氏が国民の理解を高めるために、より透明性があり説明責任のある分類システムを提唱しているのと同じように、プロジェクト マネージャーは学んだ教訓を活用して、チームや組織内での透明性と説明責任を促進します。 学んだ教訓を活かす 最も簡単に言うと、1 日に数分しかかからず、その日を通じて役に立った、奇妙な、または変更する必要があると感じた考えや問題を書き留めることができます。私はすべてのプロジェクトの実行中の生のデジタル ログを (Obsydian または Notion 経由で) 保存しており、それらのメモは学んだ教訓を記憶に呼び起こすのに役立ちます。以下に、従うべきベスト プラクティス (帰属) をいくつか示します。 : プロジェクト マネージャー、プロジェクト チーム、主要な関係者を教訓演習に参加させます。これにより、さまざまな視点からプロジェクトを包括的に理解できるようになります。 (  ) チーム全体と関係者を参加させる 学んだ教訓を理解するためのガイド : プロジェクトの複雑さに応じて、各プロジェクト管理フェーズの最後に教訓セッションを実施して、情報がまだ新しいうちに情報を収集します。これにより、何がうまくいき、何がうまくいかなかったのか、そしてそこから何を学ぶことができるのかをタイムリーに評価することができます。 ( ) 定期的なレビューの実施 アサナ : 学んだレッスンを、チーム メンバー全員が簡単にアクセスできる中央リポジトリに保存します。これにより、教訓が確実に取得可能になり、将来のプロジェクトの指針として使用できるようになります。 (  ) レッスンを中央リポジトリに保存する シンプルラーニング : チームと一緒に過去のレッスンを復習することを必須の部分にします。これは学習を強化し、過去の間違いを繰り返さないようにするのに役立ちます (Simplelearn) 過去のレッスンを復習する 教訓テンプレートのサンプル これが私の個人的な最低限のテンプレートです。 プロジェクト名 |開始日 |終了日 スポンサー、主要な関係者、チームメンバー (および電子メール) 予算 プロジェクトが開始されたとき (これは知っておくとよいため、発生した問題と照らし合わせると、既知ではあるが無視されていた問題があった可能性があります) 既知の問題点 学んだ教訓 何が問題でしたか? それはプロジェクトにどのような影響を与えましたか? 問題はどのように修正、処理、または無効化されましたか? この特定のタイプの問題が別のプロジェクトで発生した場合は、何を別の方法で実行する必要がありますか? スポンサーまたは上級関係者 (または顧客*) が学んだ教訓を検討したことを示す署名。 これらはすべて非常に簡単です。  番目の作業は、教訓から学んださまざまな問題ごとに行う必要があります。項目 については、これは必ずしも必要というわけではありませんが、食物連鎖の上流にいる人がプロジェクトまたはチームが抱えている問題を確実に認識できるようになります。最悪の場合は「ありがとう」と言われますが、最良の場合は、全員が読めるように送信されます。 5 6 使用できる例として、他のサイトをいくつか紹介します。   将来のプロジェクトに役立つ洞察を得るために使用できる、最も優れた教訓テンプレートのリストを提供します。これらのテンプレートは、包括的で使いやすいように設計されています。 ClickUp は、   あらゆる種類の専門家向けに構築された対話型のレッスン学習テンプレートを提供します。このテンプレートは、チーム メンバーが完了したプロジェクトのポジティブな経験とネガティブな経験の両方をレビューするのに役立ち、日常の管理、コミュニケーション、技術的要素、および全体的なプロジェクト管理をカバーするように構成されています。 Monday.com は、   教訓から学んださまざまなテンプレートを Excel および Word 形式で提供しています。これらのテンプレートは、プロジェクトから学んだ教訓を文書化して分析する場合に強く推奨されており、プロジェクトの定義、文書化するチーム メンバーの選択、情報の保存、学んだ教訓の広め方をガイドします。 TemplateLab は、 結局のところ、私たちまたは私たちのチームが間違ったことを二度と起こさないようにするのは私たちの責任です。 そして、この特定の種類のプロジェクトを完了するための秘密のソースを見つけた場合は、必ずそれも捕らえてください...それは 絶望的なものではありません。 すべてが 学んだ教訓のコピーを顧客に提供することを選択した場合、チームや会社の内部問題が含まれないようにフィルターをかけることを ますか?それはあなたとチームの間で秘密にしておいてください。 提案でき   でも公開されています。 ここ

The writer was physically present in relevant location(s) to this story. The location is also a prevalent aspect of this story be it news or otherwise.

This writer has a vested interest be it monetary, business, or otherwise, with 1 or more of the products or companies mentioned within.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Read My Stories

このオーディオは、ストーリーの元の言語で制作されています。

長すぎる; 読むには

Download free Tech Leaders Productivity Report!

効果的なプロジェクト管理のために学んだ教訓を捉えて応用する技術

About Author

コメント

ラベル

この記事は

Related Stories

HackerNoon Coded: HackerNoonが最も活発に活動している上位10カ国

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

ユニークなエコシステムを支えるビットコインUTXOのモデル

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

HackerNoon Coded: HackerNoonが最も活発に活動している上位10カ国

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

ユニークなエコシステムを支えるビットコインUTXOのモデル

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps