プロジェクト管理:31のベストテクニック、プラクティス、およびツール

公開: 2022-05-07

プロジェクトを成功させるには、プロジェクトを適切に管理する必要があります。これを行うための最良の方法は、作業しているプロジェクトのタイプに適したプロジェクト管理手法を使用することです。

この記事では、次のことがわかります。

  • プロジェクト管理とは何ですか? (+その重要な要素のいくつか)
  • プロジェクト管理手法とは何ですか?
  • いつ使うべきですか?
  • それらをどのように適用する必要がありますか?
  • さまざまなプロジェクトタイプに最適な14のプロジェクト管理手法は何ですか?
  • 使用するプロジェクト管理手法に関係なく、プロジェクト作業を支援するために使用できるベストプラクティスとツールは何ですか?

それ以上のことを学ぶために、読み続けてください。

プロジェクト管理:31のベストテクニック、プラクティス、およびツール

目次

プロジェクト管理、その要素、および手法の概要

このセクションでは、プロジェクト管理、その要素のいくつか、および手法について学習します。 それらをいつ使用する必要があるか、およびそれらをどのように適用できるか。

プロジェクトとは何ですか?

プロジェクト管理手法とは何かを理解するには、まず「プロジェクト」を構成するものと「プロジェクト管理」とは何かを理解する必要があります。

プロジェクトには、事前定義された目標を達成するために個人または人々のグループが行う必要のある特定の一連の操作が含まれます。 各プロジェクトには、プロジェクトを成功と呼ぶために満たす必要のある特定の一連の要件があります。

プロジェクトの最後に、結果を分析します。 ここで、これらの分析を実行するには、適切なデータが必要です。たとえば、プロジェクトタイムトラッカーを使用してプロジェクトに費やした時間を追跡し、このデータを分析に使用できます。

プロジェクト管理とは何ですか?

プロジェクト管理は、プロジェクトの一連の要件を満たすために必要な特定の一連の操作を実行するための、スキル、経験、および適切なツールの適用です。 プロジェクト管理の一般的なプロジェクトタイムラインには、プロジェクト開発の次の5つのフェーズが含まれます。

  1. 構想と開始
  2. 定義と計画
  3. 起動と実行
  4. パフォーマンス、監視、および制御
  5. 閉鎖

作業に実装できる特定のプロジェクト管理ツールについては、最高のプロジェクト管理ツールの最も信頼のおけるガイドをご覧ください。

プロジェクト管理の4つの重要な要素

プロジェクトの予算、品質、範囲とは別に、業界やプロジェクトの複雑さに関係なく、プロジェクト管理の重要な要素のいくつかに特別な注意を払いたいと思います。

1.プロジェクト憲章

プロジェクト管理のプロジェクト憲章は、プロジェクトの開始に使用される簡潔な正式な文書です。 プロジェクト憲章は、プロジェクトの目的、目標、リソース、および利害関係者を示しています。 それはあなたのチームに:

  • プロジェクトの目的を定義する
  • プロジェクトの測定と仮定を行う
  • プロジェクトの制限を定義する
  • プロジェクトスコープステートメントを定義する
  • プロジェクトマネージャーの権限を選択します
  • チームを編成する

プロジェクト憲章は、プロジェクトのスポンサーによって作成および提供され、後でプロジェクトマネージャーに委任されます。 基本的に、すべてのプロジェクトにはプロジェクト憲章が必要です。これは、プロジェクトをその目標と成功に導くためのガイドラインとして機能するためです。

以下の視覚的表現では、プロジェクトの目標を定義し、利害関係者、コスト、リスクなどを特定するプロジェクト憲章の主要なコンポーネントを見ることができます。

プロジェクト憲章

2.成果物リストとタスクリスト

成果物リストは、プロジェクトの完了時に達成される最終的な製品またはサービスを表します。 成果物は、たとえばコンピュータなどの有形のものでも、コンピュータプログラムである無形のものでもかまいません。

タスクはリストの最下位レベルとして扱われます。各タスクは、成果物または一連の成果物を完了するために実行する必要のあるアクションまたはステップを表します。

作業分解図と成果物リストおよびタスクリストの違いは、後者が各タスクの責任者を厳密に定義することです。 各タスクまたは成果物の期限を定義して、作業をより細かく制御することもできます。

これらすべてに加えて、リストを単純なチェックリストとして組み立て、各タスクと成果物をチェックして進捗状況を追跡することができます。

成果物とタスクリスト

3.プロジェクトスケジュール

プロジェクトスケジュールの作成には、実行するタスクの順序付けと、プロジェクトを完了するためのカレンダーのタイムスロットへの割り当てが含まれます。 タスクを定義し、タスクを完了するために必要なリソースを定義し、タスクを特定のチームメンバーに割り当ててから、カレンダーの特定のタイムスロットにタスクを割り当てます。

効率的なプロジェクトスケジュールの作成に問題がある場合は、次のことを自問することを検討してください。

  • 何をする必要がありますか?
  • いつ?
  • 誰がその責任を負いますか?

これらの質問に答えることは、後で実行可能なプロジェクトスケジュールを形成するタスクリストを作成するのに役立ちます。

以下のプロジェクトスケジュールの視覚的表現を見てください。 パーティーの計画には特定のタスクの完了が必要であり、タスクごとに、カレンダーに特定のタイムスロットが割り当てられていることがわかります。

プロジェクトスケジュール

4.リスクレジスター

プロジェクト管理でリスクレジスターを作成するということは、プロジェクトでの作業中に遭遇する可能性のある潜在的な問題と課題に焦点を当てることを意味します。

これらの潜在的な問題は「負のリスク」とも呼ばれます。それらを予測し、書き留め、深刻さを明確にしてから、解決策を定義する必要があります。 また、これらのソリューションの実装の責任者を明確にする必要があります。

もちろん、作業中に「前向きなリスク」に遭遇することもあります。これらは、個別のプロジェクトとして定義し、個別に取り組む必要がある追加の「プロジェクトの機会」です。

以下の表では、特定のリスクとそのリスクマトリックスの例を示しています。プロジェクトのリスクの可能性、その影響のレベル、リスク管理の担当者、および考えられる解決策です。

リスクレジスター

プロジェクト管理手法とは何ですか?

プロジェクト管理とプロジェクト管理手法の主な違いは、特異性です。 したがって、プロジェクト管理手法は、プロジェクトの一連の要件を満たすために必要な特定の一連の操作を実行するために、スキル、経験、および適切なツールを適用するためのプロジェクト管理手法とは何か、およびそれらがプロジェクトとプロジェクト管理にどのように関連しているかを理解したところで、それらをいつ最適に使用すべきかを見てみましょう。

プロジェクト管理手法をいつ使用するか?

現在、広く使用されるように思われる定義にもかかわらず、プロジェクトごとに特定のプロジェクト管理方法を使用する必要はありません。

場合によっては、プロジェクトタスクの単純で直線的な編成で十分です。

ただし、他の場合には、特定のプロジェクト管理手法が最も効率的なソリューションです。

プロジェクトで特定のプロジェクト管理手法を使用する必要があることを示す7つのプロジェクト要素を次に示します。

  1. より大きな努力—プロジェクトの目標は、特定の製品を作成することです。
  2. より重要性—プロジェクトは会社にとって非常に重要です。
  3. より高いリスク—プロジェクトは、不確実性要因の数が多いため、会社にとってより高いリスクを表します。
  4. 現在の管理構造の有効性の低下—現在の管理構造には、期限を過ぎている、予算に違反している、または特定の要件セットを見逃しているプロジェクトが含まれます。
  5. 不慣れ度が高い—プロジェクトは、範囲または予想される作業ルーチンのいずれかにおいて、「通常」とは異なります。
  6. 高い相互関係—プロジェクトでは、タスクを同時に実行する必要があります。
  7. 組織の評判または財務状況への影響—プロジェクトは、正しく処理されない場合、深刻な評判または金銭的損失をもたらす可能性があります。

リストされているすべての要素は、作業に取り掛かる前に特定のプロジェクト管理手法を選択する必要があることを示しています。

プロジェクト管理手法を適用する方法は?

プロジェクト管理手法の適用は、作業しているプロジェクトのタイプ、および使用するために選択した手法によって異なります。

現在、プロジェクトに適したプロジェクト管理手法を見つけるための最善の解決策は、いくつかのプロジェクト管理手法をテストして組み合わせることです。 作業を進めるにつれて、自分とプロジェクトに役立つプラクティスとそうでないプラクティスを特定できる可能性があります。

それを念頭に置いて、最高のPM手法と方法論のリストに移りましょう。

最高のプロジェクト管理手法と方法論のリスト

このセクションでは、今日使用できる14の最高のプロジェクト管理手法と方法論について学習します。

プロジェクトのタイプに基づいて、3つのタイプのプロジェクトを区別し、プロジェクト管理手法を次の用途に最適かどうかに基づいて分類します。

  • シンプルなプロジェクト
  • 複雑なプロジェクト
  • ソフトウェアエンジニアリングプロジェクト

もちろん、これらのタイプのPM方法論のいくつかは重複する可能性があります。達成しようとしていることに応じて、ソフトウェアエンジニアリングにいくつかの単純および複雑なプロジェクト管理手法を使用できる場合があります。

特定の業界で使用されているか、プロジェクトの複雑さに基づいているかにかかわらず、実際には多数のプロジェクト管理手法があります。 ただし、プロジェクトを成功に導くために、すべてのプロジェクトマネージャーが知っておくべきプロジェクト管理手法があります。

それでは、それらから始めましょう。

すべてのプロジェクトマネージャーが知っておくべきトップ3のプロジェクト管理手法

これらは私たちのおすすめです:

  1. 古典的なプロジェクト管理手法
  2. かんばんプロジェクト管理方法論
  3. プログラム評価およびレビュー手法(PERT)

これらの手法を使用して知識を向上させ、プロジェクト管理の分野で驚くべき結果を達成してみてください。

1.古典的なプロジェクト管理手法

これは、プロジェクトの実行に最も簡単で最も適切な1つである従来のプロジェクト管理手法です。

従来のプロジェクト管理手法とは何ですか?

従来のプロジェクト管理手法は、プロジェクト管理で最も単純で最も頻繁に使用される手法の1つです。 これには、実行する必要のあるすべてのタスクとアクティビティを含む詳細な計画が含まれています。 やるべきことは、その緊急性と依存性に基づいて整理されます。

従来のプロジェクト管理手法の使用方法は?

この手法をプロジェクトに正常に適用するには、次の手順に従う必要があります。

  1. まず、次の週のプロジェクトの計画を立てます。
  2. 次に、作業する必要のあるタスクの数と種類を見積もります。
  3. リソースを割り当て、
  4. プロジェクト全体を通してチームの作業の質を監視し、
  5. プロジェクト全体を通してチームの締め切りを監視し、
  6. プロジェクト全体を通してチームにフィードバックを提供します。
従来のプロジェクト管理手法の簡単な歴史

この基本的なタイプのプロジェクト管理は、全体として1950年代に始まりました。 ただし、プロジェクト管理の最初の一瞥は紀元前5570年までさかのぼり、ギザの大ピラミッドの完成までさかのぼることができます。 したがって、この最も基本的なタイプのプロジェクト管理手法の正確な起源を特定することは困難です。

クラシックプロジェクト管理手法は何に最適ですか?
  • 複雑なワークフローを必要としない小規模なチームと単純なプロジェクト
従来のプロジェクト管理手法の視覚的表現

以下に、従来のプロジェクト管理手法で従う必要のある段階を視覚的に表したものを示します。

2.かんばんプロジェクト管理方法論

日本語の起源を考えると、「かんばん」という言葉は看板に翻訳されます。 かんばんは、作業項目を開発列に配置するビジュアルプランニングボードです。

かんばんとは何ですか?

かんばんは、プロジェクトを視覚化し、プロジェクトの進捗状況を追跡するのに役立つアジャイルプロジェクト管理方法論の人気のあるサブタイプです。 その主な利点の1つは、作業の透明性を促進することです。

かんばんの使い方は?

単純なかんばんボードは、3つの異なる列で構成されています。 タスクを列間で移動して、タスクの進行状況と現在のステータスを通知します。

  1. 「やること」列—将来取り組む必要のあるタスクを最初に定義するときに、ここに配置します。
  2. 「実行中」列—タスクの作業を開始するときに、ここに配置します。
  3. 「完了」列—タスクの作業が終了したら、ここに配置します。
かんばんの簡単な歴史

かんばんは、トヨタ社とその「ジャストインタイム」(JIT)生産システムにまでさかのぼることができます。このシステムでは、必要なことだけを、必要な量だけ行うことが義務付けられています。

かんばんは何に最適ですか?
  • ソフトウェア開発プロジェクト
  • 新入社員の採用、面接、採用に焦点を当てた人事プロジェクト
  • ワークフローと期限が確立されたあらゆるタイプのプロジェクト
かんばんの視覚的表現

下の画像では、前述のボードの3つの列と、[バックログ]列を確認できます。 これは、バックログから実行するように選択したタスクのリストであるTo-do列とは対照的に、優先度に基づいて順番に実行する必要があるタスクのリストを表します。

3.プログラム評価およびレビュー手法(PERT)

このマッピングプロジェクト管理手法は、プロジェクト全体を完了するための現実的な時間の見積もりを行うのに役立ちます。

プログラム評価およびレビュー手法(PERT)とは何ですか?

プロジェクト管理のプログラム評価およびレビュー手法(PERT)では、特殊なPERT図で複雑で詳細に計画されたプロジェクトを視覚的に追跡します。 この手法の重点は、プロジェクトを正常に完了するために必要な時間と予算を見積もる、一定のタスク分析にあります。

プログラム評価およびレビュー手法(PERT)の使用方法は?

PERTチャートを作成するには、次の手順に従います(ソフトウェアを使用するか、自分で描画することができます)。

  1. プロジェクトのアクティビティ、タスク、またはマイルストーンの完全なリストを作成します(マイルストーン、つまり成果物を達成するために完了する必要のあるすべてのタスクを特定する必要があります)
  2. プロジェクトを完了するために必要なタスクとマイルストーンのリストができたので、依存関係に基づいて一連のタスク(どのタスクが最初に実行されるか)を慎重に作成します。
  3. ここでは、最も早い開始日時や終了日時、プロジェクト内の各タスクを完了するために必要な時間など、タスクの時間の見積もりを行う必要があるため、これは極めて重要なステップです。
  4. プロジェクトを完了するために必要な最小時間を見積もるのに役立つ、最も重要な(すべてではない)ステップをカバーするプロジェクトのクリティカルパスを特定します。
  5. このチャートを作成したからといって、厳密にそれに従う必要があるという意味ではありません。 プロジェクト管理とは、変更を変更し、変更に効果的に適応することです。
プログラム評価およびレビュー手法(PERT)の簡単な歴史

PERTは、米海軍が原子力潜水艦プロジェクトを実施するのを支援するために、1957年に米海軍特別プロジェクト事務所によって最初に設立されました。 その後、さまざまな業界で使用されるようになりました。以前の歴史で最も有名なPERTの使用法の1つに、1968年の冬季オリンピックの開催での使用があります。

プログラム評価およびレビュー手法(PERT)は何に最適ですか?
  • 多数の非定型タスクを伴う複雑なプロジェクト
  • 複雑な要件を持つ大規模なプロジェクト
プログラム評価およびレビュー手法(PERT)の視覚的表現

このチャートでは、次のことがわかります。

  • 重要なマイルストーンまたはイベントを表す黄色の円、つまりノード
  • 矢印は、期間とともにこの順序で完了する必要がある依存タスクを表します(矢印にも示されています)
  • 同時に発生するタスクを表す発散矢印(8-7および8-11)
PERTチャート

単純なプロジェクトに最適なプロジェクト管理手法

あらゆるタイプのプロジェクトのPM方法論から、「単純なプロジェクト」のプロジェクト管理方法論に移行します。

次のプロジェクトパラメータに基づいて、単純なプロジェクトを認識できます。

  • 完了するまでに6か月未満かかると予想されます
  • パートタイムの努力だけが必要です
  • 10人以下のチームメンバーが関与します
  • 費用は75,000ドル未満と予想されます
  • それは最初からすぐに利用できる予想コスト額を持っています
  • それは単一の目標を持っています
  • 簡単な解決策があります
  • プロジェクトの範囲が狭い

プロジェクト関連のタスクとプロセスのコストは、プロジェクトが単純なものであるかどうかを判断する上で重要な役割を果たします。プロジェクトと管理のコストを判断する方法の詳細については、プロジェクトのコスト管理に関するブログ投稿をご覧ください。

単純なプロジェクトで使用するのに最適なプロジェクト管理手法は次のとおりです。

  1. 作業分解図(WBS)
  2. ウォーターフォールテクニック
  3. ガントチャート

1.作業分解図(WBS)

この驚くべき階層的手法は、プロジェクトを効率的に完了するために取り組む必要のあるタスクの概要を視覚的に作成するのに役立ちます。

作業分解図(WBS)とは何ですか?

Work Breakdown Structure(WBS)では、プロジェクトをその部分、つまり、より小さく、より管理しやすい部分に分割する必要があります。 PMBOKによると、「プロジェクトの目的を達成し、必要な成果物を作成するために」、作業の分解を行う必要があります。 視覚的に言えば、WBSは、プロジェクト全体(タスクとサブタスク)内のすべてのコンポーネントの全体像を把握するのに役立ちます。

作業分解図内のすべての作業は、適切に識別、見積もり、予算編成、およびスケジュール化する必要があります。

作業分解図の使用方法は?

WBSを使用して、複雑なタスクをより小さなタスクに分割し、これらのタスクを細分化できなくなるまで続けます。 小さなタスクは、それらを完了するための時間要件とコストを見積もるのが簡単なので、作業が簡単です。

プロジェクトをWBSの最低レベルに分解すると、それらのレベルはワークパッケージと呼ばれます。 それらを特定すると、それらを効率的に制御および管理するとともに、作業の時間とコストを簡単かつ安全に見積もることができます。

ほとんどのプロジェクトのライフサイクルは類似しているため、プロジェクトに合わせて変更するために使用できる標準のWBSテンプレートがあります。

プロジェクトをより管理しやすいコンポーネントに分割する方法についてさらにヘルプが必要な場合は、この記事を確認してください→プロジェクトをタスクに分割する方法

作業分解図の簡単な歴史

WBSは、1960年代に米国国防総省(Dod)と米国航空宇宙局(NASA)によって最初に開発されました。これは、彼らが抱えていた巨大なプロジェクトに実行可能な計画と制御システムが必要だったためです。

作業分解図は何に最適ですか?
  • プロジェクトの範囲内のタスクの依存関係に主に焦点を当てた単純なプロジェクト
作業分解図の視覚的表現

ここでは、プロジェクトを構成するすべてのタスクとサブタスクを確認できます。 プロジェクトのタスクを適切に管理し、時間とコストを見積もる必要がある限り、プロジェクトのタスクを分割することができます。

作業分解図

2.ウォーターフォールテクニック

この手法は、フェーズが1つから別のフェーズに流れる滝のようなシーケンシャルな設計プロセスに基づいています。

ウォーターフォールテクニックとは何ですか?

ウォーターフォールテクニックでは、タスクを順番に実行する必要があります。前のステップを終了した場合にのみ、次のステップに進むことができます。

この手法では、プロジェクトに必要なものと、プロジェクトに取り掛かる前にプロジェクトがどのように展開されるかを明確に把握する必要があります。次のステップに進むと、前のステップに戻って修正することはできません。

ウォーターフォールテクニックの使い方は?

具体的な手順はプロジェクトの種類によって異なりますが、通常は次の手順が含まれます。

  1. ソフトウェア要件の分析と特定、
  2. 要件に従ってソフトウェアを開発するための最良のアプローチを設計し、
  3. 適切なコードを記述して問題の適切な解決策を実装し、
  4. コードをテストし、意図したとおりに機能することを確認します。
  5. コードが意図したとおりに機能し続けることを確認するために、定期的なメンテナンスを実行します。
ウォーターフォールテクニックの簡単な歴史

ウォーターフォールテクニックは、1970年に公開された記事で、ウィンストンW.ロイスによって最初に正式に説明されました。ただし、その名前では説明されていませんでした。「ウォーターフォールテクニック」という用語は、TEベルとTAターナーの論文で最初に言及されました。 1976年。

ウォーターフォールテクニックは何に最適ですか?
  • 短くてシンプルなソフトウェア開発プロジェクト
  • 明確で事前に決定された要件を持つソフトウェア開発プロジェクト
  • クリエイティブなプロジェクト管理
  • 成功するために厳格な作業構造を必要とするプロジェクト
ウォーターフォールテクニックの視覚的表現

この視覚的表現から、ウォーターフォールテクニックでは前のフェーズに戻ることができないため、先に進むことしかできないことがわかります。 厳格な秩序を尊重します。

滝のテクニック

3.ガントチャート

この実践的なプロジェクト管理手法では、棒グラフを使用して、プロジェクトのスケジューリングおよび計画プロセスを簡素化および視覚化します。

ガントチャートとは何ですか?

ガントチャートは、最も古いプロジェクト管理手法の1つです。 これは、プロジェクトのスケジュールを示す一種の横棒グラフです。 プロジェクトの各アクティビティはバーで表され、その長さは各タスクの期間(開始日と終了日)を表します。 バーの位置も重要です。これは、タスクのスケジュールを表すためです。 あるタスクが別のタスクに続く場合、それはタスクが開始するために先行タスクの完了に依存していることを意味します。 プロジェクト中の重要なマイルストーンを表すひし形や三角形のシンボルなど、チャート内に他の幾何学的な記号が表示される場合もあります。 ガントチャートは、そのシンプルさと低コストで広く知られています。

ガントチャートの使い方は?

ガントチャートは独立して動作することも、さまざまなプロジェクト管理ツールにガントチャートビューが含まれているため、プロジェクトに適用することもできます。 タスクをリストに追加して、タイムラインにドラッグするだけです。 次に、タスクまたはリソースを割り当て、依存関係を追加して、タスクが適切な順序で実行されるようにします。

ガントチャートの簡単な歴史

アメリカの機械エンジニアであり、プロジェクト管理コンサルタントであるヘンリーガントがガントチャートを発明したと思うなら、もう一度考えてみてください。 ポーランドのエンジニアであるKarolAdamieckiは、彼が最初にハーモノグラムと呼んだチャートを作成しましたが、それはポーランド語であり、その普及と採用が制限されていました。 1910年から1915年のどこかで、ヘンリーガントは、今日広く知られ、広く使用されているアダミエツキのチャートの彼のバージョンを設計しました。

ガントチャートは何に最適ですか?
  • あらゆるタイプのプロジェクトの複雑さ
  • ソフトウェア開発、設計、製造、マーケティングなどのさまざまな業界。
ガントチャートの視覚的表現

以下に示すように、バーはアクティビティ(実行する必要があること)を表します。

複雑なプロジェクトに最適なプロジェクト管理手法

次に、複雑なプロジェクトとその特定のプロジェクト管理手法について説明します。

複雑なプロジェクトは次の理由でわかります。

  • プロジェクトの成果を予測するための挑戦
  • プロジェクトの行動を予測することに挑戦
  • チーム内の役割を標準化することに挑戦
  • プロジェクトの要素数を見積もるのは難しい
  • プロジェクト要素間の依存関係を把握することに挑戦
  • プロジェクトの収益性を予測するための挑戦

複雑なプロジェクトで使用するのに最適なプロジェクト管理手法は次のとおりです。

  1. クリティカルパス法(CPM)
  2. クリティカルチェーンプロジェクト管理(CCPM)
  3. エクストリームプロジェクトマネジメント(XPM)
  4. 制御された環境でのプロジェクト(PRINCE2)

1.クリティカルパス法(CPM)

次は、重要性と依存関係に基づいてタスクを特定するのに役立つプロジェクト管理手法です。

クリティカルパス法(CPM)とは何ですか?

クリティカルパス法は、プロジェクト内のタスクの最長シーケンス内でクリティカルタスクを識別するためのスケジューリングアルゴリズムです。これらのタスクは、プロジェクトの期限を守るために重要であり、チームの最も鋭い焦点を必要とします。

クリティカルパス法(CPM)の使用方法は?

プロジェクトのクリティカルパスを見つけるために従う必要のあるステップバイステップガイドは次のとおりです。

  1. まず、すべてのプロジェクトタスクを特定して分類します
  2. 次に、各タスクの予想期間を定義します
  3. 次に、タスク間の依存関係を定義します
  4. その後、タスク間の依存関係のタイプを決定します。
  • タスク1とタスク2を同時に実行する必要があります
  • タスク2の作業を開始する前に、タスク1を完了する必要があります。
  • タスク2の作業を開始するには、タスク1の作業を開始する必要があります
  • タスク2の作業を完了するには、タスク1の作業を終了する必要があります
  1. 最後に、タスクの依存関係の種類によって指定された順序でタスクをスケジュールして作業します
クリティカルパス法(CPM)の簡単な歴史

クリティカルパス法(CPM)は、歴史的に最大の化学会社の1つであるデュポン社で1957年に設立されました(売上高の点で)。 この手法の創設者は、プラントのシャットダウンと再起動に伴うスケジュール関連の追加コストを回避したいと考えていた2人の数学者でした。彼らのソリューションには、適切なタスクを適切な順序で実行することが含まれていました。

クリティカルパス法(CPM)は何に最適ですか?
  • 相互に依存するタスクがいくつかあるプロジェクト
  • 反復的なタスクを伴うプロジェクト
  • 期限とスケジュールが厳しいプロジェクト(ソフトウェア開発や建設プロジェクトなど)
クリティカルパス法(CPM)の視覚的表現

この視覚的表現では、プロジェクトXを完了するために何を行う必要があるかを確認できます。タスクA、B、およびCは重要ではなく、これらのタスクに取り組まなければプロジェクトを完了することができます。 したがって、これらはオプションのタスクです。 一方、タスクD、E、およびFは「重要」と見なされ、プロジェクトを完了するにはそれらに取り組む必要があります。

2.クリティカルチェーンプロジェクト管理(CCPM)

これは、チームが過労にならないようにしながら、予算を維持するのに役立つもう1つのスケジューリング分析手法です。

クリティカルチェーンプロジェクト管理(CCPM)手法とは何ですか?

クリティカルチェーンプロジェクト管理(CCPM)は、基本的に、プロジェクトを実行するために必要なリソース、タスク間に存在する依存関係、およびプロジェクトを時間どおりに完了するために考慮する必要のあるバッファーに大きな重点を置くスケジューリングアルゴリズムです。

このプロジェクト管理方法論の目的は、リソースをより適切に管理し、プロジェクトのさまざまな側面で失う時間を最小限に抑え、ワークロードを均等に分散できるようにすることです。

CCPMに関連付けられているバッファには次の4種類があります。

  1. プロジェクトバッファ—つまり、プロジェクトが予想される終了日より前に完了していることを確認するバッファ。
  2. フィーディングバッファ—つまり、非クリティカルチェーンの最後のタスクとクリティカルチェーンの最後のタスクの間に配置されるバッファ。
  3. リソースバッファ—つまり、プロジェクト開発全体を通じてプロジェクトプロセスを実行するために適切なリソースが利用可能であることを確認するもの。
  4. キャパシティバッファ—つまり、予算に予期しない問題が発生した場合に追加のリソースを利用できるようにするバッファ。
クリティカルチェーンプロジェクト管理(CCPM)の使用方法は?

クリティカルチェーンプロジェクトプロセスを作成するときは、次のヒントを考慮に入れてください。

  1. 後でクリティカルパスになる最も重要なタスクを特定します。
  2. それに応じてリソース(時間、予算、人)を割り当てることを忘れないでください。
  3. チームが十分に油を塗ったマシンとして機能していることを確認し、個々のタスクに注意を向けます。
  4. 前に述べたように、チームメンバーには一度に1つのタスクを割り当てる必要があります。これは、マルチタスクを防ぐために行われます。 マルチタスクとCCPMは密接に関係していません。
  5. これは厳しいように聞こえるかもしれませんが、効率的であることが証明されています—プロジェクト完了までの時間の見積もりを半分に減らしてください。 このようにして、チーム内の先延ばしを排除し、時間の不適切な利用を回避します。 良いことは、現実的な時間見積もりの​​削減を行わなかった場合や、予期しない状況でそれらを使用できる場合に備えて、バッファーがあることです。
  6. 最後に、時間の見積もり、使用されたリソースのリスト、バッファー、および終了日を含むプロジェクトモデルを作成します。 これは、プロジェクトの遅延を回避するために行われます。
クリティカルチェーンプロジェクト管理(CCPM)技術の簡単な歴史

クリティカルチェーンプロジェクト管理(CCPM)は、制約理論から派生しています。これは、1997年にEliyahuM.Goldrattの著書CriticalChainで最初に導入されました。

クリティカルチェーンプロジェクト管理(CCPM)手法は何に最適ですか?
  • 各チームが1つのプロジェクトのみに取り組み、リソースが重複しない企業
  • 締め切りに間に合わないチーム
  • リソースが限られている複雑なプロジェクト
クリティカルチェーンプロジェクト管理(CCPM)技術の視覚的表現

CCPM手法では、予期しない状況で利用できる「エアバッグ」の一種としてバッファを追加することを提案しています。 下の図からわかるように、各タスク(図で円でマークされている)には、プロジェクトの期限やプロジェクト中の他の変更を保護するバッファーが与えられます。

クリティカルチェーン

3.エクストリームプロジェクトマネジメント(XPM)

今後の手法は、プロジェクトの計画やスケジュールではなく、プロジェクトの利害関係者の管理に重点を置いています。

エクストリームプロジェクトマネジメント(XPM)とは何ですか?

エクストリームプロジェクトマネジメント(XPM)は、その名前が示すように、複雑で変動するプロジェクト、つまり頻繁に変更され、管理に極端なアプローチを必要とするプロジェクトのために作成されたプロジェクト管理手法です。

この手法は、プロジェクトの人間的な側面に焦点を当てています。プロジェクト内でのコラボレーションに適切に取り組み、調整するために、人々が互いにどのように相互作用するかという既知の原則を利用します。

エクストリームプロジェクトマネジメント(XPM)の使い方は?

XPMのプロジェクトは、Extreme ProjectManagementの本のDougDeCarloによると、4つのフェーズ(INSPIRE)を経ています。

  1. 開始—このフェーズでは、チームを集め、ブレインストーミングを行い、考えられるアプローチについて考え、クライアントとの強力な関係を構築します。 XPMでは、プロジェクトの目標を最初に定義するのではなく、途中で定義することを忘れないでください。 それはあなたが計画できるものではありません。 目標は柔軟であるため、プロジェクトの時間の見積もりとコストも柔軟です。
  2. SPeculate —これは、アイデアのブレインストーミング、深い思考、および成果物の優先順位付けの時間です。 「これでうまくいくのだろうか?」 このフェーズで自問する質問です。
  3. インキュベーション—このフェーズで優先される成果物のリストがありますが、それらは修正されていません。 このフェーズでは、クライアントと一緒に調査、修正を行います。 これにより、新しいアイデアや目標が明確になる可能性があります。 In this phase, you need to distribute work across your team. Previously prioritized deliverables must be assigned to team members to create a synergy among team members. The goals can be achieved only with strong collaboration within the team.
  4. REview — In the last phase of the XPM, team members should attend a meeting and talk about achievements in the Incubate phase, things they learned, revising the goal, and whether the project meets client expectations and should be continued. The number of cycles is unknown, and if there is a necessity to go through the entire 4 phases again — the client and team members will make a joint decision about that.
A brief history of Extreme Project Management (XPM)

The concept of Extreme Project Management (XPM) originated in 2004, in the previously mentioned book Extreme Project Management by Douglass DeCarlo.

What is Extreme Project Management (XPM) best for?
  • Projects with a low possibility for failure
  • Projects with short deadlines
  • Projects that aim for innovation
  • Projects with factors that are difficult to control
  • Projects characterized by sudden, spontaneous changes
Visual representation of Extreme Project Management (XPM)

From this visual representation, you can get a better insight into XPM's flexibility and freedom when it comes to making decisions about the approach, cost, timeframe, and scope. Do not adapt the project to a fixed set of rules and approaches, adapt the rules and approaches to the project itself until you achieve the desired result.

Extreme Project Management

4. Projects IN Controlled Environments (PRINCE2)

Up next is one of the world's most practiced techniques for project management due to its scalability, flexibility, and practicability. As opposed to XP, managing projects in PRINCE2 is clearly planned and organized in each stage of the process.

What is PRINCE2?

Projects IN Controlled Environments (PRINCE2) is a structured project management technique that provides a framework to help divide the project into stages. It is a methodology that consists of 7 principles, 7 themes, and 7 phases each project needs to go through.

PRINCE2 Principles  

They represent underlying rules that every project needs to stick to — according to the 2017's edition of PRINCE2:

  1. Continued Business Justification — The business case is regularly updated to make sure that the project is still usable.
  2. Learning from experience — Each project has a lesson log you can refer to to avoid remaking already established workflows from scratch.
  3. Defining roles and responsibilities — Team members may have several roles in a project, or share their roles with other team members. Roles are structured into 4 different levels:
  • The corporate management/program management level
  • The project board level
  • The project manager level
  • The team level
  1. Managing by stages — You manage each stage of project development differently, by updating the business case, risks, and project plan.
  2. Managing by exception — When a specific project element (such as the project scope or project costs) changes, the question of how to continue moves to a higher level of management.
  3. Product focus — Focus is placed on the quality end delivery of the developing product.
  4. Tailoring to suit the project environment — This technique is meant to fit the project environment, ie the size, complexity, risk estimation, and overall importance of the developing project.
PRINCE2 Themes

Themes tell you how to manage a project using PRINCE2 principles. Projects need to address these themes all the way through.

  1. Business Case — Gives justification, ie reason for undertaking a project. It answers the question of why .
  2. Organization — Defines roles and responsibilities within the project. It answers the question of who.
  3. Quality — Ensures that the project's deliverables meet business expectations. It answers the question what.
  4. Plans — Describes the techniques and steps that you need to take to develop plans. It answers the questions of how and when .
  5. Risk — Identifies and assesses uncertainties. It answers the question What if .
  6. Change — Handles change requests and finds the way to successfully manage them. It answers the question of what's the impact .
  7. Progress — Tracks, checks, and monitors the project. It answers the questions where are we now, where are we going, should we carry on.
How to use PRINCE2?

If you want to manage a project using PRINCE2, you need to be aware of the 7 phases each project needs to go through:

1. Starting up a project

You start your project with a project mandate which is an initial document provided by the customer and it is required to start the project (it outlines the basic information that is available at the starting point). To make sure the project is viable, a project brief is produced and carefully reviewed by the project board to decide on whether to initiate the project. Within this phase, several activities must be completed such as appointing the project manager together with other stakeholders, preparing the business case, choosing an approach, and assembling the project brief.

2. Directing a project

This is the time when the project board makes key decisions about the project, whether it is worthwhile initiating, and delegates the project to the project manager when authorized. Activities within this stage include reviewing the project brief, formally confirming the approach with the rest of the stakeholders, and thinking about the risk and resource requirements.

3. Initiating a project

In this stage, reasons for doing a project must be stated together with the scope of work, cost, responsible stakeholders, how risks or changes should be managed. The project manager needs to assemble the Project Initiation Document — a formal document (or collection of several documents) where all questions such as what, who, why, where, how, when, and how much must be clearly stated.

4. Controlling a stage

The whole process must be carefully controlled and monitored at all times to avoid issues and loss of focus. The project manager must give authorization for any activity to be commenced or continued. That's why the project manager breaks down the project into smaller chunks — work packages to avoid chaos. Each work package must go through control after completion or change. In a nutshell, everything must work smoothly which is the project manager's responsibility.

5. Managing product delivery

The purpose of this stage is to ensure that all stakeholders agree on what is to be produced, its cost, and timescales together with meeting the quality criteria. Later, they can approve them or demand changes to be done.

6. Managing a stage boundary

Each stage must be carefully reviewed and approved to be able to move forward. The Project Board must be informed at strategic points of the project, and they are the ones who make a final decision on whether to stop or continue to the next stage.

7. Closing a project

This is the final stage of managing a project where acceptance of the product is being confirmed and whether PID's objectives are achieved. A project is successful if it has a clear end.

PRINCE2の簡単な歴史

PRINCE 2は、PROMPT IIという名前の以前の方法のバリエーションです。1989年に、英国政府はこのPROMPTIIバリエーションをITセクターのプロジェクト管理の標準として採用しました。 今日、これはすべての英国政府プロジェクトの公式プロジェクト管理方法です。

PRINCE2は何に最適ですか?
  • 要件の固定セットと複雑な環境を持つ複雑なプロジェクト。
PRINCE2の視覚的表現

以下の視覚的表現から、PRINCE2はその原則、つまりプロジェクトを正常に実行するために従う必要のあるガイドとルールに基づいて構築されていることがわかります。 次に、PRINCE2テーマは、プロジェクトを管理する方法、つまり原則を実践する方法を示します。

ソフトウェアエンジニアリングのための最高のプロジェクト管理技術

典型的なソフトウェアエンジニアリングプロジェクトには、要件の収集、ソフトウェアの開発とテスト、およびソフトウェア製品の定期的なメンテナンスの実行が含まれます。

ソフトウェアエンジニアリングプロジェクトで使用するのに最適なプロジェクト管理手法は次のとおりです。

  1. Rational Unified Process(RUP)
  2. アジャイルプロジェクト管理
  3. スクラム方法論
  4. エクストリームプログラミング(XP)

1. Rational Unified Process(RUP)

このプロジェクト管理手法は、反復的でありながら機敏です。 プロジェクト中にアクティビティが繰り返されるため、反復的であり、ソフトウェア要件に合わせて調整できるため、アジャイルです。

Rational Unified Process(RUP)とは何ですか?

Rational Unified Process(RUP)は、ソフトウェア開発チーム向けのアジャイル管理構造であり、プロジェクトを開始、精緻化、構築、移行の4つの異なるフェーズで時間の経過とともに展開します。 4つのフェーズのそれぞれに主な目的があり、ビジネスモデリング、要件、分析と設計、実装、テスト、および展開の6つの開発分野が含まれます。 前のステージの主な目的を達成しない限り、次のステージに進むことはできません。

一部の開発分野は他の分野よりも重要であるため、他の分野よりも時間がかかります。

Rational Unified Process(RUP)の使用方法は?

前述したように、RUP手法を効率的に使用するには、ソフトウェアは次の4つの開発フェーズを経る必要があります。

  1. 開始—これはプロセスの旅程ステップであるため、説明、リスク管理評価、ビジネス環境、および成功要因を含むプロジェクト計画を含むビジネスケースを作成する必要があります。 すべてを念頭に置いて、利害関係者はプロジェクトを続行するかどうかを決定します。 開始段階は、プロジェクトの最初のマイルストーンでもあります。 プロジェクトがこの段階を通過できない場合は、キャンセルまたは再設計することができます。
  2. 詳細—この段階では、プロジェクトの技術的リスク、つまり、実行可能なシステムを構築できるかどうかを検討する必要があります。 これはプロセスの2番目のマイルストーンであり、リスクが高く、後で変更を誘発するのが難しいため、重要です。
  3. 構築—これは、主要なコンポーネントと機能がコーディングとテストとともに開発される場所です。 この段階では、ユーザーマニュアルと、評価が必要なシステムのベータ版が作成されます。 製品がテストに失敗した場合は、次の段階である移​​行段階を延期する必要があります。
  4. 移行—この段階の主な目的は、製品を正常にリリースすることであり、これがこのプロセスの最後のマイルストーンです。
Rational Unified Process(RUP)の簡単な歴史

Rational Unified Processは、2003年にRationalSoftwareCorporationによって設立されました。

Rational Unified Process(RUP)は何に最適ですか?
  • 完了までの予測可能な時間枠と予測可能な最終予算を備えたソフトウェア開発プロジェクト。
Rational Unified Process(RUP)の視覚的表現

以下の視覚的表現では、RUPでのプロジェクト開発の4つのフェーズすべてを見ることができます。 また、一部のフェーズ(精緻化、構築、移行)には、各フェーズの目標を達成するための技術的な成果物の作成に焦点を当てた反復が多く含まれていることにも気付くでしょう。

Rartional Unified Process-

2.アジャイルプロジェクト管理

このプロジェクト管理手法は、プロジェクトのライフサイクル内の変更に簡単に適応できる柔軟性と適応性を提案します。 「アジャイル」という言葉自体は、変化できる、つまり適応できることを意味します。

アジャイルプロジェクト管理とは何ですか?

アジャイルプロジェクト管理は、チーム内の自己組織化とクロスファンクショナル性を強調し、顧客満足度を達成するソフトウェア開発の方法論です。

アジャイル管理の使い方は?

プロジェクトでアジャイル管理を正常に使用するには、従う必要のあるいくつかの原則があります。

  • この手法では、特定のプロセスやツールを実装する代わりに、チーム内の個人間の相互作用を強調します。
  • この手法では、製品の包括的なドキュメントを編集する代わりに、完全に機能するソフトウェアの作成に重点を置いています。
  • この手法では、契約交渉に焦点を当てるのではなく、クライアントのコラボレーションを利用して開発手順を容易にすることに重点を置いています。
  • この手法では、厳密なプロジェクト計画に従うのではなく、プロジェクトの変更にチームが対応できる最善の方法を強調します。

理解を深めるには、次の手順に従います。

  1. まず、プロジェクトを短いスプリントに分割します
  2. 作業中にプロジェクト計画を調整し、継続的な改善を目指します
  3. プロジェクトマネージャーは、チームが自己組織化されることを奨励します
  4. 提供したいサービス/製品から最大の価値と機能を生み出すことを目指しています
アジャイルプロジェクト管理の簡単な歴史

アジャイルプロジェクト管理は、アジャイルマニフェストの一部として2001年に正式に開発されました。

アジャイルプロジェクト管理は何に最適ですか?
  • 厳密な期限はないが、最終的な結果/製品についての一般的な考えを持っているプロジェクト
  • 予期しない変更を示唆するプロジェクト
  • 効率的なプロジェクト計画ではなく、効率的なチームコラボレーションに依存するプロジェクト
アジャイル管理の視覚的表現

ご覧のとおり、アジャイル管理は反復的なプロセスであり、その最終的な目標は変更に対応することです。

アジャイルプロジェクト管理

3.スクラム方法論

これは、反復プロセス、調整、および継続的な学習に基づくもう1つの柔軟なプロジェクト管理手法です。

スクラム方法論とは何ですか?

かんばんと同様に、スクラムはアジャイルプロジェクト管理手法のもう1つの人気のあるサブタイプです。その目的は、ソフトウェア開発チームが段階的かつ反復的なプラクティスの助けを借りて、動作するソフトウェアをより頻繁に提供できるようにすることです。

プロジェクトの進捗状況は、スプリントという名前の短いタイムボックス期間のシーケンスに従うことによって測定されます。各スプリントの終了は、スケジュールされた1つの作業量の完了を意味する必要があります。

スクラム方法論の使い方は?

スクラム方法論を使用してプロジェクトを実行するための6つのステップは次のとおりです。

  1. チームを割り当てる—まず、最終製品を作成するために開発、生産、またはその他の責任を実行する人(スクラムマスター、製品所有者など)を割り当てる必要があります。
  2. 製品バックログを作成する—これは、スプリントの作成—スプリントは、作業がより管理しやすいコンポーネントに分割される短期間のものです。 ここにバックログからストーリーを追加します。
  3. ミーティングを主催する—これは「デイリースクラム」または「スタンドアップ」ミーティングと呼ばれる短いデイリーミーティングです。 チーム全体が進捗状況について話し合い、問題がある場合はそれに取り組みます。
  4. スプリントレビューミーティングを主催する—このミーティングはスプリントの最後に開催されます。 結果について話し合い、データを収集し、改善または変更の計画を立てるために、すべての重要な利害関係者が立ち会う必要があります。
  5. 繰り返し—最終スプリントを完了して成果物を作成するまで、前の2つの手順を繰り返す必要があります。
スクラム方法論の簡単な歴史

先に述べたように、スクラムは正式に「アジャイル」という総称に分類されますが、1986年に竹内弘高と野中郁次郎が論文「新製品開発ゲーム」で紹介した名前で最初に登場しました。

スクラム方法論は何に最適ですか?
  • 複雑で曖昧なプロジェクト—従来、これらはソフトウェア開発プロジェクトですが、スクラムはマーケティングプロジェクトやリーダーシップチームにとっても効率的なアプローチです。
スクラム方法論の視覚的表現

スクラムプロジェクトを成功させるための手順は、プロジェクトを完了するために必要な他のアクティビティとともに次の画像に示されています。

スクラム方法論

4.エクストリームプログラミング(XP)

エクストリームプログラミング(XP)は、チームワークを促進し、複雑なプロジェクトを複数のより小さく、より管理しやすいリリースに分解することを提案する共同技術です。

エクストリームプログラミング(XP)とは何ですか?

エクストリームプログラミング(XP)は、特定のアジャイルソフトウェア開発フレームワークであり、その主な目的は、プロジェクトリリースの管理と顧客のニーズを満たすために費やす時間を短縮しながら、チームがより高品質のソフトウェアを作成できるようにすることです。

エクストリームプログラミングでは、次のプロジェクト関連の活動と原則が義務付けられています。

  • ホワイトボードの描画と組み合わせた対面の議論に重点を置いて、絶え間ないコミュニケーションを維持します。
  • 必要なことだけを実行し、現在のプロジェクト要件のみに対処することに重点を置いて、機能する最も単純なことを実行します。
  • 「構築-収集-調整」作業サイクルに重点を置いて、定期的なフィードバックを提供します。 チームは機能を構築し、機能に関するフィードバックを収集してから、フィードバックに基づいて機能を調整します。
  • 勇気を持って行動する—困難を受け入れ、フィードバックに基づいて行動し、迅速に対応し、必要に応じて物議を醸す質問をすることに重点を置きます。
  • 尊重を促進する—他者へのフィードバックの提供、他者からのフィードバックの受け入れ、およびその他すべての点に重点を置いて。
エクストリームプログラミング(XP)の使い方は?

手順に従ってください:

  1. 計画—最初のステップは、計画が行われる場所です。つまり、顧客がユーザーストーリーを作成する場所です。これは、特定の機能に対する顧客の要件の簡単な説明です。
  2. コミュニケーション—プロジェクト管理は90%のコミュニケーションであるため、次のステップは、プロジェクトマネージャーが円滑に運営されるチームを構築する必要がある場所です。
  3. 再構築—最初に最も簡単な設計から始めて、複雑な設計に進みます。 コードを簡潔で包括的に保つために、より小さくて管理しやすいコンポーネントを作成する必要があります。 スパイクソリューションを作成することを忘れないでください—難しい設計問題への答えを見つけるのに役立つ小さな実験です。
  4. コード—今こそコードを実装する時です。 XPは集合所有権モデルを使用するため、個々の開発者に依存せず、コードは集合的に所有されます。コードの問題に気付いたチームメンバーは、すぐにタスクに取り組む必要があります。
  5. レビューとテスト—最後に、プロセスのすべてのステップは、コードをリリースする前に、徹底的かつ反復的なテストを経る必要があります。
エクストリームプログラミング(XP)の簡単な歴史

エクストリームプログラミング(XP)は、1990年代にケントベックによって最初に設立されました。ケントベックは、C3給与プロジェクトの作業でこの手法を実装しました。

エクストリームプログラミング(XP)は何に最適ですか?
  • 動的で絶えず変化するソフトウェア開発プロジェクト
  • 同じ場所に配置された開発チーム
  • 時間枠が固定されたリスクの高いプロジェクト
エクストリームプログラミング(XP)の視覚的表現

この視覚的表現では、以下で説明する手順を確認できます。これには、最後の段階であるペアプログラミングも含まれます。 XPはチームワークとコラボレーションをサポートしていることはすでに述べました。したがって、ペアプログラミングは、チームメンバーが1台のコンピューターでペアで作業できるように行われます。 これにより、集団所有権が強化され、さらに、両方のチームメンバーが互いに学び合います。

エクストリームプログラミング

プロジェクト管理のテクニックとツール

使用している特定のプロジェクト管理手法や作業しているプロジェクトの種類に関係なく、特定の一般的なタスクとプロセスに取り組み、実行する必要があります。つまり、次のことを行う必要があります。

  1. プロジェクトワークフローを整理および計画する
  2. ある程度の能力でプロジェクトをスケジュールする
  3. 時間を適切に管理する
  4. チームと通信する
  5. チームと協力する
  6. プロジェクトの会計と財務の側面を処理する

さて、それをすべて行うための最良の方法は、プロジェクト管理ツールを使用することです。

ただし、プロジェクト管理ツールだけでなく、PM機能の観点から一般的な需要を調査した調査によると、プロジェクト管理に使用するツールのセットは、次の機能を提供する必要があります。

最もよく使用されるプロジェクト管理ソフトウェアの機能

ご覧のとおり、ファイル共有、タイムトラッキング、メール統合、ガントチャート、カスタムレポート、請求機能が最も高いシェア(51%から43%)でリードしていますが、クラウドストレージ統合、業界固有の機能、API 、PMメソッド固有の機能、リアルタイムチャット、モバイルアクセス、ソーシャルメディア統合、およびビデオチャットが密接に続きます(42%から28%)。

そのことを念頭に置いて、プロジェクトでの作業に関連するタスクとプロセスのタイプごとに、上記の機能を備えた最高のプロジェクト管理ツールのリストを以下に示します。

プロジェクトワークフローを整理および計画するためのPMツール

次のツールは、詳細なプロジェクト計画を立て、重要なタスクに焦点を合わせ、それに応じてそれらを順序付けながら、組織的な方法でチームとつながるのに役立ちます。

Trello

ワークフローを整理および計画するには、従来のかんばんベースのプロジェクト管理ツールであるTrelloを使用できます。

このツールを使用すると、タスクを整理して計画し、適切な名前の列全体でタスクの進行状況を追跡できます。

誰が何に取り組んでいるのか、どのようなことが進行中であるのか、どこで進行中であるのかを確認できます。 チームとのつながりを維持し、タスクのステータスについて全員に通知されます。

  • する
  • やってる
  • レビュー
  • 公開する準備ができました

Trelloのすばらしい点は、さまざまな業界に適用でき、プロジェクトに合わせてカスタム列を作成できることです。

nTask

nTaskは、チームを整理し、チーム全体の作業を効果的に管理するプロジェクト管理ソフトウェアです。 優先順位を付けてnTaskでより多くのことを成し遂げましょう—何度も逆効果であることが証明されたマルチタスクを忘れてください。 nTaskを使用すると、移動中でも重いワークロードを戦略的に分散して管理できます。

nTaskはユーザーに多くの機能を提供し、私たちはすべての人に何かがあると信じています。

チームコラボレーション

nTaskを使用—チームワークが夢を実現します。 この素晴らしいアプリは以下を提供します:

  • 効果的なチームコラボレーション
  • 専用のワークスペースとチームチャット
  • チームを形成し、その役割を定義する
  • チームメンバーにタスクを割り当て、その進捗状況を追跡する
プロジェクト計画

計画が不十分で、 nTaskを使用して、プロジェクトの完了日を逃さないようにしてください。

  • 何を、いつ、どこで行う必要があるかについての徹底的な計画を作成します
  • リソースを効果的に割り当てる
  • 請求方法を設定する
  • プロジェクトのステータスと進捗状況を表示する
タスク管理

nTaskでより多くのタスクを実行します:

  • かんばんボードでチームのワークフローを整理および追跡する
  • リストビュー、グリッドビュー、またはカレンダービューでタスクを整理します
  • タスクのリマインダーとカラータスクを設定する
  • ガントチャートは、プロジェクトスケジュールの視覚的表現を提供し、タスクの依存関係とリンクされたタスクを示します
会議管理

全員をループに入れます。

  • パーソナライズされた電子メール招待を介して会議に人々を招待します 
  • 会議を整理して追跡します
  • 明確な会議の議題を作成する
  • 定期的な会議を設定する 
タイムシート

nTaskタイムシートに時間を記録します。

  • 従業員の時間を追跡します
  • 複数のタイムシートを作成する
  • 過去のタイムシートを承認して追跡する

プロジェクトおよびプロジェクト関連のタスクを整理および計画するために使用できるその他の効率的なアプリには、ClickUp、Taiga、およびAsanaがあります。

プロジェクトスケジューリング用のPMツール

複数のプロジェクトとタスクを同時に実行することは、公園を散歩することではありません。 締め切りに間に合わないと、お金と時間がかかります。 代わりに、プロジェクトスケジュールを作成することを検討してください。 プロジェクトスケジュールは、目標を達成するために必要な計画を含むロードマップとして機能し、それを完了するのにかかる時間を示します。 それを念頭に置いて、私たちはあなたのためにいくつかのプロジェクトスケジューリングツールを選択しました。

Googleカレンダー

ワークフローをスケジュールするには、Gmailアカウントで使用できるシンプルなスケジュールカレンダーであるGoogleカレンダーを使用できます。

このツールを使用すると、簡単なカレンダースロットでチームとの会議や相談をスケジュールできます。 Googleカレンダーを使用すると、今後のアクティビティに関するリマインダーを受け取るため、予定を逃すことはありません。

Googleカレンダーでは、やることリストを作成したり、アドオンを使用してカレンダーをカスタマイズしたり、イベントを好みに合わせてカスタマイズしたりできます。

タスクやプロジェクトのスケジュールを処理するために使用できるその他の効率的なアプリには、Doodle、Calendly、Any.doなどがあります。

プロジェクトスケジューリング用のPMツール

質の高いプロジェクト時間管理ツールは、時間とタスクを効率的に管理し、時間の追跡、請求、レポートを含め、使用中に安全を確保する必要があります。 そうは言っても、次のアプリの使用を検討してください。

Clockify

clockify

プロジェクトに適切に取り組んでいる間、時間を管理するために、市場をリードするタイムトラッカーであるClockifyを使用できます。 Clockifyは、無制限のユーザーとプロジェクトに基本的な時間追跡機能を無料で提供する時間追跡アプリケーションです。

Clockifyを使用すると、非常に便利で透過的でユーザーフレンドリーな方法でプロジェクトを管理および追跡できます。 さらに、チームの時間と進捗状況を追跡し、予算を設定し、プロジェクトの正確な時間の見積もりを行うことができます。

このツールを使用すると、チームは、作業中(または作業終了後)にプロジェクト関連のタスクに費やした時間を追跡し、使用時間のレポートを生成し、それらを使用してワークフローを改善できる場所を特定できます。

Clockifyの使用に加えて、Rescue TimeまたはWakaTimeを使用して、特定のアプリに費やした時間を自動的に追跡することもできます。

プロジェクトコミュニケーションのためのPMツール

チームコラボレーションツールは、チーム内のコミュニケーションの扉を開き、世界中のどこからでもリモート作業を強化するのに役立つため、最も重要です。

私たちはあなたのためにいくつかのプロジェクトコラボレーションツールを選択しました:

パンブル

Pumbleは、無料で、無制限の数のユーザーが、無料のメッセージ履歴で利用できる効率的なチームコラボレーションツールです。 このすばらしいアプリを使用すると、プライベートチャネル、グループチャット、または公開会話を使用して、チームメンバーと1対1のプライベート会話を行うことができます。 チャンネルを作成し、メンバーを追加して、好みに合わせてカスタマイズするだけです。

Pumbleを使用すると、チームとのすべてのコミュニケーションを1か所に集中させることができ、過去の会話、リンク、ファイルを簡単に参照したり、チャネルや人でフィルタリングしたりできます。

プロジェクトコラボレーション用のPMツール

チームのコミュニケーションとは別に、プロジェクトのコラボレーションも重要です。これにより、リアルタイムでの作成とコラボレーションが可能になります。 もちろん、そのためには信頼できるアプリが必要です。

Googleスプレッドシート

google-sheets

チームコラボレーションは広義の用語です。 たとえば、データ入力や統計分析でチームと協力するには、オンラインスプレッドシートであるGoogleスプレッドシートを使用できます。

このツールを使用すると、データの追加と計算、グラフの作成、プロジェクト統計の分析を行うことができます。チームの複数のメンバーが同時にデータを操作でき、すべての変更が即座に自動的に保存されます。

さまざまなコラボレーションタスクを処理するために使用できるその他の効率的なアプリには、Dropbox(オンラインファイル共有用)、Visme(チームブレーンストーミングセッション用)、およびJira(アジャイルプロジェクト管理用)があります。

Jira

Jiraは、プロジェクト管理と問題追跡に使用されるアジャイルソフトウェアです。 その豊富な機能には、バグトラッキング、ソフトウェア開発タスクの管理、および製品管理が含まれます。

Jiraは、バグの追跡、リソース管理、チームのパフォーマンスの追跡、および速度の追跡に最適であることが証明されています。

Jiraは、カスタマイズ可能なダッシュボード、タスクを追跡するためのユーザーフレンドリーなインターフェース、およびレポート作成をユーザーに提供します。

さまざまなコラボレーションタスクを処理するために使用できるその他の効率的なアプリには、Dropbox(オンラインファイル共有用)、Visme(チームブレーンストーミングセッション用)があります。

? より優れたアプリについては、最高のコラボレーションツールのリストをご覧ください。

プロジェクトファイナンスと会計のためのPMツール

ビジネスを運営している場合は、予算とコストを分析し、レポートを生成し、プロジェクト関連のすべてのトランザクションを1か所に集中させることで、プロジェクトの透明性を促進する信頼性の高い管理ソフトウェアを組織で使用する必要があります。

したがって、以下を使用してみてください。

セージ会計

セージ会計

プロジェクト関連の財務および会計タスクを処理するには、 SageAccountingを使用できます。

このツールを使用すると、財務を分析したり、プロジェクトの完了時にクライアントに請求したりできます。

プロジェクトファイナンスと会計を処理するために使用できる他の効率的なアプリには、Fyle、Quickbooks、Wave Accounting、Freshbooksなどがあります。

より優れたアプリについては、最高の財務および会計ツールのリストを確認してください。

プロジェクト管理の手法とベストプラクティス

したがって、一般的なプロジェクト管理方法論がどのように機能するか、いつ使用する必要があるか、どのツールを使用するかを理解できます。 次に、プロジェクト管理の取り組みを非常に効率的にするのに役立つ、プロジェクト管理のいくつかのベストプラクティスに焦点を当てます。

1.すべてのプロジェクト要件を文書化します

達成したい目標と、その目標を達成するために実行する必要のあるタスクと手順を理解しました。

次に、チームと将来のプロジェクト投資家の両方のために、将来の参照用にこのデータを文書化します。

2.他の義務に従ってプロジェクトを見積もります

あなたの会社は、同じ期間に複数のプロジェクトに取り組む可能性があります。

したがって、期限を設定して責任を定義するときは、チームの他のプロジェクトと義務を考慮する必要があります。

3.ワークロードを慎重に管理します

タスク、役割、および責任を均等に割り当てましたか?

または、あるチームメンバーが5つの異なるタスクで過労しているのに、別のチームメンバーはほとんど何もしていませんか?

これを注意深く監視し、リソースを最大限に活用するために、作業を均等に分散してください。

4.プロジェクトの進捗状況を常に監視します

プロジェクトは計画通りに進んでいますか?

みんなが自分の仕事を分担していますか?

チームは、予想されるプロジェクトの期限に沿ったペースで作業していますか?

プロジェクトの1つのフェーズでホールドアップはありますか?

チームの作業を監視し、進捗状況を追跡することで、これらすべてに答え、事故や遅延を防ぐことができます。

5.すべてを伝達する

全員が現在取り組んでいること、進捗状況、およびプロジェクトに問題があるかどうかを追跡するには、チームが連絡を取る必要があります。

それで、あなたが持っているすべての質問、問題、またはジレンマについて、それについて話します。 質問に答え、問題を理解し、一緒にジレンマを解決します。

6.プロジェクトスコープクリープに対する予防措置を講じる

プロジェクトを慎重に計画し、プロジェクトが完了する前に取り組む必要のあるすべてのタスクとサブタスクを予測すると、スコープクリープから保護されます。

そのためには、すべてのタスクとサブタスクを時間どおりに、期待される品質で完了するために必要な予算と時間を慎重に計算します。

7.すべてのプロジェクトリスクを考慮する

各プロジェクトには、プロジェクトが完了する前に発生する可能性のある潜在的な問題があります。 以前、リスク登録手法を使用してこの問題に取り組みましたが、今度はその重要性を強調します。

これらの問題を苦痛なく通り抜けることを確実にする秘訣は、問題が発生する前にそれを予測することにあります。

したがって、プロジェクトの段階とタスクに関する潜在的な問題を定義するためにあなたの経験を使用することを目指してください。

次に、必要に応じて実装するソリューションを定義します。

8.完了後、時間をかけてプロジェクトを分析します

プロジェクトが完了したら、時間をかけて分析します。

あなたがうまくやったこと、そしてあなたが将来もっと良くできることを強調してください。

各段階を完了するのにかかった時間を分析し、最も労力を費やしたタスクを選び出します。 今後のプロジェクトでは、このようなタスクにより多くの時間を割り当てる必要があります。

そしてもちろん、チームの努力と献身を称賛します。 彼らはそれを獲得しました。

まとめ…

プロジェクトの作業を開始する前に、作業に使用できる最良のプロジェクト管理方法論について考えてください。 次に、選択したPMテクニックを適切なツールとベストプラクティスと組み合わせて、結果を向上させます。

選択したプロジェクト管理手法の規定された原則に従うと、ワークフローが高速化され、プロジェクト手順の制御が維持され、管理プロセスが合理化されます。 その結果、より速く仕上げ、高品質の最終製品を引き渡すことができます。

️どのプロジェクト管理手法があなたのプロジェクトに最も適していますか? ツールはどうですか? この記事または今後の記事の1つで取り上げられるチャンスについては、blogfeedback @clockify.me</aまでご連絡ください。

参考文献

  • https://www.pmi.org/learning/library/project-management-techniques-determination-10335
  • https://www.projectsmart.co.uk/brief-history-of-project-management.php
  • https://en.wikipedia.org/wiki/Kanban#Origins
  • https://www.hindawi.com/journals/complexity/2018/4891286/
  • https://en.wikipedia.org/wiki/Program_evaluation_and_review_technique#History
  • https://yourbusiness.azcentral.com/history-critical-path-method-24351.html
  • https://en.wikipedia.org/wiki/Critical_chain_project_management#Origins
  • https://en.wikipedia.org/wiki/Extreme_project_management
  • https://en.wikipedia.org/wiki/PRINCE2#Seven_Principles
  • https://en.wikipedia.org/wiki/PRINCE2#History
  • http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf
  • https://static.aminer.org/pdf/PDF/000/361/405/software_requirements_are_they_really_a_problem.pdf
  • https://www.informit.com/articles/article.aspx?p=169549&seqNum=5
  • http://agilemanifesto.org/history.html
  • https://ullizee.files.wordpress.com/2013/01/takeuchi-and-onaka-the-new-new-product-development-game.pdf
  • https://en.wikipedia.org/wiki/Extreme_programming#History