項目管理對企業的組織結構一定會產生影響，通常情況下，項目會與企業傳統的職能式結構互相影響，形成矩陣式的組織結構。
本文關鍵字： 項目管理 組織機構
1.1 形成適合項目管理的企業組織結構
1.1.1 選擇企業的組織結構
我們在前面曾經提到，項目管理對企業的組織結構一定會產生影響，通常情況下，項目會與企業傳統的職能式結構互相影響，形成矩陣式的組織結構，隨著企業對傳統職能管理和項目管理的偏重不同，形成了弱矩陣、平衡矩陣和強矩陣的不同形式。這些不同的組織方式之間，并不存在孰優孰劣的差別，它們所適應的管理要求是不同的，企業完全沒有必要為了追求項目管理而一味的向項目式管理傾斜，不必一定要采用強矩陣或者干脆采用項目式的組織結構。企業需要根據自己的使命和任務，選擇適合自身需要的組織形式。
以軟件公司為例。對于一個以產品開發為主的產品公司來說，如果它專注于產品的研發，它的銷售和實施可能主要依靠合作伙伴來完成，那么職能型的組織結構也許就是合適的。而對于一個純粹的施工隊式的系統集成公司來說，可能強矩陣或項目式的組織結構更為合適。對于既有自己的產品研發，同時又自行承擔產品的銷售和實施的公司來說，就要根據企業產品所發展的階段，采用不同的組織方式。例如在產品開發初期，產品與研發項目一一對應，職能部門與項目就可能完全重合，既可以作為職能式結構，也可以作為項目式的結構;當產品研發完成后開始推向市場時，在推向市場的初期，項目中有大量的工作涉及產品的完善，項目中的產品管理的需要更為重要，所以此時弱矩陣的結構更為適合;當產品達到比較成熟時，產品已經基本定型，產品銷售后的實施工作基本不會導致產品本身的變化，而更多的是考慮在項目中如何滿足客戶的特定需求，這時就更適合采用平衡矩陣或強矩陣的組織方式，產品管理的職能部門在其中的影響也變得比較小。
在有些企業中，為了盡量提高資源共享程度，產品研發部門的技術人員同時要參加項目中的系統實施，并在實施過程中，根據客戶的新需求改進產品，在完成項目任務滿足具體客戶需求的同時，對產品進行改進。在這樣的項目中，既有項目管理，又有產品管理，要同時滿足兩方面的要求，這種情況下的管理難度是最大的。因此可以說，平衡矩陣的管理結構，對企業的管理水平的要求是最高的。在本章后續部份中，將會重點說明產品管理與項目管理這兩者之間的關系。
不論企業采用何種組織方式來支持項目，當企業中的項目主要是跨部門涉及整個企業范圍的，企業都可以設置一個獨立的機構，稱為項目管理辦公室(PMO)，企業中的這個機構專門負責企業內項目的組織、管理工作。通常情況下，項目管理辦公室會負責制定企業的項目管理制度、流程，負責建立企業的項目管理信息系統，負責對項目經理進行培訓和指導，負責協調、管理項目相關的事務。有的企業中，將項目經理作為項目管理辦公室的成員，不隸屬于任何其他的職能部門，當企業成立項目時，就由項目管理辦公室直接任命項目經理，并對項目進行跟蹤管理。在不同的企業中，或者是在企業的不同發展時期，項目管理辦公室的職能不盡相同，這和企業整體的各部門職責分工和業務特點是密切相關的，不能簡單的一概而論。有關項目管理辦公室，在以后的章節中還有進一步討論。
對于企業中傳統的職能，則需要根據企業的核心任務、項目路線圖的基本內容，按照三條管理線的具體管理需要，將企業所需的各類角色進行組合，結合過程管理的特點，將全部所需的角色組織成若干的職能部門。這種基于角色需求的職能部門設計，使得職能部門的職責也變得非常清晰，他們在整個企業任務過程中的配合關系也非常清楚，這樣將非常有利于企業的項目管理，有利于企業的流程化管理。
1.1.2 RAEW矩陣
當企業中大量存在著跨越部門的項目時，對應的企業關鍵任務也一定是橫跨整個企業的，為完成任務而存在的工作流程也必然是跨部門的。在這種情況下，企業內流程的設計是首要的，各個職能部門的定義是基于流程的，這在前面的企業任務部分已經有過討論。但是在傳統的企業管理中，很多企業的職能部門都是相互獨立的，工作流程主要是在部門內部的，部門之間的聯系并不多，在考慮如何完成企業的任務時，往往表現出來的現象就是首先考慮各個部門的職責分工，而不是首先分析整體流程。這種思路會給需要流程的企業造成很大的困難。流程定義已經有很多工具可以支持，基于前面介紹的項目路線圖進一步細化企業的各項關鍵任務，從而形成企業內部的工作流程，這也是一種很有效的方法。
企業內部流程定義之后，就需要開始考慮各個部門在流程中的職責分工。RAEW矩陣是一個非常有幫助的工具，如下表所示：
其中，R(Responsibility)表示負有責任，A(Authority)表示有決策權，E(Expertise)表示提供專業知識，W(Work)表示提供勞動力，在一項工作任務中，每個部門都可能承擔不同的角色，如果某項工作完全由一個部門承擔，那么這個部門就應該同時具有RAEW四項內容，如果是由多個部門承擔，那么就可能各個部門分別具有R、A、E、W。這樣，通過分析企業的一項任務對各個部門的要求，定義出各個部門在企業不同任務中具體承擔的角色，從而可以整理出一個職能部門在企業所有任務中應具有的職責，定義出我們通常所說的部門職責分工。
在該表中，一個方向是企業的各個職能部門，另一個方向是企業的關鍵任務，在中間的各個單元格中，表示了各個部門在各項任務中擔當的角色。
這個工具也可以用于分析現有企業流程的合理性。根據企業各項任務中現有的部門職責分工填寫該表，全部填寫完成后，可以從企業任務的方向進行檢查。有時在一個任務中會沒有部門提供A，或者在不止一個部門有A，那么在此任務中將會出現無人決策或多頭決策的問題。如果在某個任務中不存在E，那么就有可能反映出企業在完成某項任務中還不具備相應的專業知識，可能需要考慮采購、外包等相應的解決辦法。
舉例一：
某企業內部的軟件研發單位，其RAEW矩陣如下：
在本例中，軟件研發單位要為企業提供軟件項目的技術可行性分析，還要承擔企業軟件開發的具體實施工作。需求管理部負責需求管理，與用戶部門澄清需求和控制需求變更，并按規定牽頭負責可行性分析的工作。PMO負責研發部門的所有開發項目的綜合管理。
在技術可行性分析任務中，CTO對技術的可行性作出最終的決策，所以表示決策權的A在CTO，需求管理部牽頭負責組織可行性分析工作，所以表示負責的R在該部門。在分析過程中，CTO、軟件部、商務部、PMO都要參與，分別從技術方向、現有架構和運行的系統、項目過程組織、成本等角度提出意見，所以在這些部門都有表示專業知識的E。最終形成可行性分析報告的工作，由需求管理部和軟件部具體完成，所以表示工作量的W就在這兩個部門。
在軟件開發實施過程中，通常都以項目的方式進行管理，PMO對項目的進程具有決定權，管理立項、里程碑評審、計劃變更、結項等工作，所以管理工作的A在PMO。需求管理部、軟件部、PMO，在開發過程中提供相應的專業知識，包括軟件知識和項目管理知識，所以這三個部門都有E。具體項目任務的實施，主要由軟件部完成，如果涉及對外采購，商務部也要跟蹤付款，所以表示具體純粹出力的W就在軟件部和商務部。
舉例二：
本例中是一個集成公司在售前投標和項目實施兩項關鍵任務上，相關部門之間的職責分布。
在售前投標任務中，最終的決策由COO負責，所以表示決策的A在COO，售前任務都是由銷售部負責組織，所以表示牽頭負責的R在銷售部，在售前投標的方案建議書中，既包含專業技術方案方面的內容，也包括項目過程組織的內容，還包括商務方面的內容，所以CTO、商務部、售前支持部和以后將可能承擔項目的技術部這四個主要部門，要對投標方案建議書的內容貢獻自己的聰明才智，所以這四個部門都有表示專業知識的E，在編寫投標方案建議書的過程中，主要的工作量是售前支持部和商務部實際完成，包括方案建議書的編寫、制作等，所以表示工作量的W主要由這兩個部門。
而在得到項目后的項目實施過程中，該公司規定項目經理和項目組的主要成員，都來自技術部，項目實施的各方面工作主要由技術部牽頭負責，所以技術部中就有表示負責項目的R。在項目實施過程中，關于項目進程變化的重大決策，仍然后COO做出最終的決策，所以表示決策的A在COO(該公司的CTO主要負責自有產品的研發)。在項目過程中，項目中的各類具體問題，可以由技術部、售前支持部、CTO和銷售部來提供參考意見，項目中的具體工作，主要包括項目范圍內的具體工作和商務工作兩部分，由于該公司是一家集成公司，所以在項目中經常還包括有分包商和產品供應商，所以商務工作中又包括了從客戶收款和向其他供應商付款的工作，這些實際工作量主要由技術部(項目工作)和銷售部(收款)、商務部(付款)負責，所以表示工作量的W就表現在這三個部門。同時，公司中所有的商務工作都由商務部負責，所以商務部還有一個針對商務工作的R。
RAEW矩陣方法，不僅可以用于分析企業關鍵任務在組織結構中的職責分布，還可以進一步對各項工作職責進行分解、細化。在一些大型項目中，有許多企業參與項目，那么也可以使用這一方法，作為項目中的職責分配矩陣(RAM)，來明確項目中各項任務的職責分配。
1.1.3 規定項目的組織結構
由于項目的臨時性和動態性的特點，項目組在企業中不是一種常設的、固定的組織，所以企業應該對于企業中常見項目類型的項目組織結構作出通用的規定，以指導項目團隊的建立。下圖是一種項目團隊組織的模型，它從團隊能力角度出發，對團隊中所需的四種能力作了分析：
1， 操作型。組織協調能力一般，專業知識能力一般。這種角色的項目成員適合作簡單、重復性的工作，例如在軟件開發項目中的一些缺乏工作經驗的初級程序員，就屬于操作型的角色。
2， 專家型。組織協調能力一般，專業能力很強。這種角色的項目成員適合解決復雜的專業技術問題，在幾乎所有的項目中，都需要領域中的專家參與，來負責解決項目的關鍵技術問題，他的關注重點是項目中的工程類要求。例如在軟件項目中的系統分析員、首席架構師，工程類項目中的總工程師等。
3， 協調型。組織協調能力很強，專業知識一般。這種角色的項目成員最適合作協調、溝通的工作。最典型的代表就是項目經理，在PMBOK中提出，一個典型的項目經理，應該有75%-90%的時間是用于溝通的。在實踐當中，確實對于項目經理的組織協調能力有著很高的要求，在有些企業中的項目經理，就是重點要求項目管理方面的能力，而對于專業知識方面的要求卻很一般。
4， 決策型。組織協調能力很強，專業知識也很強。這種角色的項目成員是很難得的，既能從專業角度知道事情應該做成什么樣，又能在現實環境中知道事情應該怎樣才能做成，能夠在理想與現實之間找到一個合理的平衡點。這樣的人員一般來說成本都是比較高的，很少直接進入具體的項目。
在一個項目團隊中，這四種角色一般都是需要的。但這并不意味著項目組中必須要有這樣的四個人。一個人可以同時擔當多個角色，一個角色也可以由多個人配合而成。例如在某公司的項目團隊中，有協調型的項目經理和專家型的系統分析員，但是沒有決策型的成員，項目中的決策是由項目經理與系統分析員進行溝通并達成一致意見后形成的，通過兩個人的相互配合，共同組成了決策型的角色，使項目內的角色結構保持完整。
對應前面所述三條管理線的要求，專家型的角色更偏重應對產品管理線的要求，協調型的角色更偏重解決項目管理線的要求，同時要協調企業的資源管理線以獲得項目資源。如果項目中分別有系統分析員和項目經理，那么系統分析員重點在專業技術方面，項目經理重點在項目管理、資源協調方面。現在還有許多企業中的項目經理，往往都是由技術骨干擔任，也就是用專家型的人同時擔任協調型的工作，這時的項目經理就需要同時關注產品管理、項目管理和資源管理三條管理線的要求，管理的復雜度就更大了。
在定義了項目的基本組織結構的基礎上，企業可以根據不同類型的項目所對應的任務特點，結合專業技術的要求和企業管理的要求，制定出項目組織的具體要求。例如在軟件項目中，除了項目經理，在不同階段要有相應的系統分析員、高級程序員、程序員、質量保證人員、配置管理人員、測試人員等，各種角色的職責都應根據專業技術標準和企業管理這兩方面的需要，設定不同類型的項目的內部組織結構的要求，以指導和規范項目經理組織項目組成員的工作，為項目的人力資源管理提供一個相對較好的起點。
