案例一
某外資大型汽車零配件公司，以項目形式從事汽車主要零配件的研發和銷售業務。公司組建強矩陣型項目部，項目部成員來自各職能部門(如銷售部門)，由項目經理對項目的財務指標、進度和質量等負責。在項目執行過程中，來自職能部門的成員(如銷售人員)不能按時完成工作。項目經理與職能部門經理(如銷售經理)溝通后，仍無法讓這些成員按時完成工作。項目經理不得不向總經理報告問題，由總經理直接要求職能經理督促他們按時完成工作。結果又導致職能經理認為項目經理在打小報告，從而又造成了對項目的不利影響。
理論要點：
1. 需要進一步調整組織結構。從表面上看，公司采用了強矩陣，但從項目經理和職能經理的權力分配來看，項目的強矩陣組織結構是很不到位的，例如：項目經理對來自職能部門的員工基本沒有指揮、考核和控制的權力;這些員工名義上對項目經理負責，實際上卻仍是直接對職能經理負責(因為職能經理負責員工的業績考核);項目團隊所采用的流程都是各職能部門出于各自為政的目的而分別編制的。所以，組織結構需要調整成真正的強矩陣或項目制的組織結構，減弱或消除部門經理對于項目團隊成員的管控。部門經理可以以業務專家的方式對團隊成員進行支持。既然公司要求項目成敗的第一責任人是項目經理，那么就必須讓項目經理對項目責、權、利保持一致。
2. 組織文化調整。導致強矩陣式組織流于形式和表面的根本原因，是公司沒有建立起跨部門合作的組織文化，而仍然是各職能部門分工負責、各自為政的組織文化。組織結構是明規則，組織文化是潛規則。如果明規則與潛規則相矛盾，那一定是潛規則獲勝。如果組織文化支持跨部門合作，那么項目經理與職能經理協商后，通常都能夠解決問題，無需再向總經理報告。即便要向總經理報告，職能經理也不會認為項目經理在打小報告。如果有跨部門合作的文化的支持，那么職能部門員工在參與項目工作后，職能經理就會鼓勵員工首先注重完成項目任務，而不是首先注重維護本職能部門的利益。
3. 建立定期的跨部門溝通機制。項目經理不能等到有問題了再去找職能經理溝通，而要在出現問題之前就要溝通。特別是在項目計劃編制階段，項目經理必須主要邀請職能經理參與，請他們發表意見。如果職能經理不發表意見，項目經理也要設法請他們發表意見，以便防止“虛假一致性”。在采用各部門的業務流程時，項目經理要注意分析這些流程之間的不一致甚至矛盾，引導職能經理達成協調。
4. 請公司總經理定期召開跨部門項目協調會。這是項目治理層面對項目相關事務的高層級協調。有了這種協調會，不僅可以避免所謂的“打小報告式”，專門向總經理匯報，而且有助于各職能部門在協調會召開之前解決相關問題，以免在協調會上被指名批評。《微權力下的成功項目管控》一書中講到了一個“星期二奇跡”。公司規定每周二召開項目跨部門協調會。如果某部門的工作沒有做到位，就會在會議上被領導批評。在上周四或五看起來還解決無望的問題，到了本周一大多都能得到解決，因為誰都不想被公開批評。
案例二
在目前的一個項目中，我們是乙方，由中方和德(國)方公司組成，中方是主導方。甲方也是由中方和德方公司組成的。在甲方中，中方管理方面強、技術方面弱，德方則管理方面弱、技術方面強。與乙方始終由中方主導不同，在甲方，初期由德方主導，后期由中方主導。項目前期進行很好，但現在乙方的德方經常直接找甲方的德方討論問題，導致甲方誤認為乙方也是由德方主導的，使乙方的中方事實上處于被架空的狀態。
理論要點：
1. 聯營協議。對于由兩家公司聯合組成的乙方聯營體，這兩家公司之間必須簽訂一份聯營協議，其中明確規定哪家公司是主導公司，以及兩家公司的權責。這個聯營協議應該向甲方公開，甚至應該按照甲方提供的格式來簽訂。
2. 制定明確可行的溝通計劃。在項目中，由于大家都是為了這個項目而第一次合作，相互之間不了解，所以必須認真編制溝通計劃。甲乙雙方在合同執行開始之前，要坐下來，認真地討論，制定一份雙方都愿意采納的溝通計劃，明確規定針對什么事情，應該由雙方的什么人以什么方式來溝通。溝通必須嚴格按溝通計劃中的規定進行。
3. 會議。由于甲乙方之間的大量溝通是通過會議進行的，所以乙方的主導方要盡可能參加這些會議。即便是由兩個德方進行的技術討論會議，乙方的中方也要盡量參加。在這種會議上，可以主要由乙方的德方代表乙方發言，但乙方的中方必須代表乙方發表開場講話和結束講話，并注意掌控會議中的關鍵點。這種對開場、關鍵點和結束的掌控，就可以體現出中方作為主導方的地位。
4. 要授權，不要分權。必須承認，有些純技術性的事項，由兩個德方直接溝通更有效。對于這些事項，乙方的中方必須事先以書面方式通知甲方。這樣一來，乙方的德方直接找甲方的德方溝通，那也是根據中方的授權進行的。注意，不要讓乙方的德方“瓜分”了乙方的中方的權力。項目管理強調授權，反對分權。
案例三
手機游戲軟件開發項目，需求變化頻繁，版本迭代快，團隊成員多，如何在傳統項目管理和敏捷間尋找平衡?
理論要點：
1. 不能無規則的敏捷。要用敏捷項目管理方法，必須先很好地掌握傳統項目管理方法。
2. 收集需求。需要更仔細地收集需求。注意多召開跨部門、跨專業的引導式需求研討會，注意邀請用戶代表參加，注意請綜合素質高、預見力強的人來主持需求收集工作。
3. 小規模全功能團隊。敏捷項目管理方法要求團隊規模小但擁有所需的各工種人員，以便在很短時間內開發出產品原型。這個公司40多人的團隊，規模太大，應該按可以并行的產品模塊把這個大團隊分成一些小團隊(如5-7人組成)。這些小團隊在產品總體設計框架下分別并行工作并密切溝通，開發出作為組成部分的原型，這些原型可以組裝成更大的原型。
4. 迭代期劃分。照理，需求在兩個迭代期之間必須變化，但在同一個迭代期內不能變化。如果在一個迭代期中會發生需求變化，那就說明迭代期太長了，就需要縮短迭代期。當然，也可能是迭代期開始前的準備工作做得很不到位。在劃分迭代期時，要特別注意每個迭代期必須實現的產品功能。產品的全部功能要通過各個迭代期逐漸實現。在敏捷方法中，產品功能通常要串行實現，而為實現某個功能所需開展的工作，通常要并行，以便縮短開發時間。
案例四
我公司作為乙方，用總價合同為某集團公司的某個下屬單位開發信息管理系統。項目在實施過程中發生了多次需求失控的情況，都是因為在向有關專家和領導進行階段匯報時，他們提出了新增需求模塊。第一次匯報會，從原來的8個需求模塊增加到20個。第二次匯報會，又增加到40個需求模塊。作為乙方，我們要協調這十幾位專家和領導的意見，實在太困難了。
理論要點：
1. 合同類型。像這種需求很容易變化的項目，本來是不應該簽總價合同的。如果不得不簽總價合同，最好分階段簽，或在合同中約定什么情況下應該如何調整合同價格。
2. 溝通管理。從情況來看，似乎與這些專家和領導的溝通太晚了，太被動了。建議把階段末匯報改為階段開始之前匯報，這樣就更主動，而去可以讓專家和領導體會到你對他們的充分尊重。階段前會議旨在明確需求，階段末會議旨在確認需求的實現情況，而不是提出新的需求。必須通過制定會議議程來限制會議內容，防止會議內容失控。
3. 干系人管理和收集需求。可以看出，乙方的干系人識別工作做得不夠到位，沒有把這些專家和領導列為重要干系人，并盡早收集他們的需求。在項目管理中，很強調盡早盡可能全面地識別干系人。
4. 風險管理。對于專家和領導提出的需求變更或增加，乙方必須從風險管理的角度來分析可能對項目的影響，并結合自己的風險承受力和風險臨界值確定應該采取什么風險應對措施。如果需求變更或新增所導致的風險會超出自己的承受力，就堅決要求甲方辦理合同變更手續。如果低于承受力但高于臨界值，就可以不辦合同變更手續，但乙方自己要采取一定的措施來應對。如果低于臨界值，就可以簡單接受需求變更或新增。
案例五
為某省交通系統政府機關整合五大業務信息系統，以方便數據錄入、審批，以及調閱與查詢。總價合同，合同期1年。項目執行過程中發現數據錄入者、審批者和調閱者的需求存在嚴重矛盾，如錄入者想要有關領導承擔審批的責任，但有關領導卻只想調閱，不想做出明確審批。還發現相關法規變化太快，以至于在執行過程中不得不為符合新頒布的法規而進行額外的工作調整，導致工作量大大增加。
理論要點：
1. 收集需求。項目的三級用戶之間的需求矛盾，應該是在項目開始之前就能夠預見到的。對同一個系統，不同的用戶有不同甚至矛盾的需求，是非常正常的。項目經理必須分別了解他們各自的需求，然后分析這些需求之間的一致性和矛盾性。對于矛盾之處，必須召集他們一起討論、達成協議，也許可以用折中的辦法來處理需求矛盾。例如：將需要領導審批或同意的部分，以“No Objection (不反對)”替換，既能滿足政府機關對辦事流程的需要，又能使責任主體不能推卸責任。
2. 明確項目范圍。必須明確項目范圍只是把本來用傳統的紙筆方式進行的業務流程電子化，而不包括為甲方制定新的業務流程，也不包括修改已有的業務流程。如果要包括后兩部分工作，合同就需要簽成另外的樣子了。
3. 分階段進行。考慮到法規變化快的風險，就要盡可能縮短工期。如果實在縮短不了工期，就應該設法把整個項目分成多個階段，并按階段簽署合同。要設法使這種分階段有利于實現領導關心的利益。例如，可以在第一階段先搭好系統的總體框架并以適當方式發布，讓大家看到項目很快就做出來成果。這樣，領導也會覺得很有面子，相關部門和人員也更容易支持項目。
