"專案經理"與"業務"在專案中的互動與衝突！

參與資訊系統建置專案多年，從一開始的程式設計人員、系統分析、掌控專案實際運作、配合業務爭取案子，其中的歷程、心得與角色衝突點滴在心頭。台灣的資訊環境暨所衍出的專案型態，與國外一般的專案管理存在著些許的差異！
在PMBOK第四版中對於溝通管理的架構有些許的改變－專案初始時期的” Identify Stakeholders”；在規劃階段的” Plan Comunications”；在執行作業的” Distribute Information”與” Manage Stakeholder Expectations”；在監控作業的” Report Performance”－在在說明一個重點：Their interests, involvement and impact on project success.
在一般專案管理書籍，甚少談及”專案經理”與”業務”之間互動。因為兩者多屬不同部門、績效考核方式不一樣，因此之間多存在些許的誤會與衝突。
這裏先不討論公司的文化與制度的影響，僅先就專案的執行面來討論！
我相信每個參與專案的人都會聽到很多的抱怨。「業務怎麼老是接賠錢的案子，到底業務是我們公司的人還是客戶的人？專案經理什麼都不懂，老是規劃出無法達成的milestone。」工程師說；「工程師永遠都無法溝通，每次討論都說問題一大堆，到底他在想什麼?專案經理無法掌控成本與時程，老是賠錢？」業務說；「業務承接的金額根本無法完成合約要求；工程師素質太差，無法如期完成專案」專案經理說。
這些報怨的產生均出一個共同點，『眼界僅限於當前工作的思考。』之前我常常跟我合作的夥伴說一句話：「當我們作程式設計人員時，要有系統分析師的眼界；作系統分析師時要有專案經理的眼界；作專案經理時要有公司管理的眼界。」意思就是要突破您的思考巢柩，從「本位出發，從上鳥瞰」。如果我們平心的先辨別出”專案經理”與”業務”的基本出發點，就能體會彼此的無耐與心聲。
業務人員的工作其實並不輕鬆，如何要對方簽下契約，心甘情願的拿錢，作一個未來可能不能滿足實際要求的作業系統；專案經理也不容易，配合業務所拿到的價錢與合約，專案範圍與時程根本很難達成！
業務人員首要的工作就是要專案能成立，那專案經理才有案子可以作；專案經理要設法達成預算與合約限期，但兩者的目標都是”收錢”。在這共同的目標下其實是可以有效合作的！最重要的要訣在”袒誠”的溝通與配合！
在專案成立前，專案經理應就金額與範圍給予業務就客戶的要求，給出”沒問題”、”口袋名單”、”地雷區”的三大清單。在專案未開始前，客戶期望中大多只要求”要有”，但要到什麼地步，其實還沒有具體的說明，因此如何拿捏合約的內容與字句！業務需要專案經理的全力協助與配合。
在專案初始與規劃階段，。專案經理要把合約金額、時程與特定重要利害關係人的期望，當成最大的風險要素來考量，針對某些減緩或避免策略，請業務協助或執行。
在專案執行時專案經理在面對客戶的要求與挑戰時，業務可以扮演一個緩衝的調劑。業務需要適時、適當、適況的不期然出現在某些場合，轉移客戶的目光，達成一定的共識。
在專案監控作業上，業務應本於業務的專業，去探測客戶的”容忍度”。
在專案結案時，那就更要請業務發揮長袖善舞的能力去斡旋。

在這景氣不佳的時期，為了讓自己能存活與發揮，業務與專案經理要更有效的配合，否則真得是沒有案子可以作了！

資深專案經理的建議-"與熊共舞(Waltzing with Bears)"

近日重新翻閱了先前讀過的專案風險管理的經典書籍─"與熊共舞(Waltzing with Bears)"。在這幾年的專案經驗累積與通過PMP的認證後，閱讀起來真是句句經典、字字衝擊內心。
本書的作者是Tom DeMarco與Timothy Lister，譯者是錢一一；作者與譯者均是軟體開發專案的一時之選，雖然有些字語、流程，與PMBOK的定義與程序不盡相同，但是可以互相整合、相互輝映！
本書的架構區分為五大段落：
(1)為什麼要去管理風險－有風險，才有利潤。為要賺取合理的利潤，就必須就承擔合理的風險。
(2)一般遭預抗拒管理風險的原因－風險主要探討失敗的可能原因，一般人已習慣「報喜不報憂」，不喜歡去觸楣頭。
(3)如何去管理風險－反果求因；將可能遭遇的原因儘可能去搜集資料；進行界定(量化)、判別重要性；提出對應的策略；時時監控已知的風險，不斷的探索未知風險；設法提出縮小與解決專案可能遭遇風險的開發方式與作法。
(4)應該承擔多少風險－既然承擔了風險就要獲取應有實際的利潤，不只風險要衡量，利潤也要衡量。
(5)風險管理的實用－檢測現有風險管理的程度，瞭解現行您的狀況。
就筆者觀感，整本書就是告訴讀者：任何事情都有可能遭預一些可預期或不可預期的問題，這是不可逃避的。因此我們要作的是去面對他、去討論他、去衡量他、去記錄他、去監視他、去減輕他、去反省他。書中提出了五個核心的問題─schedule flaw, requirement inflation, employee turnover, specification breakdown, poor productivity，也提出了建議的開發方式─主動漸進式開發方法，以及相關的工具－Earn value running。
一個軟體專案所可能遭遇的問題可概分為技術上(產品)與人為上(專案)，就筆者的經驗，會讓一個專案陷入萬劫不復的地步的問題，大都是專案管理的不當所造成。
就筆者先前參與一個號稱擁有無上經驗的”P”資深專案管理者(以下以”P”表示)所領導的金融系統開發失敗專案為例：
”P”完全陷入本書所規勸、所希望專案管理應要注意的問題，結果五個核心風險一一中的，該專案只有失敗一途。
(1)schedule flaw：”P”以樂觀無比的心情、自任發展的態度，認為深受上天的眷顧，所有風險都不會發生，因此一開始就錯估了時程的壓力，僅把合約的到期日，利用紙上作業，把往前自行推演出各階段的milestone(backward scheduling)。整個專案沒有要徑圖(Critical Path)，僅憑以往經驗，自認所推斷出的時程是無懈可擊。
(2)requirement inflation：”P”由於過份利用利害關係人間的利益衝突，反而導致每個利害關係人堅不讓步，不斷的擴大需求。
(3)employee turnover：”P”自以為擁有完全的know-how，用Frocing面對專案團隊內的決策，對於專案成員所提出但伊以往未曾碰觸的issues，則全部withdrawal，導致人員的異動頻頻。而且招募新血又希望沒有”ramp-up time”，因此人員補充困難。
(4)specification breakdown：”P”最厲害的一招就是閃躲，從需求討論、差異分析，碰到重要的關鍵點就是避而不談，或者推託以後；到了實作階段，自己同意原廠所設定的範圍，到了客戶測試，就全部一次爆發。
(5)poor productivity：專案成員喪失目標，專案沒有進展，心情不斷怠惰，因此績效不斷低落。
本書所闡述的重點，對於經濟本科，從事證券業四年後，轉入從事軟體專案開發的筆者來說，有著深切的體會，書末的參考資料與資訊也深具參考價值，因此與各位分享本書的個人心得，如有任何的意見，還請 不吝賜教。

PMP的到底實用不實用?

昨日公司內部一位J資深經理過來問我有關PMBOK內部所提到的Time reserve如何在Gantt Chart或其他圖形表示？J經理對PMBOK有諸多的質疑，認為PMBOK不切實際！我想這也是許多資深人士的疑惑。

個人以為這是因為我們容易忽略了一個重點：那就是PMBOK所敘述的流程領域與程序是由諸多實務與經驗中萃取而提出的一套方法邏輯，這也是PMBOK於第三章初始就強調的”…The project manager, in collaboration with the project team, is always responsible for determining what processes are appropriate, and the appropriate degree of rigor for each process, for any given project.” 以及在各處中常見的字眼”..but not limited to”。

就以Time reserve來說：PMBOK雖然在Time reserve的說明上比Cost Reserve的說明明顯少了許多，但PMBOK在schedule中強調的觀念在於”activity”的明確定義－要有list、要有attribute。接著要分別出priority，進而估計出所需要的資源與時間。在此處PMBOK強調要回應到Human resource跟Procurement對於資源取得的限制，以及在risk的管理上。經過rsik的分析，參考stakeholders’tolerance(容忍度)，提出response plan後再回頭檢視Time的安排規劃。

Time Reserve是針對”Known unknowns”而產生的，而不是一般上對所謂明確activity在完成工作的可能區間上。在明確的activity duration上，PMBOK希冀我們採用Three-Point Estimates，以避免過度樂觀的估計；對於Time Reserve的估計上，若經過risk的分析後，其所對應的response plan認為需要採用一些activities避免這些risk(如外包或教育訓練)，那就需要將這些activities在納入time的規劃上，而不是提列到Time Reserve。

至於Time Reserve的表示，除了PMBOK所提到的在activity attribute(文件)上表示外，在實務上，如採用MS的project工具那也可以利用PMBOK在cost reserve所提到的contingency activity，而不必拘泥於一定只能表示cost reserve。當然其他可用的方式很多不一定要在PMBOK所列示－”NOT LIMITED TO”。最重要是我們認為合適，並且能把RISK的要點表示出來。如個人會將特定ACTIVITY所對應的風險，在MS Project上新增欄位來表示，對於相關的activities就新增一個contingency activity。至於要呈現給stakeholder那一個時程就要看stakeholder是誰，以及公司與客戶的文化。

個人必須再次強調：”PMP”絕不是一個終點，而是一個起點。把從PMBOK所獲得的觀念，融合已有的專案經驗，檢視以往的專案實蹟；並不斷的自我充實與進修，那才是真正PMP的王道。