專案管理筆記 結語 - Notes of Project Management

每一個專案完結時, 都要有一個完結的階段, 不然別人會以為專案仍在做.
所以我在此輕輕寫一個結語.

雖然在筆記中用上了很多實戰, 但也只是紙上談兵, 只不過沒PMBOK那麼紙上談兵.
還是那一句, 實戰上專案經理的隨機應變十分重要, 讀了PMBOK還是要自求多福...

專案管理筆記(十六) 合約 Contract - Notes of Project Management (16)

合約是採購管理的重要一環, 因為無論採購物資, 還是採購服務,
當中也一定有合約在其中.

合約的種類很多, 因應不同的採購項目, 所用的合約種類也不同.

Fixed-price 固定價錢, 大部分物資採購都是固定價錢,
即使專案經理爭取到減價優惠, 只要是一旦簽訂合約, 價錢都不會變就是固定價錢.
固定價錢合約的特點是買方的風險很低, 因為價錢不會變所以容易管理成本.
而賣方的風險較高, 因為萬一賣方的成本忽然上升, 也不能轉嫁對方,
但同賣方的回報率也可以很高. 因為買方不關心賣方的成本, 所以即使賣方的回報率有十多倍也不會有怨言.

固定價錢也可以有點變化, 除了固定的價錢外, 加上一筆奬金,
當賣方的表現很好, 例如提前完全, 就可以得到這筆奬金,
這鼓勵賣方作出更好表現. 但若用固定價錢加奬金(Fixed-price Incentive Fee, FPIF)
在簽訂合約一定要清楚寫明得到奬金的準則, 免得日後爭議.

Cost-reimbursable, 成本取回, 就是不論賣方的成本多少, 買方都會支付.
這是為免賣方入不敷支而不能完成合約, 於是買方承擔了大部分風險.
很多家庭傭工也是成本取回, 不然他們只是煮咸魚青菜給主人吃.
賣方雖然是低風險, 但實際上也很麻煩的, 因為要證明自己的成本, 所有的支出也要有單據.
遇上嚴格的買方, 真的會每一項目成本也查根究底.

但只是成本取回的話, 賣方沒錢賺, 所以成本取回多數讓賣方在成本以外加一筆收費,
家庭傭工實際上是Cost Plus Fixed Fee, 成本取回加固定薪金.
而也有些合約是成本加一定比例的收費, 但這會更買方的風險變得極高,
因為賣方越亂花錢, 賣方的收益也越高.
若無奈地用成本取回加比例收費的話, 一定一定要好好看管賣方的帳目.

Time and Material是另一種合約, 看起來有點像成本取回, 但意義上很不同.
時間和物資, 像成本取回一樣, 賣方花在物資上的金錢可以向買方取回,
但不是所有的成本都可以取回, 凡是沒有交付到買方的使費都不能取回.
例如賣方找了一個顧問在給意見, 在成本取回合約可以向買方取回, 在時間和物資則不能了.
同時, 時間和物資會按所花時間收費, 不同成本取回的地方是, 一旦訂好每日的收費,
買方不會管賣方的成本, 即是收費是一天一千元, 可是賣方每天只花了五百元成本,
中間的差額就是利潤了, 時間和物資多用於人事顧問公司,
一間公司向人事顧問公司請人, 每月付三萬元, 可是人事顧問公司請來人月薪可能只有一萬元

雖然合約的種類很多, 但專案沒有選擇的餘地,
實際上簽那一種合約要看行業的慣性.

專案管理筆記(十五) 噪音 Noise - Notes of Project Management (15)

噪音是溝通管理中無可避免的問題.

噪音不單單指嘈吵的聲音, 而是泛指一齊妨礙溝通的要素.

例如寫作技巧不足也是噪音的一種,
因為寫作技巧不足會令接收者不能完全接收.

但有些噪音郤是故意製造出來,
例如過濾, 著名的有"叫佢做野冇反應"的藍精靈....
明顯地把工作的命令過濾了.

可是噪音是無可避免,
例如, 不論電郵寫得多好,
始終難以表達出聲調變化, 肢體動作等等,

還有Lost in Translation也是無可避免, 只能減少.
畢竟人心隔肚皮, 就算同樣的母語也會有誤解.

不過這些妨礙溝通的阻隔, 郤可以消除,
例如, 怕電郵無法表達出肢體動作, 可以改為視像會議.
怕有語言的阻隔可以多請專業的翻譯.
當然, 實戰上得看是否值得那樣做吧.

專案管理筆記(十四) 衝突管理 conflict management - Notes of Project Management (14)

有人的地方就有衝突, 所以衝突管理也是難以避免.
在PMBOK中, 衝突管理只在人力資源管理中輕輕帶過.
畢竟衝突管理只有招式可教, 心法還是靠專案經理的經驗.

衝突管理招式有六種, 不能同時用.

第一種Forcing, 強迫, 就是由高層話事, 其他人不得異議,
那是一種傷感情的做法, 但勝在快捷, 當問題很迫切的時候才好用.
太濫用會受強烈反抗, 結果會得不損失.

第二種是Smoothing, 潤滑, 就是找個和事佬來,
以家和萬事興為基調, 勸衝突的雙方好好相處.
問題是不一定會解決了問題, 就像兩岸問題一樣, 過了那麼多年台灣還是不統不獨,
那就是大家都偏向Smoothing.

第三種是withdrawing, 逃避, 就是避而不談,
問題是絕不會解決, 最理想是不了了之, 像皇后碼頭的問題就是一個成功地逃避的例子.
但也不能濫用, 太多事不了了之, 總有一日會被些記仇的人挖出來舊事重提.

第四種是Compromising, 妥協, 一人讓一步,
街市見最多, 買方出二十, 賣方要四十, 結果三十.
多用常見的解決方法, 但不是一定可以用, 若雙方立場堅定,
可以花二三十年也解決不了.

第五種是Collaborating, 合作, 跟妥協不同,
是找尋一些雙嬴的局面, 比妥協難得多, 因為現實不一定有雙嬴的可能性.

第六種是Problem Solving, 解決, 不一定用原本方案去解決,
總之解決了問題, 例如兩公婆都不願去煮飯, 結果可以是出外用膳,
雖然沒有解決誰去煮飯的問題, 但解決了吃飯的核心問題.

專案管理筆記(十三) 虛擬團隊與困獸鬥 virtual team & co-location - Notes of Project Management (13)

虛擬團隊與困獸鬥是在人事管理上兩個極端的技巧,
因應不同的需要而使用.

虛擬團隊在跨國公司是很常見的事, 所以在PMBOK中也會一提.
正常的團隊, 為了方便溝通, 團隊成員不會隔得太遠,
即使要常出外工作, 有需要時也可以回去開會不會太困難.

但虛擬團隊不同, 虛擬團隊的成員遍佈世界各地,
來往相隔十多小時飛行路程也不出奇.
以前也許是不可能的事, 但如今的科技讓世界各地的人可以輕易地溝通,
於是虛擬團隊出現了.

虛擬團隊有什麼好處呢? 對於很多公司來說是平價,
因為在一些平均薪酬較低的地方找隊員, 可讓團隊的平均薪酬下降.

但有時候是逼不得已, 像有些公司要二十四小時支援的,
在各個時區請人比在一處請人開夜更容易.

當然也有壞處, 雖說科技讓世界各地的人可以輕易地溝通,
但山高皇帝遠, 管理也是不容易的事, 至少不可能做到時時刻刻監視吧.
還有是要有穩定的溝通方法, 不然忽然失去聯絡團隊就完了.

困獸鬥是我作出的譯名, co-location本意是把所有的資源放在一起,
但在人事管理中就是和虛擬團隊完全相反的方案, 強迫團隊眾在一起.
好處是加強了溝通, 當然相對地磨擦也加強了.

本來團隊坐在一起是普通不過的事,
所以既然要特別介紹的, 就不是一個常態的co-location.

困獸鬥通常是當專案出問題, 專案經理為了加快進度, 才會用困獸鬥.
所以不單單坐在同一辦公室, 甚至是一隊人困在一間會議室內.
不成功便成仁...

專案管理筆記(十二) 質素管理 Quality management - Notes of Project Management (12)

質素管理是PMBOK中當相當麻煩的一章,
有一點拉雜成軍的感覺, 提及的東西很多, ISO, TQM, Six Sigma, CMMI...
不少都是足以單獨成為一個三分課程的東西,
不過在PMBOK中也只是輕輕帶過.

質素是一種很難以言喻的東西,
因為很多時何謂有質素是很主觀的想法,
例如一件有質素的衣服是讓人穿起來又舒服又好看.
但何謂舒服何謂好看郤因人而異.

所以在PMBOK中, 所謂質素只指能量化的指標.
例如美國籃球員會有很多指標, 像得分數, 籃板數, 助攻數等等,
不管他是平民射球還是入樽, 兩分就是兩分.
可是若果每一支球隊都是以這些質責為目標, 球迷是不會高興的.

質素管理在專案管理中處於一個很尷尬的位置.
PMBOK中所介紹的質量監控的技巧, 多數用於大量生產時.
像生產出一百件產品, 然後看看有多件不合格, 再分析不合格的原因,
改進之後再生產一百件產品來看看有沒有改善.

這對大量生產的製造業是很普通的事,
但郤不是每一個專案都用得著,
因為專案的獨一性, 很多時, 做一個專案只有一次機會,
錯了就錯了, 就算事後檢討了, 也只能在下一個專業中用上.
可是下一個專業未必會遇上類似的問題,
更甚的是, 連有沒有下一個專業也是一個疑問.

但專案的質素管理也不是沒有用的.
當一間公司會做大量類此的專案時, 就會有足夠的經驗去制定質素管理的方案.
不然要多參考其他人的成敗做研究.

若是完全是單一的專案, 就別想太多,
做好其他知識的管理, 質素也不會太差了.

專案管理筆記(十一) 風險反應 Risk Response - Notes of Project Management (11)

上一回說了如何決定什麼風險要處理, 今回是說如何回應那些風險.

跟據pmbok, 有四種回應風險的方法.

第一種是禁止(Avoid), 若果一件事件會對專案產生嚴重的負面影響, 那可以不做就不要做,
例如擔心個人資料會在facebook, 那就不會在facebook上放個人資料, 甚至不用facebook.
禁止是很難在實戰用, 一來很多東西不是專案經理所能控制, 例如沒有專案經理能禁止香港在八月下雨.
而且能控制的, 就不是風險了, 所以禁止往往變了斬腳指避沙蟲, 要犧牲不少才能保證禁止.

第二種是轉嫁(Transfer), 最常用的例子是買保險, 當出意外時可以將損失轉嫁到保險公司.
能轉嫁的, 不只是金錢上的損失, 責任也可以轉嫁, 例如比武前要簽生死狀,
因為比武出人命傷亡的風險極高, 所以專案經理把人命傷亡的責任轉嫁到參加者身上.

第三種是減輕(Mitigate), 減輕是常用和易用的方法, 但應對風險的效果也有限.
減輕可以分兩方面, 一是減輕出事的影響, 例如踏單車時帶頭盔, 出事時受的傷害會減輕了.
另一種是減低出事的機會, 例如踏單車的速度減慢, 出事的機會也減少了.

第四種是接受(Accept), 即是不預先做什麼, 萬一出事才處理.
接受也分主動接受(Active Accept)和被動接受(Passive Accept),
被動接受其實就是不作準備, 真的發生了才算,
絕大多數的風險也是如此處理, 尤其是在前面風險矩陣中較低分的一些風險,
好處是省時省力.
主動接受就是定好B計劃, 萬一發生了就立即改變計劃去應對,
甚至預留了金錢和時間.
雖然預留了金錢和時間, 但若果風險最後沒發生, 預留了的金錢和時間可以用作其他用途.

很多人會覺得, 做到了主動接受已經是做好了風險管理,
但實戰上有些風險的影響太大, 不可能出事或面臨出事才改變計劃.
所以禁止和減輕也是要多多利用, 即使感覺上花了無謂的金錢和時間,
但風險就是這樣子, 當你成功預防了一些風險, 總會有人覺得你過慮了...

至於轉嫁, 只是推卸, 老實說, 若一個已知的風險發生了, 專案經理是跑不掉,
轉嫁只是讓專案經理死得沒那麼慘.....

有一點要注意的, 風險反應會產生新的風險,
著名的例子是, 中國為怕人民用社交網絡來結黨的風險, 禁止了人民用社交網絡,
結果同時出現了被指責侵犯人權的風險....
所以做風險反應, 除了平衡資源和風險的取捨, 也要想想那個風險反應所帶來的影響.

最後一點, 之後說過, 風險也包括對專案有正面影響的事,
原則上正面的風險也可以做一些風險反應.
但實戰上, 應付負面的風險已經足夠讓專案經理累死了, 正面的風險就隨遇而安吧.

專案管理筆記(十) 風險矩陣 Risk Matrix - Notes of Project Management (10)

風險管理是近年熱門的課題, 也是教授推介的一個很值得做的流程.

可是也是一個很難做好的流程.

先說風險, 今時今日用風險這個名詞不夠傳神了.
以前人說風險管理, 只會注意有什麼潛在的危險, 減少問題.
但今時今日, 人們也會注意有什麼潛在的機會, 以好好把握.

所以風險管理泛指了一切不確定的事件, 不管對專案有正面或負面的影響.
但有些事件是完全的意料之外, 例如冰島的屠殺事件, 那麼風險管理也無幫助.
因為在資源有限的情況下, 那些虛無縹緲的風險是不應花功夫去處理.

而風險矩陣則是幫助專案經理去決定那些風險要管理, 那些風險不要理.

做風險矩陣的第一步是列出潛在風險, 原則上是越多越好, 反正不是全都要處理.
為了列出潛在風險, PMBOK教了多種方法, 但在這裡不詳述, 因為有些方法也頗麻煩,
實戰上專案經理靠常識和經驗去列出潛在風險, 已有不錯效果,
除非專案經理欠缺專業知識, 那麼找個專家來也可以解決.

第二步是訂出潛在風險出現的機會率和萬一潛在風險出現的影響,
若發生的機會很高, 就要給較高的分數, 通常是一至三或一至五,
同樣地影響也可以分成不同等級, 但何謂嚴重郤因專案而異,
例如在一般的專案, 會引起一人死亡的潛在風險, 肯定是高度影響.
但在戰爭的專案, 只會引起一人死亡的潛在風險, 很可能只是中度甚至低影響.

有些專案經理還會訂出偵測潛在風險的難度,
例如颱風, 現今的天文台已可以早早預測,
但例如交通意外, 往往到發生了才知道,
知道偵測潛在風險的難度有什麼好處呢?
若果一個潛在風險是很容易偵測, 也較容易提防和應變,
例如颱風, 大家不必天天都做防風措施, 而是知道颱風臨近才去做.
若果一個潛在風險不能預測, 就應該盡早作好打算.
例如交通意外, 為免交通意外, 所以過馬路前會注意交通情況, 而不是走入了馬路才算.

而偵測潛在風險的難度越高, 分數也越高.

第三步是把每個潛在風險的各項分數相乘,
原則上較高分的潛在風險要多加注意,
但敎授說, 有些專案經理可以另訂指引, 如影響力較高的潛在風險要優先處理.

好了, 到這一步就可以知道有什麼風險在等專案經理.
但知而不行, 是為不知, 若專案經理不做些事來回應那些潛在風險,
就怎算風險管理呢, 但要肴什麼可做, 則是下回分解.

專案管理筆記(九) 掙值 Earned value - Notes of Project Management (9)

掙值是在成本管理中的一個重要流程, 也是不少教授花了很多時間去教的一個監控流程.

平常提到監控流程, 教授老是說只要做好計劃, 監控其實很容易.

但是掙值郤是即使做好了計劃, 也要花一番計算才能好好運作的流程.

首先, 為了計算掙值, 把工作分解結構中所有的交付項目都定立一個成本值.

雖然原則上不一定是錢, 可以要其他的資源例如工時代替.

只要把所有資源轉化為同一單位就可以了.

但是為了方便計算成本, 成本值通常還是轉換成錢來計算.

而掙值就是完成的交付項目的成本值總和.

例如每寫一篇專案管理筆記的成本是一百港元, 寫了九篇的掙值就是九百港元了.

當然掙值也有多種計算方法, 常用的有0/100, 50/50, 比例制.

0/100就是一日未完工, 就不計入掙值, 直到完工後才把成本值全數計入掙值.

50/50就是一旦放開始, 就先計一半計入掙值, 到完工後就把另一半也計入掙值.

而比例制則是按完成度來計掙值, 但比例制太麻煩, 而且不是每一個交付項目都可以準確地說出完成度, 所以實戰上很難用, 用了也會有爭議的.

其實若果工作分解結構做得夠仔細, 用0/100或50/50已有極佳效果.

有了掙值也不足以監控專案的成本, 因為監控必需要有原定計劃來比例.

否則單單說專案管理筆記的掙值是九百港元, 誰知道是好是壞.

所以有兩個數字必須知道的, 第一個是計劃值, 第二個是實際成本.

計劃值就是照原定計劃, 今天這個專案應有的掙值.

例如今日照原定計劃, 我應該要寫第六篇案管理筆記, 所以計劃值就是六百港元了.

其實計劃值是用來監控時間多於監控成本, 不過那算是一石二鳥吧

而實際成本顧名思義是實際成本, 專案經理必須記錄那個專案實際所花的每分每毫.

然後和掙值比較就可以知到是否用得其所了.

做比較是離不開差值和指標兩種方法, 差值是減數, 而指標則是除數.

差值讓人清楚差額, 而指標是讓人清楚那個專案的效率.

例如專案管理筆記的掙值是九百港元, 計劃值是六百港元, 而實際成本是一千港元,

進度差值(SV)是三百港元, 進度指標(SPI)是1.5

成本差值(CV)是負一百港元, 成本指標(CPI)是0.9

由此可見專案管理筆記的進度比預期快, 可是成本上多花了一點.

掙值是中看不中用, 雖然看起來很有效地監控進度和成本,

但用起來就會發現, 很多交付項目的成本難以量化, 難以訂出成本值.

而且若工作分解結構做得不好, 反過來會誤導了專案經理.

一個例子, 一個重大的交付項目還差一點點才完工, 所以相關的掙值還差一點點才到手.

但時間和成本也確實付出了, 結果在那個重大的交付項目完成前的成本指標和進度指標都變得很差,

不明袖裏的權益關係者看了數據, 肯定不滿意, 但專案經理只能在乾急了.

所以呢, 掙值不能隨便用, 要看專案性質和專案經理的能力.

專案管理筆記(八) 關鍵鏈專案管理 Critical chain Project Management - Notes of Project Management (8)

關鍵鏈專案管理是一種很離奇的管理方式,
在香港是沒什麼價值, 但PMBOK寫了, 教授不但教了, 還在考試試了就當有認識的需要吧.

立論是在一個懶鬼的國度, 一個任務若定了要花十日才完成, 萬一專案團隊只花六日就做好了, 他們不會做任

務, 而是等到第十一日才繼續做.
而專案經理也不會在那十日內關心一下進度, 所以專案經理不會知道任務提早完成了.

很難想像香港會發生那樣的事, 香港的管理習慣是天天盯著專案團隊, 怎可能讓專案團隊停工四日.
單單是立論在香港已不成立了.

不過在某些國家和架構下, 還是有可能的,
那些地方的人為免浪費時間, 所以出現了關鍵鏈專案管理.

首先改變穩打穩紮態度, 正常估計每個任務所花的時間, 都是九成以上信心可以完成的時間,
若非出現極大不幸, 不然專案經理也會佷安心可以完成.

但關鍵鏈專案管理要求估計每個任務所花的時間, 是只有一半機會能完成的時間,
是有點幸運才能完成的時間, 但為免延誤, 就會加一點緩衝.
不過若然專案經理夠幸運的話, 就可以大大減少了所花時間.
若然專案經理很不幸的話, 也有緩衝時間去補救.

而在香港, 就是專案經理明知那是只有一半機會能完成的時間, 還是會強迫專案團隊按時完成的.
所以不會有專案團隊敢提出的"只有一半機會能完成的時間", 大概還是有九成信心的完成.
也鮮有老闆接受預留大量緩衝時間.

所以關鍵鏈專案管理在香港是一個高層和低層都不會高興的管理方法.
可能要等多二三十年, 當那些不是工作奴隸的人做專案經理去管一些不是工作奴隸的人構成的專案團隊才會有用.

專案管理筆記(七) 網絡圖和關鍵路徑 Network diagram & Critical path - Notes of Project Management (7)

通常做時間管理, 第一件會想到的工具是甘特圖(Gantt Chart)
甘特圖十分易懂, 不用多說.

而且在PMBOK中, 甘特圖也不是那麼重要的東西.
PMBOK更著重網絡圖和關鍵路徑.

在說網絡圖之前, 先談談什麼是任務?
上回提過工作分解結構會把交付項目細分到不能再細分.
而時間管理中的任務, 就是完成交付項目的步驟.
如果工作分解結構中有一百個交付項目, 在時間管理中也應列出完成這一百個交付項目的任務.
然後要做兩件事, 第一是估計每個任務所花的時間,
第二是研究各個任務之間依靠的關係.

估計時間就只有靠估, 沒有什麼理論可言.

而任務之間依靠的關係, 在PMBOK分成了四類,
第一是FS, 前者完成, 後者才開始, 例子, 蒸水蛋一定是打完蛋漿才拿去蒸, 絕不可能一邊打一邊蒸, 更不可能蒸完才打蛋, 所以打蛋和蒸蛋之間有FS的關係.
第二是FF, 前者完成, 後者可完成. 例子, 炒肉片通常要加入獻汁才算完成, 所以就算早早開始了炒肉片, 還要等獻汁完成才可以完成.
第三是SS, 前者開始了, 後者才可開始, 例子, 馬拉松比賽, 通常是等一組開始了, 第二組才開始, 但不用等到第一組完成才讓第二組開始.
第四是SF, 前者開始了, 後者才可完成, 教授用了一個很可悲的例子, 就是考試開始了, 溫習才可完成, 即是一日未到考試, 大家還是要溫習.

實戰是會搞好FS的關係已經很好, 別勉強去搞其他的關係,
其他關係對後面的關鍵路徑幫助不大, 反而使自己更亂.

把任務之間依靠的關係用線連上了, 網絡圖就完成.
然後透過網絡圖, 就可以計算出每個任務最早開始時間和最早完成時間.
例如蒸水蛋, 打蛋要花兩分鐘, 那麼蒸蛋就最早也要在第三分鐘才可以開始, 而蒸蛋要花七分鐘, 那麼在第十分鐘才可以加上葱花和上碟.

接下來就會發現整個專案要最少花多久才可完成.
一個超簡單例子, 蒸水蛋花十分鐘, 炒肉片花五分鐘, 炆牛腩要花三十分鐘,
即使有一個很大的廚房和十分充足的人手, 使蒸水蛋, 炒肉片, 炆牛腩可以同步進行.
這餐晚飯最少也要三十分鐘, 因為炆牛腩要花三十分鐘.

好了, 知道這餐晚飯最少也要三十分鐘, 於是有些懶鬼就會覺得蒸水蛋和炒肉片遲一點才開始也沒所謂.
但為免耽誤晚飯, 所以要算算最遲開始而又不會影響這專案的時間,
蒸水蛋因為要花十分鐘, 所以最遲第二十分鐘要開始了,
而炒肉片只花五分鐘, 所以最遲第二十五分鐘才要開始.
最後炆牛腩要花三十分鐘, 所以專案一開始就必須開始了.

由於可見, 蒸水蛋和炒肉片的浮動時間分別是二十分鐘和二十五分鐘, 而炆牛腩的浮動時間則是零.
而關鍵路徑就是所有浮動時間則是零的任務, 好像十分簡單吧....

關鍵路徑為什麼那麼關鍵呢?
用上面的例子, 炆牛腩是關鍵路徑, 若果炆牛腩時出了什麼意外, 結果花了四十分鐘,
晚餐就絕對要延誤了.
反過來, 若發現有新食譜, 只花二十分鐘就可以炆好牛腩. 整個晚餐所花也減少了.
所以一個專案經理必須好好看管關鍵路徑上的任務.

不幸的是, 關鍵路徑隨時會改變, 例如有權益關係者堅持炒肉片之前, 肉片必需先醃三十分鐘.
那麼炒肉片馬上變了關鍵路徑, 而炆牛腩則有五分鐘的浮動時間...
所以網絡圖和關鍵路徑不是一開始做得好就一了百了, 要時刻警覺的一個流程.

專案管理筆記(六) 工作分解結構 Work breakdown structure - Notes of Project Management (6)

工作分解結構是很容易做而又很重要的一個流程.
所以有心做好一個專案時, 沒理由不做工作分解結構.

工作分解結構就是把專案的交付項目列出來.
然後把那些交付項目細分細分再細分.
一直到不能再細分為止.

容易做是因為只是把眼見東西寫出來, 沒有大量計算, 沒有假設性,
但也有不容易是地方, 第一個問題是什麼是交付項目?

交付項目不一定有形的物件, 一個服務, 一個會議也可以是交付項目.
而交付項目的重點可以能讓權益關係者去評定某個交付項目是否完成及可否收貨.

第二個問題是這個專案該有什麼交付項目?
不同的專案要交付的東西也當然不同, 專案經理也必須知道該交付什麼才算完成,
可是不是每個專案經理都對專案的範疇十分熟識, 所以非跟各個權益關係者聽取他們的要求不可.

工作分解結構的重要性是工作分解結構包含了所有的交付項目,
所以一個專案是否完成的一個關鍵是工作分解結構中的項目是否都完成了.

後面會提到的網絡圖和掙值, 也是建基於工作分解結構.
雖然不是說不做工作分解結構就無法做網絡圖或掙值,
但沒有做工作分解結構就難以確保網絡圖和掙值中沒有任何遺漏.

另一方面, 若一些重要的交付項目沒有在工作分解結構中出現, 那麼這個專案將會面臨一個危機,
最嚴重就是當大家以為完成了之後, 郤因遺忘了那個重要的交付項目而導致專案失敗.
若發現得早, 也可以及早變更計劃去完成.
但是若沒有工作分解結構, 別人也無從得知有沒有交付項目遺漏了.
所以工作分解結構是絕不應跳過的流程.

專案管理筆記(五) 變更控制委員會 change control Board - Notes of Project Management (5)

接下來寫的是不計成本的做法, 因為是功課之一所以比較詳細...

1. 當變更經理收到變更要求時, 先記錄變更的事項, 變更的原因, 誰是變更要求的人, 並且給予一個變更編號, 方便日後跟進和參考用. 這一步面對最大的問題是, 到底什麼要記錄, 什麼不要記錄呢? 若果事無大小都鉅細無遺的記錄並交到變更控制委員, 專案會被嚴重的拖延. 但太多的變更都跳過這一步, 只會令機制變得明存實亡. 所以這很考驗變更經理的經驗.

2. 有了變更要求, 變更經理就要研究變更所帶來的影響, 不單是變更本身是否可行, 還要研究對成本, 資源, 時間等等方面的影響. 例如由宴請四位客人變宴請五位客人, 菜單, 材料, 烹調時間等 也要相應改變. 更甚是, 受影響的不一定只限於這一個專案. 一個專案的變更, 可能成為了其他專案的變更要求, 傳統的例子, 當一個專案忽然要大量增加人手, 調配第二個專案的資源就要減少了, 於是第二個專案就出現一個資源減少的變更要求. 所以變更經理不能單單只願自己的專案, 而是要研究任何會有影響的地方.

3. 做好了影響評估, 就要交到變更控制委員會那裡審批, 變更控制委員會應由權益關係者組成, 有需要時可以邀請外來人仕一同審批. 但是面對一些緊急的變更要求, 一時間未必可以找齊變更控制委員會來審批.

4. 當變更控制委員會通過變更要求之後, 專案經理(不是變經理)就要在專案的計劃作出改變. 而且當變更會影響到其他專案, 就要對其他專案提出一個變更要求, 並且做好一個風險評估, 以應付萬一對其他專案的變更要求不獲通過的情況.

5. 更改了專案的計劃, 也要通知所有相關人等, 不是單單的知會, 而且要確保他們按照更新的計劃去執行, 所以專案經理在有新變更後要加強監控.
而通知所有相關人等本身也十分困難的一件事, 例如專案是相乎大眾的, 如何令每一位市民都能得知呢. 不過如果在溝道計劃做好了, 這一步的煩惱也減少了.

6. 萬一變更要求不獲通過, 也需要記錄變更控制委員會拒絕的原因, 若果日後有相似的變更要求, 這些被拒絕的變更要求也可以拿來參考.

但實際做專案時, 變更控制委員會是一件十分奢侈的事,
就算是很多中型的專案也不會有一個正式的變更控制委員, 更不會有變更經理. 大多數是專案經理兼任.

不過變更控制郤是不可不做的一回事, 頂多是大有大做, 細有細做.
就算不詳細記錄和批核變更要求, 但變更要求所帶來的影響也必須好好想一想.

專案管理筆記(四) 專案許可證 project charter - Notes of Project Management (4)

專案許可證是專案的一個重要里程碑,
就算是簡單的專案, 沒有一個正式的專案許可證,
也應該想一想下列專案許可證中的常見項目.

1. 業務需要, 花那麼多人力物力做一個業務, 首要考慮的是為何要做這個專案,
尤其是在公司裡, 專案許可證裡必須說明這個專案滿足了什麼業務需要.
而批核的人則要確保專案滿足的業務需要是公司的策略一致.
例如一個專案是做一些有趣的宣傳品來提升公司知名度,
對新興的公司可以是很好的專案, 但對老牌標榜專業形象的公司來說, 就和公司策略不太一致.

2. 目標, 專案許可證必須有目標, 目標除了用來做成功指標, 也是給專案團隊的指引.
有時寫專案許可證的人, 不一定就是這專案的專案經理, 更不一定是實行這專案的人.
所以寫清楚一點, 可免除日後爭吵.

3. 權益關係者, 權益關係者的重要性已經說過了. 而在專案許可證只需列出主要的權益關係者就足夠.

4. 假設, 很多事一個專案能否實行, 如何實行, 是建基於一些假設, 而那些假設未必一定成為事實,
如果那些假設錯了, 會嚴重影響專案的話, 是必須在專案許可證列出來, 讓專案經理做風險評估.

5. 資源, 專案許可證必須指出誰是這個專案的專案經理, 而不應該在批核專案許可證才慢慢找人.
另外, 如果專案需要一些特別的資源, 例如某些學問的專家, 某些難以購買的機器等, 都要在專案許可證提出來.

6. 批核者簽署, 這是專案許可證最重要的一部分, 若沒有批核者簽署, 那只是一份普通分析專案的文件.
但有批核者簽署, 就是出資人同意去實行這個專案, 同時專案正式開始.

其他的專案範圍, 專案限制, 財政預算, 專案里程碑等等. 視乎專案的大小而決定, 不一定要在專案許可證中出現.

要做好一個專案許可證, 其他也花了不少精力去研究專案的可行性, 潛在風險等等.
所以一個專案不是在專案許可證批核後才開始, 其實在專案許可證批核之前, 做好一些準備

專案管理筆記(三) 階段和流程 phase and process - Notes of Project Management (3)

階段和流程是專案管理最容易混淆的名稱,
不單大家都P字開頭, 概念相近, 連分類的項目也很相似.

不過相對地有極多的專案管理教科書會花不少篇幅來介紹兩者分別,
所以有心讀是不可能弄錯的.

先說階段, 一個稍為大專案, 也不可能一朝一夕可以完成的,
所以要分階段, 分階段的好處是讓專案團隊知道這一刻大家要注重什麼.
例如一個做菜的專案, 當中會有一個採購的階段, 也會有一個烹調的階段,
大家一看就知道在採購的階段應該去街市買菜, 而烹調的階段應該去廚房, 十分清晰.

任何專案都應該有一個起始階段, 實行階段和結束階段.
而實行階段可因應專案的工作而再細分.
例如之前提到的採購階段和烹調階段都是實行階段再細分的階段.

通常完成了一個階段, 才會到下一個階段.
PMP也容許兩個階段有小量時間重疊, 但是盡量不要, 因為不好管理.

不少深受專案管理影響的專案經理會在起始階段和實行階段中間加上一個計劃階段,

結果和五大流程更加貼近.

五大流程包括起始流程（Initiating）、計劃流程（Planning）、實行流程（Executing）、監控流程（Monitoring and Controlling）、結束流程（Closing）
五大流程中有四個看起來很似之前提到的起始階段, 計劃階段, 實行階段和結束階段.
可是只有名稱相似, 實際相差很遠.

例如起始流程通常是階段開始時的工作, 多數是開會通知所有人專案已經到逹一個新階段.
而起始階段只會有專案最初的時候實行, 一旦過了起始階段一般是不會回頭的.

同樣地結束流程, 也是每一個階段結尾的工作, 而結束階段則是專案最後的階段.

而計劃流程在PMBOK不是計劃專案的內容, 而是計劃如何實行,
例如在採買管理, 計劃流程只是決定定立合約的原則,
而實際計劃採取向那一間公司採買郤是實行流程.

監控流程大概是五大流程中就容易明白的.
就是監控, 看看實際狀況和計劃中的狀況有沒有偏差.

雖說五大流程, 九大知識是PMP的精髓,
但其實五大流程是為了讓人容易了解PMP的各樣流程, 而做出的分類.
做寫project charter比知道project charter屬於那一大流程重要得多.

專案管理筆記(二) 權益關係者 stakeholder - Notes of Project Management (2)

把stakeholder解作權益關係者, 其實不是太傳神.

在解釋權益關係者之前, 先看看stake的意思.

1.股本, 股份; 利害關係
2.賭金, 賭注
3.樁, 標樁; 棍子, 棒
4.(賽馬等的)獎金; 有獎賽馬, 有獎比賽
5.危險, 風險
6.火刑柱; 大刑, 火刑

stake是一字多意, 不管PMP是故意還是無心插柳, 那對尋找誰是專案的權益關係者很有幫助.

股本也好, 賭金也好, 第一種權益關係者就是出錢支持這個專案的人,
沒有出資人, 任何專案也行不了.
但要弄清誰才是出錢支持專案的人, 一般公司可能是老闆, 也可能是客戶, 視乎專案性質.
而政府的專案, 出錢支持的多半就是納稅人了, 雖然納稅人在政府的專案影響力不大, 但絕不應被遺忘.
其實權益關係者付出的, 不一定真金白銀, 像李小龍故居紀念館的專案, 業主余彭年絕對是主要的權益關係者, 政府就是無視這一點, 令專案失敗.

拿棍子的人, 令人想起每天在鞭策大家的上司, 第二種權益關係者就是管理這個專案的人,
專案經理固之然是權益關係者, 專案經理的上司, 專案經理的上司的上司...也多多少少對這個專案有影響.
還有專案團隊同事的上司, 當公司的結構是功能為主結構(functional structure), 專案團隊同事的上司往往能左右專案的成失.
因為專案團隊的同事要面對兩個上司的困境, 正常的員工都會偏向聽部門經理多於聽專案經理.

拿獎金的人, 自然也是辛勤工作的一班人, 第三種權益關係者就是執行這個專案的人,
專案團隊毫無疑問是權益關係者, PMBOK有整整一章去照顧他們.
除了專案團隊, 專案所用的服務供應商, 也是權益關係者之一,
有時候專案要因應服務供應商的能力而改變計畫.

不論風險或火刑柱, 都是危險的人, 第四種權益關係者就是想要破壞這個專案的人,
所以我說權益關係者不是太傳神中文名稱, 他們對專案沒有益處.
這一班人會因為專案成功而有所損失, 他們對專案沒有幫助, 但不注意他們是很多專案出問題的原因.
PMBOK稱他們為負極權益關係者(Negative stakeholder), 容易察覺的有競爭對手, 不管公司的還是專案經理的.
不容易察覺的有環保塔利班, 工地鄰近的居民等等.

弄清誰是權益關係者不一定能令專案更成功.
弄不清誰是權益關係者郤是很多專案失敗的原因.

專案管理筆記(一) 專案 project - Notes of Project Management (1)

專案管理的第一課, 永遠都是"什麼是專案".

在讀PMBOK之前, 對專案多多少少都有些概念.
讀完PMBOK之後, 對專案的概念反而矇糊了.

在PMBOK, 一個專案可大可小, 可長可短, 專案中可以有專案,
同一件事可以當成一個專案, 又可以分多個專案.

只要記得三個重點, temporary, unique和result

暫時性, 若一件事, 大家是打算永續去做, 是成不了一個專案.
例如減肥, 減肥是終身事業, 所以沒法個專案管理.
但是加上一個目標, 或者一個期限, 就可以變成一個專案.

獨一性, 若一件事, 會重覆又重覆去做, 過程沒有變化, 用不著成立一個專案.
例如生產i-phone, 每一部i-phone都是遵照程序做, 沒有人會為生產1000部i-phone而成立1000個專案.
但是生產1000部i-phone這件事, 就應該成立專案.

成果, 若一件事, 本身沒有目標成果, 就算勉強成立了專案也無從管理.
例如漫無目的去逛街, 就算有收穫, 也不能算是成功的專案, 因為沒有一個指標去決定是否成功.
但是如果為買相機而逛街, 就可以成立專案.

在解釋什麼是專案之後, 下一個問題通常就是"為什麼要做專案管理?"

通常的答案是控制成本, 確保準時, 提升質素.
那只是專案管理的宣傳口號吧,
若你告訴你的老闆, 當你讀完/考完PMP之後,
公司的專案就一定能控制成本, 確保準時, 提升質素的話,
你可以準備執包袱, 因為當意外發生, 再好專案管理也不一定能救了那個專案.

那為什麼要做專案管理?
專案管理最大好處是, 當問題出現, 你會很快就知道而可以盡早處理,
不會等到問題爆發到不可收拾的地步才知道.

專案管理筆記 前言 - Notes of Project Management

因為剛剛讀完專案管理的課程, 大概會順手考一考PMP,
只是個人不太喜歡精讀式讀書法, 所以用上了最不具成本效益的讀書法.
就是反覆思考逹致融會貫通. 因此寫寫筆記是絕對有幫助的.

但我也不打算做PMBOK的中文譯本, 因為第五版也快將推出,
筆記結構也不會跟PMBOK, 而是以名詞為主.
也正如我讀的課程一樣, 沒有半點針對PMP題目的內容.
而是把PMBOK中對做專案有實際幫助的部份寫出來.

也許讀完這筆記會對PMBOK加深認識, 但肯定讀完這筆記對拿證書沒大幫助
只是比起考到PMP郤不會做專案, 會做專案郤考不到PMP的人有用得多.