平衡矩陣
本文是「從馬西斯」集合的一部分。 其中說明在使用矩陣專案管理環境的組織中，實作企業專案管理 (EPM) 的人員所面臨的挑戰。
若要下載本文的 Word 版本，請參閱 平衡矩陣：白皮書。
若要查看更多文章，請參閱 白皮書。
平衡矩陣
在專案管理圈中，我們通常會經常討論矩陣管理環境。 矩陣管理並非任何新功能。 它已成為幾乎所有高技術組織中管理的實務標準。
矩陣管理的概念是從 70 年代早期的管理思考而來。 J.R. Galbraith 提供我們在 1971 年首次發佈的主題工作之一，討論如何結合組織和功能責任。 當時普遍存在的管理環境是階層式的。
組織是強大的部門領導者所支援的部門龐大定址器。 這非常適合，直到有多個專案必須跨越多個部門才能完成為止。 專案經理和專案管理機構等關聯已提升「投影」矩陣的概念超過 30 年。
在投影矩陣中，我們會為組織建立第二個軸，並將一些責任授與管理專案的組織部分。 結果會讓組織部門沿著顯示器的一側，以及專案經理將專案或產品傳遞到另一端。
為什麼在討論企業專案管理時討論這個問題？ 因為此模型幾乎已成為每個 Microsoft EPM 解決方案部署的基石。 如果您現在正在部署 Project Server，則務必在移動中遇到此模型。 「矩陣管理」模型有一些例外狀況，我會在完成此處之前加以討論，但前提是，如果我們看看技術組織，它就已接近通用。
如果您目前正在處理 Microsoft EPM 解決方案部署，您會發現組織處於下列幾個狀態之一：
沒有矩陣
組織完全以定址接收器為基礎。 每個部門主管都會管理自己的部門，就像是大型組織的子公司一樣。 預算會以階層方式向上匯總， (考慮組織結構) 。 當專案起始時，它會在每個部門內完成，即使其他部門可能需要資源才能完成專案也一致。 如果無法使用管理該專案之部門的資源來完成專案，則外部資源會交涉為部門間要求。
實際上，在您嘗試管理這類專案之前，這聽起來不會太糟。 如果幾乎所有專案都需要部門間資源，則不可能找出群組之間的優先順序。 沒有任何獎勵可讓任何部門主管放棄對自己資源優先順序的控制權。 放棄這類能力是違反直覺的，因此無法在單一部門內完成的任何專案都會受到影響。
此外，當我們與比部門主管高一層的主管交談時，通用的優點是他們無法取得任何資源容量規劃。 這非常合理。 沒有任何跨部門結構可匯總資源容量規劃所需的資訊，也不會有任何獎勵讓每個部門主管提交到這類分析所需的集中式優先順序。
在此情況下，我們可能會發現不是一個，而是多個專案辦公室，每個部門彼此之間的合作非常少。
將 Microsoft EPM 解決方案部署到這種案例中，需要同時思考如何調整組織。 我們通常會收到這類公司的來電，要求我們執行不可能的動作。 訓練數百或甚至數千名使用者、安裝 Project Server，並在數周內進入生產環境。 預期是因為公司已購買集中式企業專案管理系統，所以組織會立即以集中式矩陣環境的方式進行連線並運作。 這是耗費資源的昂貴物件。 無可避免，我們必須與資深管理層討論如何變更組織。 對於希望只購買軟體的管理人員來說，這通常不是一個好消息，只要承諾讓每個人變更就已足夠。
我們會藉由處理集中式專案管理辦公室和集中式專案管理程式的計畫來啟動這類專案。 Project Server 從中間導入速度很慢。這類專案需要 12 到 24 個月，直到整個組織最終都參與為止，並不常見。 我們剛在延遲 21/2 之後重新開機這類專案，同時他們自行建立 PMO。
有平衡矩陣
當發生這種情況時，這很好，但很抱歉很不尋常。 維護平衡矩陣需要持續調整和小心。 但是，當我們找到平衡矩陣時，我們也可能會找到一組高度進化的程式、定義的角色，以及所有相關人員都清楚瞭解的程式。 將 Microsoft EPM 解決方案部署到這類組織是最佳案例。
有矩陣，但不平衡
這是我們目前最常遇到的案例，而且非常合理。 矩陣模型有一些固有的衝突，因此我們通常會發現矩陣已加權至 PMO 較弱的部門，或加權至具有弱部門主管的 PMO。 或者， (，這是到目前為止最具挑戰性的) 我們發現矩陣會加權至某些部門，但不會加權給某些部門，而非其他部門，而非其他部門，因此組織中的重力中心難以實現。
在這些環境中部署 Microsoft EPM 解決方案表示執行一些清查和探索工作。 已在何處建立成功的程式？ 進程失敗的位置為何？ 在集中式專案管理層級，我們可以利用哪些專案管理層級來部署 Project Server，哪些不是？
在這些類型的部署中，我們必須非常小心地挑選我們想要先部署的 EPM 解決方案元素，以及要部署它們的目標。 在這種案例中以階段式方法進行部署非常重要，因為此處幾乎永遠不會成功使用巨量方法。
矩陣挑戰
對於已成長且只瞭解矩陣結構化組織的人，您可能甚至不會想出它是良好的結構還是不良的結構，或是想一想這種管理的強式或弱式。 矩陣組織有一個根本挑戰，許多人甚至不會問：它是依設計而衝突。 結構會設定兩個相反的強制：部門主管和專案經理。 當然，我們絕不會大聲說出這點，但只看結構會讓它變得很明顯。
部門主管的目標是要注意部門中的員工成員。 他們想要確保其人員具有生產力、熟練且滿意的員工。 如果我們要讓組織只由部門主管負責，最後會得到訓練良好、工作過度、補償良好，但未產生太多結果的知名員工。
專案經理的目標是要注意專案的傳遞。 他們想要確保其專案盡可能快速且便宜地完成，同時維持專案一開始所定義的範圍和品質。 如果我們要讓組織只由專案經理決定，我們最終會得到一些快速完成的專案，但員工卻因為燒錄員工完成專案的名稱而產生很大的流失。
矩陣組織的概念是設定這兩個力力之間的衝突，可讓組織在生產力與員工滿意度之間取得平衡。 不過，其前提是部門主管和專案經理最終的強大程度幾乎等同于彼此。 當然，挑戰在於人們的建立不相等。 永遠會有一些比另一位更有經驗的專案經理;有些部門主管比下一個更熟練。
這種不相等會在第一天使矩陣超出平衡。 只瞭解例外狀況是平衡的矩陣組織，通常就足以讓 PMO 和召集人思考如何維護訂單，這可以是一個不錯的事。
取得完美平衡並不像確定有一些努力來識別組織的專案和人員停滯的位置一樣重要。 讓矩陣環境運作的工具一律相同：處理常式和通訊。 技術熟練的實作者可以識別程式和程式，以建立對組織很重要的事項。
要放棄矩陣嗎？
並非每個人都是矩陣組織的風扇。 在過去幾年中，許多企業領導人都認為矩陣組織的想法可能不是最佳計畫。 「將人員劃分為專用的專案小組」，他們表示「您將會樂於這麼做」或「組織專案以在每個部門內工作，並將其提供給部門主管」。如需詳細資訊，請參閱 Rob Enderle 的這篇文章，以查看認為應該淘汰矩陣模型的人員。
在許多我最近造訪過的組織中，我發現矩陣模型有一個方向或另一個方向扭曲，而每種情況都會讓我提出在如何部署 Project Server 和 Microsoft EPM 解決方案方面稍有不同的建議。 如果沒有集中式 PMO，就會成為我的第一個建議。 我曾有一些組織向我指出，他們只想要使用 Project Server 來降低授權成本，但不想合作。 這並沒有多大意義。 集中式企業專案系統的整個概念是將資料結合在一起進行分析和顯示，以允許將專案管理在一起。 如果您不打算這麼做，請遵守個別的桌面授權。
在某些組織中，矩陣模型已因返回定址接收器思考而無法使用。 例如，當經濟發生重大變更或外部壓力時，就會發生這種情形。 當有壓力時，某些經理會盡可能努力求成存活。 我最近看過幾個大型組織，其中部門主管已成功將 PMO 及其人員描述為「備援專案資源」，並支援將控制權交還給部門主管。
這類變更的結果可能會與預期的結果完全相反。 若為 True，成本會在短時間內下降，但其工作是透過較短且更便宜的專案來產生效率的人員效率降低，通常會在稍後發生失敗。 不過，使用大型組織時，可能需要數個月或甚至一年或兩年才能實現這些效果。 同時，矩陣會折迭，而且可以抑制 Project Server 的功能。
在更漸進的組織中，新的重點可能會放在 PMO 上，並對其功能有全新的尊重，甚至是面對挑戰性經濟時，甚至是新的授權層級。
還原 (或建立) 平衡
對於正在或即將處理 EPM 部署的人員，以下是您所遇到矩陣管理環境的一些考慮事項：
首先，尋找矩陣每個軸的進程和角色定義。 在進行面試時，請尋找程式讓組織更具生產力的位置，而不是更具語意。 查看角色時，請留意專案管理圈中經常討論的傳統「沒有授權的責任」挑戰。
如果您是從頭開始，您仍然可以在階層式結構中找到可採用的程式，而這些程式可能非常值得您使用。 如果您可以在一個部門中找到可由整個企業採用的現有程式或程式，則認可程式的來源會立即取得兩件事：首先，您在一個不需要部署的部門中有一個程式。 它已採用。 其次，您在建立矩陣的第二個軸時，最後可能會有一大個同盟，其中涉及部門主管可以看到您不打算擲回部門已完成的所有專案。
如果您要建立跨部門的程式，而您必須這麼做，請考慮牽涉到可能感到被重組的人員。 例如，我最近協助組織必須建立跨部門資源容量規劃程式。 不用說，部門主管對此概念並不太抱歉，因為他們覺得會失去對自己員工管理的某種程度控制。 我建議建立組合指導委員會 (包括其部門主管) 成員，以建立專案優先順序。 部門主管不會覺得已從他們取得授權;相反地，它們會包含在新的授權結構中，以進行跨部門決策。 以這種方式工作，藉由包含原本會對其進行攻擊的人員，來消除 EPM 部署的具挑戰性層面。
最後，請考慮在部署上「輕度」，並建立集中式程式，而不需過度介入，方法是在圖層中工作。 例如，我們正在處理矩陣在組織上非常強大的專案。 PMO 處於起步狀態，而且很難針對組織結構進行推送並不理想。 我們建議您不要向下著手進行個別層級，以開始進行資源管理。 相反地，組織會將資源管理部署為集中式程式，其中只有極少數的使用者直接或從部門附加為 Emissaries 至 PMO。 資源全都會定義為泛型，而且目標不會是推動每個員工啟動的個別工作層級。 相反地，PMO 會開始進行資源容量規劃，方法是識別未來期間的匯總資源挑戰，然後將問題轉移到部門主管進行管理。 我們預期，部門主管本身會要求更廣泛地推送 EPM 部署，以簡化他們自行管理資源衝突的工作。
總結
不論您是以其他人的顧問身分部署企業專案管理，還是要在自己的組織內部署自己的 EPM，您幾乎都必須克服矩陣組織的挑戰。 保持矩陣平衡是 EPM 和 EPM 系統的主要挑戰之一，例如 Microsoft EPM 解決方案，讓它們成功。
關於作者
Chris Vandersluis 是 Microsoft 認證合作夥伴、加拿大 HMS Software 的副總裁和建立者。 他擁有 McGill University 的經濟效益學位，以及超過 30 年的專案控制系統自動化經驗。 他長期隸屬于 Project Management Institute (PMI) ，並協助您找到 Microsoft Project Users Group (MPUG) 的多倫多、多倫多和魁北克章節。 Chris 所撰寫的發行集包括《星號》、《重度建構新聞》、《計算加拿大》雜誌和 PMI 的 PMNetwork，而他也是 Project Times 的一般常客。 他教授 McGill University 的進階專案管理，並經常在北美洲全球各地的專案管理關聯函式上進行討論。 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) 。