EPM 展開計画の作成

  • [アーティクル]

この記事は、"From the Trenches" コレクションの一部です。 エンタープライズ プロジェクト管理 (EPM) 展開計画を作成する方法について説明します。 また、EPM 展開計画でのフェーズおよび主要ポイントを確認し、数百の EPM システム ユーザーから成る中規模組織を基準にそれぞれの時間を見積もります。 さらに、各フェーズの推定継続時間に影響する可能性のある要因も確認します。

この記事のWordバージョンをダウンロードするには、「EPM 展開計画の作成」を参照してください。

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

EPM 展開計画の作成

「EPM システムをインストールし、数日後に稼働させることができますか?」は、EPM 展開会社が受け取る最も一般的な要求の 1 つです。 また、organizationのサイズに関係なく、短い答えは残念ながら"いいえ"です。課題はテクノロジではありません。これは、広範囲に及ぶ組織の変化を生み出す可能性のある一連のポリシー、プロセス、手順、プラクティスの質問です。

EPM デプロイ 計画に含める必要がある内容と、独自の展開計画を作成する方法を見てみましょう。 私は主要なポイントを特定し、各フェーズが数百のEPMシステムユーザーとの中規模のorganizationにかかる時間の推定時間を入れました。 毎回の見積もりを短すぎるか長すぎると無視する前に、そのセクションを実行するために特定のorganizationで何をする必要があるかを考えてください。 期間は仕事の見積もりではなく、予定表の見積もりであるため、必要な作業の種類に合わせて特定の種類のユーザーを組み立てるのにかかる時間に注意してください。

1. EPM システム展開チームを確立する

プロジェクト チームが存在しない場合、プロジェクトは遠く離れません。 アイデア フェーズから運用環境にこのプロジェクトを持ち込むには、複数のユーザーを組み立てる必要があります。 概要計画を既に念頭に置いているので、プロジェクトに参加する人について、2、3 年ほど考える必要があります。

この最初のフェーズの主な手順は次のとおりです。

主要な利害関係者を特定する

プロジェクトが開始される前に、多くの場合、重要な利害関係者が 1 人います。 通常、エグゼクティブ レベルの誰かが、この種のシステムを持っていないという痛みを感じています。 それは素晴らしいスタートですが、そのようなプロジェクトを実現するのにほぼ十分ではないでしょう。 システムのビジネス所有者を特定することは、EPM の展開を成功させるために重要であり、ほぼ直ちに実行する必要があります。 ビジネス所有者は、完成したシステムの利点を使用し、それを完了するために必要なものの価値を見る人になります。 また、1 つまたは複数のエグゼクティブ スポンサーが存在する場合もあります。 エグゼクティブスポンサーは、最終的な結果のために何らかの用途を持っている管理レベルのスタッフかもしれませんが、彼らはまた、その完了までプロジェクトに取り組み、EPM環境の最終的な運用にほとんど投資して進む人かもしれません。 あなたはエグゼクティブスポンサーなしで生きることができます。 ビジネス所有者なしでは生活できません。

社内の専門知識リソースを特定する

プロジェクト チームは、ビジネス所有者とエグゼクティブ スポンサーが誰であるかを決定した後、プロジェクトを前進させるために必要な内部の専門知識と利用可能な知識を決定する必要があります。 多くの場合、EPM ソフトウェアの現在のバージョンなど、特定のテクノロジに専門知識が不足していますが、それが必要な唯一の種類の専門知識ではありません。 organizationのプロセス、プラクティス、手順、役割、責任、およびプロセスを推進するためにデータを配置できる場所に関する内部知識が不可欠です。

外部の専門知識を活用する (必要な場合)

プロジェクト チームには、エンタープライズ以外のプロジェクト管理からエンタープライズ プロジェクト管理に移行するための知識またはスキル ギャップがあると判断するのが一般的です。 その場合、ノウハウを持つ人を見つける代わりはありません。 内部リソースが利用できない程度まで、外部から関与する必要があります。 これらの人々は、コンサルティングやアウトソーシング契約の一部として関与したり、開発に役立つ環境で長期的に使用するために雇われたりする可能性があります。 この種の専門知識を内部からトレーニングすることはめったに成功しません。 この分野で見られる最も一般的な課題は、内部リソースに責任が与えられているが、知識がない、または知識が限られているという点です。 「私は一度EPMソフトウェアを使用し、今、私はそれを展開するように求められている」と、私たちはあまりにも頻繁に聞く叫びです。

チームの規模は、プロジェクトが最終的にどのくらいの範囲になるかによって異なります。 プロジェクトの変更のフェーズとして、数か月間プロジェクトを持つ人を他の人に置き換える人を見つけることは珍しくありません。 現時点では、チームの権限と管理のサポートも重要です。

ああ、私はそれを言う必要がありますか? このプロジェクトをプロジェクトとして扱います。 驚くべきことに、EPM デプロイは、他の展開計画 (靴屋の子供たちが裸足で行くことについて) に入れる要素なしでデプロイされるorganizationの中で最も可能性の高いプロジェクトです。 そのため、プロジェクトのスケジュール、予算、チャーター、十分なリソースの割り当てを行います。

これを達成する時間: 4 週間。

2. 事業目的の特定

チームをまとめました。 それを動作させる時間! プロジェクトのスコープを特定し、そのスコープが大きい場合はフェーズに分割し、作業の計画を作成する必要があります。

このフェーズで実行する必要がある内容を次に示します。

エグゼクティブおよび利害関係者のワークショップ

これを回避する方法はありません。 EPM 環境を作成する全体の目的は、管理とエンド ユーザーがビジネス上の意思決定を行えるようにすることです。 そのため、関連する管理担当者は、システムを使用して行われる決定を特定するために、プロセスの開始時に少し時間を費やす必要があります。 私は過去にそのようなワークショップを実施する方法について書きました( 「ソリューションのバイヤーになる:ホワイトペーパー」を参照してください)。しかし、彼らが行われる方法は、彼らが終わったものよりも重要ではありません。

これは、デプロイ チームが管理に注意を払っている間に、他の 2 つの非常に重要なものを取得する機会です。 1 つ目は、プロセスへの管理のコミットメント、取り組み、最終的な利点です。 2 つ目 (さらに重要) は、管理に対する管理上の期待です。 最も一般的な管理上の期待は、これは数日または数週間で達成できることです。 関係する内容の影響を把握すると、管理サポートが蒸発する可能性があります。 時間やリソースが不足している可能性のあるものを開始するよりも、すぐに実行することをお勧めします。

これらのワークショップの結果 (はい、複数かかる場合があります) は、スコープを構成し、最終的にスケジュールを決定するビジネス目標になります。

管理ロールへの影響を特定する

ビジネス目標が経営陣によって合意されたら、管理の役割と責任への影響を特定するセッションが 1 つまたは 2 つ必要です。 一般的な例は、多くの場合、リソース容量計画と共に表示されます。 ハイテク企業では、リソースキャパシティプランニングはほとんどの場合、EPMシステムの管理要求ですが、リソースを割り当て、競合を管理し、異なる部門の人々の仕事に優先順位を付けるために、誰がそのプロセスの権限を取得する必要がありますか? 定義されたプロセスがないため、この時点ではこれらの問題を解決できませんが、エグゼクティブ スイートの誰が影響を受けるかを特定することが重要です。これにより、時間が来たときにプロセスに含めることができます。

ビジネス目標に優先順位を付け、マスター展開計画を作成する

計画がフェーズに分割することはほぼ確実です。 ほぼすべての EPM 展開では、EPM システムが提供する必要がある利点に対する管理の望みは膨大です。 最初に行く目的の優先順位付けは、この時点での成功の重要な要素です。 上位 2 つまたはおそらく 3 つの目標をフェーズに入れ、他のすべてをダウンストリームにプッシュします。 各フェーズは、独自の権利で価値のある、稼働中の運用 EPM 環境を提供する必要があります。

マイルストーンとメトリックを確立する

私たちはプロジェクト マネージャーです。 プロジェクトにいくつかのマイルストーンを取り込み、測定可能なメトリックにコミットしてみましょう。 エンタープライズ システムの展開では、確実に軌道に乗っていることを確認することは、プロセスの重要な部分です。

ここでは、最初のフェーズの詳細を含む全体的なスケジュールを作成するのに十分な情報が必要です。

この作業の時間: 4 週間

フェーズ 1

フェーズごとに、いくつかのタスクを繰り返す必要があります。 手順 3 から 9 は、すべて 1 つのフェーズの一部です。

3. インベントリ プロセス

ツールに近づく前に、このフェーズで最終的に自動化する必要があるプロセスを決定する必要があります。

どのようなプロセスが存在し、採用できますか?

まず、このフェーズで特定されたビジネス目標のorganizationに既に存在するプロセス、プラクティス、手順を見て、新しい EPM 環境内で採用できるプロセスを決定します。 ほとんど、またはまったく作業なしで適応できる既存のプロセスを見つけることには、両面的な利点があります。 まず第一に、それらは既に作成され、ユーザーに認識されています。 第二に、それらを採用すると、それらを作成した人の友人になります。 これで、そのプロセスの主題の専門家として名前を付けることができ、デプロイが容易になります。

設計する必要があるプロセス

必要なすべてのプロセス、プラクティス、手順は見つかりませんが、欠けているものを特定する必要があります。 これは、既に存在するプロセスを見つけるよりも難しい場合があります。 あなたはそこにないものを探していて、それは経験豊富な目を必要とします。

ホワイトボードワークショップを処理する

作業を適応させる必要があるプロセスや、ゼロから作成する必要があるプロセスの場合は、ホワイト ボードが進行中のワークショップ セッションを受ける必要があります。 プロセスとそのすべての影響は、完了したらそれを生きる人々に最もよく行われます。 すべてを文書化します。

影響を受けた管理ロールを解決する

発生する変更に影響を与える可能性のあるエグゼクティブまたはマネージャーを特定した場合を思い出してください。 呼び戻す時間。 ロール、権限、階層、または既存の責任に影響を与える新しく設計されたプロセスの場合は、会議を整理して解決する必要があります。

この最終的な結果は、プロセス ガイドのドラフトです。

プロセス演習を実行する時間: 4 週間。

4. プロセスの採用、適応、設計

設計されたプロセスを確認、適応、受け入れる

すべてのユーザーが、最後の一連のタスクで発生したすべてのプロセス演習に参加しているわけではありません。 そのため、新しいプロセス ガイドの草案を利害関係者、マネージャー、影響を受ける関係者に公開することが不可欠です。 このガイドでは、いくつかのレビューを行い、プロセス内の競合を解決するために追加のワークショップをスケジュールする場合も非常に一般的です。

この出力は、完了して受け入れられたプロセス ドキュメントです。 「受け入れられた」側面は、いくつかのラウンドを要し、完了する前に最高レベルのエグゼクティブ介入を必要とすることさえありますが、受け入れられたプロセスがなければ、自動化するものはありません。 良いニュースは、デプロイ プロセスがここで停止した場合でも、これは既に大きな価値です。 これらのプロセスを内部的に実行する人々は、自分が考えたことのないorganizationに関する事柄を見ることは避けられません。 その結果、ほぼすぐに開始されるため、より効果的になります。

完了したプロセス ガイドを達成するための時間: 8 週間

5. EPM ツールを評価して選択する

ベンダー向けの "問題ステートメント" ドキュメントを準備する

あなたが私がやった他の記事を読んだなら、潜在的なベンダーにあなたのEPMの問題の説明を与え、彼らがそれらを解決する方法をあなたに伝えることを強く信じていることを知っています。 結局のところ、彼らはソリューションビジネスにいると言いますか? 優れたソリューションを設計してください。 これは、必要なすべての機能のスプレッドシートを作成するよりも少し難しくなりますが、重要です。

ベンダーの応答を求める

1 つだけは実行しないでください。 お好みのベンダーが誰であるかは既にわかっているかもしれませんが、それが適切なベンダーだと思っていても、比較するものを得ることができます。 2 つのベンダーが同じ方法で問題を解決しようとしないため、驚いてオープンマインドを保つ準備をしてください。

短いリスト

1 つの製品を見ているが、複数の実装者を見ている場合でも、実際に会いたいユーザーにアクセスしてください。

ベンダーと実装者のプレゼンテーション

ああ、デモの日。 デモンストレーションを見ることから得られる価値はたくさんありますが、そのフラッシュに巻き込まれるのはそれらの一つではありません。 販売デモは、すべてのベンダーによって慎重に調整されます。 ビューやレポート、ダッシュボードに特に興奮している場合は、具体的に「その正確なビューを開発するのにどのくらいの時間がかかるか」と尋ねます。

ツールの選択と取得

さて、大きな購入をする時間。 私は知っている、あなたは、この記事の冒頭に戻って、出発点だと思った。 さて、心配しないでください。 ついにここに来たのです。 EPMシステムの選択を行い、その途中でその注文を取得します!

このフェーズの最終結果は、デスクに座っている光沢のある新しい EPM 製品です。

このフェーズを達成する時間: 8 週間。

6. オートメーションの設計と構成

選択した EPM ツールにプロセス 設計ドキュメントを適用する

これで、ツールが何であるかを把握したので、プロセス ドキュメントから始まり、機能仕様に終わるシステム 設計ドキュメントの作成を開始できます。 特定の設計基準をテストまたは検証できるように、新しい EPM システムの開発インスタンスをインストールすることをお勧めします。 初めて、実際のシステムの構成のシステムエキスパートが船上で必要です。

標準の設計と実装

確立する必要がある多くの標準があります。 これらの標準の一つ一つが、システムアーキテクチャと設計に影響を及ぼします。 たとえば、予定表は見落とされることが多いです。 予定表は 1 つまたは複数ですか? リソースカレンダーはありますか? 誰がそれらを変更する権限を持っていますか? リソースカレンダーの変更のスケジュールと進行状況データへの影響を知っていますか? などなど。。。 以下に、標準が必要な EPM システムの要素をいくつか示します。

  • 予定表

  • 名前付け規則

  • リソース階層

  • プロジェクトとプロジェクト以外の作業のリソース負荷標準

  • レートと原価計算基準

  • 役割と責任

  • 承認構造

  • プロジェクトとタスクの階層

  • WBS およびその他のコーディング構造

  • ドキュメント管理

  • コミュニケーション テンプレート

  • プロジェクト テンプレート

また、フェーズ 1 のビジネス目標から生み出された要素に対して、他の設計と可能なコーディングも必要になります。 考慮する必要がある要素の一部を次に示します。

  • カスタム コーディングを設計して実装する

  • ダッシュボードの設計と実装

  • 外部システムへのリンクを設計および作成する

  • ワークフローの設計と作成

  • レポートの設計と実装

  • EPM ツール トレーニングの設計と作成

  • 影響を受けるすべての関係者とデザインを確認する

結果は、乗車のために取り出される準備ができているEPMツールです。 作業環境に移行するために必要なすべての構成が必要です。

このフェーズに必要な時間は、必要なカスタム作業の量によって大きく異なりますが、最初のフェーズに制限された場合、12 週間と言います。

7. パイロット EPM ツール

システムの準備ができたので、パイロット グループを特定し、それに取り組んでもらう必要があります。

フェーズ 1 データのインストール/構成/移行

新しく構成されたシステムを (開発インスタンスではなく) パイロット インスタンスにインストールする必要があります。今後のフェーズとサポートとトレーニング システムとして引き続き使用します)。 また、開発インスタンスに合わせて構成を更新し、現在のプロジェクトから新しいシステムにパイロット プロジェクトを移行する必要もあります。

トレーニング

トレーニングは、プロジェクトデプロイの貧しいステップチャイルドです。 デプロイ 計画では忘れられることがよくあります。 パイロット担当者がシステムを適切に使用するために必要なトレーニングを受けてください。

アクティブなプロジェクトを実行する

ここで、これらのパイロット プロジェクトは、定義に多くの時間を費やしてきたプロセス、プラクティス、手順、自動化に基づいて管理します。 パイロットは、多くの場合、これらのプロジェクトがどのくらいの期間続くかを中心としたスケジュール自体を持っている必要があります。

学習したレッスンと文書化

パイロット プロジェクトが完了したら、組み立て直して、作成された内容によって設定された課題がどのように解決されたかを確認します。 調整、修正、または基本的な変更がある場合は、今が時間です。

完全なパイロット プロジェクトとレビューの時間: 12 週間。

8. フェーズ 1 を運用環境にロールアウトする

Go-live

時間です。 新しいシステムの使用を適切なユーザーにロールアウトし、適切なデータを移行します。 システムが稼働するにつれて、トレーニング、サポート、フォローアップを忘れないでください。

ロールアウトまでの時間は、ユーザーの総数 (4 週間) に大きく依存します。

9. マスター展開計画の確認と適応

次のフェーズに備えてマスター プランを確認して調整する マスター プランは、おそらく数か月で確認されていません。 それをほこり取り、フェーズ2の当初計画されていたものを見る時間。 次のフェーズを見る目が違うのは避けられない。 結局のところ、彼らは今、最初のフェーズのすべての経験を持っています。

このフェーズを完了する時間: 2 週間。

10. フェーズ 2 - 手順 3 ~ 9 をもう一度実行する

フェーズ 1 のみを完了しました。今後のフェーズを見ると、手順 3 から 9 (手順 5 を除く) をやり直す必要があります。 各フェーズでは、以前よりも効果的なorganizationを残す EPM 運用が動作する必要があります。

最初のフェーズの各ステップの期間をカウントしていますか? それは58週間まで追加されます。 上記で定義した概要手順のスケジュールを次に示します。

58 週間にわたるプロセスを示すガント チャート。

これで、すべてのorganizationが異なります。 プロジェクトの合計期間に影響を与える多くの要因があります。 これらの中で最も重要なのは、既存のエンタープライズ プロジェクト管理プロセスがどの程度成熟しているかです。 次に、organizationのサイズとその複雑さです。 EPM システムを 1 つの建物に配置するorganizationに展開する方が、多数の部門、オフィス、都市、さらには国/地域に広がるorganizationよりも明らかに簡単です。

各デプロイでは、スケジュールは異なって表示され、常に短いとは限りません。 数日から数週間で実行できるスケジュールを作成する必要は事実上常にありますが、展開を成功させるためには、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) を参照してください。