プロジェクト マネジメント システムの成熟度モデル
この記事は、"From the Trenches" コレクションの一部です。 組織が成熟するにつれて、プロジェクト管理システムをより効果的に使用する方法について説明します。 新しいプロジェクト マネジメント システムで利用できるすべての機能を使用するよりも、その特定の側面のみを満足できるレベルまで使用するほうが企業にとってどれほど効果的かを説明します。 企業は、成熟を続けるにつれて、使用する必要がある機能をより巧みに使用できるようになります。
その他の記事については、「 溝から」ホワイト ペーパーを参照してください。
プロジェクト管理システムの成熟度モデル
最近、プロジェクト管理成熟度 (PMM) モデルはかなりホットなトピックです。 組織が「プロジェクトの成熟度」を評価するのに役立つ良い生活を送っているコンサルタントの波があります。これは、ほとんど常に階層的に表示され、より成熟度が低い場合よりも常に優れていると表示されます。 この概念の支持者は、PMM モデルがプロジェクトを管理するためのorganizationの機能を示していると言います。 組織がより効果的になる方法について話し合う必要があり、プロジェクト管理の成熟度モデルを登るだけでは必ずしもそこに到達するとは限りません。 しかし、それは別の日の主題です。 PMM モデルのファンであるかどうかに関係なく、Project Management システムを使用する組織で見た成熟度モデルの別の種類があります。
プロジェクト管理システムを展開している組織と連携する場合、organizationの望みは、ベンダーが示した新しいシステムのすべての要素の利点を享受することです。 クライアントは、これまで夢見たことのないレポートや画面、ワークフロー、機能を見て、販売デモと同じように、その機能がすべてorganizationでスムーズに機能する世界を想像します。 通常、実証されているデモ データとデモ構成が、できるだけ多くの製品を紹介するために慎重に開発されたことは、クライアントには不明です。 Microsoft Project と Project Server の場合、これは単一製品をはるかに超えて、テクノロジのスタック全体を含む可能性があります。
クライアントには、Windows SharePoint Servicesまたは Microsoft Office SharePoint Server フォームから開始する画面が表示されます。 Active Directory またはSQL Server Reporting Servicesに触れる機能が表示されます。 BizTalk Serverまたは Windows Workflow Foundation からのワークフローと、PerformancePoint からのディスプレイが表示される場合があります。 データのフローは、ストーリーボードまたはユース ケース シナリオに従って、潜在的な利点を簡単に理解できますが、基になるテクノロジの理解が難しくなる可能性があります。
クライアントが関心を持っている機能を実際に提供するには、現実のチェックですべてを一度にデプロイしたいという彼らの望みを和らげる必要があります。 クライアントは、そのような機能を構成する前に、ビジネスを行う方法を決定する必要があります。また、そのような機能をすぐに提供できるか、構成を使用するか、カスタマイズ作業を行うかを検討する必要があります。 想定した機能のあらゆる側面を展開し、そのソリューションの設計、トレーニング、学習、開発を行い、それを展開するための資金を時間内と資金の両方で見つける準備ができていると主張しているクライアントもいますが、これらの組織は例外です。
より一般的なのは、クライアントが新しいプロジェクト管理システムの側面を、既に快適なレベルに展開することを選択することです。 organizationは、システムと基になるビジネス プロセスの両方についてより知識が深まるにつれて、システムの要求がますます増え、進行するにつれて"成熟" します。 それは自然な進行です。
自動化できるプロジェクト管理プロセスに対するorganizationの理解が進化するにつれて、その自動化に対する需要も進化します。 この自然な進行は、Project Management または Capability Maturity モデルと同じです。 組織がこれらのパスに沿って進化する可能性が最も高いと知ることで、organizationを効果的にするための取り組みを行う場所を知る上で非常に効果的になりました。 私たちは、導入の可能性が高いとわかっているプロジェクトシステム領域に焦点を当て、プロジェクトシステムのorganizationの成熟度を考えると、投資に対するリターンを与える傾向があります。 もちろん、2 つの組織が同じではないので、この知識をタブレットに挿入することは良い計画ではありません。 これは、多くの企業との経験に基づいて最も可能性の高い進行です。
私たちの経験では、プロジェクト管理システムの使用の自然な進化は、5つの基本的な領域に入っていますが、それらのシーケンシングは近年、技術に大きな部分のおかげでシフトしています。 最初に 5 つの基本的な領域について説明します。この記事の最後に近い過去数年間に見た新しいシフトのいくつかについて説明します。
1 - 計画。 ほとんどの場合、計画は最初の波と見なされます。 一部の組織では、これを超えることはありません。 基本的なスケジュールを作成し、ガント チャートをブロンズし、プロジェクト チームのオフィスの壁に取り付けます。 Peopleは、プロジェクトが開始される直前のスケジュールの細かい状態を思い出すので、時にはノスタルジックにプラークを指します。
私は高価なプロジェクト管理ソフトウェアを使用して棒グラフを作成している人には少し残酷ですが、そうすることで確かに価値があります。 整理されたスケジュールを作成すると、プロジェクトの参加者は作業をまとめる方法について考える傾向があり、何もしないか、スプレッドシートリストを作成するよりもはるかに効果的です。
2 - 追跡。 次のエクスペリエンスでは、通常は追跡が行われます。 プロジェクト管理システムを使用する際にもう少し "成熟した" organizationは、計画を立てるだけでなく、スケジュールを追跡し、定期的に進捗状況を確認し、計画が進むにつれて予測されたスケジュールを楽しみにしています。 多くの組織では、ここで停止することが有効です。 彼らはプロジェクト管理システムで計画を立て、計画を定期的に更新し、管理に役立つレポートを提供することで計画を実行しています。
3 - リソース管理。 計画と追跡が処理されると、組織はリソース管理の問題と、プロジェクト管理システムを使用して解決される可能性がある方法に目を向ける傾向があります。 リソースには、前に説明したように多くの側面がありますが、最も基本的なレベルでは、リソースの割り当て (リソースへの作業の割り当て) が大きなステップであり、その後に何らかの種類のリソース分析が続きます。
4 - コスト管理。 コスト管理は 4 番目の一般的な領域であり、多くの組織がここに来ることはありません。 基本的なレベルでは、コスト見積もりをフェーズ別に分割するか、プロジェクトのタスク別に分割することをお勧めします。 実際のコストを時間単位またはドル単位で追跡することは、次のレベルです。
5 - 詳細設定。 ここでは、これまでに他のカテゴリに入れていない幅広いトピックについて、"高度な" テーマの 5 番目の領域を配置します。 重要ではないというわけではありませんが、organizationの第5の進化の波に到達すると、さまざまな方法で行くことができます。 そこで、リスク分析、ドキュメント管理、自動化されたワークフローをここに配置します。 他の4つの分野のそれぞれに高度な領域もあります。
これまでに説明した各要素は、さらに拡張することができ、多くの場合、organizationのプロジェクトの成熟度と、プロジェクト管理環境の自動化された側面の理解が高まるにつれてです。
計画では、プロジェクト間リンクを含む複数プロジェクト統合スケジュール、またはサブプロジェクトを使用したプログラム管理に進むことができます。
追跡の場合、organizationは通常、追跡データの品質が最も低い単純な進捗から残りの期間に進みます。 また、追跡はタイムシートまで拡張され、元のプランに対して正確に作業時間が得られます。
[リソース] 領域では、タスクをリソースに割り当てるだけで、通常はタイムシートを使用してリソースの進行状況を追跡し、EPM の最も要求された側面であるリソース容量計画に移行することがわかります。 一部の組織では、Critical Chain もここに収まり、リソースとスケジュール情報を 1 つの高度なアルゴリズムにマージします。
コストについては、通常、基本的な予算編成から実際のコストの追跡に時間と時間を加え、予算と実際の差異を取得し、そこから防衛および航空宇宙セクターで行われるように、アーンド バリューの追跡に進みます。
高度な領域でも、高度なトピックがあります。 これらの中で最も人気のあるのは、モンテカルロ リスク分析と統合プロジェクト管理手法 (特に IT 部門) です。
ほとんどの組織は、上の図の左側にある 5 つの基本的な要素すべてを、先ほど説明した順に進み、高度な領域のいずれかに目を向けます。 特定のプロジェクト管理の課題は、他の要素よりも 1 つの要素に焦点を当てることを意味する人もいます。 非常に難しく、めったに成功しないのは、あなたよりも成熟しようとしています。
たとえば、リソース容量計画を望むorganizationは非常に一般的ですが、organizationのスキルと経験を見ると、リソース容量計画システムを作成するための構成要素が不足していることがわかります。 私は多くの場合、プロジェクト管理システムの成熟度モデルのどこにいるかを知ることが非常に重要である理由の例として容量計画を使用します。 私の経験では、これはEPMシステムから最も要求された唯一の利益ですが、それは私が提供できるほぼ最後の利益です。 これは、リソース容量の計画では、他の多くの要素を最初に機能させる必要があるためです。 予測されるリソース要件と可用性を提供するには、まず次のものが必要です。
当てにできるプロジェクト 計画
正確な進行状況で追跡されるプロジェクト
リソースに割り当てられるすべてのタスク
完全で正確なリソースの可用性
定量化および追跡されるすべてのプロジェクト以外の作業
プロジェクト マネージャーと部門マネージャーによる、完了した作業、プロジェクトされた作業、およびリソースの変更に関するコンプライアンスを完了します。
ふう！ それは小さなリストでなく、そのような環境に準拠するために必要な企業文化は、多くの場合、大規模な変更管理を必要とします。 そのため、プロジェクト管理システムの成熟度モデルに戻り、クライアントは達成するために必要なロードマップを作成できます。
これはもちろん網羅的なリストではありません。 3 列目と 4 列目を簡単に作成できますが、この時点から最も一般的な進行はあまり明確ではないため、ここでは行いません。 各organizationのプロジェクト管理要件は、特定の領域での前進への関心を決定します。
私は記事の前半で、ここ数年で変わったことを話し合うことを約束しました。 私が上で説明したモデルはかなり長い間立ち上がりましたが、ここ数年、IT業界の動きは別の方向に大きなシフトを遂げ、コラボレーションと関係があります。
プロジェクト管理ソフトウェア業界では、一度はアルゴリズム中心でした。 すべてがクリティカル パス のスケジュールに由来すると考えました。 しかし、ここ数年で、いくつかのことが変わりました。 まず第一に、ユビキタスなインターネットや電話技術を通じて人々が利用できるようになったため、プロジェクト チームの組み立てやコミュニケーションがさらに容易になりました。 これにより、プロジェクト管理チームの担当者を変更できます。 プロジェクト チームのメンバーをorganizationの深い人と考え、巨大なプロッターを囲むデスクがある小さな窓のない部屋で作業していたら、organization全体のプロジェクト チーム メンバーを思い出します。
もちろん、チーム メンバーには作業を行うユーザーが含まれますが、エグゼクティブ スポンサー、部門リソース マネージャー、ユーザー、マーケティング部門も含まれる場合があります。 今では、プロジェクト チームが建物の壁だけでなく、organization自体の外側に拡張して、下請業者、プライム請負業者、さらにはクライアントを含めるのは珍しいことではありません。 サブ請負業者は、同じタイム ゾーンまたは同じ国/地域に存在しない場合があります。 これらすべてが、さまざまな種類の業界のプロジェクトの重要な成功要因となっています。
そのため、R&D や IT などの業界の一部の組織では、たとえば、プロジェクト管理システムの成熟度モデルをまったく異なる方法で見ています。
これらの組織の最初の要素は、コミュニケーション プランを作成することです。これは、ほとんどの場合、SharePoint Server などのコラボレーション テクノロジに基づいています。 これらの組織は、一元的な観点から、拡張されたプロジェクト管理チームが共同作業やコミュニケーションを行い、一元化された計画よりも多くのメリットを得ることができることがわかります。 SharePoint Server の人気の流星の上昇は、人々が共同作業を行うのにどれだけの願望があるかの証です。
その後、基本的なコミュニケーション 計画からの進行は、多くの場合、ドキュメント管理に行きます。そのうちの 1 つのドキュメントは、プロジェクト スケジュールである可能性があります。 これは、従来のエンタープライズ プロジェクト管理の進捗状況を頭の上に向けていますが、一部の組織ではこれがどれほど魅力的であるかを確認できます。 契約、ドキュメント、電子メール、会議、その他のコミュニケーションに関するハンドルを取得すると、効率が非常に迅速に向上します。 通信のハンドルを取得しないでください。効率の低下は深刻な可能性があります。
ドキュメント管理から、問題の管理と変更管理の簡単な手順です。IT と R&D では、プロジェクトの最も損害を与える可能性のある側面の 1 つを管理することを意味します。
驚くべきことに、タイムシートは次に来ます。 実際には、タイムシートがさらに早く来る場合があります。 organizationが TimeControl 製品のタイムシート ビジネスで最初に開始されたとき、私たちのようなタイムシートを必要とする組織は、それを利用できる計画と追跡プロセスで十分に成熟している組織であると確信していました。 多くの組織がエンタープライズ プロジェクト管理システムをデプロイする前にエンタープライズ タイムシートをデプロイしたいと考えているのは驚きだと思います。 それぞれの変更管理の課題を見ると、その理由が明らかになります。 ほとんどのユーザーは、タイムシートを恨むが迅速に採用します。 一元化されたタイムシート システムを受け入れるために 1000 人のorganizationを取得するには、数週間かかります。 同じ 1,000 人のユーザーが一元化されたプロジェクト管理システムを受け入れるには、数か月から数年かかることがあります。 そのため、一元化された計画が確立されていない場合でも、organizationは一元化されたタイムシート データから大きなメリットを得ることができます。
最後に、これらの組織は、コア プロジェクト計画演習に注目します。 これは、これまでプロジェクトのスケジュール設定を行っていないが、高度に一元化されていないというわけではありません。
最初のプロジェクト管理システムの成熟度モデルと同様に、これらの各要素にも高度なトピックを含めることができます。
通信計画は、多くの場合、インスタント メッセージング、電子メール統合など、より統合された通信システムに進みます。
ドキュメント管理は、多くの場合、ワークフロー管理とフォーム統合に進みます。
問題管理は、通常、あらゆる種類のリストと統合された変更管理プロセスの管理に進化します。
タイムシートは、タスク タイムシートから Finance、Payroll、HR へのリンクに進化し、最終的には監査可能な追跡データのためにエンタープライズ プロジェクト管理システムにリンクします。
計画とリソース管理は、従来の Project Management Systems の成熟度モデルと同じように進化する傾向があります。
プロジェクト管理システムの使用を進めるための "正しい" 方法はなく、"間違った" 方法もありません。 前にこれらの列で説明したように、最も重要なのは、organizationとしてより効果的にするために達成する必要があることを最初に見て、そこからその課題へのソリューションを設計することです。 重要なのは、より高度なものを構築する前に、基本的な要素の構成要素があることを知っていることです。 プロジェクト管理の PhD に移行する前に、Project Management 101 が必要であるとよく聞きます。
プロジェクト管理システムの使用は、可能なソリューションの 1 つの側面に過ぎません。プロジェクトの管理をより効果的にするために、"成熟" する必要がある方法と領域を決定するのはユーザーの責任です。
著者について
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) を参照してください。