EPM 展開のロードマップでの GPS アシスタンス: ホワイト ペーパー

このホワイト ペーパーは、「最前線の現場から」コレクションの一部です。 ここでは、エンタープライズ プロジェクト マネジメント (EPM) の実装を計画する場合に、EPM 展開の "ロードマップ" を作成する方法について説明します。 特に、展開パスを計画する場合に、考慮すべき要素について説明します。

このホワイト ペーパーの Word 版をダウンロードするには、「G.P.S. 機能を利用した EPM 展開ロードマップの作成 (英語)」を参照してください。

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

G.P.S. 機能を利用した EPM 展開ロードマップの作成

前回のコラムでは、Microsoft のエンタープライズ プロジェクト マネジメント (EPM) ソリューションの展開計画の作成にあたって、段階的なアプローチの採用についてお話ししましたが、 ここでは、EPM 展開のロードマップを、プロジェクト計画の一環として作成する方法について説明します。

Microsoft Live Maps を使ったことがあれば、道順を示すには、目的地と出発地点という 2 つの要素が必要なことをご存じだと思います。 このことを EPM 展開に当てはめてみると、次のように同類の用語で考える必要があります。

  1. 出発地点: テクノロジ、プロセス、人材という観点から定義される

  2. 目的地: ビジネスという観点から定義され、優先順位が付けられる

また、グループを再編成する、写真撮影をする、景色を眺めて楽しむ、次の旅のために必要な物を補給するための「通過点」(中継地) を定義する場合もあります。

ロードマップや道順を作成する場合、2 つの基準を使うことは、きわめて一般的です。 旅行の次の行程について、進路変更ごとの経路にまで細分化した詳細な計画を立てますが、 一方で、全旅程の中での現在の行程の位置を確認するため、もっと大まかな上位レベルの旅程全体の地図を作成することもあります。 プロジェクト管理用語では、これを "ローリング ウェーブ計画法" と呼びます。

“道順”

EPM 展開のロードマップを作成する場合は、EPM の取り組みに関して、会社が目指しているビジョンや目的から必ず始めます。 これにより、Microsoft Live Maps のように、道順を決めるのに必要な目的地を特定できます。

シアトルからモントリオールまでの経路を示す地図

「どうしたいのですか?」と単に聞いた場合、返ってくる答えは、ほぼ間違いなく解決策に関するものです。 おそらく、「こんなレポートが必要です」や「うちの会社ではポートフォリオ分析が必要です」などと言うでしょう。

ソリューション ビジネスに関わっている者として、私たちは、この手のメモが、リスクを伴うことを知っています。 私たちは、問題を解決策として説明するクライアントの話を聞くときは注意するよう、自社のコンサルタントを訓練しています。 「それは、問題の解決策で、問題ではありません。 問題を定義しましょう」と言います。

「どうしたいのですか?」という質問は、しないようにしています。その代わりに、構想の手がかりとなる次のような質問をします。

「現在抱えているビジネス上の決定で、判断できない、または判断できるがかなりな困難を伴うのはどんな事項ですか? そして、今回の EPM 展開の結果、どの場合により簡単にビジネス上の決定を下せるようになると思いますか?」

または、

「今回の EPM 展開によるスループットの向上や労力の削減によって、組織のどのような点がより効率的になり得ると思いますか?」

では、このような質問をだれに対してすべきでしょうか? それは、もちろん、ビジネス上の決定を行う人々です。 ワンボックス車に大勢の子供たちを乗せて、どこへ行きたいかを子供たちにたずねたことがあれば、50 とおりの答えが出てくることを知っているでしょう。

同じように、私たちは、組織の意思決定者が、このプロセスの重要な役割を果たすことを確認しておく必要があります。さもなければ、"ドライバー" 抜きで目的地を選んでしまうような危険を冒すことになります。 この時点で、 組織の上層部を EPM のロードマップ作成プロセスに引き込むことには、さらにメリットがあります。 上層部に EPM 展開の方向性を決定する上で重要な参加者となってもうらだけでなく、プロジェクトの重要性を感じ取ってもらうこともできます。 EPM 展開の成功にとって、最も一般的でかつ困難な課題の 1 つは、長期的なマネジメントからのサポートです。 上層部の中には、EPM 展開によって、既存のやり方や手順がどの程度変わる可能性があるか、また、一時的とはいえ、どの程度の混乱が予想されるかなどについて、考えたことがない人もいます。 EPM のような、社内の文化を変えるプロジェクトにどれだけの労力が必要なのかも、正しく理解されていないことがあります。

組織の上層部はもちろん、プロジェクトの管理者や実際の業務担当者と仕事をする中で、私たちは、ビジネス上の決定やビジネスの効率をプロセスとやテクノロジと結びつけようとします。 この要件を達成するために、構築する必要があるプロセスはあるか? 達成するには何が必要か? そのビジネス上の決定のために、既に存在するか、または新たに作成が必要なシステムの機能は? 実現するには何が必要か?

この段階では、基本的なシステム分析が重要となります。 ビジネス上の決定という "出力" から出発して、その決定を下すのに必要であったデータ要素にまでさかのぼって調べます。 場合によっては、基本的なデータが単に存在せず、結果として、ロードマップのその要素が "高リスク" と判断されることもあります。結局、ビジネス プロセスの改革を考える以前に、それらのデータを新たに取得する新しい形式や構造でのデータ収集が必要となり、それは、場合によっては、無理難題になることもあります。

目的地の特定プロセスの完了には、もう 1 つ必要なことがあります。最終的なビジョンのさまざまな要素に優先順位を付けることです。 ロードマップの作成プロセスの初期には、優先事項は一方向に進むだろうと考えたものの、優先事項を実際に記録し始めると、さまざまな方向に進むことがわかるというのは、よくあることです。 興味深いことに、目的地に含めるターゲットについて、全員が同意する頃までには、最優先事項を何にすべきかについての合意が見事なまでに形成されるようになっています。

道順を決める上で次に必要となるのは、出発地点です。選んだ目標に照らして、組織が現在どの地点にいるのかを示すデータを使って、その出発地点を決めます。

シアトルからモントリオールまでの経路を示す地図

現状の人員について考えてみます。 プロジェクト管理における特定の役割について、訓練を受けているか? 設定した目標を達成するのに十分な経験を持つ人材がいるか? ここでは、複数の評価基準を検討する必要があることを忘れないでください。最終的なエンタープライズ プロジェクト マネジメントのプロセスでは、さまざまな人がさまざまな役割を果たすようになるためです。 実際にはスケジュールの作成を担当することがないのに、すべての従業員に対してプロジェクトのスケジュール管理者のトレーニングを行うことは意味がありません。 既定では、管理者、プロジェクト マネージャー、個別のリソース、経営陣の 4 つの役割について考えます。 タイムシートが関係する場合は、スーパーバイザーも 5 番目の役割として考えます。 もちろん、最初の構想のプロセスで定義した目的地によって、役割はかなり異なることがあります。 それによって、スキルのリストアップ プロセスは大きく変わるため、出発地点を考える前に、必ず目的地を定義することから始めるのです。

また、既存のプロセスについても考えてみます。 明示されたまたは文書化されたプロジェクト管理プロセスはあるか? どのように維持管理されているか? その担当者は? プロジェクト管理の部局が既に設立されている場合、管理業務の多くは、その部局で集中的に行われます。 結局のところ、有効な手順やプロセスが既に存在しているのであれば、新しい手順を作成する意味はありません。 EPM の最終目的の内容によっては、現在のプロジェクト管理プロセスの内部と外部の両方に存在する、既存のプロセスのリストアップを行う場合もあります。

たとえば、契約管理を新しい EPM プロセスの重要な要素にすることを決定したが、契約管理は、 組織内のプロジェクト管理プロセスの一部であったことが、これまでに一度もなかったとします。 一方で、若干離れたところから見てみると、組織には文書管理のしっかりした仕組みがあり、たとえば SharePoint 内の文書移動のワークフローが既にあったりすることがあります。 これは、理想的なプロセスであり、採用して、必要に応じて、新しいエンタープライズ プロジェクト マネジメント環境のこのような点が強化されるように調整します。 これには、3 つの面でメリットがあります。 1 つ目は、新しいプロセスを作成するための労力が必要ありません。 2 つ目は、担当者に、所定の方法でプロセスを使用するスキルや習慣が既にあり、それを身につけるためのトレーニングや労力は必要ありません。 3 つ目は、契約書などの文書を管理する既存のプロセスと一致しない別のプロセスを作成するという難しい状況がありません。

最大の課題の 1 つは、コンプライアンスということになります。 システムを構築するということではなく、全員にシステムを利用してもらい、常に使ってもらうようにするということです。 組織に組み込まれている既存の習慣、方法、手順を採用することが多くなればなるほど、コンプライアンスはより簡単なものになります。

最後に、テクノロジ プラットフォームのリストアップが必要です。 Microsoft EPM ソリューションは、テクノロジのプラットフォームをベースに構築されているので、一部のテクノロジは、既に配置されている可能性がありますが、同時に、設計中のソリューションを機能させるためには、一部のプラットフォームのアップグレードが必要になる可能性もあります。 SharePoint と SQL Server は、Microsoft Office Project Server の展開に必要な要素であることは明らかですが、ブラウザーの互換性 (全員が最新バージョンの Internet Explorer を使っているか?)、セキュリティの状態 (システムは外部に向いているか?)、どのバージョンの SQL Server が展開されているか (OLAP Services または SQL Server Reporting Services が既に使用されているか?) などについても、確認が必要になる場合があります。 また、接続や連携が必要になる他のシステムについても、検討が必要になることがあります。 実稼働時には、それらのシステムにどのような手段でアクセスするか?

計画しているシステムのサイズについても、システムの開始時に必要な構造となっているように、ハードウェア、ネットワーク、その他のインフラストラクチャ要素の検討が必要になる場合もあります。

他のエンタープライズ システムと同様、更新プログラムや拡張機能を実稼働のシステムではなく、ラボで時間をかけて作成できるように、実稼働とステージング領域の両方を計画する場合があります。 また、パイロット フェーズや概念実証フェーズの計画も必要になることがあります。これらのフェーズについては、次のコラムで詳しく説明します。

“経路の再計算”

車載の G.P.S. 装置によって、角を曲がりそこなったことが検出されると、女性の声で「経路を再計算しています」というメッセージが流れます。 少しすると、地図上の線が変わり、新しい道順が示されます。 EPM 展開の場合でも、工事中で通行止めになっているときは、回り道や別の場所を曲がるための準備をしておく必要があります。 もしかすると、高速道路の出口を通過してしまったかもしれません。 どのように計画をし直したらいいでしょうか? コースからはずれた場合に、問うべきことは 2 つあります。1 つ目は、「続けて同じ場所に向かうか?」という質問で、 2 つ目は、「ここから、その場所まで、どうやって行くか?」です。 このテーマに関する、プロジェクト管理についてのお気に入りの引用句は、かのナポレオンが言った「作戦の有効性は、敵と接触するまでしか続かない」です。

シアトルからレドモンドまでの経路を示すマップ

EPM 展開では、これと同じ原則をどのように適用するか? まず、コースからはずれていないかどうかを確認するための、測定基準が必要です。 チーム メンバーの 1 人が、明日、急に歯医者に行くことになり、4 時間ほど不在になるような場合、時間に相違が生じたことで、下流にあるすべての作業を変更し、明日の正午からプロジェクトの終了時までの、全員のスケジュールを組み直してから、新しく割り当てたスケジュールについて、全員にメールで知らせる必要があるでしょうか?

もちろんありません。

多くの人が関係する 6 か月にわたるプロジェクトにおいて、1 人の担当者の作業時間に、4 時間の相違が生じても、 行程の変更を正当化するための割り込みには値しません。 どのような種類のエンタープライズ プロジェクトを始める場合にも、必要なことは、許容できる進捗状況のしきい値を設定することです。 航空宇宙防衛の世界では、最近、しきい値を表す、仕掛け線を意味する「トリップワイヤー」という新しい用語を使い始めました。 経路の再計算が必要であることを示してくれる基準を確立することができますが、 それには、検討すべき、いくつかの一般的な評価基準や測定基準があります。 まず、終了時の予想コストが、最初の予算より X パーセント以上多くなるような場合は、プロジェクト計画の見直しが必要になるでしょう。 コストを算定する場合の単位としては、作業時間と費用のうち、 効果的な方を使います。 予想した完了日が、最初に計画した完了日より X 日以上長くなるような場合は、プロジェクト計画の見直しがおそらく必要になるでしょう。

また、重要なマイルストーンの日を逃してから、一定の日数以上を経過すれば、トリップワイヤーであると決定する場合もあるでしょうし、トリップワイヤーとして認識される場合のリスクを特定するでしょう。または、エグゼクティブ スポンサーなど、プロジェクト チームの重要なメンバーの変更をトリップワイヤーであると判断することも考えられます。 基準を正確に決めるより、ある程度の基準を設定する方が、より重要です。 また、基準に照らし合わせた評価は、プロジェクトの期間全体を通して必要になるので、50 または 100 とおりの評価基準を選ぶと、結果的に、プロジェクト自体の作業を行う時間より、評価にかかる時間の方が多くなってしまうことがあるので、注意が必要です。

コースからはずれたと判断した場合、正しい方向に戻す最適な方法は、プロジェクト計画の見直しを行うことです。 見直し作業には、最初の段階で目的地の設定に関わった経営上層部と、初期のデータ収集に尽力したプロジェクト管理チームの、双方のグループが関与することをお勧めします。 プロジェクト計画の見直し作業では、プロジェクトがコースから外れたことや、特定のトリップワイヤーに抵触したことの責任の所在をめぐって膠着する恐れがあります。 そのようなことに労力を費やすことは、きわめて非生産的です。 そこで、次のような質問に重点を置くことをお勧めします。

  1. 何が起こったのか?

  2. 最終的には、どこに行き着いたか? 現在の出発地点はどこか?

  3. 最初の目的地に向けて、引き続き取り組んでいるか、またはプロセスを見直すか、構想のプロセスをやり直すための説得力のある理由があるか?

  4. 中間のマイルストーンやフェーズの再設定が必要か?

  5. プロジェクト チームの何かを変更する必要があるか?

  6. トリップワイヤーの評価基準を再設定する必要があるか?

生産的でないと思われる質問には、次のようなものがあります。

  • だれの落ち度で、今の状態になったのか? だれの責任か? だれが責任を負うのか?

  • 正しい方向に “戻る”、前の計画に戻るにはどうすればいいか?

プロジェクト計画を見直す最も一般的な理由は、組織の優先事項がシフトするということです。 たとえば、フェーズ 3 で設計することになっていた項目が、フェーズ 2 で必要になることがあります。 このようなシフトは、通常、組織内で正常な活性化が現れた兆候であり、EPM システムの展開の意義について、人々が真剣に考え始めた結果、生じたものです。

悪天候

長距離ドライブに出発する前は、旅行中に荒れ模様の天気の影響を受けないように、おそらく、Weather Channel (または weather.msn.com) で天気予報をチェックするでしょう。 人生にはリスクがつきものです。 リスクがなければ、プロジェクト マネージャーの存在は、必要なくなります。 最も明白なリスクに備えて計画を立てることは、複雑なプロセスではありません。 まず、構想プロセスの最初に開始して、設計中の目的地の要素をそれぞれ確認しながら、目的地への到達にとっての障害について、思い付くことをグループにたずねます。 場合によっては、リスクが重大になることがあります。 組織が特定の結果を望むことは、めずらしいことではありません。結果を出すために必要な生のデータを、今まで一度も収集したことがなく、 そのようなデータを収集することに、かなり抵抗があったことが単に判明することも、決してめずらしいことではありません。

モントリオールの天気予報を表示する MSN ページ

一例として、ある組織では、リソース キャパシティ プランニングを必要としていましたが、 それには、すべてのプロジェクトの担当者について、すべてのリソースの可用性を徹底的に計算し、担当者に該当する可能性のあるすべてのワークロードを、徹底的に計算することが必要でした。 その両方の計算が可能であるかどうかを聞いたところ、もちろん可能ではあるが、可能なのは、組織の 5 分の 2 だけであるという回答でした。 ところが、データの入手が不可能な残りの 5 分の 3 は、代表者が構想を立案する会議にも出席していなかったことがわかりました。そこで、「当ててみましょうか。 リソース キャパシティ プランニングの問題があるのは、この 3 つの部門ではないですか」と言いました。それは当然のことで、プロジェクトの別のフェーズにそれらの部門のリーダーたちが参加していることを確認し、きわめて高いリスクを特定する必要がありました。

プロジェクト管理担当者および業務担当者と協力して、リストアップのプロセスの作業を進める場合は、特定できるリスクについて、インタビューで担当者にたずねます。

リスクの特定を終えたら、リスクを整理することが重要です。 このような作業を以前に行っていない場合、最も基本的な情報が最も貴重になります。 リスク情報には、次のものを含めます。

  1. リスクの簡単な説明

  2. 影響を受ける可能性のあるプロジェクトのフェーズまたは領域

  3. 基準に達した場合のリスクの重大度

最後に、最も重要なことの 1 つは、リスクの緩和に関する詳細を追加することです。 リスクについて考えることだけでも、大きな緩和の要因になりますが、EPM 展開の初期段階では、プロジェクト中に発生する、特定のリスクに対処する方法をメモに記しておくことが、きわめて重要です。 リスクが発生したときに、感情的な状況で、慌てて決断を下すのは、よくあることです。 冷静な状態で考えたことをメモに残しておくと、役に立つことがあります。

自分たちで作った車を運転する

大きな利益をもたらすロードマップを作成するためのヒントは、ロードマップ計画の作成と管理を支援する、Project Server と Microsoft EPM ソリューションを使うことです。 これは、当たり前であると思うかもしれませんが、ここで説明したことを実際に行う組織は非常にまれです。

プロジェクトの成果物一覧を示す SharePoint サイト

ある上級マネージャーに、こう言われたことがあります。彼は、プロジェクトの担当者から、Microsoft EPM ソリューションを使って、Microsoft EPM ソリューションを展開するのはやりすぎだと思わないかと、聞かれたそうです。 「仕事でジェット機を作っていても、通勤にジェット機を飛ばすことはないでしょう」と彼らは言いました。 「冗談でしょう?」と彼は返答しました。 「もし仕事へ行くのにジェット機を飛ばすことができるなら、毎日そうすると思いますよ」

実際のところ、Microsoft EPM ソリューションを EPM 展開チームで使うことは、とてもいい考えです。

Project Server と Microsoft EPM ソリューションのその他の要素をインストールすることは、技術的にさほど難しいことではなく、必要最小限の構成で、小規模な展開チームをユーザーとするシステムを、数日以内に立ち上げることができます。 このような方法は、展開を推進するようになるユーザーにとって、大部分のスタッフのデスクにシステムが届けられる前に、システムの使い方や機能に慣れ親しむのに最適です。

このような展開は、実稼働環境では行うべきではありません。 展開を設定してから、元の目的地のビジョンを実現するために、カスタマイズすることが、ほぼ確実だからです。 また、マルチプロジェクトのスケジューリングやリソース キャパシティ プランニング、ポートフォリオの最適化などを、Project Server の EPM 展開の繰り返しの中で行うことは、まずないでしょうが、大きな利益をもたらすシステムを提供することはできるようになるでしょう。 そこで、次のことをお勧めします。

  1. ローリング ウェーブ スケジュールを公開プロジェクトとして実施する

    ローリング ウェーブ スケジュールは、現在のフェーズを詳細に表し、将来のフェーズを概要として表すのが特徴です。 これにより、チーム メンバーは、今すぐに取り組むべきことがわかるだけでなく、プロジェクト全体を、より大きな枠組みの中で理解することもできます。

  2. ビジョンに関するドキュメントをプロジェクト ワークスペースで管理する

    プロジェクト ワークスペースは、プロジェクトに関連付けられた SharePoint サイトで、既定では懸案事項、リスク、ドキュメントの領域が含まれています。 プロジェクトのドキュメントをすべて、EPM 展開プロジェクトのワークスペースにまとめて、いつでも元のバージョンに戻れるように、SharePoint のバージョン管理を設定してみては、いかがでしょうか?

  3. マイルストーンのサインオフと "ゲート" を、プロジェクト ワークスペースの成果物に入れます。

    これは、シンプルなタスク リストで、Project Server のタスクにリンクできます。 これで、プロジェクトのきわめて高性能なビューができ、“コースからはずれた” ことを判断するための、しきい値の管理に簡単に使用できるツールになります。

  4. 変更管理を懸案事項として、プロジェクト ワークスペースに入れる

    変更管理は、技術プロジェクトにとって、最大の課題の 1 つです。 プロジェクトに対する変更について、新たな提案が生まれた場合は、提案の内容を、管理の可能性がある変更として、懸案事項領域に入れます。 この領域に、いくつかのフィールドを追加することで、優先度の高い項目とその責任者のリストをいつでも作成できます。

  5. プロジェクトのリスクをプロジェクト ワークスペースに入れる

    ドキュメントと懸案事項のほかに、ワークスペースのリスク領域は、リスクや緩和計画を追加するのに最適な場所です。 実際、既定の画面には、すぐに使用できるすべてのフィールドが表示されます。

もう目的地に到着したでしょうか?

「もうすぐです。 まもなく目的地に到着します。」

EPM 展開によって、組織には全員の既定のスケジュールを単純に公開することのできないような、数多くのさまざまな場所が生まれますが、 インターネットで数分でも検索すれば、プロジェクトのさまざまな部分についてたくさんの例を見つけることができます。 これまで説明したロードマップ演習を要約してみると、ひとつのプロジェクトは、次のようないくつかの明白なフェーズからなるということになります。

  1. ロードマップ演習

    1. 構想を描く (目的地を選ぶ)

    2. 既存のプロセスのリストアップ (出発地点を特定する)

    3. 既存の担当者のリストアップ (出発地点を特定する)

    4. テクノロジのリストアップ (出発地点を特定する)

  2. EPM チーム向けに EPM ソリューションを展開する

  3. フェーズ 1

    1. 設計

    2. 構成、カスタマイズ、文書化

    3. パイロット

    4. トレーニング

    5. ロールアウト

    6. フェーズ 1 の見直しとフェーズ 2 の調整 (必要な場合)

  4. フェーズ 2

  5. フェーズ 3

  6. フェーズ 4

  7. プロジェクトの完成

ロードマップ演習を EPM 展開に応用することで、その経験を混沌としたものから管理可能なものへと、すぐに変えることができます。 重要なのは、最初に目的地を選んで、次に出発地点を割り出し、そしてその間の経路を描くということなのです。

では、良い旅を!

著者について

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 サポートの担当者におつなぎいたします。

×