エンタープライズ プロジェクト管理を展開する段階的方法: ホワイト ペーパー

このホワイト ペーパーは、Microsoft の「From the trenches」コレクションの一部であり、自社環境へのエンタープライズ プロジェクト管理ソリューションの展開を計画する際に直面する、さまざまな課題について説明します。また、利用可能ないくつかの展開シナリオとともに、考慮が必要な重要な前提条件も紹介します。

このホワイト ペーパーの Word 版をダウンロードするには、「エンタープライズ プロジェクト管理を展開するための段階的アプローチ: ホワイト ペーパー」を参照してください。

その他のホワイト ペーパーについては、「From the Trenches」のホワイト ペーパーを参照してください。

エンタープライズ プロジェクト管理を展開するための段階的アプローチ

このホワイト ペーパーは、自社環境へのエンタープライズ プロジェクト管理ソリューションの展開を計画する際に直面するさまざまな課題について、経営上の意思決定者、ネットワーク管理者、プロジェクト サーバー管理者に指針を示します。また、利用可能ないくつかの展開シナリオとともに、考慮が必要な重要な前提条件もご紹介しています。

概要

私が所有する会社では、Microsoft のエンタープライズ プロジェクト管理 (EPM) ソリューションの展開を推進しています。公平を期していえば、HMS Software 社はそれ以外にも多くの業務を行っており、また ISV でもありますが、私はかなりの時間を費やして、中規模から大規模の企業の皆様とともに、EPM をどのように展開できるかという課題に取り組んでいます。これらの課題の中には Microsoft のテクノロジに特有のものもありますが、その多くは、1983 年にプロジェクト管理ソフトウェアの事業を開始して以来、数々の企業が直面するのを目の当たりにしてきた課題に類似しています。ここでは、独自の EPM 展開を計画するにはどのような方法があるかを見ていきます。

EPM の展開を開始する際に直面する最大の課題の 1 つは、意図した結果を生み出すための確かなロードマップの確立です。これまで 24 年間にわたってエンタープライズ プロジェクト管理システムの展開に携わってきましたが、その間変わっていないことは、経営幹部がすべての結果を性急に手に入れることを望むという点です。

課題はほとんど常に存在する、次の 2 つの複合的な要素から成ります。

  1. 営業チームは顧客に最終的な成果を示すときに、それだけの結果を本番環境で再現するためにどれほどの労力が必要になるか、あるいは販促デモに含まれる仮想的なイメージやデータを作成するのでさえどれだけの労力が費やされているか (一般に延べ月数で数か月) を説明していません。

  2. Microsoft は、展開が容易であるという実績を受け継いでいます。私たちは DVD を PC に挿入して排出されるのを待つだけで、購入したソフトウェアを直ちに利用することに慣れてきました。任意の研修という考え方もあるかもしれませんが、組織を変化させるトレーニングが実施されるという期待は持てそうにありません。

エンタープライズ プロジェクト管理とは

困難な課題ではありますが、購入に際して顧客が見過ごしがちなその他の点として最初に挙げられるのが、「EPM とは正確にはどのようなものか」という問いです。短い問いですが、答えは長くなるはずです。EPM 展開の初期ステージにおいて、当社では顧客の経営幹部を対象に、ビジョンを描くワークショップを開催しています。その際にいつも使用しているスライドの 1 つは次のようなものです。

EMP ソリューションのさまざまな特長を一覧表示した図

「あなたが考える EPM とはどのようなものですか」という問いへの答えは、多くの場合、このスライドの輪のどこかに見つかります。たとえば、次のような答えです。

  • 基本的なプロジェクト管理   。「当社にとってエンタープライズ プロジェクト管理とは、全員が同じ方法でプロジェクト管理を行い、同じツールを使用することです。」

  • エンタープライズ プロジェクト管理   。「それだけでは十分ではない」と言う人もいます。「当社にとってエンタープライズ プロジェクト管理とは、プロジェクト管理データが統合されることです。統合され要約された形式でスケジュールを示すレポートを取得できること、そしてプロジェクト間の影響を管理できることを意味します。」

  • プロジェクト ポートフォリオ管理 (PPM)   。「プロジェクト ポートフォリオ管理を意味する」と答える人もいるでしょう。「当社にとってエンタープライズ プロジェクト管理とは、1 つ上のプロジェクト レベルで管理を実現することです。プロジェクトをポートフォリオやプロジェクト グループにグループ化して、それらをまとめて分析したりレポートを作成したりする必要があります。このような要約レベルで、進捗のトラッキングやステージ ゲートの実施ができることが必要です。」

  • リソース管理   。「当社にとってエンタープライズ プロジェクト管理とは、リソースのキャパシティ プランニングを意味します。新しいプロジェクトを請け負うことができるかどうか、既存の責務にどのような影響を与える可能性があるかを把握するだけでなく、プロジェクトの進捗状況やリソースの空き状況に基づいて、既に請け負っている業務の管理ステータスを把握することも必要です。」

  • レポート分析   。「エンタープライズ プロジェクト管理はレポートで行われる」と語る人もいます。「プロジェクト管理、財務、人事その他の内部システムから抽出されるレポートから、管理および意思決定のためのロールアップ レポートを作成する必要があります。レポートについてお話ししていますが、動的なダッシュボードやスコアカード、その他の視覚的システムも必要です。」

  • 予算管理とコスト管理   。「当社にとってエンタープライズ プロジェクト管理とは、もっぱら資金に関するものです。毎年期首に予算を編成して、そこから各プロジェクトの予算を組んでいます。当社にとって重要なことは、計画に照らして毎月の収支を管理することだけです。」

  • タイムシート   。「計画のことなどまったく気にかけていません。社員たちが実際に何に時間を費やしているかだけわかれば、現状から先んじることになります。それが EPM の成功といえます」としばしば口にする人もいます。

  • コミュニケーションとコラボレーション   。「精密なアルゴリズムの話ではありません。私たちは社員との対話を円滑にする必要があります。今やプランナーだけでなく、経営幹部、顧客、ユーザー、下請け業者、アウトソーシング先、チーム メンバーまでも含むようになったプロジェクト チームとコミュニケーションを保つための支援を得ることができるでしょうか。」

  • 外部アプリケーションとの統合   。「当社では大規模な ERP/財務システムを運用しています。プロジェクト管理の成果とコストについて前向きな見通しがないという点を除けば、大変優れたシステムです。プロジェクト管理ツールをその ERP/財務システムと連携させることができれば、当社にとっては十分なエンタープライズ プロジェクト管理となります。」

  • ワークフロー   。「当社では、タスクだけでなく手順も、自動化された方法で追跡するシステムの展開を構想しています。プロジェクト マネージャーがオンライン フォームに記入してプロジェクト資金を要請し、自動化された方法でその要請が責任者に回送されて、承認または却下されるようなシステムです。承認されたプロジェクトは、即時に EPM システムに追加されます。プロジェクトの全ドキュメントについて同じ方法を適用したいのです。実際には、ワークフロー管理を用いて、すべてのプロジェクト管理手順をこのように自動化したいと考えています。これこそが真のエンタープライズ プロジェクト管理です。」

  • ビジネス インテリジェンス   。「必要なのは、プロジェクト データのスコアカード、ダッシュボード、データ マイニングです。」と語る人たちもいるでしょう。「それが最終的なエンタープライズ プロジェクト管理環境です。」

  • プロジェクト管理の成熟度モデル   。「当社では、‘プロジェクト管理成熟度モデル’ に基づいて評価される成熟度レベルの向上に取り組んでいます。」

では、どれが正しい答えなのでしょうか。これらはいずれも正しい答えです。実際には、これでもすべてが網羅されているとはいえないでしょう。EPM は多くの人たちにとって多くの意味を持ち得るものであり、問題をどのような観点で捉えるかによって大きく異なります。

この問いかけを経営幹部に対して行ったときにしばしば起こることは、これらの特徴の中に、必要とされていないものがないということです。そうです、皆、これらのすべてを求めています。そして、Microsoft EPM ソリューションを展開することでこのすべてが可能になるかと問われれば、正直な答えはイエスです。問題なのは、EPM のこれらの特徴のそれぞれが、EPM 環境を推進するベクトルあるいは方向と考えられていることです。プロジェクトの第 1 日目から、これらのベクトルすべてを推進すると決めたとしたら、そのプロジェクトの最終的な設計規模は非常に大きく、分裂の可能性が高く、非常に複雑で、あまりに多くの社内システムが関与して、成功する可能性はほとんどなくなります。

EPM の導入には、戦術、ひと、プロセス、そして技術が関わります

エンタープライズ プロジェクト管理の展開は単なるテクノロジに留まりません。テクノロジだけの問題であれば、数日で実装することも可能だったでしょう。しかし、そうではありません。EPM の展開には、戦略、人員、プロセス、テクノロジが関わっています。Microsoft EPM ソリューションの仮想的な展開の成功例においては、プロジェクトをテクノロジ プロジェクトではなく、必ず ‘変更管理’ プロジェクトと見なしています。達成しようとしていることは、ビジネスの仕組みを変えることなのです。どのように変えるのか、それは、目指している課題の進む方向によってさまざまであり、まったく異なる方向の場合もあります。

すべての特徴と方向を同時に展開しようとすれば、結局は複雑で理解が困難な、展開のリスクがはるかに高くなるだけの巨大プロジェクトが生まれてしまう可能性があります。

EPM の展開アプローチ

ここで少し、いかに多くの人たちが EPM の展開に取り組んでいるかについてお話ししましょう。考えられるシナリオはいくつかあります。ビッグ バン、即時バン、段階的アプローチが挙げられます。

ビッグ バン

ビッグ バンの手法は「すべてを行おう」とするもので、最終的なエンタープライズ プロジェクト管理環境を、桁違いの時間を費やして設計、構築、書き直し、プログラミングします。プログラマーを集結させ、将来のある日、ある週末に、スイッチをカチッと入れて、皆で一斉にエンタープライズ プロジェクト管理の運用に移行しようとするものです。投資利益を時系列でグラフに示すと、次の図のようになります。

プロジェクトが終了するまで、投資収益率はグラフに表示されません

ビッグ バンの手法にもプラスの点とマイナスの点があります。プラスの点は、他のタイプのアプローチの場合よりも、最終結果が当初の意図に近くなる可能性が大きいことです。つまり、プロジェクトの開始時に策定された要求事項をすべて満たすまで、チームが落ち着くことはありません。

一方、マイナスの点として、いくつかの大きな問題があります。何よりもまず、企業はプロジェクトが 100% 完了するまで、投資利益をまったく得ることができません。利益を得るのは場合によっては数か月、1 年、あるいはもっと先のことかもしれません。プロジェクトが完了しない間は毎日、誰かしらが "より良い" アイデアを携えて建物内を歩き回る日々となるかもしれません。そして、何事も変化するのが世の常です。チームの変更、経営陣の変更、企業の使命や戦略の変更、基礎となるテクノロジ アーキテクチャの変更、企業の所有権の変更が発生すれば、プロジェクトの再構築や撤退に至ることもあり得ます。そのような事態になれば、企業はそれまで払った労力に対して何も得られないことになります。

即時バン

Microsoft を模範として慣れ親しまれてきた、即時に満足を提供するという側面について考えると、異なる展開方法が見えてきます。顧客の中には、Microsoft EPM ソリューションを展開することは、Microsoft のゲームをプレイするのと同じようなものであると捉える人たちがいます。DVD をロードしてしばらく後には、調整された共同的な方法でプロジェクトを運用しているというわけです。投資利益も、新システムに夢中になっているパイロット グループが使用を開始して数日間、あるいは数週間は好調に見えます。しかし、経営幹部の後押しなしに文化や行動の変化を実現するのは、不可能とはいわないまでも極めて難しく、プロジェクトが拡大されることはめったにありません。システムは短期間利用された後で放棄されるか、システムを一緒に使用するように社内の他の人たちを引き付けられなかったことにしばしば失望している少数のユーザーによって、そのまま使用されることになります。

早期の小さな投資収益率を表示するダイアグラム

段階的アプローチ

エンタープライズ プロジェクト管理環境を展開するには段階的アプローチが最も有効な手法であることを、これまで長年にわたって明らかにしてきました。その理由はたくさんありますが、ここでいくつかご紹介しましょう。

  • 1 つ目は、企業が投資利益をプロセスの初期段階から獲得し始めるという点です。これは展開を保護する役割を果たし、経営陣に対して、EPM の展開を第一に行うというその決定の正当性の裏付けを提供します。

  • 2 つ目は、展開に伴う技術的課題のすべてに一度に取り組むのではなく、波状的に対処できるという点です。システムの複雑度が高くなるにつれて、その複雑さに対処する企業の成熟度も同様に上がっていきます。

  • 3 つ目は、展開により、時間の経過とともに文化の変化が組織にゆっくり浸透していく点です。時間をかけた方がスムーズに運ぶものです。変化が混乱を招くのは自明のことであり、プロジェクト管理のそのような変化によって何らかの混乱が生じることは避けられません。ビジョン全体を時間をかけて展開することで、ユーザーはビジネスの推進方法の変化に適応していくことができます。

  • 最後に、企業が当初の設計の立案にどれだけ時間をかけたとしても、システムが運用に至ると同時に、その意図には変更が発生するものです。そのような展開の第 1 フェーズを早い内に本番に移行することで、企業が先に進むにあたって、そこから学ぶことができます。

段階的アプローチで、安定および増加傾向の投資収益率

この手法において一番重要な要素は、第 1 フェーズです。当社ではコンサルタントたちに、「継続的なプラスの投資利益を生む、可能な限り最小の展開」を発見するように教えています。これは大変慎重に言葉を選んで表現しています。私たちは、本番環境に移行して結果を出し、その実現に要した労力よりも大きい利益を毎週もたらすことができるような、展開の第 1 フェーズを見つけ出したいと考えています。それを行えば、展開はその先もずっと続いていきます。「'このような実際の利益' を毎週生み出している以上、廃止することはできない」という理由があるため、展開を止めようとする人はいないはずです。そのような展開を生み出すことに成功すれば、それをベースにして、その先何か月間も展開を続けていけるでしょう。しかし成功できなければ、プロジェクトとその展開は、大きなリスクにさらされたままになります。

EPM 展開戦略の概要

EPM の展開の実施について皆さんに熟慮を強いてしまったかもしれませんが、おそらくそれでよいのだと思います。そうすべきでないというわけではありませんが、EPM の展開の成功はいつでも、少し余分に考えることから始まります。では、展開を進めるにはどのようにすればよいのでしょうか。いくつかの前提条件から説明していきましょう。

1. プロジェクト管理オフィス

エンタープライズ プロジェクト管理環境の展開を目的としているのであれば、エンタープライズ プロジェクト管理の担当部署を設けるしか方法はありません。これは一般に、プロジェクト管理オフィス (PMO) と呼ばれます。どのように呼んでも構いませんが、Microsoft EPM ソリューションなどのシステムを一元管理することが必要になります。テンプレートを '公式' テンプレートと宣言するのは誰でしょうか。リソースの優先順序を変更する権限を誰に与えるか決めるのは誰でしょうか。レポートをどのような外観にするか、それらのレポートにアクセスできるのは誰かを決めるのは誰でしょうか。リスク管理を行うかどうか、行う場合、周囲にどのプロセスを配備する必要があるかなど、判断すべきことはたくさんあります。そうです、PMO が不可欠です。PMO を (たとえ担当者 1 人であっても) 設けなかった場合、EPM 環境の実現に向けた初期手順の 1 つとして、PMO の設定から始めることが必要になります。

2. 経営陣の支援

続いて、経営幹部の支援と支持を仰ぎます。このプロジェクトを支援するのが経営陣の誰であっても、その人は、展開の目標だけでなく、どの程度の期間にわたって支援の提供が必要になるかも把握する必要があります。私たちは通常、支援の責務は最低でも丸 1 年間は必要になる予定であると伝えます。よく目にする落とし穴は、エンタープライズ プロジェクト管理環境の推進を切望しているが、経営陣レベルの支援が得られない中間管理職やプロジェクト マネージャーの小規模のグループが、支持を取り付けるために、自分たちで展開を行おうとするケースです。映画「フィールド オブ ドリームス」の「それを作れば彼らはやって来る」の手法ですが、これが成功することはまずありません。問題なのは、経営陣を引き付けるような真の利益 (プロジェクト管理の方法論のコンプライアンス、グローバルなプロジェクト レポート、リソースのキャパシティ プランニング、共同プロジェクト管理など) は、経営陣が参加してこそ達成できる類の利益であるということです。

3. プロジェクト マネージャーにもプロジェクト管理は必要である

EPM 展開の最も一般的な落とし穴を回避したければ、プロジェクト計画を策定することです。妙に単純に聞こえるかと思いますが、驚くほど多くの EPM 展開プロジェクトで、実際にはプロジェクト計画が立てられていません。Microsoft EPM ソリューションの展開を検討している企業に向けた最も簡単な助言の 1 つは、その展開をプロジェクトとして立ち上げ、その他のプロジェクトに既に用いてきたものと同じすべての方法論を適用するということです。プロジェクト スケジュールはあるでしょうか。予算を策定し、経営陣の支援を仰ぎ、プロジェクトの取り決めを行い、リソース、成功指標は準備しているでしょうか。これらの項目は、企業のその他すべてのプロジェクトで見受けられるものかもしれません。しかし、いつも裸足でいる靴屋の子供のように、プロジェクト マネージャーは往々にして、自分の持つスキルを自分のプロジェクトに活かすことを忘れることがあります。

4. 目標の設定

各フェーズの成功指標の設定は、プロジェクトのごく初期の段階で行います。一連の明確な業績指標を設けることは、プロジェクト チームのみならず経営陣がプロジェクトの各フェーズの完了に注力する上で大いに役立ちます。

作業の開始

どこから着手すればよいか迷っている場合は、次に示すいくつかの提言を参考にしてください。

ビジョンを描く

経営幹部とのビジョン明確化セッションから開始します。外部の支援を利用しているプロジェクトの要件がほかにない場合、このセッションは最も役に立つでしょう。他の EPM の展開に何件か関与したことがある人の存在が、成功への鍵となります。ここでは、単に EPM システムのユーザーだった人を指しているのではなく、先述した問題のいくつかに対処した経験があり、Microsoft EPM ソリューションの機能と、企業におけるプロジェクトの管理プロセスの両方に精通している人を意味しています。

誰に参画を働きかけるか

プロジェクトの初期に決定する必要がある項目の 1 つに、'エンタープライズ' を誰に設定するかという点があります。この記事の中で 'エンタープライズ' という言葉を何度か使ってきましたが、エンタープライズは、皆さんが定めた何を指しても構わないのです。所属する部門、部署、あるいは会社全体でも構いません。展開を進める上で起こる共通の間違いは、会社全体向けの計画を策定しているのに、自分たちの部署に対する権限しか持っていないことです。システムが稼働したら、他の人たちも一緒に運用することが望ましいのにそれでは、フィールド オブ ドリームスの手法と大差はなく、一緒に運用できたはずの他の部署にとって魅力のない、権限のない部署の人たちには役に立たないソリューションになってしまいます。このため、誰が関与するのかを早い段階で定めて、必ずそれらの人たちにプランニングに参画してもらうようにします。

プロジェクト計画の策定

その他のプロジェクトで行うのと同じように、時間をかけて適切なプロジェクト計画を策定します。計画に含める必要がある項目のガイドラインとなる多くの計画サンプルをオンライン上で入手できるので、これを基にして作業を開始できますが、EPM 展開の適切なプロジェクト計画を作成するためのスキルは、ほぼ確実に皆さんはお持ちだと思います。

結論

Microsoft EPM ソリューションの展開を検討している方や、既に展開を開始したという方は、重要なポイントとして次の 3 つの点を考慮してください。

  1. このプロジェクトを 1 つのプロジェクトとして立ち上げます。現在持っているプロジェクト管理のあらゆるスキルを活用して、Microsoft EPM 展開プロジェクトを管理します。これはテクノロジ プロジェクトではなく、本来は変更管理プロジェクトであることを思い出してください。

  2. プロジェクトを管理可能な区分に分割して、プロジェクトの各フェーズをサブ プロジェクトとして扱います。これらのサブ プロジェクトにも独自の成功指標、スケジュール、予算、リソースを設定します。システム全体の進行が早まることでメリットが得られるほか、経営陣からさらに多くの支援を受けるプラス材料が加わります。

  3. システムを使用するあらゆるユーザー レベルで投資利益を得られることが大切です。経営幹部には有用でも、システムを管理する人々にとっては有用でないシステムを作っても、十分ではありません。また、プロジェクト マネージャーの役には立つけれども、経営幹部が必要とするレポート機能を提供できないシステムも同様です。プロジェクト マネージャーと経営幹部には役立つけれども、個人ユーザーには難しすぎたり労力が多すぎたりするシステムでも適切ではありません。システムの使用に時間とエネルギーを費やすことになるすべてのユーザーを考慮に入れて、各人が投資利益を得られるようにする必要があります。

段階的アプローチに従って、他のプロジェクトですでに使用している基本的なプロジェクト管理の方法論を用いて展開を設計すれば、大きな成功のチャンスが待ち受けています。皆さんの幸運と楽しいプランニングをお祈りしています。

著者について

Chris Vandersluis 氏は、カナダのモントリオールに拠点を置き、Microsoft 認定パートナーである HMS Software 社の社長であり創業者です。マギル大学で経済学の学士を取得し、プロジェクト制御システムの自動化に 30 年以上携わってきました。PMI (プロジェクト マネジメント協会) の古くからの会員であり、MPUG (Microsoft Project Users Group) のモントリオール、トロント、ケベックの支部の設立を支援しました。Vandersluis 氏が寄稿した出版物には、Fortune、Heavy Construction News、Computing Canada magazine、および PMI の PMNetwork などがあり、Project Times のレギュラー コラムニストです。マギル大学で上級プロジェクト管理を教えており、北米および世界中のプロジェクト管理団体の会合で頻繁に講演しています。HMS Software 社は TimeControl プロジェクト指向型の時間管理システムの発行元であり、1995 年から Microsoft Project ソリューション パートナー企業です。

Chris Vandersluis 氏のメールの連絡先は chris.vandersluis@hms.ca です。

Chris Vandersluis 氏の EPM 関連のその他の記事については、HMS 社の EPM ガイダンスのサイト (http://www.epmguidance.com/?page_id=39) を参照してください。

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

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

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

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

×