プロジェクト管理システムの成熟モデル: ホワイト ペーパー

このホワイト ペーパーは、「最前線の現場から」コレクションの一部です。 組織の成熟に合わせて、プロジェクト管理システムの使用をより効率的にする方法について説明します。 また、会社にとって、新しいプロジェクト管理システムの使用可能なすべての機能を利用したくなる場合でも、特定の機能だけを快適なレベルまで使うことを選ぶ方が効率的な場合についても説明します。 会社が成熟し続けると、使う必要がある機能の使用方法も高度になる可能性があります。

このホワイト ペーパーの Word 版をダウンロードするには、「プロジェクト管理システムの成熟モデル: ホワイト ペーパー」を参照してください。

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

プロジェクト管理システムの成熟モデル

プロジェクト管理成熟 (PMM) モデルは、最近注目されている話題です。 組織の "プロジェクト成熟レベル" の評価を支援することを仕事としているコンサルタントは多数います。ほとんどの場合、プロジェクト成熟レベルは階層表示され、成熟度が高い方が低い方よりも良い階層です。 この概念の支持者は、PMM モデルが組織のプロジェクト管理能力を示していると言います。 組織がより効率的になる方法についてはさまざまなことが話されていますが、プロジェクト管理成熟モデルの階層が上がるだけで必ず効率的になるかどうか、私にはわかりません。 ただ、ある日、このことが話題になりました。 皆さんが PMM モデルの支持者かどうかに関係なく、別の種類の成熟モデルがあります。それは、私がプロジェクト管理システムを使用する複数の組織で見たものです。

プロジェクト管理システムを展開している組織と仕事をする場合、ベンダーが示した新しいシステムのすべての要素を活用したい、と組織が希望することはよくあります。 お客様は、かつて夢見ていたレポート、画面、ワークフロー、機能を営業のデモンストレーションで見て、すべての機能が組織内でスムーズに動作した場合を想像します。 実演されるデモンストレーション データとデモンストレーション構成はできるだけ多くの製品機能を見せるために念入りに作られたものですが、通常、それはお客様にとってわかりづらいものです。 Microsoft Project と Project Server の場合、単一の製品をはるかに超えて、テクノロジのスタック全体を含む可能性があります。

Windows SharePoint Services または Microsoft Office SharePoint Server フォームから始まる画面がクライアントに表示されます。 次に Active Directory または SQL Server レポート サービスを使う機能が表示されます。 このとき、BizTalk Server または Windows Workflow Foundation のワークフローが表示され、PerformancePoint 由来のワークフローが表示される可能性があります。 データのフローはストーリーボードや使用事例シナリオに従って進むこともありますが、メリットの可能性は理解しやすくても、基礎となるテクノロジは理解しづらくなります。

実際、お客様が関心を持つ機能を提供する段階になると、一度にすべてを開発したいというお客様の希望を、現実性チェックを行って和らげる必要があります。 お客様が業務にどの程度必要な機能かを判断して初めて、私たちは、その機能の構成や、すぐに提供できるか、構成が必要か、カスタマイズ作業が必要かを検討できます。 時間と資金の両面で展開の予算を用意するだけでなく、想定したすべての状況の機能を展開すると主張し、ソリューションの設計、トレーニング、学習、開発を熱心に行う準備があるお客様も一部にはいますが、このような組織は例外です。

多くのお客様は、 新しいプロジェクト管理システムの側面を快適なレベルまで展開することを選びます。 システムと基礎となるビジネス プロセスの両方について組織の知識が増えると、システムに対する要求が増え、組織の発展につれて "成熟度" が高くなります。 これは自然な成り行きです。

自動化できるプロジェクト管理プロセスについて組織の理解が進化すると、その自動化に対する要求も進化します。 この自然な進行は、プロジェクト管理や機能の成熟モデルと同様です。 組織が最も可能性の高いこれらの経路に沿って進化することがわかると、組織を効率的にするために注力すべき点を知る上でとても効果があります。 私たちは、組織のプロジェクト システムの成熟を前提として、導入の可能性と投資に対する収益の見込みがあるとわかっているプロジェクト システム領域を重視する傾向があります。 当然ながら、同じ組織は 2 つと存在しないので、この知識を絶対的なものと考えることはお勧めしません。 単に、私たちが多くの会社から得られた豊富な経験に基づく、最も可能性が高い行程であるというだけです。

私たちの経験では、プロジェクト管理システムの使用による自然な進化は 5 つの基本領域で起こりますが、主にテクノロジのおかげで、近年その順序は変化しています。 まずは 5 つの基本領域について説明します。また、この記事の後半では、過去数年で見られたいくつかの新しい変化についても説明します。

プロジェクト管理システムの主要な 5 つの分野

1 – 計画   。 ほとんどの場合、計画が第 1 の波です。 この波を越えられない組織もあります。 基本的なスケジュールを作成し、しっかりしたガント チャートを作り、プロジェクト チームのオフィスの壁に掛けます。 そして、プロジェクト開始前のスケジュールのすばらしい状態を思い出しながら、ときどき懐かしくそのスケジュール表を見るのです。

棒グラフを作るためだけに高価なプロジェクト管理ソフトウェアを使用しているユーザーに対して私はやや冷たいかもしれませんが、グラフを作る価値は確かにあります。 整理されたスケジュールを作成すると、プロジェクト参加者は作業の連携方法について検討するので、何もしない場合やスプレッドシート リストを作成するだけよりもはるかに効率的になります。

2 – 追跡   。 通常、私たちの経験では、次の段階は追跡です。 プロジェクト管理システムの使用が少し "成熟" した組織は、計画するだけでなく、スケジュールを追跡し、最新の進行状況に合わせて定期的に更新し、さらには計画の進展に合わせて予測されるスケジュールを考えます。 多くの組織にとって、ここで止めることが効率的です。 プロジェクト管理システムで計画を作成し、定期的に計画を更新して計画を実行に移し、さらには有益なレポートを経営陣に提出します。

3 – リソース管理   。 いったん計画と追跡を処理してしまえば、組織はリソース管理の問題と、プロジェクト管理システムを使用してそれを解決する方法に着目する傾向があります。 前述のように、リソースには多くの側面がありますが、最も基本的なレベルでは、リソースの割り当て (作業をリソースに割り当てること) が大きな 1 歩であり、何らかのリソースの分析が続きます。

4 – コスト管理   。 コスト管理は、4 つ目の一般的な領域であり、多くの組織はこの領域にたどり着きません。 基本的なレベルでは、コスト管理の出発点として、プロジェクトのフェーズ別か、できればタスク別に分類したコスト見積を作成することをお勧めします。 時間別または金額別で実際のコストを追跡することは、次のレベルです。

5 – 高度   。 これまでの他のカテゴリには含まれない幅広いトピックの "高度" な主題については、5 つ目の領域として 説明します。 この領域はそれほど重要ではありませんが、組織の進化が第 5 の波に達すると、進化は多岐にわたる可能性があります。 そのため、リスク分析、ドキュメント管理、自動ワークフローをここで扱います。 また、これまでに説明した他の 4 つの各領域にも高度な領域があります。

これまでに説明した各要素はさらに拡張することができます。これは、多くの場合、組織のプロジェクト成熟度とプロジェクト管理環境の自動化される側面の理解の向上に沿っています。

計画については、プロジェクト間のリンクで複数プロジェクトが統合されたスケジュールや、サブプロジェクトがあるプログラム管理に進展する可能性があります。

追跡については、組織は、残りの期間に対するシンプルな進行率から発展します。通常、これは最も低品質なデータ追跡です。 追跡は、個人別に、元の計画に対して働いた正確な値を示すタイムシートにまで拡張される場合もあります。

リソース領域では、タスクをリソースに割り当てるだけの状況から、タイムシートを使って日常的にリソースの進行状況を追跡するようになり、さらには EPM の最も求められる側面であるリソース容量計画に移行します。 この段階で、リソースとスケジュールの情報を 1 つの高度なアルゴリズムに結合するクリティカル チェーンが適している組織もあります。

コストについては、通常、基本的な予算作成から始まり、時系列での実際のコスト追跡に進み、予算と実額との差異を計算し、そこから出来高の計算に進みます。この方法は防衛分野や航空宇宙分野の場合と同様です。

さらに高度領域にも高度なトピックがあります。 その中でも最も人気があるのが、モンテカルロ リスク分析と統合プロジェクト管理手法 (特に IT 分野) です。

プロジェクト管理システムの基本的な領域と高度な領域

ほとんどの組織は、前述の高度領域のいずれかに移行するために、上記の図の左側にある 5 つの基本要素すべてを使って進歩します。 特定のプロジェクト管理の課題が、ある要素を他の要素よりも重視することだと判明する組織もあります。 自分自身よりも成熟しようとすることは非常に困難で、ほとんど成功することはありません。

たとえば、リソース容量計画を作ろうとしている組織で、あなたが組織のスキルと経験を確認すると、リソース容量計画システムの構成単位が不足していることがわかることはよくあります。 プロジェクト管理システム成熟モデルのどの段階にいるかを把握する理由の例として、私がよく容量計画を使うのは、それが重要だからです。 経験上、容量計画は EPM システムで最も求められるメリットの 1 つではありますが、そのメリットを実現できるのはほぼ最後になります。 その理由は、リソース容量計画の前に、取り組む必要がある他の要素が数多くあるためです。 予測されたリソース要件と可用性を達成するために、まず次の情報が必要です。

  • 確実性が高いプロジェクト計画

  • 正確な進行状況と共に追跡されたプロジェクト

  • リソースに割り当てられるすべてのタスク

  • 詳細で正確なリソースの可用性

  • 数量化および追跡するすべてのプロジェクト以外の作業

  • 完了した作業、予測される作業、リソースの変化に関するプロジェクト マネージャーと部門マネージャーによる詳細なコンプライアンス情報

うんざりされたでしょうか。 リストの項目数は少なくありません。多くの場合、このような環境に準拠することが必要な企業文化には、大規模な変更管理が必要です。 そこで、私たちはプロジェクト管理システム成熟モデルに戻り、達成する必要がある作業について、お客様がロードマップを作成できるようにします。

当然ながら、これはすべてが網羅されたリストではありません。 3 列目や 4 列目を追加するのは簡単ですが、この段階では一般的な進行状況がわかりづらくなるため、追加したことはありません。 各 組織のプロジェクト管理要件で、特定領域で先に進むことへの関心がわかります。

この記事の冒頭で、過去数年で変化したことについて説明することをお約束しました。 前述のモデルは、しばらくの間は有効でしたが、ここ数年に起こった IT 業界の動きによって別の方向に大きく変化しました。変化はすべてコラボレーションに関連するものです。

一時期のプロジェクト管理ソフトウェア業界は、非常にアルゴリズム中心でした。 クリティカル パス スケジュールに基づいてすべてが決まる、と考えられていたのです。 ただ、ここ数年で、いくつかのことが変化しました。 何よりもまず、ユビキタス インターネットや電話テクノロジによって人の可用性が高まり、プロジェクト チームとの会合と通信がさらに簡単になりました。 その結果、プロジェクト管理チームに参加する人員が変わりました。 かつては、組織内部にいるプロジェクト チーム メンバーを検討し、巨大なプロッターを囲むように机が並んだ窓のない小さな部屋で働いていましたが、組織全体からプロジェクト チーム メンバーを検討できるようになりました。

チーム メンバーには、当然ながらその作業に携わる人員が含まれますが、エグゼクティブ スポンサー、部門のリソース マネージャー、ユーザー、マーケティング部門も含めることができます。 プロジェクト チームの範囲が建物の壁を越えるだけでなく、組織の外部にまで広がり、下請け業者、元請け業者、さらには顧客まで含める事例も珍しいことではなくなりました。 下請け業者は、同じタイム ゾーンや同じ国にすら属さない可能性があります。 このようなことから、多様な業界のプロジェクトにおいては、通信が成功の鍵となる要因になっています。

たとえば、研究開発や IT などの業界で一部の組織は、プロジェクト管理システム成熟モデルの進歩の仕方がまったく異なります。

並べ替えられたプロジェクト管理システムの要素

このような組織の第 1 の要素は、通信計画を作成することです。この計画はほとんどの場合、SharePoint Server などのコラボレーション テクノロジに基づいています。 このような組織では、一元化の観点から、コラボレーションと通信を行うプロジェクト管理チームを拡張する方が、一元管理型の計画よりもメリットがあることがわかっています。 あっという間に高まった SharePoint Server の人気は、共同作業を可能にしたいという需要が高まっていたことを示しています。

基本的な通信計画が完了すると、多くの場合、次はドキュメント管理に移行します。プロジェクト スケジュールになる可能性があるドキュメントです。 これは従来のエンタープライズ プロジェクト管理を覆すものですが、一部の組織には魅力的な場合があります。 契約、ドキュメント、メール、ミーティングなどの通信を把握すると、すぐに効率が向上します。 通信を把握していなければ、効率の喪失は重大になる可能性があります。

ドキュメント管理の段階から問題管理と変更管理の段階まではすぐです。IT と研究開発にとっては、プロジェクトに最も損害を与える可能性がある側面を管理することを意味します。

驚かれるかもしれませんが、タイムシートは次の段階です。 実際、タイムシートはもっと早い段階になることもあります。 私たちの組織が TimeControl 製品を使ってタイムシート業務を開始したところ、私たちのようにタイムシートが必要な組織は、タイムシートを利用できるほど計画および追跡プロセスの成熟度が既に高いことがわかりました。 多くの組織が、エンタープライズ タイムシートを展開してから、エンタープライズ プロジェクト管理システムを展開することを望んでいることがわかった私たちの驚きは想像できるでしょうか。 各組織の変更管理の課題に注目すると、その理由が明らかになります。 ほとんどのユーザーは、渋々でありながら迅速にタイムシートを導入します。 1,000 人の組織が一元管理のタイムシート システムを受け入れるには、数週間単位の時間がかかります。 同じ 1,000 ユーザーが一元管理のプロジェクト 管理システムを受け入れるには、数か月から数年単位の時間がかかる可能性があります。 そのため、一元管理の計画が確立していない場合でも、組織は一元管理されたタイムシート データから多大なメリットを得ることができます。

最後に、このような組織は、コア プロジェクト計画の実行に注意を向けます。 これまでプロジェクトのスケジュールを作成してこなかったとは言えませんが、高度な一元管理は行われません。

最初のプロジェクト管理システム成熟モデルと同様に、これらの各要素は高度なトピックも伝えている可能性があります。

多くの場合、通信計画は、インスタント メッセージ、メール統合など、より統合的な通信システムに発展します。

多くの場合、ドキュメント管理は、ワークフロー管理とフォーム統合に発展します。

通常、問題管理は、あらゆる種類のリスト管理と統合変更管理プロセスに発展します。

タイムシートは、タスク タイムシートから、会計、給与、人事とのリンクへ、また最終的には監査可能な追跡データのためにエンタープライズ プロジェクト管理システムに戻るリンクへと発展します。

計画とリソース管理は、従来のプロジェクト管理システム成熟モデルと同様に発展する傾向があります。

プロジェクト管理システムの利用に "正しい" 発展方法はありません。同様に、"間違った" 方法もありません。 これらのコラムでこれまで話してきたように、最も重要なことは、まず組織としてより効率的になるために達成する必要がある事項に注目し、そこから課題の解決策を設計することです。 重要なのは、基本的な要素の構成単位があることを把握してから、高度な要素の構築を始めることです。 プロジェクト管理 101 を完了してから、プロジェクト管理 PhD に移行する必要があるという話はよく聞きます。

プロジェクト管理システムの使用は、考えられる解決策の 1 つの側面でしかありません。プロジェクトの管理をより効率的にするために、"成熟" のレベルとその領域を決めるのはあなた次第です。

著者について

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

×