半減期 (t 1/2) に打ち勝つ: PPM ソリューションの実装後の管理

  • [アーティクル]

この記事は、"From the Trenches" コレクションの一部です。 プロジェクト ポートフォリオ管理 (PPM) ソリューションのガバナンス モデルを設定するフレームワークを設定する方法について説明します。 また、独自のガバナンス戦略を設定するための出発点として使用できるサンプル ガバナンス 計画も含まれています。

この記事のWordバージョンをダウンロードするには、「Beat the Half-life (t 1/2): Governing Your PPM Solution, Post-Implementation: white paper」を参照してください。

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

半減期を上回る (t 1/2): PPM ソリューションの管理、実装後

概要

放射性物理学では、半減期 (t1/2) は、期間の開始時に測定された数量がその値の半分に落ちるのに必要な時間の量です。 (参照: https://en.wikipedia.org/wiki/Half-life)。

では、これは最近実装されたブランドの新しいプロジェクト ポートフォリオ管理 (PPM) ソリューションにどのように適用されますか? 適用される理由は、正常に実装された PPM ソリューションに有効期限が付属しているためです。 PPM ソリューションの管理に関するガバナンス プロセスの計画、設計、実行に時間を要しない場合は、ソリューションに古いデータ、不適切な設計変更、実際の組織プロセスと同期していないプロセスが格納され、一覧が表示されることを安心できます。 メンテナンスを受け取らない車と同様に、ソリューションは期待される ROI の生成を停止します。 ユーザーは受動的になり、ソリューションの使用を停止するか、別のソリューションを熱心に提案します。

このホワイト ペーパーの目的は、PPM ソリューションのガバナンス モデルを設定するフレームワークについて説明することです。 独自のガバナンス戦略を設定するための出発点として使用できるサンプル ガバナンス 計画も提供されています。

The What and the Why

ガバナンスという言葉は、さまざまな人々に異なる意味を持つ可能性があります。基本的には、ガバナンス計画は、アプリケーションがすべての分野で正常であることを確認し、ツールに対して行われた投資に最適な価値のリターンを生み出すために、一連の自己強制ポリシーと手順です。

これらの制限が必要なのはなぜですか? それはあなたが住んでいる家のメンテナンスに似ている。 たとえば、家に何かを固定または追加する必要があるたびに、別の請負業者が現れ、前の請負業者とは異なる方法で作業を行うとします。 かなりすぐにあなたは窓の不一致、マルチデザインのドアノブなどと終わることを確認することができます。 そのため、ビルダーは、何かの構築中に従うすべてのコードとガイドライン、保守する必要があるコンポーネントの標準などを用意するのが理にかなっています。

同様に、PPM ソリューションが稼働すると、いくつかの変更、機能強化、機能の削除が行われます。 これらの変更の実行方法に関する標準を設定しない限り、完全に混乱しているソリューションを安心できます。

ガバナンスの領域

PPM ソリューションのガバナンス 計画の設定を検討するときは、実際に管理する領域を検討する必要があります。 エンタープライズ ソリューションのガバナンス 計画を確立するための多くの理論とモデルがあり、organizationに合った最適なものを自由に選択できます。 この記事では、ほとんどの PPM 実装に適合するこれらのモデルの 1 つについて説明します。

必要なガバナンス領域を把握する最も簡単な方法は、変更が発生する可能性が高い領域を検討し、それらの変更を管理するためのガバナンス 計画を設定することです。

注:

それ自体が "変更" ではなく、標準的なメンテナンス (例: 新しいユーザーの追加、タイムシート期間の更新など) の場合でも、一連の標準手順を記録することが重要です。

一般に、PPM ソリューションに対して変更が発生する可能性がある重要な領域は 4 つあります。

PPM ソリューションの 4 つの重要な変更領域: 情報、設計、インフラストラクチャ、およびプロセス。

情報ガバナンス

PPM ソリューションが実装されている場合は、ソリューション内の適切な "マスター" データから始めると想定するのが妥当です。 たとえば、エンタープライズ リソースの詳細、エンタープライズ 予定表、関連するユーザー設定フィールドなどが含まれます。基本的には、PPM ソリューションを効果的に使用できるようにするすべての "マスター" データです。 ただし、ソリューションを使用し続けるにつれて、部署を変更したり、organizationを残したり、カレンダーを新しい休日で更新したり、レポート期間を作成する必要がある、会計期間を変更する必要がある、リストが続く場合があります。 明らかに、このデータが更新され続けなければ、すべてのレポートが不正確になり、セキュリティ構成も同様になります。

情報ガバナンスは、このコア データの場合にソリューションの残りの部分を活用できるように、このデータを更新して完了させる責任を負います。

設計ガバナンス

ガバナンス 計画の一部である必要がある 2 番目の領域は、PPM 展開の "設計" のメンテナンスです。 ソリューションを引き続き使用すると、ソリューションの設計を調整する要求が発生します。 これらは、ツールの使用方法を変更したい、または新機能を利用したい特定のグループから発生する可能性があります。 従来の例では、時間レポートの実行方法を切り替える方法があります。 %Work Complete メソッドを使用することを選択した場合と、新しい部署が追加された場合は、他の財務ソリューションとの統合のために、"期間あたりの作業時間" メソッドに切り替える必要がある場合があります。 そのため、問題は、ソリューション全体でこの変更の影響を評価するユーザーと、変更がどのようにロールアウトされるかです。

設計ガバナンスは、PPM ソリューションの全体的な設計に影響を与える変更を管理するための計画です。

プロセス ガバナンス

ほとんどの場合、プロセスと設計が手をつながっているため、ガバナンスのこの領域を設計ガバナンスの一部と考えるのは簡単です。 しかし、全体的に言えば、この領域は単なるデザイン以上のものをカバーしています。 これは、その有効性を促進する PPM ソリューションの内外のプロセスのガバナンスに対処します。

たとえば、PMO が毎週水曜日の午前に上級管理職にレポートを送信するシナリオを考えます。 タイムシートが毎週金曜日に一定の時間までに送信されるようにプロセスを設定し、レポートが発生する前に、プロジェクト マネージャーが月曜日の午前までにプロジェクト 計画を更新して発行する場合があります。 次に、上級管理職が毎週水曜日の午前ではなく、月曜日の午前にレポートを送信するように求めたとします。 これにより、PPM ソリューション自体の設計の変更ではなく、PPM ソリューションの使用方法に関するプロセスの変更がトリガーされます。

これらの種類の変更は、プロセス ガバナンスの一部として定義された標準の規則セットによって管理される必要があります。

インフラストラクチャ ガバナンス

これはサイロ化が容易と思われるもう 1 つの領域ですが、上記の他の 3 つの領域と重複する可能性があります。 簡単に言えば、PPM ソリューションをサポートするインフラストラクチャは、インストールと共に維持する必要があります。 この種のガバナンス モデルに該当する重要な項目の例を次に示します。

  • サービス パックまたは累積的な更新プログラムのインストール。

  • 新しいアドオンまたはアプリケーションのインストール。

  • パフォーマンスの問題に対処するためのインフラストラクチャのアップグレード (アプリケーション サーバー、Web サーバーの追加など)。

  • 組織の他のアプリケーション (たとえば、すべてのサーバーの仮想化) への変更によるインフラストラクチャの変更。

式の一方で、何かをインストールするかどうかの決定は、純粋に基づくメリットです (たとえば、現在の生産ソリューションに悪影響を与えるかどうかなど)。 インフラストラクチャの方程式のもう 1 つの側面は、インストールによって発生する "プロセス" または "設計" の変更を調べます。 場合によっては、インフラストラクチャの変更は、他の領域の変更の結果である可能性があります。 前述のように、各変更をこれらの領域の 1 つの一部として分類しようとしていますが、一部の変更が 4 つの領域すべてと完全に重複する可能性があります。

主な質問

設定しようとしているガバナンスの領域に関係なく、ガバナンス 計画の中核となる 3 つの重要な質問に答える必要があります。

  • PPM チームは、変更が発生する必要があることをどのように認識していますか (たとえば、これらの変更のトリガーは何ですか? 場合によっては、これらの変更自体は "トリガー" されませんが、PPM 実装の定期的なケアとフィードの一部です (たとえば、プロジェクト センターの新しいビューの追加など)

  • ビジネス収益率 (ROI) の観点だけでなく、ガバナンスの観点からも、これらの変更を承認するユーザーはだれですか?

  • 実際にこれらの変更を行うユーザーはだれですか? これらの変更の多くでは、複数のチームが関与します。 一部の組織では、一部の変更機能は、ビジネス ニーズに基づいてエンド ユーザーのサブセットに転送されます。 このようなシナリオでは、実際にどのような変更を加えるのかを定義することがさらに重要になります。

ガバナンス チーム

ガバナンス戦略の重要な要素は、実際にガバナンス 計画を機能するチームです。 このガバナンス チームの外観に関してスライスしてサイコロを付ける方法はいくつかありますが、すべての考え方の学校が同意する 1 つの推奨事項は、シンプルに保つことです。

チーム構造を設定する 1 つの方法を次に示します。

ガバナンス 領域の所有者 これらは、この記事で前述した各ガバナンス領域の所有者です。 一般に、これらのガバナンス所有者の指定された領域に影響を与える変更要求は、これらの所有者の責任になります。 評価、推奨事項の提供、新機能に関するガバナンスの設定などを行う役割になります。

中央ガバナンス委員会 (CGC) これは、ガバナンス所有者が行った推奨事項を承認または拒否できる意思決定者のチームです。 中央ガバナンス委員会を持つことは、官僚主義を減らすのに役立つだけでなく、すべてのアイデアを共通のプラットフォームに持ち込み、互いに認識して評価するのに役立ちます。

前述のように、実装のサイズと、他のアプリケーションのorganizationに存在する現在のプロセスによっては、これらのロールの定義と構造が小さいか大きくなる可能性があります。 重要な点は、少なくとも最小限の構造を配置することです。

その他の主要コンポーネント

ガバナンス戦略を成功させるためのその他の主要コンポーネントには、次のものが含まれますが、これらに限定されません。

  • ユーザーが変更、機能、機能を要求できるようにする Work Request ソリューション。 これは、SharePoint リストや、現在社内で使用されている作業要求ソリューションと同じくらい簡単です。

  • IT、ガバナンス、CGC、および関連する他のビジネス機能からのレビューを含む、変更を処理するためのプロセス。

  • 実際に変更を実装するためのプロセス。 これは、開発からテスト、運用ソリューションへの変更の単純な進行、またはorganization基準に従った本格的なRelease Managementです。

プロセス

ガバナンス戦略の構築の一環として、上記で説明したすべてのコンポーネントを取り上げたり、そのプロセスを構築してみましょう。 ここでは、どのように表示されるかを示します (組織の要件によって異なる場合があります)。

ユーザーが要求を送信し、ガバナンス委員会を通じてレビューと承認のためにルーティングされる方法を示すガバナンス戦略図。

まとめ

PPM ソリューションに発生する可能性のあるすべての変更を予測して計画することは困難ですが、どのシナリオにも柔軟でスケーラブルな戦略を用意することが重要です。

別れた考えとして、ガバナンス戦略を構築するための次の基本的な常識的アプローチを検討してください。

  • ガバナンス 計画は、多くのあいまいな用語と、日常生活で誰も使用できない言語を持つ tome である必要はありません。 Excel シートと同じくらい簡単で、主要な質問に対する簡単な回答を得ることができます (「キーの質問」で対処)。

  • ガバナンス プランは、構成のドキュメントではないことに注意してください。 これは、構成を保護、維持、変更するための "プラン" です (必要に応じて)。

  • ガバナンス 計画を簡単に実装し、organizationの既存のプロセスに適切に統合する必要があります。 ホイールを再発明する必要はありません。

  • PPM ソリューションのガバナンスは絶えず進化するプロセスであることを理解してください。 分析の麻痺でハングアップしないようにすることが重要です。 小規模から始め、価値を提供し、スケールアップします。

著者について

Prasanna Adavi (PMP、MCTS、MCITP、MCT) は、Microsoft Project、Microsoft Project Server、および Microsoft SharePoint プラットフォームを専門とする上級エンタープライズ プロジェクト管理 (EPM) コンサルタントおよびトレーナーです。 彼のメインの焦点は、組織が投資に対する最良のリターンを達成するのに役立つビジネス ソリューションを構築し、有効にすることです。

また、IT、ERP(SAP)、製造、アプリケーション開発、自動車、クリエイティブサービスなど、幅広い分野や業界でエンドツーエンドの主要プロジェクトに幅広い経験を持っています。 彼は、国/地域全体のさまざまな Project Server、EPM、SharePoint イベントの定期的な発表者であり、SharePoint および EPM コミュニティへの定期的な共同作成者です。

Prasanna は通常のブロガー (https://www.prasannaadavi.com) であり、主に Microsoft Project および Project Server ソリューションに焦点を当てた隔週ポッドキャスト (https://www.msprojectpodcast.com) も実行しています。 Prasanna は、EPMA (https://www.epmainc.com) のシニア コンサルタントです。