半減期 (t ½) の克服: 実装後の PPM ソリューションのガバナンス: ホワイト ペーパー

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

このホワイト ペーパーの Word 版をダウンロードするには、「半減期 (t ½) の克服: 実装後の PPM ソリューションのガバナンス: ホワイト ペーパー」を参照してください。

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

半減期 (t ½) の克服: 実装後の PPM ソリューションのガバナンス

概要

放射性物理学では、半減期 (t½) とは、期間の開始時に測定された放射能量の半分になるまでに必要な時間のことです (http://en.wikipedia.org/wiki/Half-life 参照)。

では、その半減期が、最近実装した最新のプロジェクト ポートフォリオ管理 (PPM) ソリューションにどのように適用されるのでしょうか。適用される理由は、正しく実装された PPM ソリューションには期限切れの日がやってくるためです。PPM ソリューションの管理に関するガバナンス プロセスを計画、設計、実行する時間がない場合、ソリューションは、陳腐化したデータ、不適切な設計変更、実際の組織のプロセスと同期されていないプロセスなどでいっぱいになると考えて間違いありません。メンテナンスを受けたことのない自動車のように、ソリューションは、期待されている ROI を生み出さなくなります。ユーザーは活発に活動しなくなり、ソリューションの使用をやめるか、別のソリューションを声高に要求するようになります。

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

内容と理由

governanceという用語は、人によって異なる意味を持つ場合がありますが、根底にある意味としては、ガバナンス計画とは、アプリケーションがすべての領域で健全であるようにしながら、ツールに対する最高の投資収益率を実現するための、自ら課した一連のポリシーと手順です。

これらの制約はなぜ必要なのかと疑問に思うでしょう。住居としての家のメンテナンスに似ています。何かを修理したり家に追加する必要があるたびに、さまざまな施工業者が現れ、以前の施工業者とは違った方法で作業するという状況を想像してみてください。結局、不整合の窓や複数のデザインのドア ノブなどになってしまうことはすぐに確信できます。このため、何かを建築しているときに従うべき規則とガイドライン、メンテナンスする必要のあるコンポーネントの規格などをすべて施工業者が持っていることに意味があるのです。

同様に、ソリューションを運用すると、いろいろな変更、拡張、機能の削除が行われます。これらの変更を「どのように」実行するかに関する標準を設定しないかぎり、将来、まったく混沌としたソリューションになってしまうことは間違いありません。

ガバナンスの領域

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

必要なガバナンスの領域を把握する最も単純な方法は、変更が行われる可能性の高い領域を考慮し、続いてこれらの変更を管理するためのガバナンス計画を設定するというものです。

注:  本質的に「変更」しない項目や、どちらかといえば標準的なメンテナンス (新しいユーザーの追加、タイムシート期間の更新など) についても、一連の標準的な手順を記録することが重要です。

一般に、PPM ソリューションで変更が起きる主要な領域は 4 つあります。

PPM ソリューションの 4 つの主要な変更エリア: 情報、デザイン、インフラストラクチャ、プロセス。

情報ガバナンス

PPM ソリューションが実装されていれば、ソリューションの適切な「マスター」データから開始すると想定することが妥当です。たとえば、エンタープライズ リソース詳細、エンタープライズ カレンダー、関連するカスタム フィールドなどがありますが、基本的に、PPM ソリューションを効果的に使用できるようにするすべての「マスター」データです。ただし、ソリューションを使用し続けていると、人々が部門を変える、ある人が組織を離れる、新しい祝日に合わせてカレンダーを更新する必要がある、タイムシート期間を作成する必要がある、会計期間を変更する必要がある、などさまざまな変更が行われます。このデータの更新が継続されないと、間違いなく、すべてのレポートは不正確になり、セキュリティ設定も不正確になります。

情報ガバナンスは、このデータを更新し、完全な状態を維持して、ソリューションの残りの部分がこの中核データを利用できるようにする役割を担っています。

設計ガバナンス

ガバナンス計画に含める必要のある 2 番目の領域は、PPM 展開の「設計」のメンテナンスです。ソリューションを使用し続けていると、ソリューション設計の変更要求が起こります。これらの要求は、ツールを使用する方法の変更を望んでいるか、新しい機能の利用を望んでいる特定のグループから発せられる可能性があります。古典的な例は、時間レポートを行う方法を切り替える場合です。作業時間の達成率方法で行くことにしていても、新しい部門を追加したときに、他の財務ソリューションとの統合のためにそれを「期間あたりの作業時間」方法に切り替える必要が生じる場合もあります。したがって、問題は、誰がソリューション全体のこの変更の影響を評価するのか、そして変更がどのように展開されるのかということになります。

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

プロセス ガバナンス

時間、プロセス、および設計のほとんどが同一の歩調を取るので、ガバナンスのこの領域を設計ガバナンスの一部と考えることは簡単です。ただし、全体論的に言うと、この領域は単なる設計以上の範囲に及んでいます。この領域は、その効果性を推進する PPM ソリューションの内部および外部のプロセスのガバナンスに対処します。

たとえば、PMO が毎週水曜日の午前に上級管理者にレポートを提出することになっているシナリオを考えてみます。毎週金曜日の特定の時間までに、タイムシートが提出され、プロジェクト マネージャー全員が、月曜日の午前のレポート作成の行われる前にプロジェクト計画を更新および発行していることを確認するプロセスを設定しているとします。次に、上級管理者がレポートを毎週水曜日の午前ではなく月曜日の午前に送信するように依頼してきたとしましょう。これは、PPM ソリューション自体の設計の変更を誘引するのではなく、PPM ソリューションの使用法に関するプロセスでの変更を誘引します。

このような変更は、プロセス ガバナンスの一部として定義した標準的なルール セットで制御する必要があります。

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

これは、簡単にサイロ化できるように思える領域の別の 1 つですが、上記の 3 つの領域に重複することもあります。簡単に言えば、PPM ソリューションをサポートするインフラストラクチャはインストールで保持される必要があります。この種のガバナンス モデルに分類されるべき主要な項目のいくつかの例は、次のとおりです。

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

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

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

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

インフラストラクチャの数式の片側では、何かをインストールするかどうかの決定は純粋にメリットに基づきます (たとえば、現在の運用ソリューションに悪影響を及ぼすかどうか)。数式のもう片側では、インストールによって生じた「プロセス」または「設計」の変更を調べます。場合によっては、インフラストラクチャの変更によって他の領域にも変更が生じます。前述のように、これらの領域のいずれかに属するものとして各変更を分類しようとしていますが、4 つの領域すべてに完全に重複する変更もあり得ます。

主要な質問

ガバナンスのどの領域を設定しようとしているかにかかわらず、ガバナンス計画の中核を形成する、回答する必要のある 3 つの主要な質問があります。

  • PPM チームはどのようにして変更を行う必要があることがわかったのでしょうか (たとえば、変更の動機付けは何でしょう)。変更は本質的に「誘引」されないこともありますが、PPM 実装の定期的なケアおよび供給の一部です (たとえば、プロジェクト センターの新しいビューの追加)。

  • ビジネス上の投資収益率 (ROI) の観点だけでなく、ガバナンスの観点から見て、変更を誰が承認しますか。

  • 誰が実際に変更を行いますか。変更の多くでは、複数のチームが関わります。組織の中には、ビジネス ニーズに基づいて、一部の変更機能をエンド ユーザーのサブセットに移す場合があります。このような種類のシナリオでは、誰が実際に変更を行うかを定義することがさらに重要になります。

ガバナンス チーム

すべてのガバナンス方針の主要コンポーネントは、実際にガバナンス計画を担当するチームです。このガバナンス チームをどのようになるかについてより詳しく調べる方法は複数ありますが、どの流派にも同意されている 1 つの推奨事項は、シンプルにしておくということです。

チーム構造を設定する 1 つの方法は次のとおりです。

ガバナンス領域の所有者    この記事ですでに述べたガバナンス領域それぞれの所有者です。一般に、ガバナンス所有者の指定された領域に影響する変更要求は、各所有者の責任になります。新しい機能に対して、評価し、推奨事項を提供し、ガバナンスを設定するなどの役割があります。

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

先に述べたように、実装の規模と他のアプリケーションについて組織内に存在する現在のプロセスに応じて、これらの役割の定義と構造は小さくも大きくもなります。重要な点は、少なくとも最低の構造を用意しておくことです。

他の主要コンポーネント

ガバナンス方針を成功に導くための他の主要コンポーネントには、次のものがあります (ただしこれだけではありません)。

  • 作業依頼ソリューション。ユーザーは、このソリューションを使用して変更や機能を要求できます。SharePoint リストのように単純なものでも、社内の作業依頼ソリューションで現在使用されているものでも構いません。

  • 変更を処理するプロセス。IT、ガバナンス、CGC、他の関与するビジネス機能によるレビューが含まれます。

  • 実際に変更を実装するプロセス。開発からテスト、そして運用ソリューションの変更を実装する単純な経過の場合も、組織の標準に従った本格的なリリース管理の場合もあります。

プロセス

これまで説明してきたすべてのコンポーネントを、ガバナンス方針を構築する一部として捉え、それを中心にプロセスを構築しましょう。どのようなものになるかを次に示します (組織の要件に応じて異なる場合があります)。

ユーザーが要求を提出した場合に、その要求がガバナンス委員会でレビューおよび承認されるルートを示すガバナンス戦略図

結論

PPM ソリューションに起こる可能性のあるすべて変更を予測し、計画することは困難ですが、柔軟でどのシナリオにも拡張できる戦略を用意しておくことが重要です。

最後に、ガバナンス方針の構築に向けた次の基本的な常識的アプローチを考慮してください。

  • ガバナンス計画は、多くのあいまいな用語と、日常生活で誰も使用できない言語を含んだ学術書である必要はありません。主要な質問 (「主要な質問」を参照) に対して簡単に回答できる、Excel シートのような単純なものにすることができます。

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

  • ガバナンス計画は簡単に実装できる必要があり、組織の既存のプロセスに適切に統合できる必要があります。わざわざ一からやり直す必要はありません。

  • 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 氏はレギュラー ブロガー (http://www.prasannaadavi.com) であり、主に Microsoft Project と Project Server ソリューションに焦点を当てながら隔週のポッドキャスト (http://www.msprojectpodcast.com) も運営しています。Prasanna 氏は EPMA 社 (http://www.epmainc.com) の上級コンサルタントです。

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

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

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

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

×