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

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

專案的預算與成本管理101

  專案的預算以及成本管理雖然出現了一堆念起來很繞口的名詞，但實際上這些東西都不脫基本常識，大部分是我們在日常生活中就會直覺用到的東西。 只是平常我們直覺用到時，不會給這些東西一個名字，只會覺得事情「就該這麼做」。 確實，事情就該這麼做，日常生活是這樣、專案也是如此。 所以，我這裡用個日常生活的小故事，來進一步說明這些欄位的實質意義。

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

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

幹嘛要看著後照鏡開車?

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

預估不準，但那又如何?

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

PMI的新認證

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

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

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