EPM: 集中型か分散型か: ホワイト ペーパー

このホワイト ペーパーは、「最前線の現場から」コレクションの一部です。 プロジェクト管理システムの実装について決断するときに、解決する問題について組織がどのように理解する必要があるかについて説明します。 一元管理のプロジェクト管理システムを展開することは、最適ではない場合があります。

このホワイト ペーパーの Word 版をダウンロードするには、「EPM: 一元管理型か分散管理型か」を参照してください。

その他のホワイト ペーパーについては、「最前線の現場から」のホワイト ペーパーを参照してください。

EPM: 一元管理型か分散管理型か

私は、1980 年代の初頭に初めてプロジェクト管理業界に入って以来、エンタープライズ プロジェクト管理の提唱者であり続けてきました。 そのため、常に一元管理のプロジェクト管理の側に立つと思われるかもしれませんが、そうとは限りません。 それでは、エンタープライズ プロジェクト管理の意味について少し説明しましょう。

EPM の意味は、人によって実にさまざまです。 このコラムの別の記事で既に説明したように、EPM 展開の焦点は、ある組織にとってはドキュメント管理であり、別の組織にとっては統合されたスケジュールです。 エンタープライズ プロジェクト管理はその中心にありますが、実際のプロジェクト管理ではユーザーが相互にやり取りする必要があります。 つまり、プロジェクト マネージャーとプロジェクト管理チームが完全に独立して作業することはありません。 それでは、この "やり取り" を実現するには、一元管理されたプロジェクト スケジューリング システムが必要なのでしょうか。 常に必要な訳ではありません。 組織によっては、すべてのプロジェクトが場当たり的に管理されているので、まとめられた企業全体のプロジェクト管理レポートを作成できないことがプロジェクト管理の課題の場合があります。 このような場合、すべてのプロジェクト管理担当者間で共有されるプロジェクト基準を用意するだけで、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 つのプロジェクトにつき 6 個前後の期日があります」という話でした。

この人の場合、大規模な一元管理の EPM システムをインストールすべきではないことは、この時点で明らかでした。

そこで、「お客様のパーティション内に大きなホワイト ボードを設置して、マイルストーンごとにマーカーの色を分けて書いてみてはいかがでしょうか。 1 つ目のマイルストーンには青、2 つ目には緑、最後には赤というように」と提案しました。

お客様はその概念に興味をそそられ、大量にメモを取りました。 その日、何のサービスや製品も販売せず、想定していたシステムを展開できないことにお客様を失望させたまま別れてしまった、と思いながら、その会社を後にしました。 帰宅中の車内で、電話が鳴りました。 それはあの担当者でした。 彼から「ホワイト ボードの色分けについて説明してもらえますか」と聞かれました。

解決しようとしている問題を解明してから、ソリューションを設計し、自動化する方法を選択する方法は、お金を節約できるだけではありません。 そもそも解決する必要がある問題が存在しない組織の要素に費やす多大な時間を節約できます。

解決しようとしている問題が、一元管理のエンタープライズ プロジェクト管理ソフトウェアで解決するのが最適な場合、他にできることはありませんが、問題を明確にすることで得られる焦点があれば、さらに役立ちます。 展開チームは、問題が解決したときにプロジェクトの成功を宣言できる、成功のメトリックを作成できます。 一元管理でも、分散管理でも、 エンタープライズ プロジェクト管理を達成できます。

著者について

Chris Vandersluis 氏は、Microsoft 認定パートナーであり、モントリオール (カナダ) に拠点を置く HMS Software の社長兼創業者です。 マギル大学で経済学の学士を取得し、プロジェクト制御システムの自動化に 30 年以上携わってきました。 PMI (プロジェクト マネジメント協会) の古くからの会員であり、MPUG (Microsoft Project Users Group) のモントリオール、トロント、ケベックの支部の設立を支援しました。 氏は、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 ガイダンスのサイト (http://www.epmguidance.com/?page_id=39) を参照してください。

スキルを磨く
トレーニングの探索
新機能を最初に入手
Office Insider に参加する

この情報は役に立ちましたか?

ご意見をいただきありがとうございます。

フィードバックをお寄せいただき、ありがとうございます。Office サポートの担当者におつなぎいたします。

×