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

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

幹嘛要看著後照鏡開車?

  下面是一個常見的專案規劃，專案的負責人把所有工作用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

你在找聖杯嗎？

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

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

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

三個打破穀倉、突破專案困境的方法

幾十年來台灣的經濟支柱多以製造業為主，大部分公司常是以功能性的部門(Functional Departments)做為其基本的組織架構。 比方說公司內可能會有業務部、設計部、工程部、生產部、會計部、或行銷部這樣的單位。 專長類似的人被聚集在相同的部門中，部門中每天則大多做著重覆度很高的工作。 比方說生產部每天忙著加工產品、業務部的人則每天跟客戶聯絡、拿著型錄拉攏生意、試圖談妥訂單等。 但是，隨著商業活動複雜度越來越高，服務、研發、創意、或是需為客戶量身打造的東西越來越多下，工作變得難以獨立切割。 產出物的流程也不再只是部門內自己的事務，而是必須走出

流程系列一之 只是好吃還不夠

之前我上班的附近有間小吃店，店裡賣的是魯肉飯、炒麵、炒飯、豬肝湯那類菜色。 說起來其實並不多特別，但是因為那附近很少小吃店，他的一盤炒飯又大約僅是60元上下的價位，加上份量適中口味又還不差，也因此與當時的同事中午常去那邊吃。 那家店東西雖然不錯，我們也從來沒吃到不新鮮的餐點或異物，但這店卻有個問題。 因為中午生意很好客人非常多，幾乎每五次有兩次會有誰點的東西漏掉沒做、不然就是看著送菜的小姐一桌一桌問著：「鳳梨炒飯是你們點的嗎？」、再不然就是明明鳳梨炒飯吃完了，不知道為何卻又做了一份送來。 幾次下來我就好奇，到底這家店發生了甚麼事？ 人多雖然是助長混

Accountability

最近有位待在大陸一間風管工廠的朋友回台灣，於是我們幾個朋友約了一起吃飯。 席間聊到在大陸工作有甚麼是他覺得最辛苦的部分。 他說：「在大陸做事情，吃、住、環境或是離鄉背景都還其次，最讓人頭痛的恐怕是當地的『沒問題文化』。」 「甚麼是沒問題文化呢‧‧‧ 很多人，他們常不管你要求的是甚麼，都是先滿口跟你說『沒問題』。」 「往往搞得你不知道他們是真沒問題，還是只是為了跟你做生意或是取得工作才隨便誇下海口。」 「但不論是哪一個，常常到後面其實都有問題。 而且問題還都不是小問題。」 席間幾位跟大陸市場有接觸的也深有同感，因為「凡事沒問題」這似乎是個非常普遍的一個現

利害關係人管理初探 Stakeholder Management

或許是因為近年來環保議題發酵的緣故，似乎越來越多商店的自動門不再用感應器來開啟。 很多變成是如下圖，在開門處多了一個長型的按鈕，一定要有人去按壓這按鈕門才會打開。   資料來源 http://www.w-shield.com.tw  我是不知道別人怎麼想，可是隨著這東西出現的越來越多，對我而言其實是苦惱多於便利的。 一方面是已被自動門該自己會開這種概念給制約了太多年，常常無法直覺得想到還要多按個鈕，以至於會一個人呆呆的站在別人店門口兩三秒，並疑惑著門怎麼沒自己打開。 然後才很不好意思的驚覺是因為自己沒按按鈕。

你該去考PMP嗎？

PMP的認證人數從兩千年後在台灣呈現大幅的成長。 雖然還沒有到達人手一張的氾濫程度，但是從Yahoo奇摩的知識區或是偶爾接到的讀者來信，發現實在有些過熱的跡象。 (雖然目前可能還不到三千人？) 已經開始有些根本沒有考試資格的人誤以為這是個轉職的門票。 加上一些補習班推波助瀾下，讓一般普羅大眾以為就算自己這輩子從沒碰過專案，只要上個課考了試就能當上專案經理。 但實際上PMI(美國專案管理學會)從來就沒把PMP當成一個入門考試，而是把他當成一個參與了一段專案工作後，希望更上層樓，或是有能力轉管理職的一個證明。 這讓人很憂心。 在一些人胡亂的包裝與

水平思考

我之前待過一間軟體公司，曾經有件讓我記憶深刻的事情。 當時的老闆希望製作一份產品介紹的光碟，能在客戶放入光碟時跳出一個歡迎頁面，讓觀看光碟的人可以選擇相關產品的介紹或是短片。 當時老闆交代一名新來的工程師：「也不用弄的多特別，就做個簡單的網站吧。 讓使用者放入光碟時，會自動打開裡頭的網站，然後他就可以點選連結看介紹影片」。 可是那時候Windows一直在改造他的系統安全設定，所以如果有網站是在光碟或是硬碟上的話，系統會跳出一個類似下圖的警語：