マトリックスのバランス維持
この記事は、"From the Trenches" コレクションの一部です。 マトリックス プロジェクト管理環境を使用する組織でエンタープライズ プロジェクト管理 (EPM) を実装するユーザーが直面する課題について説明します。
この記事の Word バージョンをダウンロードするには、「 マトリックスの分散: ホワイト ペーパー」を参照してください。
その他の記事については、「 溝から」ホワイト ペーパーを参照してください。
マトリックスのバランス維持
プロジェクト管理サークルでは、マトリックス管理環境についてよく話す傾向があります。 マトリックス管理は何も新しいことではありません。 事実上すべてのハイテク組織における管理の事実上の標準となっています。
マトリックス管理のアイデアは、70年代初頭の管理思考から生み出されました。 J.R.Galbraithは、1971年に発表された最初の作品の1つで、組織と機能的な責任を組み合わせる方法について話しています。 当時の優勢な管理環境は階層型でした。
組織は、強力な部門リーダーによって支配された部門の巨大なサイロでした。 これは、完了するために複数の部署にまたがる必要がある複数のプロジェクトが存在するまでは最適です。 プロジェクトマネジメント研究所のようなプロジェクトマネージャーや協会は、30年以上にわたって「投影」マトリックスの概念を推進してきました。
投影マトリックスでは、組織の 2 番目の軸を確立し、プロジェクトを管理する組織のその部分に何らかの責任を与えます。 その結果、ディスプレイの一方の側に組織部門が配置され、プロジェクトマネージャーがプロジェクトまたは製品を他方の側に配信します。
Enterprise Project Management について話している間に、このことについて話す理由 このモデルは、ほぼすべての Microsoft EPM ソリューションデプロイの基礎となっているためです。 Project Server のデプロイに取り組んでいる場合は、旅行中に必ずこのモデルに取り組みます。 ここで説明するマトリックス管理モデルには例外がありますが、テクノロジ組織を見るとユニバーサルに近いと言えば十分です。
Microsoft EPM ソリューションの展開に取り組んでいる場合は、次のいずれかの状態の組織を見つけることができます。
マトリックスがありません
組織は完全にサイロベースです。 各部門長は、大きな組織の子会社であるかのように、自分の部署を管理します。 予算は、階層的な方法で部門を通じて上向きにまとめられます (オルガニグラムを考えてみましょう)。 プロジェクトが開始されると、プロジェクトを完了するために他の部門からリソースが必要な場合でも、各部門内で実行されます。 プロジェクトを管理している部署のリソースでプロジェクトを完了できない場合は、部門間の要求として外部リソースがネゴシエートされます。
実際には、そのようなプロジェクトを管理するまで、それほど悪く聞こえません。 ほぼすべてのプロジェクトで部門間リソースが必要な場合、グループ間の優先順位を把握することは不可能です。 1 つの部門長が自分のリソースの優先順位を制御することを放棄するインセンティブはありません。 このような力を放棄することは直感的ではないため、1 つの部門内で完了できないプロジェクトは苦しみます。
また、部署長より1つ上の幹部と話をすると、リソース容量計画を立てることができないという普遍的な嘆きがあります。 これは完全に理にかなっています。 リソースキャパシティプランニングに必要な情報を集約するための部門間構造や、そのような分析に必要な一元的な優先順位付けに各部門の責任者が提出するインセンティブはありません。
このような状況では、1 つのプロジェクト オフィスではなく複数のプロジェクト オフィスが見つかる可能性が高いです。1 つの部門ごとに 1 つのプロジェクト オフィスが互いにほとんど協力しません。
この種のシナリオに Microsoft EPM ソリューションを展開するには、組織を同時に調整する方法について考える必要があります。 多くの場合、このような企業から、不可能を行うように求める電話が寄せられます。 数百人または数千人のユーザーをトレーニングし、Project Server をインストールして数週間で運用します。 期待は、会社が一元化されたエンタープライズ プロジェクト管理システムを購入したため、組織はすぐに一元化されたマトリックス環境として並んで運用されるということです。 それは高価なファンタジーです。 必然的に、組織をどのように変更する必要があるかについて、上級管理職と話をする必要があります。 これは通常、ソフトウェアを購入するだけで、すべてのユーザーが変更されるというコミットメントで十分であることを望んでいた経営陣にとっては素晴らしいニュースではありません。
このようなプロジェクトを開始するには、一元化されたプロジェクト管理オフィスの計画と一元化されたプロジェクト管理手順に取り組みます。 Project Server は、途中から徐々に導入されます。組織全体が最終的に関与するまで、このようなプロジェクトが 12 か月から 24 か月かかるのは珍しいことではありません。 私たちは、PMOを作成するために独自に取り組んでいる間、21/2年の遅れの後にこのようなプロジェクトを再開しました。
バランスの取れたマトリックスがある
これが起こったとき、それは素晴らしいことですが、残念ながら非常に珍しいです。 バランスの取れたマトリックスを維持するには、一定の調整と注意が必要です。 しかし、バランスの取れたマトリックスを見つけると、高度に進化した一連のプロシージャ、定義されたロール、関係者全員がよく理解できるプロセスも見つかる可能性があります。 この種の組織に Microsoft EPM ソリューションを展開することが最適なシナリオです。
マトリックスはありますが、不均衡です
これは私たちが直面する最も一般的なシナリオであり、それは完全に理にかなっています。 マトリックス モデルには固有の競合がいくつか存在するため、多くの場合、マトリックスは弱い PMO を持つ部署に重み付けされるか、弱い部門長を持つ PMO に重み付けされます。 または(これははるかに困難です)、マトリックスは一部の部門に重み付けされていますが、他の部門やプロジェクトマネージャーには重み付けされていませんが、他のプロジェクトマネージャーは見つからないため、組織内の重心を得るのが難しくなります。
これらの環境に Microsoft EPM ソリューションを展開することは、インベントリと検出作業を行うことを意味します。 成功したプロセスはどこで確立されていますか? プロセスが失敗した場所 Project Server を展開するために利用できる一元化されたプロジェクト管理レベルでは何が機能していますか。
これらの種類のデプロイでは、最初にデプロイする EPM ソリューションの要素と、展開先の要素を選択して選択するように注意する必要があります。 この種のシナリオでは段階的なアプローチでデプロイすることが重要です。ビッグバンアプローチはここでほとんど成功しません。
マトリックス チャレンジ
マトリックス構造の組織だけを知って育った人にとっては、それが良い構造なのか悪いのか、この種の管理について何が強いか弱いかを考えることさえ考えないかもしれません。 マトリックス組織には、多くの人が疑問を持たない根本的な課題があります。それは設計上の競合です。 この構造は、部署の責任者とプロジェクト マネージャーの 2 つの対立する力を設定します。 もちろん、これを大声で言うことは決してありませんが、構造を見るだけで自明になります。
部署長の目標は、部署のスタッフに注意することです。 従業員が生産性が高く、スキルを持ち、満足している従業員であることを確認したいと考えています。 組織を部署の長に任せるとしたら、十分なトレーニングを受け、過労ではなく、十分な報酬を受けたが、あまり生産していない喜びの従業員になります。
プロジェクト マネージャーの目標は、プロジェクトの配信に注意することです。 プロジェクトの開始時に定義された範囲と品質を維持しながら、プロジェクトが可能な限り迅速かつ安価に実行されるようにしたいと考えています。 組織をプロジェクト マネージャーだけに任せるとしたら、プロジェクトを完了するという名前で従業員を焼き払うにつれて、いくつかのプロジェクトがすぐに完了しますが、スタッフが大きな離職を遂げる結果になります。
マトリックス組織の考え方は、これら 2 つの力の間に競合を設定すると、生産性と従業員の満足度の間で組織のバランスを取ることができます。 しかし、その前提は、部門の責任者とプロジェクトマネージャーは、最終的には互いにかなり強力であるということです。 もちろん、課題は、人々が平等に作成されないことです。 他のプロジェクトマネージャーよりも経験豊富なプロジェクトマネージャーが常にいます。一部の部署長は、次の部門よりも熟練しています。
この等価性の欠如は、最初の日にマトリックスのバランスが取れなくなっているのをスローします。 例外がバランスの取れたマトリックス組織であることを認識するだけで、多くの場合、PMO やオーガナイザーに順序を維持する方法を考えさせるのに十分です。これは良いことです。
完璧なバランスを取ることは、組織のプロジェクトと人々がどこで動けなくなるかを特定するための努力を確実にするほど重要ではありません。 マトリックス環境の作業を行うツールは、常に同じプロセスとコミュニケーションです。 熟練した実装者は、組織にとって重要なものを確立するプロセスと手順を特定できます。
マトリックスをあきらめる?
誰もがマトリックス組織のファンではありません。 ここ数年、多くのビジネス リーダーが、おそらくマトリックス組織の考えは最適な計画ではないという考えを表明してきました。 「担当者を専用のプロジェクト チームに分割する」と言います。"より幸せになります"、または "各部門内で作業するプロジェクトを整理し、部門長に渡します" と言います。詳細については、Rob Enderle のこの記事を参照して、Matrix モデルを廃止する必要があると考えているユーザーを確認してください。
最近訪問した多くの組織では、ある方向または別の方向に傾斜しているマトリックス モデルを見てきました。それぞれの状況により、Project Server と Microsoft EPM ソリューションを展開する方法が少し異なる推奨事項が作成されます。 一元化されたPMOがまったくない場合、それは私の最初の推奨事項になります。 一部の組織では、ライセンス コストを削減するために Project Server を使用したいが、連携する意図はないと言ってもらった。 それはあまり意味がありません。 一元化されたエンタープライズ プロジェクト システムの全体的な考え方は、分析と表示のためにデータをまとめ、プロジェクトを一緒に管理できるようにすることです。 これを行う意図がない場合は、個々のデスクトップ ライセンスを使用してください。
一部の組織では、マトリックス モデルはサイロ思考への復帰によって変位しています。 このようなことは、経済の大きな変化など、組織の大きな変化や外部からの刺激が発生した場合に発生する可能性があります。 圧力をかけられたら、一部のマネージャーは可能な限り生存のために戦います。 私は最近、部門長がPMOとその人員を「冗長なプロジェクトリソース」として正常に説明し、部門長に制御を戻すためにロビー活動を行った大規模な組織をいくつか見てきました。
このような変更の結果は、意図されたものとは正反対の効果を持つ可能性があります。 確かに、コストは短期間低下しますが、短くて安価なプロジェクトを通じて効率を生み出す仕事をしていた人々の効率が低下すると、後でリバウンドすることがよくあります。 それでも、大規模な組織では、これらの効果が実現されるまでに数か月から 1 年か 2 年かかる場合があります。 その間、マトリックスが折りたたまれると、Project Server の電源が抑制される可能性があります。
より進歩的な組織では、PMOに新たな重点が置かれ、その機能を新たに尊重し、困難な経済に直面する新しいレベルの権限さえも考慮されるかもしれません。
残高の復元 (または確立)
EPM の展開に取り組んでいるユーザー、または EPM のデプロイに取り組んでいるユーザーには、発生するマトリックス管理環境に関して考慮すべき点をいくつか次に示します。
まず、マトリックスの各軸のプロセスとロールの定義を探します。 インタビューを行いながら、プロセスによって、より官僚的ではなく組織の生産性が向上している場所を探します。 ロールを見るときは、プロジェクト管理サークルでよく取り上げられますが、従来の "権限のない責任" の課題に注意してください。
ゼロから始めている場合でも、採用できる階層構造内のプロセスを見つけることができます。これは大きな価値があるかもしれません。 企業全体で採用できる部署内に既存のプロセスまたは手順が見つかった場合、プロセスのソースを認識すると、すぐに 2 つのことを確認できます。まず、展開する必要のない 1 つの部門に 1 つのプロセスがあります。 既に採用されています。 2 つ目は、関係する部署の責任者が、部門によって既に行われたすべてを投げ出すつもりがない証拠を見ることができるマトリックスの 2 番目の軸を作成する取り組みの大きな同盟国になります。
部門をまたがるプロセスを作成していて、必要な場合は、不満を感じる可能性のある人々を巻き込もうと考えてください。 たとえば、最近、部門間のリソース容量計画プロセスを作成する必要がある組織を支援していました。 言うまでもなく、部署の責任者は、自分のスタッフの管理に対する何らかの制御を失うと感じたので、この考えに大喜びではなかった。 私は、プロジェクトの優先順位を確立するポートフォリオ運営委員会(それらの部門長を含む)を作成することをお勧めします。 部署長は、権限が彼らから取られているとは感じないでしょう。代わりに、部門間の意思決定を行う権限の新しい構造に含まれます。 この方法で作業することで、EPM 展開に反対する非常に多くの人々を含めることによって、EPM 展開の他の困難な側面が偏向しました。
最後に、デプロイを "軽く" 行い、レイヤーで作業することで過剰な介入を行わずに一元化された手順を確立することを考えます。 たとえば、マトリックスが非常に組織的に強力なプロジェクトに取り組んでいます。 PMO は初期段階にあり、組織構造に対してハードプッシュすることは理想的ではありません。 リソース管理を開始するために、個々のレベルにまで作業しないことをお勧めします。 代わりに、組織はリソース管理を一元化されたプロセスとしてデプロイし、非常に少数のユーザーが直接、または部門から PMO への放射としてアタッチされます。 リソースはすべてジェネリックとして定義され、各従業員が開始する個々のタスク レベルに到達することを目標としません。 代わりに、PMO は、今後の期間のリソースの課題の集計を特定し、管理する部門長に問題を引き継ぎ、リソース容量計画を開始します。 時間内に、リソースの競合を管理する作業を容易にするために、EPM の展開を広くプッシュする部署の責任者からの要求が発生することを期待しています。
まとめ
エンタープライズ プロジェクト管理を他のユーザーのコンサルタントとして展開する場合でも、独自の EPM を自分の組織内に展開する場合でも、マトリックス組織の課題に立ち向かう必要はほぼ確実です。 マトリックスのバランスを取ることは、MICROSOFT EPM ソリューションのような EPM および EPM システムが成功するための重要な課題の 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) を参照してください。