EPM 開発のロードマップ作成における GPS アシスト
この記事は、"From the Trenches" コレクションの一部です。 EPM の実装を計画するときに、Enterprise Project Management の展開を "ロードマップ" にする方法について説明します。 デプロイ パスを計画する際に考慮すべき要素について一意に説明します。
その他の記事については、「 溝から」ホワイト ペーパーを参照してください。
EPM デプロイのロードマップ作成に関する G.P.S. の支援
最後の列では、段階的なアプローチを使用して、Microsoft の Enterprise Project Management (EPM) ソリューションの展開計画を作成する方法について説明しました。 今日は、プロジェクト計画の一環として EPM デプロイ ロードマップの作成に取り組みます。
Microsoft Live Maps にアクセスしたことがある場合、ルート案内には宛先と出発地の 2 つのことが必要です。 この例を EPM 展開に適用する場合は、同様の用語で考える必要があります。
技術、プロセス、人事用語で定義された原点
ビジネス用語で定義され、優先順位付けされた宛先
また、再グループ化、写真の撮影、しばらくの間景色を楽しみ、航海の次の区間のためにあなたの供給を補充することができるいくつかの「ウェイステーション」または中間停留所を定義したいかもしれません。
ロードマップや指示を作成する場合、2 つのスケールを持つことは非常に一般的です。 私たちは、ターンバイターンルートまで、旅行の次の足を細かく保ちます。 ただし、現在の足を旅行全体のコンテキストに保つために、旅行全体のより高いレベルのマップを詳細に保持することもできます。 プロジェクト管理の用語では、この "ローリングウェーブ計画" と呼びます。
"ルート案内"
EPM 展開ロードマップを作成するときは、常に、EPM の取り組みの観点から、会社がどこに向かっているかを示すビジョンまたは意図から始めます。 これにより、Microsoft Live Maps と同様にルート案内を行う必要がある目的地が提供されます。
「何が欲しいですか」と尋ねるだけの場合、答えはほとんど必ず解決策の観点から来ます。 Peopleは、「このようなレポートが必要」または「ポートフォリオ分析が必要です」と言う可能性があります。
ソリューション ビジネスのユーザーにとって、これらの種類の設計ノートにはリスクが伴うことがわかります。 私たちは、自分の問題を解決策として説明するクライアントを聞いているようにコンサルタントをトレーニングします。 「これは問題の解決策です」と言います。"問題ではありません。 問題を定義しましょう。
だから、私たちは「何が欲しいですか?」代わりに、構想中に役立つ可能性のある質問には、次のようなものがあります。
「この EPM 展開の結果、どのビジネス上の決定を行うことができないか、または非常に困難な場合にのみ行うことができるでしょうか。
または
「スループットの向上や、この EPM デプロイによる労力の減少によって、組織のどのような側面がより効率的になると思いますか?
さて、私たちは誰のこれらの質問をする必要がありますか? もちろん、これらの決定を下す人々は、なぜ! あなたが子供でいっぱいのミニバンを持っていて、目的地としてどこに行くべきかを尋ねたことがあるなら、あなたは50の答えを得ることを知っています。
同じトークンによって、組織の意思決定者がこのプロセスの重要な部分であることを確認するか、"ドライバー" が移動する準備ができていない方向を選択するリスクを実行する必要があります。 現時点では、上級管理職を EPM ロードマップ プロセスに取り込むには、追加の利点があります。 EPM デプロイの方向を選択する上で重要な参加者である以外に、プロジェクトの大きさを把握することもできます。 EPM の展開を成功させるために最も一般的で困難な課題の 1 つは、長期的な管理サポートです。 一部の上級幹部は、これが既存のプラクティスと手順をどれだけ変える可能性があるか、また、一時的にさえ破壊的な影響を与える可能性があることを考慮していません。 また、EPM のような文化変革プロジェクトの取り組みに対する評価も得られない場合があります。
上級管理職やプロジェクト管理、おそらくライン担当者との作業では、ビジネス上の意思決定やビジネス効率をプロセスとテクノロジに結び付けます。 この要件を満たすために作成する必要があるプロセスはありますか? 何を達成する必要がありますか? そのビジネス上の決定に対応するために存在するか、作成する必要があるシステム機能はありますか? 何を提供する必要がありますか?
このフェーズでは、基本的なシステム分析が重要です。 私たちは、ビジネス上の意思決定 "出力" から始め、それらの意思決定を行うために必要なデータ要素に戻ります。 場合によっては、基本的なデータが存在せず、ロードマップのその要素が "高リスク" としてフラグ付けされていることがわかります。結局のところ、より良いビジネス プロセスを提供することを考える前に、これらの新しいデータ要素をキャプチャするために、新しい形式または構造でデータを収集することを含める必要があります。これは場合によっては高い順序になる可能性があります。
宛先プロセスを終了する前にもう 1 つのことを行う必要があり、最終的なビジョンのさまざまな要素を優先しています。 ロードマップ作成プロセスの開始時に、優先順位は一方向に進むが、実際に記録する際に、それらが非常に異なる方法で行われると考えるのが非常に一般的です。 興味深いことに、目的地に含まれるターゲットについて全員が合意した時点で、最優先事項が何であるかについて顕著な合意が得られるのです。
次に指示に必要なのは原点であり、組織が選択した目標に関連する場所のインベントリを通じて管理します。
既存の担当者を確認します。 特定のロールに対してプロジェクト管理でトレーニングされていますか? 設定された目標を達成するのに十分な経験を持つ十分な人材はいますか? ここでは、最終的なエンタープライズ プロジェクト管理プロセスで異なるユーザーが異なる役割を果たすので、複数のメジャーを確認する必要があります。 実際にスケジュールを作成する責任を負わない場合は、すべての従業員をプロジェクト スケジューラとしてトレーニングしても意味がありません。 既定では、管理者、プロジェクト マネージャー、個々のリソース、およびエグゼクティブの 4 つのロールが考えられます。 タイムシートが関係している場合は、スーパーバイザーも 5 番目の役割と考えます。 もちろん、元の構想プロセスで定義した宛先によっては、ロールが大きく異なる場合があります。 これにより、スキルインベントリプロセスが大きく変わるので、私たちは常に出発地を考える前に目的地を定義することから始めます。
また、既存のプロセスについても確認します。 プロジェクト管理プロセスが記載されているか文書化されていますか? どのように管理されていますか? 誰が担当していますか? プロジェクト管理オフィスが既に確立されている場合は、この作業の多くがそこに焦点を当てています。 結局のところ、既に有効な既存のプロシージャとプロセスがある場合、新しいプロシージャを作成しても意味がありません。 EPM 環境の最終的な目標に応じて、現在のプロジェクト管理プロセスの内部と外部の両方にある既存のプロセスをインベントリする場合があります。
たとえば、契約管理が新しい EPM 環境の重要な要素になり、この組織のプロジェクト管理プロセスの一部になることは決してないと判断した可能性があります。 しかし、もう少し先を見ると、組織はドキュメントを管理するための強力なコントロールセットを持ち、既存のワークフローが既にドキュメントを移動している(おそらく SharePoint) ことに気が付くかもしれません。 これは、導入するための理想的なプロセスであり、必要に応じて、新しいエンタープライズ プロジェクト管理環境のこの側面を強化するように調整します。 これを行うと、3 つの利点があります。 まず、新しいプロセスを作成する作業を費やす必要はありません。 2 つ目は、この方法でプロセスを使用するスキルと習慣が既に担当者にあることがわかっています。つまり、従業員に従うトレーニングの努力や努力がないことを意味します。 最後に、コントラクトなどのドキュメントを管理するための既存のプロセスと対立する可能性がある別のプロセスを作成しようとする困難な状況はありません。
最大の課題の 1 つはコンプライアンスです。 システムを構築するのではなく、すべてのユーザーがシステムを使用し、一貫して使用できるようにします。 組織に埋め込まれている既存の習慣、プラクティス、手順を採用すればするほど、コンプライアンスが容易になります。
最後に、テクノロジ プラットフォームのインベントリが必要です。 Microsoft EPM Solution はテクノロジのプラットフォーム上に構築されているため、そのテクノロジの一部が既に配置されている可能性がありますが、設計しているソリューションを機能させるには、組織がプラットフォームの一部をアップグレードする必要がある可能性もあります。 SharePoint と SQL Server は、Microsoft Office Project Server を展開する際の明らかな要素ですが、ブラウザーの互換性 (すべてのユーザーが最新バージョンの Internet Explorer を使用しているか)、セキュリティ状態 (システムが外向きになりますか)、展開されているSQL Serverのバージョン (OLAP Services またはSQL Server Reporting Services既に使用されていますか?) また、インターフェイスまたは統合する必要がある他のシステムも検討する必要があります。 運用環境でこれらのシステムにアクセスするにはどうすればよいですか?
計画システムのサイズは、ハードウェア、ネットワーク、およびその他のインフラストラクチャ要素を調べることで、システムが到着したときに必要な構造を確保することが必要になる場合もあります。
他のエンタープライズ システムと同様に、運用環境とステージング領域の両方を計画して、時間の経過と共にライブ システムではなくラボで更新と拡張機能を作成できるようにする必要があります。 また、パイロットまたは概念実証フェーズの計画を立てなければならない場合もあります。次の列で詳しく説明します。
"ルートの再計算"
私の車のG.P.S.ユニットは、私がターンを逃したことを発見したとき、非常に素敵な女性の声は「ルートを再計算する」と言います。 しばらくすると、マップを通る線が変わり、新しいルート案内が表示されます。 EPM 展開では、迂回または修理のためにブロックされているターンの準備が必要です。 おそらく、私たちはその高速道路の出口を逃した。 再計画に対処する方法 コースを離れるときに尋ねる必要があることは 2 つあります。最初に、あなたはまだ同じ場所に行くのですか? 第二に、ここからどうやってそこに着くのですか? このテーマに関する私のお気に入りのプロジェクト管理の引用の一つは、ナポレオン・ボナパルトから来ています。かつては「戦闘計画は敵と接触するまで続く」と言いました。
EPM デプロイでは、この同じ原則をどのように適用しますか? まず第一に、コースに入っていないかどうかを判断するための対策が必要です。 あるチーム メンバーが明日緊急歯科医師の任命を受け、4 時間不在の場合、その不一致がすべてのダウンストリーム タスクを変更し、明日の正午からプロジェクトの終わりまで全員を再スケジュールし、新しい割り当て時間を全員に電子メールで送信する必要がありますか?
もちろん、ありません。
何十人もの人々が関与するプロジェクトの6ヶ月間の1つのリソースに対して4時間の不一致は、私たちのパスを変更することを保証するのに十分ではありません。 あらゆる種類のエンタープライズ プロジェクトを開始する場合に必要なのは、許容される進行状況のしきい値を設定することです。 航空宇宙と防衛の世界では、最近この「Tripwires」の新しい用語が見つけられます。これは非常に説明的です。 ルートを再計算する必要があることを示す条件を確立できます。 いくつかの一般的なメトリックまたはメジャーを考慮する必要があります。 最初に、計画完了コストが元の予算から X% を超える場合は、プロジェクト計画のレビューが構成される可能性があります。 労働時間またはコストの測定を行う場合があります。 どちらかが有効です。 おそらく、予測終了日が当初計画された終了日から X 日を超える場合は、プロジェクト計画のレビューが構成される可能性があります。
また、特定の重要なマイルストーンが一定の日数を超えて見つからないことがトリップワイヤーであると判断したり、トリップワイヤーとして実現される特定のリスクを特定したり、エグゼクティブ スポンサーなどの特定の重要なプロジェクト チーム メンバーの変更がトリップワイヤーであると判断したりする場合もあります。 条件を正確に取得するよりも、条件を設定する方が重要です。 また、プロジェクトの有効期間を通じてこれらの条件を測定する必要があることを覚えておいてください。そのため、50 または 100 の異なるメトリックを選択すると、プロジェクトを実行するよりもプロジェクトの測定に多くの時間を費やすことになる可能性があります。
コースから外れていると判断したら、再び軌道に乗る最善の方法は、プロジェクト計画のレビューを実施することです。 最初に目的地の確立を支援した元の上級管理職グループと、元のインベントリの実行を支援したプロジェクト管理チーム内のグループからの表現を含めることをお勧めします。 プロジェクト計画のレビューは、プロジェクトが不調である理由と、特定のトリップワイヤーがトリガーされた理由に対する責任の割り当てに陥る可能性があります。 このような作業は非常に逆効果になる可能性があります。 次の質問に焦点を当てることをお勧めします。
何が起こったのでしょうか?
私たちはどこで終わったのですか? 現在の原点は何ですか?
私たちはまだ元の目的地にコミットしていますか、それともそのプロセスをレビューしたり、構想プロセスをやり直したりする説得力のある理由がありますか?
中間マイルストーンまたはフェーズをリセットする必要がありますか?
プロジェクト チームを変更する必要がありますか?
いずれかのトリップワイヤ メトリックをリセットする必要がありますか?
生産性が低いことがわかった質問は次のとおりです。
私たちがここにいるのは誰のせいですか? 誰が責任を負いますか? 誰が責任を負うのか?
トラックに "戻る" 方法。古いプランに戻りますか?
プロジェクト計画のレビューの最も一般的な理由は、組織の優先順位が変わるということです。 たとえば、フェーズ 3 に設計された項目はフェーズ 2 で要求されます。 これは通常、組織内の健全な動的な兆候であり、EPM システムの展開の影響について人々が真剣に考え始めた結果です。
悪天候
長いドライブに出発する前に、おそらく天気チャンネル(または weather.msn.com)をチェックして、天候が航海に影響を与えないことを確認してください。 リスクは人生の一部です。 リスクがなければ、プロジェクト マネージャーは必要ありません。 最も明らかなリスクの計画は、複雑なプロセスではありません。 構想プロセスの最初から開始し、設計する宛先の各要素を見て、この目的地に到達するための障壁をグループに尋ねます。 場合によっては、リスクが大きくなります。 組織が特定の結果を望むのは珍しいことではなく、その結果を提供するために必要な生データが収集されていないことと、そのデータの収集に対してかなりの抵抗がある可能性があることがわかります。
ある例では、リソース容量計画を必要とする組織を見つけました。 そのため、すべてのプロジェクト担当者のすべてのリソースの可用性を完全に説明し、それらのスタッフに適用できるすべての可能なワークロードの完全な会計処理が必要でした。 両方とも利用できるかどうかを尋ねると、確実に利用できるが、組織の 5 分の 2 だけであると言われました。 その後、データが利用できなかった組織の 5 分の 3 が、構想会議でも表されていないことを発見したとき、"推測してみましょう。 リソース容量計画で発生している問題は、これらの 3 つの部門にあります。当然、これらの部門のリーダーをプロジェクトの別のフェーズとして登録し、非常に高いリスクを特定する必要がありました。
在庫プロセスでプロジェクト管理とライン担当者と作業を進める際に、面接中に、これらの担当者が特定できる可能性があるリスクについて尋ねます。
リスクが特定されたら、それらを整理することが重要です。 これを行ったことがない場合は、最も基本的な情報が最も重要になります。 次の内容を含めます。
リスクの簡単な説明
影響を与える可能性があるプロジェクトの領域またはフェーズ
基準が実現された場合のリスクの重大度
最後に、最も重要なことの 1 つは、リスク軽減策に関する詳細を追加することです。 リスクを考えるだけでも大きな軽減要因ですが、EPM のデプロイは初期段階ですが、プロジェクト中に特定のリスクに対処する方法に関するメモを入力することは非常に重要です。 リスクが実現された場合、感情的なコンテキストで意思決定が行われるのは一般的です。 クーラーヘッドが優先されている間に考えられていたいくつかのノートを持つことは役に立つかもしれません。
建設中の車を運転しましょう
大きな配当を支払う可能性のあるロードマップの作成に関するヒントを次に示します。Project Server と Microsoft EPM ソリューションを使用して、ロードマップ計画の作成と管理に役立てます。 おそらく明らかなようですが、組織がここで言及することはまれです。
私は、プロジェクト スタッフが Microsoft EPM ソリューションを使用して Microsoft EPM ソリューションをデプロイすることはやり過ぎではないと考えているかどうかを尋ねられたことを、先輩マネージャーに教えてもらったことがありました。 「私たちが生活のためにジェット機を構築した場合、私たちは彼らを働かすために飛ばしません」と、彼らは言いました。 「いじってるの?」と彼は答えた。 「ジェット機を飛ばして働けるなら、毎日やる!
実際、MICROSOFT EPM ソリューションを EPM デプロイ チームに使用することは、優れたアイデアです。
Project Server と Microsoft EPM ソリューションの他の要素をインストールすることは大きな技術的な課題ではなく、構成を最小限に抑えて、数日以内に小規模な展開チームをユーザーとして稼働させることができます。 これは、デプロイチャンピオンになるユーザーが、スタッフの大部分のデスクに到着する前に、システムの使用と利点に慣れるための優れた方法です。
このデプロイを運用環境にすることはできません。 ほぼ確実に、それを構成し、元の宛先のビジョンを満たすようにカスタマイズします。 Project Server の EPM 展開イテレーションでは、マルチプロジェクト スケジューリングやリソース容量計画、ポートフォリオの最適化など、ほぼ確実に作業しませんが、大きな利点を提供できるシステムを提供できます。 次のことをお勧めします。
発行済みプロジェクトとしてローリング ウェーブ スケジュールを実行します。
ローリング ウェーブ スケジュールでは、現在のフェーズが詳しく、将来のフェーズが概要として強調表示されます。 これにより、チーム メンバーは現在作業する必要があることを把握でき、さらに大きなコンテキストでプロジェクトを表示できます。
プロジェクト ワークスペースでビジョン ドキュメントを管理します。
プロジェクト ワークスペースは、プロジェクトに関連付けられた SharePoint サイトであり、既定では、[Issue]、[リスク]、[ドキュメント] の領域が含まれています。 EPM 展開プロジェクトのすべてのプロジェクト ドキュメントをここに配置し、元のバージョンにいつでも戻ることができるように SharePoint のバージョン管理を設定してみませんか?
マイルストーンのサインオフと "ゲート" を Project Workspace 成果物に配置します。
これは、Project Server のタスクにリンクできる単純なタスク リストです。 これは、プロジェクトの非常にハイエンドなビューを提供し、しきい値管理に使用して"コース外"に行くタイミングを決定するための簡単なツールです。
変更管理を問題としてプロジェクト ワークスペースに配置します。
変更管理は、テクノロジ プロジェクトの大きな課題の 1 つです。 プロジェクトの変更に関する新しい提案が発生したら、管理する可能性のある変更として問題領域に移動します。 この領域にいくつかのフィールドを追加することで、優先度の高い項目の一覧を取得し、いつでもその項目を担当するユーザーを取得できます。
プロジェクト のリスクをプロジェクト ワークスペースに配置します。
ドキュメントや問題とは別に、ワークスペースのリスク領域は、リスクと軽減計画を追加するのに理想的な場所です。 実際、既定の画面には、使用できるすべてのフィールドがあります。
目的地に着きましたか?
"ほぼ。 私たちはすぐにそこにいます。
EPM デプロイを使用すると、組織をさまざまな場所に移動できるため、すべてのユーザーの既定のスケジュールを公開する方法はありません。 しかし、数分インターネットを検索すると、プロジェクトのさまざまな部分で可能な多くの例が提供される場合があります。 上記のロードマップの演習を要約すると、いくつかの明白なフェーズを持つプロジェクトになる可能性があります。
ロードマップの演習
構想 (変換先の選択)
既存のプロセスのインベントリ (起点を特定する)
既存の担当者のインベントリ (出発地を特定する)
テクノロジのインベントリ (出発地を特定する)
EPM チーム向けの EPM ソリューションの展開
フェーズ 1
Design
構成、カスタマイズ、ドキュメント
パイロット
トレーニング
ロールアウト
フェーズ 1 を確認し、必要に応じてフェーズ 2 を調整する
フェーズ 2
フェーズ 3
フェーズ 4
プロジェクトのラップアップ
EPM デプロイにロードマップの演習を適用すると、エクスペリエンスがカオスから管理可能にすばやく変わる可能性があります。 先に目的地を選び、次に出発地を見つけ、その間のパスを描画することを忘れないでください。
幸せな旅行!
著者について
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) を参照してください。