マトリックスのバランスを取る: ホワイト ペーパー

このホワイト ペーパーは、「From the trenches」コレクションの一部です。ここでは、マトリックス プロジェクト管理環境を使用している組織でエンタープライズ プロジェクト マネジメント (EPM) を実装している担当者が直面する問題について説明します。

このホワイト ペーパーの Word 版をダウンロードするには、「マトリックスの均衡: ホワイト ペーパー」を参照してください。

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

マトリックスの均衡

プロジェクト管理のサークルでは、マトリックス管理環境がよく話題に上ります。マトリックス管理は新しいものではありません。事実上、すべてのハイテク組織において管理のデファクト スタンダードになっています。

マトリックス管理の概念は、70 年代前半に管理に関する思索から生じたものです。J.R. Galbraith 氏は、この件に関する最初の刊行物の 1 つとして、組織的な責務と機能的な責務を組み合わせる方法について記した作品を 1971 年に発表しました。

組織は、強力な部門リーダーに統制された部門の巨大なサイロでした。完了するには複数の部門が関わる必要のあるプロジェクトが複数存在するような事態にならない限り、これは十分に機能します。「プロジェクト化」したマトリックスの概念は、30 年以上にわたって、プロジェクト マネージャーやプロジェクト マネジメント協会などの団体によって促進されてきたものです。

プロジェクト化したマトリックスでは、組織に第 2 の軸を設け、プロジェクトの管理担当に何らかの責務を与えます。その結果、組織の部門がディスプレイの一辺に並び、プロジェクトまたは製品を提供しているプロジェクト マネージャーが別の一辺に並びます。

プロジェクト管理の責任範囲における部門共有

エンタープライズ プロジェクト マネジメントの説明で、なぜこのことを話すのでしょうか。その理由は、このモデルが事実上すべての Microsoft EPM ソリューション展開の土台を担っているからです。現在、Project Server の展開で作業している場合は、確実に途中でこのモデルに出会います。マトリックス マネジメント モデルには例外があり、これについては後述しようと思いますが、技術的な組織の場合、それは汎用に近づいているとだけ言っておきます。

現在、Microsoft EPM ソリューションの展開で作業している場合、組織は、次の状態のいずれかになっています。

  1. マトリックスがない

    組織は完全にサイロベースです。各部門長が自身の部門を大きな組織の系列会社であるかのように管理します。予算は、階層的な形式で (組織図を思い浮かべてください) 部門を通じて上層に集められます。プロジェクトが開始されると、プロジェクトの完了に他の部門のリソースが必要な場合でも、それぞれの部門内でプロジェクトは行われます。管理している部門のリソースでプロジェクトを完了できない場合、部門間の要求として外部リソースの調達が交渉されます。

    この方式は、次のようなプロジェクトを管理しようとするまで、実際にはそれほど悪いとは感じられません。つまり、ほとんどすべてのプロジェクトが部門間のリソースを要求した場合、グループ間の優先順位を見出すことはできません。どの部門長にも、自身のリソースの優先順位に対する制御を放棄するような動機付けがありません。このような支配権をあきらめることは直観でわかるものではないので、単一の部門内で完了できないプロジェクトはすべて苦労します。

    さらに、部門長より 1 レベル高い上司と話したときに、リソース キャパシティ プランニングが一切得られないという嘆きをよく耳にします。これはまったくそのとおりです。リソース キャパシティ プランニングに必要な情報を集計するための部門間の構造も、このような分析に必要な一元的な優先順位設定に各部門長が従う動機付けもないのです。

    この状況では、プロジェクト オフィスが 1 つではなく複数 (互いに協力することがほとんどない部門ごとに 1 つずつ) 見られることが非常によくあります。

    Microsoft EPM ソリューションをこの種のシナリオで展開するには、同時に組織を調整する方法を検討することが必要になります。このような企業から、この不可能なことの実行を依頼する電話をよく受けます。2、3 週間で、数百人さらには数千人のユーザーを訓練し、Project Server をインストールして運用できるようにします。この企業は一元的なエンタープライズ プロジェクト マネジメント システムを購入しているので、組織は即座に一元的なマトリックス化した環境として準備が整い運用できるものと期待しているのです。これは費用のかかる夢物語です。必ず、どのように組織を変更する必要があるかについて、上級管理者と話す必要があります。話し合いは、通常、ソフトウェアを購入しただけで全員を変更させる十分な対応になると望んでいた管理者にとって楽しいニュースではありません。

    このようなプロジェクトを、一元化したプロジェクト管理オフィスと一元的なプロジェクト管理手順の計画に取り組むことから開始します。Project Server は中盤頃からゆっくりと展開されます。このようなプロジェクトで、組織全体が最終的に関与するまでに 12 ~ 24 か月かかることは珍しくありません。当社は 2 年半遅れてからこのようなプロジェクトを再度開始しただけで、その間に彼らは自ら取り組んで PMO を作成しました。

  2. 均衡の取れたマトリックスがある

    この状態であれば申し分ありませんが、残念ながら非常に珍しいことです。均衡の取れたマトリックスを維持するには、絶え間ない調整と注意が必要です。ただし、均衡の取れたマトリックスがある場合、非常に進化した一連の手順、定義された役割、関与する全員が十分理解したプロセスも存在する傾向があります。この種の組織への Microsoft EPM ソリューションの展開が、最もよいシナリオになります。

  3. マトリックスはあるが均衡が取れていない

    これは間違いなく最もよく見かける一般的なシナリオで、納得できるものです。マトリックス モデルはいくつかの固有の衝突をもたらすので、部門に重みを置き、PMO が弱いマトリックスや、PMO に重みを置き、部門長が弱いマトリックスをよく目にします。または (はるかに対処が困難ですが)、一部の部門だけに重みを置き他の部門を軽視し、一部のプロジェクト マネージャーに重みを置き他のプロジェクト マネージャーは軽視しているマトリックスもあり、このマトリックスでは、組織内の重心を見出すことが難しくなります。

    このような環境で Microsoft EPM ソリューションを展開すると、何らかのインベントリおよび検出作業を行うことになります。成功したプロセスはどこに確立されていますか。プロセスはどこで失敗しましたか。Project Server を展開するために活用できる一元的なプロジェクト管理レベルで、何が機能しており、何が機能していませんか。

    これらの種類の展開では、最初に展開する EPM ソリューションの要素とそれらを展開する相手を非常に慎重に選択する必要があります。ビッグバン アプローチはこの種のシナリオではほとんど成功しないので、フェーズ アプローチでの展開が重要になります。

マトリックスの問題

マトリックス構造の組織しか知らずに成長した人々にとって、それがよい構造か悪い構造かを考えたり、この種の管理について何が強力で弱いかについて考えることもないかもしれません。マトリックス組織には多くの人が疑問にも思わない根本的な問題があります。設計による衝突です。マトリックス組織の構造は、部門長とプロジェクト マネージャーという 2 つの拮抗する力をもたらします。もちろんこのことを大きな声では言っていませんが、構造を見ただけで明白です。

部門長の目標は、部門内のスタッフ メンバーに注意することです。部門長は、そのメンバーが生産的で、スキルがあって、満足した従業員であってほしいと考えています。組織を部門長に任せた場合、最終的に、十分に訓練され、あまり酷使されておらず、十分に報酬を受けたがあまり生産していなかった従業員を喜ばせることになります。

プロジェクト マネージャーの目標は、プロジェクトの配信を監視することです。プロジェクト マネージャーは、プロジェクトの開始時に定義された適用範囲と品質を維持しながら、できるだけ迅速に低費用でプロジェクトを行えるようにしたいと考えています。組織をプロジェクト マネージャーだけに任せた場合、最終的に、一部のプロジェクトが迅速に行われるものの、プロジェクトの完了という名目で従業員を疲弊させるので多くのスタッフの離職を招いてしまします。

マトリックス組織という概念は、これらの 2 つの力の衝突を引き起こすことで、生産性と従業員の満足との間でうまく組織の均衡を取るというものです。ただし、最終的に部門長とプロジェクト マネージャーが互いにほとんど同じ力を持つようになるという前提があります。もちろん、人は同じようには作られていないことが問題です。必ず、他のプロジェクト マネージャーよりも経験が豊富なプロジェクト マネージャーが存在し、次の部門長よりもスキルに長けた部門長が存在するものです。

この平等性の欠如によって、初日からマトリックスの均衡が取れなくなります。均衡の取れたマトリックス組織が例外であることを認識するだけで、多くの場合、PMO と組織者に秩序を保つ方法について考えさせるには十分であり、望ましい結果につながります。

完全な均衡を得ることは、組織のプロジェクトと人員が行き詰まる箇所の特定に労力が向けられるようにすることほど重要ではありません。マトリックス環境を機能させるツールは常に変わることなく、プロセスとコミュニケーションです。熟練した実装者であれば、組織にとって重要な要素を確立するプロセスと手順を特定できます。

マトリックスをあきらめるか?

全員がマトリックス組織の支持者というわけではありません。ここ 2、3 年、多数の企業リーダーが、マトリックス組織という考え方は最善の計画ではないかもしれないという考えを口にしてきました。「専従のプロジェクト チームに人員を分配すれば、それで満足でしょう」と述べたり、「各部門内で機能するようにプロジェクトを編成して、部門長にプロジェクトを任せてください」と言っています。詳細については、Rob Enderle 氏のこの記事を見て、マトリックス モデルは退場すべきだと考えている人を参照してください。

最近訪問した多くの組織で、どちらかの方向に歪曲したマトリックス モデルを目にしてきましたが、それぞれの状況から、Project Server と Microsoft EPM ソリューションを展開する方法が少し異なった提言を行っています。一元化された PMO がまったくない場合、この提言が最初になります。ライセンス コストを減らすためだけに Project Server を使用したいと言ってアプローチしてきた組織もいくつかありましたが、協力するつもりはありません。そのような目的は、納得のいくものではありません。一元化されたエンタープライズ プロジェクト システムの全体的な概念とは、分析のためにデータをまとめ、プロジェクトを一緒に管理できるように、データを表示することです。このような目的がない場合は、個々のデスクトップ ライセンスを堅持してください。

ある組織では、マトリックス モデルがサイロに立ち返るという概念に取って代わられていました。この種のことは、組織での大きな変更や、経済での大きな変動などの外部的な刺激があったときに起こることが考えられます。プレッシャーを受けると、マネージャーの中には可能なあらゆる手段を使って生き残ろうともがくものもいます。最近、部門長が PMO とその人員を「冗長なプロジェクト リソース」と評し、部門長に制御を戻すように働きかけることに成功した、複数の大きな組織を見てきました。

このような変化の結果、目的としていたものとは正反対の効果を生み出すことがあります。確かに、短期間ではコストが低下しますが、これまで、より短期間により低費用のプロジェクトで効率性を生み出すことが仕事だった人々の効率性の損失は多くの場合、しばらく経ってから反動を引き起こします。また、大きな組織では、これらの効果が現れるまでに数か月、さらには 1、2 年かかることもあります。その間に、マトリックスが崩壊し、Project Server の力が抑制される可能性があります。

革新的な組織では、その機能や、おそらく困難な経済状況をものともしない新しいレベルの権威として、新たな尊敬の念を持って、PMO に新しい力点が置かれている場合があります。

均衡の回復 (または構築)

EPM 展開に取り組んでいる、または取り組もうとしている人々にとって、マトリックス管理環境について検討すべき事項がいくつかあります。

第一に、プロセスと、マトリックスのそれぞれの軸に対する役割の定義を探します。インタビュー中に、プロセスによって、組織が官僚的ではなく、生産的になっているところを探します。役割を見るときには、プロジェクト管理サークルで頻繁に話題になっている、古典的な「権限を伴わない責任」の問題に注意します。

一から始めている場合は、採用可能なプロセスを階層構造からでも見つけることができ、非常に役立つ可能性があります。企業全体で採用できる既存のプロセスまたは手順を、ある部門内で見つけられる場合は、プロセスのソースを認識すれば、簡単に次の 2 つのことがわかります。まず、展開する必要のない 1 つのプロセスが 1 つの部門に存在しており、これは既に採用されています。次に、部門でこれまで行われてきたすべてをあなたが却下するつもりではないという証拠を、関与する部門長に示せれば、マトリックスの 2 番目の軸を作成しようという取り組みで、部門長から協力を得られます。

部門間を横断するプロセスを作成しており、完成させなければならない場合は、権利を奪われたと感じるかもしれない人々を関わらせることを検討してください。たとえば、最近、部門間のリソース キャパシティ プランニング プロセスを作成する必要があった組織を支援しました。言うまでもなく、部門長は、自身のスタッフの管理に対する制御手段を失うと感じていたため、このアイデアを歓迎しませんでした。プロジェクトの優先順位を定めるポートフォリオ運営委員会 (そのメンバーには部門長を含めます) を作成することを提言しました。部門長は、権威が奪われたとは感じることはなく、その代わりに部門間の意思決定を行う権威の新しい構造に関わりました。このように対処して、他の方法では反対していたであろう人々を関与させることによって、他の方法では困難になっていた EPM 展開の側面を回避することができました。

最後に、展開に「手加減」を加え、階層で作業することで過度の介入なしに一元化された手順を確立することについて考えます。一例として、マトリックスが組織的に非常に強力であるプロジェクトに取り組んでいます。PMO はその初期段階にあり、組織的な構造を強く押し出すことは理想的ではありません。そこで、リソース管理が開始する個々のレベルまで下げて作業しないように提言しました。組織が代わりに、直接配属されたか、部門から PMO への派遣として配属されたごく少数のユーザーで、一元化されたプロセスとしてリソース管理を展開します。リソースはすべて汎用として定義されます。目標は、各従業員が開始する個々のタスクレベルまで進めることではありません。そうではなく、PMO は、次の期間での総計のリソース問題を識別し、続いて問題を部門長に引き渡して管理させることによって、リソース キャパシティ プランニングを実行し始めます。やがては部門長自身から、リソースの衝突を管理しながら抱えている作業を楽にするために EPM 展開を広げるように要求されるだろうと期待しています。

結論

他者のコンサルタントとしてエンタープライズ プロジェクト管理を展開しているか、自身の組織内で独自の EPM を展開しているかにかかわらず、マトリックス組織の問題に直面することはまず避けられません。マトリックスの均衡を維持することは、EPM および EPM システム (Microsoft EPM ソリューションなど) を成功させるための主要な問題の 1 つです。

著者について

Chris Vandersluis 氏は、カナダのモントリオールに拠点を置き、Microsoft 認定パートナーである HMS Software 社の社長であり創業者です。マギル大学で経済学の学士を取得し、プロジェクト制御システムの自動化に 30 年以上携わってきました。PMI (プロジェクト マネジメント協会) の古くからの会員であり、MPUG (Microsoft Project Users Group) のモントリオール、トロント、ケベックの支部の設立を支援しました。Vandersluis 氏が寄稿した出版物には、Fortune、Heavy Construction News、Computing Canada magazine、および PMI の PMNetwork などがあり、Project Times のレギュラー コラムニストです。マギル大学で上級プロジェクト管理を教えており、北米および世界中のプロジェクト管理団体の会合で頻繁に講演しています。HMS Software 社は TimeControl プロジェクト指向型の時間管理システムの発行元であり、1995 年から Microsoft Project ソリューション パートナー企業です。

Chris Vandersluis 氏のメールの連絡先は chris.vandersluis@hms.ca です。

Chris Vandersluis 氏の EPM 関連のその他の記事については、HMS 社の EPM ガイダンスのサイト (http://www.epmguidance.com/?page_id=39) を参照してください。

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

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

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

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

×