最新文章

預估不準,但那又如何?

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

你在找聖杯嗎?

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

專案管理的用處何在?

曾經在一本理財書中讀到,當你聽到菜市場裡的人都在談論股票時,也就是該退出股市的時候了!近幾年,周遭的親友,不管是保險業的,大陸台商,還是藝術工作者,都不約而同聊起了專案管理,有的甚至還打算去考PMP(美國專案管理師)認證,我心中突然百感交集,想跟各位聊聊這個現象。