預估不準，但那又如何?

上次提到，專案計畫書中包含了我們打算怎麼作這次專案的詳細內容。 所以計畫中除了管理流程，專案的「交付標地(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, sta

你在找聖杯嗎？

隨著組織的擴張，通常組織中既有專案會加速增加其複雜度。 不單同時執行的案件增多、每一案件的範疇可能增加、客戶在技術或品質的要求會越來越嚴苛，但很遺憾的是案子執行的時間與成本卻未必會對應上升。 而有趣的事情是，組織對於專案管理上的成熟度，幾乎都不會跟隨著複雜度的增加而自動同步提升。 甚至很多時候，組織會被複雜專案牽扯而變得越來越混亂。 這是因為大部分的組織，當面對複雜的專案環境時，並沒有從基礎來檢視如何改進專案的做法，多是以疊床架屋(如，當狀況複雜時，就多加個一兩個職位，或特別成立一個部門或小組；但這些職位與小組常沒有從全面來做思考，它們跟原本的架構

流程系列二之 讓團隊自由的基礎

兩周前，我們談到了流程的標準化對於商業行為的長期運作的重要性。 甚至只是間小吃店也是一樣，因為若缺乏這東西的話，混亂、錯誤、衝突、與失敗就很可能出現在日常工作中。 但若回到以專案為主體的工作環境，相同的概念卻好像並不那麼容易可以帶入？