EPM: 集中型か、または分散型か?

  • [アーティクル]

この記事は、"From the Trenches" コレクションの一部です。 プロジェクト管理システムの実装を決定するときに、組織が解決しようとしている問題を理解する必要がある方法について説明します。 集中型プロジェクト マネジメント システムが最適な答えではない場合もあります。

この記事の Word バージョンをダウンロードするには、「 EPM 一元化または分散化?」を参照してください。

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

EPM - 一元化または分散化

私は、1980年代初頭にプロジェクト管理業界に初めて参入して以来、エンタープライズプロジェクトマネジメントの支持者でした。 あなたは、私が常に一元化されたプロジェクト管理の側に投票すると思うでしょうが、それは必ずしもそうではありません。 Enterprise Project Management の意味について少しだけ説明しましょう。

EPM は、さまざまな人にさまざまなことを意味します。 この列の他の記事では、EPM 展開の焦点が 1 つの組織のドキュメント管理と次の組織の統合スケジュールである可能性がある方法について既に説明しました。 ただし、エンタープライズ プロジェクト管理は、プロジェクト管理演習でユーザーが相互に対話しなければならないという考え方を中心にしています。 つまり、プロジェクト マネージャーやプロジェクト管理チームは完全に独立して機能しません。 しかし、それは、この「相互作用」を達成する唯一の方法は、一元化されたプロジェクトスケジューリングシステムを持つことであることを意味しますか? 必ずしも。 一部の組織では、プロジェクト管理の課題は、プロジェクトがすべてアドホックベースで管理されているため、概要とエンタープライズ全体のプロジェクト管理レポートを生成できない可能性があります。 この場合、EPM は、すべてのプロジェクト管理担当者間で共有されるプロジェクト標準を持つことによって実現される場合があります。 これは、すべてのユーザーが使用できるテンプレート、トレーニング資料、ドキュメント、およびレポート標準の中央プールで実現するのが最適な場合があります。 おそらく、単純な SharePoint サイトで十分でしょう。

一部の組織では、プロジェクト管理の課題は、リソース間で作業内容と次の焦点が何であるかについてのコミュニケーションが不足しているため、効果的でない個人的なスケジュールである可能性があります。 この場合、EPM はチーム間のコミュニケーションを改善することによって実現される可能性があります。 ツールは、共有予定表、インスタント メッセージング、またはユーザーが優先順位を一覧表示できる共有ポータルと同じくらい簡単です。

一部の組織では、プロジェクト管理の課題は、プログラミング開発プロジェクトの進捗状況を把握しているだけです。 その場合、Visual Studio Team Servicesのような製品に既に存在するツールで十分な場合があります。 プログラミング プロジェクトでは、多くのタスクをほぼ任意の順序で完了できるのが非常に一般的であるため、実行される開発の種類によっては、クリティカル パス スケジューリングの厳格ささえも適切でない可能性があります。

私は何年も前に航空会社のメンテナンス部門と一緒に働いていたのを覚えています。 スタッフは毎月初めに自分のスケジュールを選択することが許可され、これが調整されていない場合(多くの場合)、誰も働いていないことを知るためにシフトを管理することが可能でした。 彼らのプロジェクト管理の課題は、"いつ作業が完了しますか? "誰かが仕事に来ていますか?この場合、EPM はシフト スケジューリング ツールを実装することによって実現されました。

EPM の課題をプロジェクト スケジュールに焦点を当てても、一元化されたプロジェクト管理システムをデプロイすることが唯一または最善の答えであることはすぐには明らかではありません。 プロジェクト管理担当者が互いにどのようなやり取りを行う必要があるかを尋ねる価値があります。 リソースの競合を解決したり、組織内の他の優先順位を確認したり、あるプロジェクトの進行状況が別のプロジェクトにどのような影響を与えるかを確認したりするために、定期的に共同作業を行う必要がある場合は、Project Server のようなツールを調べることは完全に理にかなっていますが、多くの場合、この質問さえしていない組織とやり取りすることになります。

一部の組織では、少数のスケジューラと多数のリソースが見つかります。 適切な規模の組織でも、これは、達成されるプロジェクトの業界や種類に応じて構造になる可能性があります。 その前に、私は彼らが彼らのEPMチャレンジのための適切なソリューションを選んだと確信していた組織と会いました。 彼らは私に解決策を明確にするように頼みましたが、いつものように、私は最初にプロジェクト管理の問題を明確にするように頼みました。

ホワイトボードで自分の環境を説明する作業が終わった頃には、彼らが選択したソリューションが問題を解決するつもりはないことを彼らにも明らかでした。

この場合、問題は、下請け業者の大規模なプールによって報告されていたプロジェクトの進捗状況の欠如でした。 クライアントは、本当に必要なのは、下請け業者に時間と請求の種類のタイムシートを課すことであると判断しました。 プログラムディレクターは落胆しました。 「下請け業者の契約に入ることは決してできません」と、彼らは言いました。 幸い、財務部のメンバーが出席しました。 「ご存知のように」と、その人は「私たちの選択したタイムシートを記入することを要求する条項は、既に下請け業者契約にあります」と答えました。問題は解決しました。

解決策に進む前に問題を説明するという考えは、私がここでよく話すものですが、採用するのは難しいものです。 論理的な考え方では、自動化されたソリューションを決定する順序は次のようになります。

  1. 問題を特定する

  2. ソリューションを定義する

  3. ソリューションを自動化するかどうか (および、その場合は方法) を決定する

Web サイト、ビデオなどの自動化されたソリューション デモでは、そのことを忘れてしまいます。 もちろん、何らかの問題がない限り、ソリューションは探しませんが、自動化されたソリューションは魅力的に見え、最終的にこれを行うようになります。

  1. 自動ソリューションを選択する

  2. ソリューションのデプロイに問題を発生させる

  3. 自動ツールをソリューションに適用する方法を定義することで、その問題を解決します

  4. 元の問題が何であったかを思い出してみてください

新しい問題は、かなり長い間ソリューションをデプロイすることになり、数週間、数ヶ月、または数年後に、上層部の誰かが元の問題が解決され、誰もが驚いてお互いを見合う時期を尋ねます。 忘れやすかったです。

何年もの間、私は可能な自動化されたソリューションのすべての種類を推奨してきました。 ああ、Project Server はもちろんオプションの 1 つですが、Microsoft Project Pro と SharePoint Server の組み合わせも推奨しています。 Excel と Outlook の組み合わせを使用することをお勧めします。 Project でサード パーティのタイムシートを使用することをお勧めします。

私はかつて大きなホワイトボードを使うことをお勧めします。 正直。 この組織は、何年もの間、私がビジネスを行っていた組織でした。 本人は不動産の役割を果たしており、不動産の長期リースを更新する必要がありました。 私が問題は何であるかを尋ねたとき、それは明らかにスケジューリングの問題でした。 その人は、重要ないくつかの期限を逃し、エンタープライズ プロジェクト管理ツールが問題を解決することを確信していました。 組織は、将来の期限を逃さないように、複数のエグゼクティブにレポートを配布するよう既に求めていました。 "何人のユーザーが存在しますか?私は尋ねた。 「私だけ」と彼は答えた。 "これらのプロジェクトの数は一度にいくつですか?私は「7、8」と尋ねた。彼は答えた。 「これらの期限のマイルストーンのうち、プロジェクトごとに管理するマイルストーンの数はいくつで、非常に複雑です。 1つ1つに半ダースの期限があります」と、彼は私に言いました。

私たちは、この貧しい仲間のための大きな一元化されたEPMシステムをインストールしてはならないことは私には既に明らかでした。

「キュービクルに大きなホワイトボードを置いて、さまざまなマイルストーンに色付きのマーカーを使ってみませんか?私は尋ねた。 "最初の 1 つは青、2 つ目は緑、最後には赤などを使用できます。

彼はコンセプトに魅了され、多くのメモを取りました。 私はその日、サービスや製品を販売しなかったが、想定していたシステムを展開できなかったことに失望したことを知って会社を辞めた。 家に帰る途中で、私の携帯電話は車の中で鳴りました。 それは彼でした。 「ホワイトボードのさまざまな色を説明してもらえますか」と彼は尋ねた。

ソリューションを設計する前と自動化方法を選択する前に、解決しようとしている問題を把握することは、コストを節約するだけではありません。 これは、最初に解決が必要な問題を抱えていなかった組織の要素に取り組むのに費やす膨大な時間を節約できます。

解決しようとしている問題を一元化されたエンタープライズ プロジェクト管理ソフトウェアで解決するのが最善の場合、他に何も行われませんが、問題を明確にすることで得られる焦点は、そこにさえ役立ちます。 デプロイ チームは、問題が解決されたときにプロジェクトが成功と宣言できる成功メトリックを作成できます。 一元化または分散化しますか? エンタープライズ プロジェクト管理は、どちらの方法でも実現できます。

著者について

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) を参照してください。