自我實現的"風險"

十多年前，肥蝦剛轉入金融軟體開發產業，第一個參與的較大型專案是某國營企業的信用卡系統轉置案，負責新系統的客製化功能開發。記得上線的前半年，心中總是擔心系統晚上批次作業會掛掉，針對修改的程式總是一再Review，但是半夜被叫去資訊室的機會還是常常；後續也許是系統穩定了，也許是不那麼在意了，反而半夜被call的機會變少了。

記得心理學上有一個自我實現預言(Self-fulfilling Prophecy)的理論，定義為：「the case whereby people (a) have a n expectation about what another people is like, which (b) influences how they act toward that person, which (c) causes that person to behave consistently with their original expectations.」這不禁也讓肥蝦想到那痛苦的莫菲定理(Murphy's Law)" Anything that can go wrong, will go wrong"。如果把這兩個定理合起來，好像變成肥蝦在管理專案風險時常發生的慘劇－" the case whereby people (a) have a n expectation about what a problem may be happen, which (b) influences how they act toward that problem, which (c) causes that problem to happen consistently with their original expectations."

針對風險這個名詞，雖說PMBOK或一般管理書籍把它視為中性的名詞，即表示它可能是個機會或是個危機，反正不確定性造成專案變化的都是風險。但是，可能案子作久了，再加上肥蝦杞人憂天的天性，總是先想到那不好的一面。

在進入專案之前，預估可能風險是非常重要的，尤其是可能導致專案阻礙或失敗的風險類別。肥蝦習慣上會就個人的經驗與瞭解，努力獲取所有可獲知的訊息去瞭解專案可能的風險，並找三、五個重要成員大家一起集思廣益，先看看案子可能遭遇的問題，然後再找業務來問問看這個案子。說也奇怪，業務老是想的都是那opportunities的風險；執行人員想的都是threats的風險。身為一個PM或Functional Manager一定是要平衡去考量正負兩邊的風險(問題是大老闆都喜歡只聽opportunities，搞得肥蝦在老闆面前老像隻烏鴉，在團隊同仁面前像個聒噪的喜鵲)。

接著，是再進一步確認導致風險發生的可能機率，針對高層次的風險類別，在進而探討其中的可能風險因子(risk factors)，以及其間的相關性，並設定相關的警戒線。然後大家再一起來討論因應的對策，決定是否要採行先期的相關作業。也許肥蝦的方式比起PMBOK的順序與流程有些差異，這是因應肥蝦所處的窘困環境，如果有足夠的時間與相關資源，能照著PMBOK這樣一步一步來當然最好，但是在資源及時間有限的情況下，只能作些不得不的取捨。

對於threats，團隊總會想些與作些工作來避免或轉移，如斟酌合約的條款，設計適宜的架構或採行對應的開發方法。而團隊所衷心期盼的就是不要發生；但這十多年的經驗，發現要是愈縈繞在腦中，念茲在茲的問題，並且時刻警醒要避免的，還是會發生。

可能肥蝦碰到的專案環境可能不太成熟，每次問題真得發生了，當跟當初想得差不了太多，雖然會慶幸早有想到，也許也有些因應的方法，但還是多少會有些人仰馬翻的場面。更慘者，有時還像批評得像是田豐一樣剛而犯上的黑五類。這些苦境對應到了自我實現預言與莫菲定理，真讓肥蝦有時候懷疑起自己，是不是因為為了怕專案的不測，特別考量相關風險類別與因子，進而採取相對應的步驟後，才導致不想面對的問題真得就發生了！

俗話說：「傻人有傻福。」但真得可以裝傻就避過那些風險與問題嗎？是不是遮起眼睛，看不見就真得碰不到？還是時到時擔當，沒米就煮蕃薯湯？唉！尤其在跟高層說明之時，這感觸更是錐心刺骨的疼痛呀！

專案vs.營運的流程建構差異

PMBOK或一般專案管理的教科書一直告訴我們，專案有兩大特質：臨時性(temporary)、獨特性(unique)。也強調了專案(Project)與營運(Operations)的重大差別。那在達成臨時性與獨特性組織目標的專案程序，以及在match組織的宗旨、方向與目標所為一般日常營運所需的營運程序是否其間有所差別呢？


記得十多年前肥蝦剛從中正畢業去應徵7-11的大專培訓人員，結果一直沒有訊息，直到三年後突接獲7-11的通知希望我去面試，記得面試當時面試官特別說明他感謝7-11的人事部門XXX，因為當初我以碩士應徵大專培訓人員所以資格不符就未獲通知。三年前，肥蝦主導一個產品開發的專案，上司塞來了一個xxx人，老闆的理由是：「xxx不去你那，那也沒有別的地方可以去了，你就看看要如何用他吧！」


為了完成目標，不管有意無意、有知無知、有章無章，總得一步一步作來，這每一步可說就是程序，當然程序有很多的定義(可參考：http://www.sei.cmu.edu/library/assets/process-pro.pdf)。就以肥蝦的認知：在工作領域中，經由有效的組織資源，採行一定的方式，從事特定的活動，達成期望的要求，這就是所謂的程序(Process)。進一步將程序適當的串連就成為我們常碰到所謂的流程圖(Flow Chart)；在IT的UML圖中分析Behavior的也有Activity、State Machine、Sequence等的Diagram；在PMBOK也有work package、Activity到Project Schedule Network Diagrams。

肥蝦就自身的經驗來看，程序與流程在專案與營運中最大的不同來自於專案獨有的特質：臨時性(temporary)、獨特性(unique)。


(一)臨時性(temporary)所導致的差異
不管原先的程序思考多麼週全，程序內容多麼詳盡，程序介面多麼明確，進出條件多麼特定，人員要求多麼確實，防呆機制多麼完備，流程的持續與定期改善，是維持流程符合並促進目標達成的不二法門。但問題點在於您是否有足夠的時間進行調整與改善，甚至挽救？專案的執行在時間上有一定的緊迫性，重新施作的成本也多半非常高昂；相對地，企業營運雖有有相關的問題，但多有在重覆施作的可能。


在於資源的取得、訓練與適用，專案也承受較大的時間壓力。專案資源的取得應設法儘早規畫，但等到要劃下去之時，常會碰到相當的阻礙。所能獲取的人員與資源經常在組織部門的分派下，少能盡如人意，就像肥蝦剛開始舉的例子，「你就看看要如何用他吧！」如果碰到願花錢的老闆可能就專案流程的特性招募特定符合的人員，不行的話也就只能將就，能練盡量練，人不能轉也就只能"路"轉囉；但是企業營運所可進行較縝密的挑選，也因為工作職務的內容與分派多有明規或暗例，企業可進行有計畫的招募與訓練。


企業為一法人，理論上是要長久經營；但是專案確有明確的結束時點，也因此讓組織高層對於專案的投資傾向於保守。不管專案或企業營運，所要達成組織的目標大都是有多元性的：市佔率、獲利率、人員流動率、成本效益比、現金流量狀況、營收比、無形的聲譽、…，這都需要整合考量，但大多而言，專案在於組織之下，決策者與資源掌握者均為組織高層，其思考觀點一定是從組織、從長遠進行思考，而非是專案性與臨時性的思維。


(二)獨特性(unique)所導致的差異
企業營運要符合整體組織的目標，因此程序內容有一定的穩定性，遇到外在環境的變化之時可以有較多的因應與應變時間，因此標準化與防呆機制可以進行較多的要求與協助；相對專案的程序，就必須需要多一點人為的判斷，尤其是關鍵路徑上的程序，更是必須小心謹慎，在風險因應流程的決策上，專案更需要有明快明確的回應與處理。


專案的A unique product, service, or result多是明確的概要載述於合約或者是Project Charter，在Scope的界定之時，專案經理的職責之一就是因應專案成本、時間、品質等限制，還有公司所要的獲利，將需求者或利害關係人的要求聚合到合約的明確條文。不同於企業宗旨與目標，尤其是乙方，這一專案目標是否要盡善盡美？是否要永無止境？答案當然是不可能的。如果在一組織中所執行的專案獨特性(unique)又真得難以整合或分享，那A unique product, service, or result的達成也許只要符合標準規範就好，作得太好也許反而會有意想不到的反效果。


(三)臨時性(temporary)加上獨特性(unique)所導致的差異
就PMBOK與專案管理的要求，Lessons Learned Documentation 可使組織後續的專案在規畫、執行與監控上有更多的參考與資源，減少更多不確定的風險，降低專案的成本。但隨著不同的專案的性質、屬性、期限等不同的差異，尤其是人跟錢的差別，很多原先的參考或工具可不能抄著來用，那反而會畫虎不成反類犬，自掘死路。因此要使用組織非強制性套用的Lessons Learned，得要審慎的停、看、聽、聞。


一般而言，在一個組織會有多個專案的情形下，組織會為了發揮最高的資源效益，並努力減少成本下，單一資源或人員可能會指派到不同的專案，身為一個專案經理依照PMBOK所指示的，專案目標應緊密的與組織目標結合。套句肥蝦最喜歡的法令條文：「…謂以營利為目的…。」如果再加上企業為了市佔不得不以紅海戰術，以及整體環境因素，一個有良心的專案經理就真得在「使用合約金額扣除公司要求利潤與管理成本的餘額資源，盡量使用組織現有的人力，設法達成符合合約條文設法緊縮解釋的明確規範，去進行專案流程與資源安排的規畫。」