PM Network Vol. 23, No. 4, Page 53-57.
本篇文張舉出了五個會嚴重破壞專案團隊的五種狀況─(一)失控的會議。(二)隨機變更專案的方向。(三)利害關係人的過份需求。(四)未預期延遲。(五)專案人員的爭執。─這種情況在肥蝦的專案經驗中其實常常遭遇，對於專案的進行，以及專案成員間的和諧，真得有莫大的衝擊。文中提供了一些實務的經驗予讀者分享，個人認為非常具有參考性。因此肥蝦特就文章內容，並對應個人的經驗，分述五種情況的核心，以及可能有效的建議。
(一)失控的會議(Out-of control meeting)：專案從啟始到結束總有不斷的會議要開－kick off meeting, group progress meeting(Daily), status review meeting(weekly, project performance report meeting(monthly), change control meeting, project management meeting…。但經常都是流於形式，參與者大多不知道會議的目的與要求；或是成為長官單向佈達的會議，無法真正的有效溝通，更進而長官們厭倦聽到問題；簡報的資料一再重複，會議資料與實際狀況嚴重脫節，無法真正的反應現況，更進而專案經理或長官玩起數字遊戲，藉由變更計算方式粉飾太平；與會人員雜亂，主題失焦…。這種種的會議惡象，我想很多人都有經驗。
在本文中提供了一些方法試圖杜絕上述的惡果：(1)聚焦：每個會議必需有確定的目標與議題，切忌離題。(2)慎選與會人員：會議人數應適當參與人員須對會議主題有明確相關。(3)訂定基本規則(ground rules)：遵守既定的規則獲取與會人員以及未與會人員的信任。(4)限制會議時間：會議應有明確的起始與結束時間，冗長的會議徒使與會人員喪失注意力。(5)確保會議是雙向(上層與執行者)有效的溝通。
(二)隨機變更專案的方向(Seemingly random changes in project direction)：專案管理計劃最重要的是標明what、when、how、who (why基本上會建議寫在project document)去執行一個專案。因此專案的目標必須非常明確；標明每個特定區間與milestone的重點，專案成員才有依循的努力方向。
但是專案的本質就是【變化】，在遭逢無法避免的改變下，惟有開誠佈公的跟專案團隊說明變更的理由，大家同心合意下，才能化解因為專案方向變更，所導致成員戰鬥力的衰減。試想，如果專案方向經常在成員無法獲知、無法理解的情形下變更，專案成員將會如何迷失工作的方向，喪失鬥志。當一個人不知道今天或以往的努力是否有效的情況下，誰願意去努力達成目標。
(三)利害關係人的過份需求(Overly demanding stakeholders)：在專案的進行中利害關係人(包含使用者或客戶或公司高層)常會無端的加進很多臨時的要求。這不只發生在客戶身上，更常遇到的狀況就是公司內部的高層，常會為了某些理由(如公司管理…)要求專案成員提供相關的資料或報表，更可悲者，還會限定交付時間。
一般的情況下，每個成員在瞭解專案的目標與方向下，大多會擬定每日的工作進度與內容。突然安插的要求，常會導致成員淪落於疲於應付非專案主體的工作。此時專案經理必須有所擔當，除了建立一個暢通完善的溝通管道與流程，應將要求記載於書面，獲致正式的同意，按照標準的作業流程處理；對於不合專案目標的要求，應該要明白的向要求來源陳述事實跟現況，爭取有利與合理的作法；對於不可避免的要求，也要向成員坦誠的溝通，獲取成員的支持。
(四)未預期延遲(Energy-zapping soul-sucking unexpected delays)：專案的任何計劃均無法保證百分之百無誤，難免會有疏漏或執行上有所錯誤，進而影響專案的時程。因此最重要的處理方式就要是向成員充分的揭露，發現問題，戮去解決，保持專案不斷的往前進行；而不是去找個替罪羔羊，想個卸責的藉口。因此在遭遇某些問題或發現疏失，第一步是要向成員主動的說明。再來，就是與團隊中的相關人員商討解決的辦法，凝聚團隊的共識，朝向克服問題與達成專案目標前進。
(五)專案人員的爭執(Team squabbles gone awry)：專案團隊間常會諸多因素引起爭執或紛爭。雖然PMBOK說明要求爭執的雙方先行協商合解；如果無法獲致解決爭端的方法時，再由專案經理介入。但在本文中要求專案經理應立即安排面對面的會談；如果無法解決，接著是專案經理與爭執的雙方依序的一對一面談；如果確定爭執雙方無法在一同合作之時，專案經理應透過上層管理階層留下對專案有較大的貢獻者。
針對上述五種情況，肥蝦認為主要可歸類於專案的溝通管理(失控的會議、隨機變更專案的方向、利害關係人的過份需求、未預期延遲)，以及人力資源管理(專案人員的爭執)。由於專案的本質就是要集聚特定人員與資源的力量，處理變化難測的狀況，達成既定的目標。因此對於專案團隊、公司內部以及客戶，首要的是建立"信任"的關係。
如果客戶能相信您與所有專案成員，都是為了建置一個為客戶設想的系統的前提下，對於雙方的溝通奠定穩固的基礎，在共通的基礎與限制上，雙方才能進行折衝商談，共同追求一個較佳的解決方案。肥蝦至今的經驗還沒有遇到一個案子，客戶擺明就是要您掛掉的狀況。一旦專案無法完成，不只會對vendor side造成傷害，對user side也有一定程度的損失，惟有設法使客戶認清這個事實，才可以有效減少客戶過份的要求。
在公司內部的溝通上，也是如此一旦公司上層懷疑或認定專案出現問題，上層主管將會不斷地想探索專案團隊，甚至每個成員，每天的工作內容與進度。如此一來專案成員會光填寫報告與進度回應將浪費掉無數的寶貴光陰，進而使專案停滯不前。坊間很多專案管理的工具或方法論，但實行的結果往往本末倒置。原本為著加速與方便控管專案的管理流程，反過來變為成員每日的主要工作。因此專案經理應設法強化公司與專案間的溝通，扮演一個折衝的角色，必要時應坦白的向上層反應。說句實在地，如果上層執意如此，並可預知將造成團隊的生產力與士氣蕩然無存，與其委曲求全，不如另謀他路。
至於處理專案成員爭執的作法，每個人基於自身的經驗與瞭解有著不同的作法。個人能認同文中所說：「專案沒有時間可以浪費。」因此先由爭執雙方自行處理可能無法獲得滿意的答案。以肥蝦個人的經驗，會建議由專案經理與爭執雙方一同與會討論。但是會前專案經理應設法私下分別與爭執雙方以及相關的周遭成員討論，設法釐清爭執的"起源"－工作界面不明、專案資源爭取、或個人情緒問題…。不同的爭執原因應有不同的處理方式。如果是雙方個人情緒上的問題，已經無法排解，我會建議如溫伯格(Gerald M. Weinberg)在"從需求到設計(Exploring Requriements )"乙書中所說的讓雙方都離開團隊，以免可能造成留存的人自大的心態。
文章定位：
