Resource Management: ホワイト ペーパー

  • [アーティクル]

この記事は、"From the Trenches" コレクションの一部です。 リソース管理のさまざまな側面での課題について説明し、リソース管理システムの作成に関する提案を提供します。

その他の記事については、「 溝から」ホワイト ペーパーを参照してください。

リソース管理

リソース管理は、組織が Microsoft Office Project Server などのシステムを使用して個々のプロジェクト管理からエンタープライズ プロジェクト管理に切り替える最も一般的な理由です。

これは、そのようなシステムから最高のリソース管理を取得する方法に関する広範なプレイブックを用意することを意味すると思います。

場合のみ。

リソース管理の定義

最初の問題は、エンタープライズ システムの多くの側面と同様に、"リソース管理" によって人々が何を意味するのかを正確に定義することです。 あなたの視点に応じて、リソース管理はさまざまなものになる可能性があります。

リソースの平準化

まず、純粋なビューから始めましょう。 これは15年以上業界の私たちから来ています。 プロジェクト管理ソフトウェアが商用製品として初めて利用可能になったとき、それはクリティカル パス手法 (CPM) スケジューリング ツールでした。 初期のシステムでは、リソースの考慮はまったくありませんでした。 システムからスケジュールを取得し、ロールフィードプロッターが出てきたときに(主に技術図面業界をサポートするために)、それらを使用して、プロジェクトの棒グラフまたはロジック(ネットワーク)図の表示を取得するのに十分な刺激を与えた。

これらのシステムにリソースが組み込まれると、リソースを追加して元の計算を強化する必要がありました。 アルゴリズムはさまざまですが、意図は、特定の取引の不十分な数からの遅延が、それらの人々を雇い、仕事にそれらを得るために十分に長い間特定されることを保証することでした。 もう少し後でリソース 平準化に戻ります。

クリティカル チェーンプランニング

私はクリティカルチェーンの概念が新しいようで非常にエキサイティングですが、私は何人かの人々のために知っているが、それは実際には長い時間の周りでした。 スケジュール中心のユーザーの場合、クリティカル チェーンはリソース制約をスケジュールに適用し、スケジュールの配信に最も大きな影響を与えるリソースを探します。 おそらく、CPM は最初から何だったべきだったかであり、適切な状況で適用されると、非常に明らかになる可能性があります。

リソース容量計画

考えを少し広げれば、リソースの容量を管理するより広範な概念に、これらの最初の 2 つの定義を含めることができます。 これは、エンタープライズ プロジェクト管理のデプロイで提供するように求められる最も一般的な概念です。 リソース容量計画では、組織の意思決定者に関するいくつかの質問に答えようとしています。

  • 私が持っている担当者と既に行ったコミットメントを満たすことができますか?

  • そうでない場合、私のコミットメントを満たすために必要な人事の変更は何ですか?

  • その場合、追加のコミットメントを引き受ける必要がある余分な容量は何ですか?

  • 追加のプロジェクトが与えられた場合、既存の担当者と一緒にプロジェクトを実行できますか?

  • 担当者を変更できない場合、達成する必要がある新しい作業の影響は何ですか?

リソース容量計画には、プロジェクト管理プロセスの一部として実装する必要があるいくつかの概念が含まれています。 たとえば、次の環境です。:

  • リソースの読み込み

    リソース容量計画の課題を開始するには、実行する必要がある作業量から始めることができます。 (実行する作業がない場合は、リソースを管理する必要はありません)。各タスクにかかる作業量と、それを達成する必要があるユーザーを正確に把握することは、正確な分析にとって重要です。

  • スキル スケジューリング

    Microsoft Project などの最新のプロジェクト管理ツールでは、部門または個人としてだけでなく、スキルとしてもリソース要件を管理できるようになりました。 スキルスケジューリングには、リソース要件の管理だけでなく、インベントリとしてのスキルの可用性の管理も含まれます。これは、各部門で利用可能な人数を管理するよりも全体的に効果的であると思われます。 結局のところ、データベース管理部門があるかもしれませんが、2008年SQL Serverに担当者のスキルが不足していて、それが次のプロジェクトに必要なスキルである場合、プロジェクトを完了する際にはまだ不足しています。

  • リソースの割り当て

    どのリソースを割り当てに配置しますか? リソース要件を定義して解決する方法を決定するためのプロセスを作成する必要があります。 まず、リソースのカテゴリまたはコンピテンシーを要求する必要がありますか? "提案済み" モードで個々のリソースの要求を行い、権限を持つユーザーに "コミット済み" にする必要がありますか? 提案されたリソースを含むさまざまなプロジェクトを別々に保持する必要がありますか? プロジェクト マネージャーは、異なる部門のリソースをコミットできる必要がありますか、それとも部門長にその特権を持つ必要がありますか?

  • リソースの可用性

    リソースに対するプロジェクトのニーズはありますが、使用可能なリソースは何ですか? プロジェクトとプロジェクト以外の作業で各リソースを利用できる時間は誰が決めますか? 休暇を取得できるタイミングは誰が決めますか? 1 日に何時間の超過勤務を行うことができるかは、どのように判断しますか? 未払い残業はどのように対処しますか? 銀行取引の時間になりますか?

  • リソースの平準化

    プロジェクトのリソースの可用性とニーズの両方が得られたら、2 つを比較すると、割り当て過ぎの場所を知り、過剰割り当てに対処する課題が提示されます。 一部のプロジェクトは、リソースを取得し、一部が取得しないように優先順位を付ける必要がありますか? 一部のタスクは、リソースを取得し、一部が取得しないように優先順位を付ける必要がありますか? 自動リソース 平準化を使用する必要がありますか? タスクの手動移動はどうですか? 会社の一部が他の部分からの作業を待っている競合の調整に対処する人は誰ですか?

リソース コントラクト

この用語は、通常、リソースのグループを管理する部門長と、それらのリソースによって達成する必要がある作業を管理するプロジェクト マネージャーを持つマトリックス組織で見られます。 "リソース コントラクト" という用語は、特定の作業にリソースをコミットするために、プロジェクト マネージャーと部門長の間の交渉を指します。 これは、特定のユーザーが特定の日付に特定の時刻に使用できるようにするためのプロジェクト マネージャーからの要求として開始される場合があります。 部門長は、類似のスキルを持つ別の人または別の日付に要求された人のオプションを含むカウンターオファーで返信する場合があります。 その後、プロジェクト マネージャーは、リソース要件が満たされるまで、同意またはカウンター カウンター オファーなどの返信を行います。

リソース追跡

一部の組織では、リソース管理の最も重要な側面は、計画ではなく、実際に何が起こったかを決定することです。 「私の人々が実際に時間を使って何をしているのかを教えてくれば、はるかに効率的になります」と上級幹部は言うかもしれません。 これらの組織では、エンタープライズ プロジェクト管理システムのタイムシートの側面が最も重要になります。 プロジェクト計画に統合しなくても、活動ごとの会計は、各タスクのコストを管理するために膨大なデータを提供します。 また、プロジェクト作業に使用できる時間と、さらに興味深いことに、プロジェクト作業以外に何時間が費やされているかを興味深く描いています。 タイムシート コレクションをプロジェクト 計画に関連付けることができる場合、リソース管理は予算と実際の分析に拡張できます。 各計画タスクに必要な時間、これまでのタスクの進行状況、そのタスクのプロジェクト完了に対する進行状況の影響、およびその影響を受ける可能性があるその他のタスクを確認できます。

リソース通信

メガプロジェクトの建設の世界では、私たちはリソース通信についてそれほど心配していなかった。 前者は、午前中にプロジェクトオフィスから最新のニュースを受け取り、彼らが始めたら何を知る必要があるかをスタッフに伝えました。 ホワイトカラーのハイテクタイプのプロジェクト環境では、そうではありません。 プロジェクト チームは、すべての種類のユーザーで構成される可能性があります。 プロジェクト スケジューラと作業を行うリソースとは別に、エグゼクティブ スポンサー、ユーザー、クライアント、サブ請負業者、アウトソース開発者などがいます。 オフィスの壁だけでなく、組織の境界を超えるプロジェクト チームが今では珍しくありません。 このような環境での通信は、はるかに重要になります。 このコンテキストのリソース管理は、プロジェクト管理プロセスに関係するすべてのリソースと効果的に共同作業できるだけかもしれません。

リソースコミットメント

プロジェクト管理システムについて話すときは、非常にアルゴリズム的な環境について話す傾向がありますが、プロジェクト内のリソースのコミットメントを管理することも、作業を行う上で重要な側面です。 プロジェクト チームのリーダーは、要求したコミットメントと、彼らが行ったコミットメントを管理する必要があります。 リソースに "金曜日までに完了します" と表示される場合があります。これはコミットメントです。約束。 スケジュールの予想終了日と完全に一致している可能性があり、そうでない場合があります。 これはコミットメントであり、スケジューリング アルゴリズムが作業を行う必要があると言う場合とは異なります。 リソースコミットメントは、Outlook または Office SharePoint Server、ホワイト ボード、またはその他のコミットメント ツールで管理される場合がありますが、何らかの方法で管理する必要があります。

リソース Sub-Contracting

一部の組織では、他の企業から契約されているリソースを管理するだけで十分なリソース管理が行われます。 サブ契約が関与する場合は、下請業者が行う約束を管理し、契約が適切なインセンティブを提供し、下請負業者によって受け入れられるように、プロジェクトを作成または中断することができます。

それはかなり簡単に聞こえます。 結局のところ、Microsoft EPM ソリューションには、リソース管理のすべての側面に対応するツールがあります。 リソース平準化、リソースの割り当て、リソースの読み込み、スキルのスケジューリングはすべて、Project Server の基本的な機能、またはProject Standardまたは Professional でのみ参照されます。 複数プロジェクトのリソース割り当ては、リソース置換ウィザードまたは Project Server のチーム ビルダーで行うことができます。 リソースの追跡は、Project Server のタイムシートで実行できます。 リソース コントラクトには、既定では多くのインターフェイスはありませんが、提案されたリソースとコミットされたリソースの概念全体がその領域にあります。そのため、リソース要求を処理するためのより堅牢なインターフェイスは、Office SharePoint Server を使用した Web ベースのフォームで行い、機能に直接結び付けられます。 リソース Sub-Contractingでも、Office SharePoint Server の機能を使用して対処できます。

チャレンジ

私はリソース容量計画について話していないので、それは不可能だからではないことに注意してください。 これは通常、EPM デプロイで最も要求される側面ですが、実際に提供するのが最も難しい側面の 1 つです。

高度なスキルを持つリソース グループにリソース 平準化アルゴリズムを適用しようとすると、基本的な課題があります。 それを理解するには、リソース 平準化アルゴリズムが作成されたときに元のデザイナーが考えていたものに戻る価値があります。 私はリソース平準化と重要なチェーン分析に戻ると約束しました。これが理由です。

元のリソース 平準化エンジンを考えると、それらはエンジニアリング コンテキスト用に設計されました。 最初のプロジェクト スケジューリング ツールは、一度に 1 つのプロジェクトで計算が行われる重いエンジニアリングおよび建設プロジェクト用に作成されました。 確かに、組織全体が 1 つのプロジェクトを提供するために作成されている可能性があります。 オリジナルの商用ツールは、防衛および石油・ガス産業をターゲットにしており、これらのツールが管理できる大量のデータを利用できます。 しかし、このようなプロジェクトのリソースを見ると、常に一般的なリソースを考えます。

このようなプロジェクトのリソース スケジューリングは、必然的にスキルによって行われます。 プロジェクト スケジューラは、必要な機械エンジニア、電気技師、パイプフィッターの数を考え出します。 リソース 平準化アルゴリズムは、この質問に最適です。 多くのリソースがあり、タスクを平準化し、正社員の数は必要に応じて上向きまたは下向きに変化する可能性があります。 同じ種類の交換可能なリソースのかなりの数に対してこれを考えると、アルゴリズムはかなりうまく機能します。

最新のプロジェクト管理は、もともと多数の交換可能なリソースを持つメガ プロジェクト用に作成された概念を拡張し、それらを個々のレベルまで適用しました。 このアルゴリズムは、少なくとも理論的には引き続き機能し、一度に 1 つのリソースしか表示されないため、デモンストレーションで問題なく動作します。

次の例を見てみましょう。

Chris のオーバーブックを示す Microsoft プロジェクト ビュー。

私は2007年Project Professionalここで簡単なプロジェクトを持っています。 私はマイルストーンでプロジェクトを開始し、マイルストーンが完了した直後に開始する2つのタスクを追加しました。 両方のタスクに Chris を割り当てるとすぐに、リソース平準化の問題が発生します。 分割画面でわかるように、Chris は 2 倍の可用性に割り当てられます。これは完全に理にかなっています。

次に、プロジェクトのリソース 平準化アルゴリズムを使用してプロジェクトを平準化します。

Chris の連続したタスクを示す Microsoft Project ビュー。予約が取り過ぎないようにします。

ここでも、物事は完璧です。 Chris のタスクは、1 つではなく 2 週間にわたって分散されており、すべてを達成するためにタスクの 1 つを 2 週間に遅延させる必要があることを示しています。 また、Chris は第 1 週から第 2 週まで継続的に作業していることが示されています。

計算に別のリソースを追加するまでは、すべてうまくいっています。 最初の状況に戻り、いくつかの追加タスクをプロジェクトに追加しますが、他のユーザーに割り当てます。

Chris と John のタスクを示す Microsoft プロジェクト ビュー。

今、私は一度に2人の人が働いています。 Chris は割り当て過ぎの状況に戻っています (1 週間目に両方のタスクを確認でき、同時に開始する John に対して 3 つのタスクが追加されました。 ただし、John のタスクは、いくつかのシーケンスがあるため、既にリソース が平準化されています。 ジョンの状況だけを見ていると、問題なく見えます。 John は第 1 週から第 2 週まで継続的に作業していますが、リソース 平準化アルゴリズムを今すぐ適用するとどうなりますか?

Chris と John のタスクと John の 1 週間のギャップを示す Microsoft プロジェクト ビュー。

プロジェクト レベル Chris の時間は初めて行ったとおりで、Chris の作業は第 1 週から第 2 週まで連続しています。 しかし、John は、クリスが 2 番目のタスクを完了するのを待つ間、仕事に完全な 1 週間のギャップを持つ予定です。 ジョンに新聞を読んでもらい、1週間ずっとキュービクルでアイドル状態を保ちたいとは考えにくいので、時間をスケジュールする方法を手動で管理するのは、John と Chris の上司次第です。

ここでは、2 つのリソースの最も簡単な例のみを見ています。 問題は、話をする完全なチームがあり、影響を受けるプロジェクトが複数ある場合や、各タスクに複数の人が配置されている場合に、それほど悪化します。

これは Project の障害ではありません。 これは、リソース平準化を行う市場のほぼすべてのスケジューリング ツールでリソース平準化がどのように機能するかだけです。 最初にクリティカル パスを計算し、選択したオプションに基づいてリソース制約をスケジュールに適用します。 システムによってオプションは異なりますが、リソース 平準化アルゴリズムを個人に適用すると、これが常に終了します。 最新のプロジェクト スケジューラは、スケジュールを個々のレベルに行う必要がある場合に、クラシック リソース 平準化を適用しないことを学習しました。

これは、Project などの分析ツールが Outlook などのリソース コミットメント システムに情報をプッシュしない根本的な理由の 1 つでもあります。 その中核となる Outlook は、個人コミットメント システムと見なすことができます。 Outlook では、毎日コミットメントを行います。 来週の午後 2 時に予定に入ると約束します。 (誰かが自分である可能性があります。あなたは、今週の火曜日までにタスクを完了する人を約束します。 今日の Outlook では、実行する必要があるタスクと予定を確認し、システムの通信機能を使用して、作成または要求しているコミットメントについて他のユーザーに対応します。

これを Project と統合するとします。これは、その中核となる分析システムです。 Project または Project Server から Outlook にアクティビティを移動し、その進行状況を取得することは 1 つのことです。 誰かの Outlook タスクがすべてスケジュールに統合された場合はどうしますか? 来週、朝の歯医者に予約を入れるかもしれません。 今後スケジュールしたすべてのタスクを通じて、この 4 時間のギャップが可用性の波及に与える影響を与える必要がありますか? すべてのタスクを 4 時間後にプッシュする必要がありますか? 対話するすべてのユーザー、またはタスクが 4 時間の遅延の影響を受けるすべてのユーザーのスケジュールはどうでしょうか。 会社全体で、スケジュールが 4 時間後にプッシュされたというメールの受信を開始する必要がありますか? しかし、待って、私は唯一の人です。 すべてのユーザーの Outlook コミットメントが、社内のすべてのユーザーのすべてのタスクに影響を与えるとどうなりますか? 簡単に言えば、混乱が発生します。

Outlook などのリソース コミットメントまたはリソース通信ツールを Project や Project Server などのリソース容量計画ツールと統合する場合は、2 つのパラダイムの哲学上の違いを調整する必要があります。 Project Server から Outlook へのリンクが設計されたとき、これは考え方の一部でした。 Outlook は、Project からタスクを受信し、それらのタスクを Outlook の予定表またはタスクリストに統合するために有効になります。 Outlook から Project Server への "プッシュ" タスクは許可されませんでした。

リソース管理システムの作成

ここまで行った場合は、リソース管理を作成する方法に関するいくつかのアドバイスを得て、いくつかの提案をしたいと思っているかもしれません。

まず第一に、リソース管理のどの側面が組織に適用され、どの側面を迅速に利用できるかについて説明する価値があります。 リソース管理の一部の側面は、実装する際に他の側面よりも大きな課題になることが非常に一般的です。 私はいつも最初に低ぶら下がりの果物をつかむために熱心です。 たとえば、リソースキャパシティプランニングに最も関心があるかもしれませんが、そのようなプロセスを作成し、すべてのデータを収集して一貫性のあるプロセスを作成することは困難な課題です。 ただし、タイムシート システムを使用して Resource Tracking を実装すると、克服すべき文化的なハードルが少なくなる場合があります。 そのため、まず、リソース管理とは何か、他の側面を検討する視点を広げることから始めます。

リソース容量計画を見ている場合は、リソース平準化アルゴリズムが個々のレベルでリソース定義に問題があることを理解する必要があります。 その場合は、リソースの平準化をスキルまたは一般的なレベルに行い、個々の割り当てをチーム リーダーに任せるかどうかを考えることができます。 これは、多くの場合、上級幹部に動揺している EPM 展開の領域です。 すべての影響を考慮していない人にとっては、分析が一元的に行われるシステムを想像することは珍しくありません。また、すべての個人の日常の予定表を個人的および企業のコミットメントと魔法のように調整するだけでなく、毎日完全な作業を確実に行うことができます。

リソースキャパシティプランニングがあなたの懸念事項である場合、私はあまり頻繁に提案されていないあなたにアイデアを持っています。 どのハイテク組織でも、個々のレベルへのスキル スケジューリングは非常に一般的です。多くの人は、特定の種類の作業に特に適した独自のスキルと知識のコレクションを持っているためです。 その場合は、'Key Resource Project' の作成を検討してください。 私の経験では、組織内の主要なリソースは、リソースの総数の 5% 未満を表しています。 これらの重要なリソースは、すべてのプロジェクトに不可欠なユーザーです。 彼らは他に見つからないスキルと知識の組み合わせを持っており、成功したプロジェクトマネージャーは、成功したい場合は、それらの重要なリソースの1つをプロジェクトに確実に取得することを知っています。

キー リソース プロジェクトは、それらのユーザーにのみ割り当てられているすべてのタスクの一覧です。 リソース レベルの作業を行い、チーム リーダーが担当している場合でも、周囲の他のすべてのリソースをスケジュールします。 これはほぼ瞬時に実装でき、比較的少量の労力がかかります。 これを試みた組織は、多くの場合、すべてのユーザーを含める必要があるプロセスの文化的課題とプロセス改善の課題なしに、リソース 平準化の心痛の多くを解決します。

また、プロジェクト チームが Microsoft で行うのと同じように、ソリューションが Project Server よりも広範であると考える価値もあります。 "Microsoft EPM ソリューション" は、結局のところ、テクノロジのスタックです。 リソース管理のすべての異なる側面を検討した後、Windows SharePoint Services、Windows ワークフロー、Office SharePoint Server (フォームの場合)、SQL Serverすべてが、組織に必要な環境を作成するために不可欠なベクトルになります。

著者について

Chris Vandersluis は、カナダに拠点を置く MICROSOFT 認定パートナーであるモントリオールの社長兼創設者です。 彼はマギル大学で経済学の学位を取得し、プロジェクト制御システムの自動化に30年以上の経験を持っています。 彼は、プロジェクト管理研究所 (PMI) の長年のメンバーであり、Microsoft Project Users Group (MPUG) のモントリオール、トロント、ケベックの各章の設立を支援しました。 クリスが執筆した出版物には、Fortune、Heavy Construction News、Computing Canada Magazine、PMI の PMNetwork が含まれており、彼は Project Times の定期的なコラムニストです。 彼はマギル大学で高度なプロジェクト管理を教え、多くの場合、北米と世界中のプロジェクト管理協会の機能で話します。 HMS Software は、TimeControl プロジェクト指向のタイムキーピング システムの発行元であり、1995 年から Microsoft Project Solution Partner です。

Chris Vandersluis には、次の電子メールで連絡できます。 chris.vandersluis@hms.ca

Chris Vandersluis による EPM 関連の記事をさらに読む場合は、HMS の EPM ガイダンス サイト (https://www.epmguidance.com/?page_id=39) を参照してください。