企業專案治理

組合管理之 三個關鍵

  上篇提到專案組合管理(Project Portfolio)這件事情,也提到組合管理這件事情需要的是「使命」、「組合篩選機制」、以及「專案監控」三個層面的機制。 「使命」這部分最難,沒有這東西任何管理機制都可能徒勞一場。 但也還好,因為這畢竟不是我們大部分的人能夠去左右的東西,往往是公司的營運團隊會去傷腦筋的事情。 但對大部分人而言,了解組織的最終目標卻還是有必要,畢竟這是一個我們隨時檢視做的事情是否有對應到大方向的一個主要指標。 換言之,這東西確定後,才能轉化成所謂「篩選機制」,也就是用來評量某一專案到底是否值得做

太多領導‧太少管理

我自己這幾年一直有個感覺,總覺得我們的環境太過於著重「領導議題」了。 而且總會在談論這議題時有意無意間把「領導跟管理」拿來比較。 這讓我一直覺得有種隱隱的不妥。 以商學院或是管理學院為例。 通常商學院都會有「管理概論」之類的課題,課程中都會拿「領導與管理」來做分析。 老師上課時,都不免俗的暗示「領導好於管理」。 比方說,會提「領導人代表靈活、有魅力、帶領團隊」;而管理者則在刻板印象中帶有「照章行事、不講人情、always play by the book」的印象。

所謂專案組合管理 (Project Portfolio Management)

這篇也是我在集團內部PMO宣導用的文章。 談的是一個一般人會比較不熟的名詞,也就「專案組合管理」(Portfolio Management)這個名詞。  

PMO使命之 專案成熟度提升

大家或許好奇,到底甚麼是「專案管理成熟度」? 成熟度高、與低又差別在哪裡? 主管常有迷思,以為讓專案成功就給PM上上課就好啦,或覺得成功或失敗都只是PM一個人的問題。 但其實沒這麼簡單,專案問題其實多是系統問題… 本文就要好好談談,到底啥是「專案管理成熟度」…

PMO的目標與願景

這篇也是原本於公司內部貼出的宣導文章。   前篇提到一般PMO的常見目標。 包含「監管專案」、「協調資源」、「統一做法」、「保存經驗」、「開案評估」、「稽核內控」、與「訓練人員」等目的。簡單的講,就是希望透過這些面向的統一規劃來提升整個組織的「專案成熟度」及確保專案順利下能帶給公司營運的成功。 雖然專案管理的概念本身是跨產業的,但在不同產業型態中,關注的管理重心還是有些不同。 比方說,工程營造或國防產業會較在意進度與合約,資源重視材料,但人力投入的統計常相對而言較不重要;但軟體業或是我們這種人力為導向的產業,則會較在意人力盤點、利用率、工時、流程改

What is PMO

這篇是我跟集團內部同仁分享到底我帶領的PMO是個怎麼樣的單位,又在集團中扮演怎麼樣的角色。 雖然版上的一般讀者不是我集團中的同仁,但PMO的功能是大同小異,若你在PMO單位、或是也試著想了解EPM(Enterpirse project Management)的概念者,也歡迎參考參考。 回顧了這兩年來的一百篇,發現我花很多篇幅談專案的技術與做法,也花了些時間談工作態度、談邏輯思維。 但把所有文章翻了翻,發現我似乎從來沒談過最重要的一個議題,也就是「PMO到底是個甚麼單位」。 這還真是我自己的一大疏忽。 運作著這樣的一個部門,但卻絲毫沒有花時間跟

利害關係人管理,在正直VS聽話之間~

這周我與Bryan都在談組織變革與過程中利害關係人管理的問題。 只講好的一面或許太平淡了,所以我打算把這議題弄得更複雜且醜陋些。 談個沒這麼黑白分明的部分...(笑)

組織變革失敗的關鍵原因

看到布萊恩寫的「面對顧問,你該問些甚麼 – 布萊恩」一文,我忍不住很想狗尾續貂一下。 純顧問的經驗我恐怕不如他,但我帶了幾年PMO倒想談談在企業中推動組織轉型的關鍵需求。 不管是內部變革或是外部顧問介入,其實都有著相同能力上的需求,或許能藉此幫忙一些朋友在關鍵時刻做出對的判斷。   中國以農立國,農民靠天吃飯。 靠天吃飯是個很不穩當的行業。 你在春天播下種子,耕耘、除草、施肥,等到秋天收成後才能把投資回收。 農家多是困苦的人家,常見的狀況是秋天收穫的糧食在冬天吃完了,等春耕時期往往家中已經無糧。 所以呢,農民大

創意專案的管理關鍵點

創意與研發畢竟不像其他功能性強的東西。 如果是捷運的話,就算專案過程中別人發展出更好的規格(如速度更快的火車),蓋好了設備也還是能用,不至於沒人來搭。 但創意或研發專案的問題在於,要是這是個爛點子(或是別人搶先做出),就算最後能「即時」且「控制在預算內」的上市,很可能一樣沒甚麼意義。 因為誰也不會多看一眼了。所以這類案子,就算開發過程順利,始終也無法避免中間會出現異聲:「這東西還不夠好,我們還能讓他更好」。

規則的邊界

我在學校時,曾經拿過一堂叫做「Transportation Design」(交通設計)的課程。 所謂交通設計呢,大致是兩個層面的東西。 一個是設計道路的起伏與角度:轉彎車子會有離心力,所以道路若有轉彎時,路面應該以多少角度傾斜才不會滑出路邊是個需要考量的問題。 而起伏呢,則是若在有坡的道路上,若弄得太陡、可能車子會爬不上去,也可能到頂端時不能讓對向車道提早注意到而發生車禍。 所以所謂「起伏與角度」大體是去考慮這類事情。 另一個更有趣的部分,則是設計市區道路的速限還有燈號系統。 這樣講或許很抽象,所以為了便於理解你或許可以去試著想像任何一處你熟

共同經驗讓團隊UP! UP!

前幾天在家看天外奇蹟(UP)的DVD,就無聊點了幕後花絮看看。其中有段是講皮克斯的動畫小組一起到南美洲勘查場景的經歷,覺得還挺有意思的,這裡跟大家分享一下。

變數

記得小時候做自然實驗,老師教的最基本一個原則,就是在實驗中途一次只能更改一個變數。 比方說要想知道「到底是甚麼東西會影響種子發芽」,那可能需要在相同的溫度、天氣、濕度、土壤成份下播種。 然後有些澆水、有些不澆水,有些放肥料、有些不放,有些曬太陽、有些不曬,有些加些奇怪的東西、有些則不加。 如此記錄每項的變化,才知道到底甚麼東西對這件事情影響最大。 若沒有注意「變數」的控制,一次調整太多因素下,就算得出了正確的成果,我們往往也不知道到底是甚麼帶來了豐收的成果;是純粹的好運? 亦或是我們真掌握了某個改良方法? 我後來發現,這樣的概念在「專案管理」還有「事

我的美國之旅 - 紐約市環保署

不知道大家有沒有類似的感覺,越是靠近自己的事務,因為身在其中,反而很難跟旁人說個明白。記得去看變形金剛第一集,我坐第二排,從頭到尾人影晃動,不知誰打誰,只記得Megan Fox修車那段(所以第二集又去看了)。自從06年加入紐約市環保署(NYCDEP,簡稱DEP)這個案子,就覺得這是個難得的經驗,一定要留下紀錄。但轉眼快三年,一直沒有靜下來寫篇文章。實在是因為有種不知從何說起的感覺。 既然這樣,還是先看看統計資料,有個大概的輪廓:

「公有地悲劇」文章的一些討論

這篇是「公有地的悲劇 」那篇貼出來後公司內部的一些討論。 因為BLOG的讀者無法看到我覺得滿可惜的,所以把當事人匿名後在此轉錄。 有興趣的讀者也可以一起討論。 :) ----- 四月06日 C說: 其實關於這個Life Cycle Cost,在軟體開發也有相同的概念,只是我們叫做total cost ownership, tco。也就是說,大部分的user,會將注意力放在很顯而易見的「購入價格」,所以傾向於買便宜的東西,所以最後可能買了一個軟體,很便宜,但是發現很難擴充、或是不穩定、經常當機,而這些當機的處理成本、損失...連同購入成本,

公有地的悲劇

據說在某個高原上有一個小部落。 高原上雖然有著大片的草地,但因為土地很貧脊,每年雨量不充足,所以幾乎種不活甚麼農作物來。 數百年來,居民大都是過著狩獵與採集的生活,這也造成幾乎每一個人家都過得很清苦。 其中有一家人,我們就叫緒厲兀家族吧。 緒厲兀家的老爸,有一天去了城裡一趟。 他發現原來城裡的人生活都過得很好,有大房子遮風避雨不說,吃的、喝的都比他們部落好上百倍。 這讓他開始思索,有沒有甚麼辦法能夠多賺點錢,改善一下家裡的生活。 他去城裡的百貨公司逛了一圈,發現裡面怎麼甚麼東西都有賣。 只是哩,看來看去好像都沒有甚麼他們能拿來賣的東西。