1-5, 堅持到底，就看到勝利!?

(前情提要) Eric在會議上使用造假的方式順利的讓大家相信進度順利這件事。 老闆還跟他大力的握了握手說：「這新部門的第一款作品就靠你啦!!」 講的Eric不知道是該高興還是該擔憂….. ---- 會議順利過關後，Eric算是鬆了一大口氣。 但他也很清楚知道，更大的挑戰隨之而來。 畢竟原來合約抓的Schedule就已經很趕，就算是正常狀況恐怕都讓人有些擔憂。 事實上之前團隊已經抱怨很辛苦了。 但目前這樣的情形下，不但要想辦法「偽裝」專案進度順利，還得在不被上頭發現的狀況下重新設計。 這極度耗損人力不說，得壓著團隊每天加班，而部分元件得另外發包，成本控制也

用Outlook來做「協同合作」(一)

當進入專案管理這領域並開始摸索一些技術上的東西後，一般人往往立刻苦於沒有工具可以配合應用。 當然，如Microsoft Project 或是 P3這類系統雖然都很專業、也確實廣為大型專案所應用，但對於一些小案子的負責人而言，排程的需求其實並不高。 這是因為很多小案子的工作之間關聯性其實不多、或說就算有也都還「勉強」可以靠人力掌握、網圖並不複雜。 加上這些小案子未必有嚴謹的合約關係、沒有業主或是其他介面單位，因此CPM的幫助其實也不明顯。 所以，真正讓很多小案子的負責人所困擾的反而不在排程，而多在於工作分派、與其他人溝通、分享訊息、議題掌握、進度追蹤等等所

1-4, Marriage

在我們繼續Eric的故事之前，還有一件事情想聊一聊。  看了上禮拜的文章，可能有人心裡會有嘀咕想說：「偷偷改規格或許是罪大惡極，但如果只是讓案子盡善盡美呢？」「追求盡善盡美有罪嗎？ 幫專案加分需要被人管理嗎？」 嗯，這問題看起來也滿有道理的不是？ 我們設定一個情境好了。 假設我參與一個網站設計的專案，我負責版面的配置。 我在安排版面時，發現客戶送的文案寫得很爛。 我可以「為了他好」自己幫他改寫嗎？ 看了上次那篇之後，大家應該知道這是不應該發生的。 就算他寫的爛，也不表示我可以自作主張的把他文字內容改掉。 畢竟改了文字描述後，搞不好他想表達的意思

1-3, 到底是誰害的(下)

(承前文) 故事繼續之前，我們先來聊聊到底是怎麼讓事情變成這樣的吧。 到底誰是壞人呢… 是Eric嗎？ Well, 雖然Eric因為沒有誠實面對造成一些問題 - 從一開始他因為恐懼所說的小謊(跟老闆說很容易就能解決)，讓他之後騎虎難下而沒辦法坦然面對真像。 不斷的繼續做假，才造成整個狀況惡化至此。 這部分當然是有他的責任，但卻不是我最想要談的東西。 一來，我並不打算從道德的角度來看這件事情，畢竟若故事講了半天只是宣導人要誠實，也未免太八股太無趣了吧? 我還不如直接貼華盛頓砍櫻桃樹的故事，最少不用自己寫的累得要死。

1-2, 到底是誰害的 (上)

說起來，還有人記得可憐的Eric嗎? 他曾有個專案因為一開始的定位不清，以至於後來花了很多時間累得要死卻只落得被罵的下場。 但自從那次血淚的經驗後，Eric學到教訓，並決定之後所有的專案他都要好好的準備個詳細的Project Charter(專案授權書)並取得高層的認同與授權。 他想，應該可以從此脫離悲慘的命運吧。 如此，又過了幾個月。 這次，他被授權帶領一個全新的案子。 他們公司其實一直都不大，之前大多是幫手機廠接單做些小開發或小設計。 幾年前雖然想弄些自有品牌的東西，但其實一直沒有明顯的成效。 而在新總經理上任後，更開始想嘗試些不同

1-1, 功勞 苦勞

會議室中一片寂靜 所有的主管眉頭深鎖，盯著台前的總經理；他正用著誇張的手勢大聲的責罵著所有的人。 台下的一位專案經理，Eric幾次想要開口反駁，卻都因為不知道怎麼清楚解釋這一切的來龍去脈而只好作罷。 畢竟台上總經理指責的都不能說有錯，確實案子Delay嚴重、甚至嚴重超支。 但Eric卻不認為自己有做錯，只是在這當下卻完全無能為力。 只好憋著臉握著拳頭被挨罵。 上個月初，N公司在前任總經理退休且新的總經理上任後，在一個月間所有的專案都被拿出來檢討。 而今天則是總檢討大會，所有的主管都列席，低著頭聽著新任總經理生氣的訓示大半個鐘頭。 N公司

夫將者，國之輔也

孫子兵法理頭開宗明義的第一段寫到： 「兵者，國之大事也；死生之地，存亡之道，不可不察也。故經之以五，校之以計，以索其情。一曰道，二曰天，三曰地，四曰將，五曰法。道者：令民與上同意者也；故可與之死，可與之生，民弗詭也。天者：陰陽、寒暑，時制也。地者：高下、廣狹、遠近、險易、死生也。將者：智、信、仁、勇、嚴也。法者：曲制、官道、主用也。凡此五者，將莫不聞；知之者勝，不知者不勝。」 這段的大意是說： 決定戰爭勝負有五個要素，分別是「道」、「天」、「地」、「將」、「法」。 「道」指的是「上下同欲、君民一心」，方向集中才能同心協力。  「天」指的則是「

不能心電感應，所以這麼做.. (圖多)

之前提到人與人之前無法透過心電感應互相察知彼此的意念，以至於知識無法快速轉換、想法與心意也很難透過語言來溝通；而各類誤解與錯誤更可能在言語溝通中產生。 但饒是如此，專案還是得做，我們終究希望能把心中美好的概念、設計、與構思在世人的面前展現，至於無法心電感應下意念整合與理解的困難，則要想辦法排除…… 我這邊處的公司是一個完全專案導向的產業，所有的商品都有高度的不確定性、時間性、以及需要大量的人力投入。 但在這樣複雜且動態的環境下，我們如何確保橫向的溝通與連繫？ 尤其如何確保所有溝通路徑能在動態變動的環境下沒有斷裂並能確保同

如果我們都能心電感應多好？

人類間語言的有限性也常常讓人深感挫折。 會議就是一個例子。 常是大家熱熱鬧鬧、興高采烈的討論了一堆東西。 但離開會議室後，往往沒人知道具體結論是甚麼，或每人其實都有不同的解讀。 以至於「很有共識」的會議開下來，最後卻常沒有各自以為是共識的成果出現。 另一個狀況則發生在事情爭議性很高、而立場很難黑白分明時。 人一多時反而無法暢所欲言，官樣的文章談了談最後問題一樣無法解決。 所以相較於很多人喜歡開會解決問題，我反而老有開會很難解決問題的感覺。  

幹嘛要看著後照鏡開車?

  下面是一個常見的專案規劃，專案的負責人把所有工作用Excel列出，並定出他覺得可行的開始與完成時間。   (表一，某專案的作業清單) 假設今天的日期是九月十日。 透過上圖可以看出，在紅線上面(也就是九月十日之前)有四個作業的開始日期或結束日期跟預計的時間有所出入。 因此，在這組織裡頭的高階管理人員可能會要求專案經理針對這些作業的延遲做出報告，給與每個延遲的理由。

預估不準，但那又如何?

上次提到，專案計畫書中包含了我們打算怎麼作這次專案的詳細內容。 所以計畫中除了管理流程，專案的「交付標地(WBS)」之外，當然也會要求團隊一起思考如果這些「交付標地」必須要達成的情況下，我們這次到底要做甚麼、怎麼做、誰來做、並花多少時間來做。 就像爬山計畫書中我們得評估這次要爬到哪裡，是山頂還是山腰？ 如果是山頂，那路線會是哪一條？ 如果要走這條路線，我們需要哪些配備、帶多少數量的食物飲水、又每個定位點間我們大概要花多少時間。 也因此整個登山計畫的過程中，預估(Estimation)會在其中扮演一定份量的角色。 食物的量是預估、水的消耗量是預估、路

PMI的新認證

這兩天注意到，美國專案管理學會(PMI)除了原本的CAPM、PMP、以及pgMP以外，最近新增了稱之為「PMI-SP」這樣的認證項目。  PMI-SP呢，是Scheduling Professional的縮寫。  是個在「專案排程」上的一個能力認證考試。 看到這東西，可真是讓人拍手叫好；我個人真是樂見這東西的出現。 如我之前提到，一個讓我持續困擾的問題，就在於過去PMP認證的領域太廣泛了，以至於很多之前考過PMP的人其實並沒有排程的實務經驗，排出來的Schedule幾乎是慘不忍睹。 要重頭教起，很讓人頭痛。 (都怪Microsoft

流程系列五之 專案流程的重點在管理而非方法

之前寫到專案性質的工作應該分三種流程來看待 1. 專案管理的流程 (要怎麼管) 2. 管理支援之流程 (特殊事件怎麼處理) 3. 產品導向之流程 (要怎麼做) 前兩者是可以標準化，也是提升組織管理成熟度一開始該做的部分。 但產品導向之流程，也就是案子的實際施作方法，則會因為每次案子的需求與差異，可能有極大的變動。 若想一下子標準化常是不切實際的，所以並不需要勉強在這部分打轉想做成SOP。 但雖然不需要勉強把施作方法建立成SOP，可不表示施作過程不需要被描繪。 反而就是因為專案變化多端的特性，反而應當在「每次專案開始前」做一次完整的構想，並把我們接下

流程系列四之 如何撰寫真正有用的SOP

上周提到，在製作標準化的流程時(也就是SOP)，我個人建議把握下列幾個原則： 1. 架構應由粗到細，由上而下 2. 清楚易讀 3. 每一步驟的介面切割清楚，定義明白 4. 日後好管理 5. 防呆設計 而上周談了第一項，也就是SOP制定及思考時，我們應從抽象的架構開始，然後逐漸往下展細。 這意思是說，不需要勉強把所有的細節、判定、負責人員、甚至說明都要在一張圖上表達。 畢竟都放在一張圖上雖然很完整，但是相對東西多時將很嚇人，對於溝通或是概念傳遞這目的而言，反而未必有幫助。 很可能會讓第一次接觸的人在面對眼花撩亂的資訊時整個傻眼，更別說還能理解到底實際該

流程系列三之 撰寫SOP的原則

前兩周提到，我們談到流程規劃時可以大略的分成「一般性的產業」，或是「專案導向的產業」來做思考。 因為在面對這兩類產業中，我們對於流程的定義很可能會有些不同。 在前者，我們應定義「產品導向的流程」(怎麼做)以及「管理支援流程」(碰到特殊事件該怎麼辦)；而對於後者，我們則增加了「專案管理的流程」(專案進行中我們怎麼管，以及可能會動用到哪些流程)。 那在接下來的兩周，我們或許先來談談一般性流程的製作原則；這議題談完後，則再來談談專案性質產業流程的製作與管理。 一般性的商業活動，大多重複性高。 也因為重複性高，才有制定成標準作業程序(SOP, standar