沒量沒真相 – 談工作進度評估

Score

管理是從「量測」開始!

不知道這句話是誰說的,但我覺得是對的。我知道有些人認真上了管理課,讀了一堆管理的書,甚至還拿到了MBA或是PMP,但回到辦公室,主管問起了工作進度,卻只有類似的回答:

  • 目前一切順利,下週就開始收尾了!(請問這「尾」有多長?)
  • 目前超過2/3的工作都已經完成!(那剩下的1/3是什麼?)
  • 上週為止進度百分比大約80%!(掐指一算出來的?)

以上的回答,尤其是後兩項,雖然包含數字,卻不是真正的「客觀量測結果」,只不過是用數字來表達主觀的「判斷」甚至「期望」罷了,就像我說我「身高號稱170」一樣的意思。當然,所有事情都要量測是不太可能的,但要是完全沒有客觀的評估基準,卻說自己做的是專案管理,這是絕對說不通的。所以今天我想整理一下我過去的經驗,歸納出一些進度評估的方式,讓各位看官參詳參詳!

1. 以投入為基準

1.1 投入時間  /  1.2 投入工時(或資源量)  /  1.3 投入金錢

2. 以產出為基準

2.1 完成量  /  2.2 里程碑(權重法) /  2.3 0/100或50/50法

3. 投入/產出混合

首先來看第一類「以投入為基準」的進度評估。我最近剛好聽到一個例子:

某PM對主管會報:「工作X原訂10天完成,目前進行了8天,其中X.1和X.2都已經順利完成,以上。」

以上?!給我趴下還差不多。雖然這PM沒有明說進度是80%,但其實從他的會報中可以隱約看出兩個假設:

1. 時間不會延誤,也就是完成時的工期等於原訂的工期,這裡是10天

2. 投入的時間與產出的結果呈現正比關係

這也正是所有「投入法」要能成立的前提假設。某些特定狀況下的確可以成立,比方說媽媽懷寶寶平均要40周,現在有位懷孕20周的媽媽,我們說她已經完成了一半,這評估大致是合理的。但某位同學預計花5個月準備PMP考試,現在已經過了4個月,所以進度已完成80%,這樣就有問題了。(改成「必須」完成80%還差不多!)

類似的陳述套用在工時(資源)投入也是一樣的道理。假設灌滿游泳池的水需要2,000立方公尺,水表讀數告訴我們已經用掉1,000立方公尺,雖然可能有蒸發或流失等些許誤差,我們說進度完成50%應屬合理。但如果有支電腦程式估計需要投入100個人時(Man-hour),由工時單得知已經填報50個人時,要說進度達成50%就有爭議了!

我認為,採用「以投入為基準」的進度評估方式,最大的好處,就是「方便」。我們在一項工作上花了多少時間,投入了多少人力,花費了多少金錢,相對於得到多少成果而言,是比較容易蒐集跟判定的。這也是投入法被普遍使用的原因。而我在使用上的建議就是:「盡量不要用,要用也得補足資訊」。什麼樣的資訊?簡單地說就是「預估的剩餘投入量」。直接拿一開始那位PM的例子,我認為正確的進度回報應該是這樣的:

工作X原訂10天完成,目前進行了8天,預估還需要4天結束,所以進度是8/(8+4)*100%=66.7%

從回報的當下到工作完成,還需要多少天,需要多少資源,需要多少成本,這部份的預估是PM或是第一線執行人員的責任,再先進的專案管理軟體都幫不上忙,這也是我擔任顧問時,一定會跟客戶釐清的部份。不考慮「剩餘投入」而計算出的百分比,常常產生過度樂觀的誤導嫌疑

邏輯上,「以結果為基準」的進度認定是比較客觀合理的。概念上不難理解,所謂進度,原本就該以工作得到了多少成果來決定,而非投入。舉例來說,有個工作是完成100台電腦的安裝,目前已完成30台,我們才能說進度完成30%,這正是2.1 完成量評估法的精神。

但問題來了,不是所有工作都是容易「計數」的,尤其是創造性、開發性的工作,像是撰寫程式、建築設計,或者像辦理採購、申請許可這類流程性質的工作,那怎麼辦呢?既然無法計數,又必須客觀,這時候就得用所謂的2.2 里程碑法,或者稱權重法。這類方法是稍稍麻煩的,因為必須在專案規劃時期,就要先講定「評分基準」。這有點類似奧運跳水項目的評分方式,這分數絕對不是裁判亂喊的,而是跳水的所有的動作早已被國際游泳聯盟分類為數個類別,而且個別動作都有所謂的難度係數(權重),因此每位裁判雖然能針對個別動作進行主觀判定,但仍在一個標準架構下維持一定的客觀性。

就以一個採購作業來說,一個客觀的評估基準應該拆分為數個步驟,並給定權重,類似這樣:

規格書開出 佔20%

蒐集供應者名單 佔10%

完成詢價議價 佔30%

決定廠商 佔20%

簽定合約 佔20%

以上幾個步驟不一定要有先後順序,端看公司如何定義。重點是每個步驟都代表了整個採購作業的一部分配重(總和100%),而且都必須是一個明確的交付點,有沒有做完是一翻兩瞪眼,不能含糊帶過的。假設某個採購人員完成了「規格書開出」和「蒐集供應者名單」兩項,就可以認定為採購工作完成30%(20%+10%)。假設公司裡所有專案的採購作業都統一以這樣的標準回報,管理者就可以更清楚正確地掌握進度數值。否則,專案回報變成在玩心理測驗一樣,一個人心中先默想一個數字,讓另一個人來猜到底該是多少,好玩是好玩,但你得確定客戶和老闆有這番興致!

至於2.3項的0/100或50/50法,可說是里程碑法的簡化。所謂0/100是指工作不論完成多少都顯示0%,直到全部完成才認列100%。50/50是指工作一開始就認列50%,全部完成時剩下的100%。同理,還有20/80,40/60,就看管理者的需求決定。

最後一種是投入和產出的混合法。我們直接用上面那個採購的例子說明。假設採購人員認真工作了好幾週,但規格書還差一點,就進度數值來看是0%,但說完全沒有進度似乎也不正確,這時我們就可以先以投入的時間或是工時來計算百分比,但必須以里程碑當做門檻上限。假設採購工作預計完成時共要100天,目前進行了10天,我們可以先認列進度為10%,但又過了20天,規格書(20%門檻)仍未開出,進度卻不能算30%,而只能算19%(假設最小進度增量為1%),直到規格書完成,進度才可以超過20%的門檻。

我和Joe常被問到,大眾化的Microsoft Project和企業級的Primavera P6有什麼不同?這裡剛好就是個例子,MS Project的進度百分比目前僅有投入基準法,但在Primavera中以上提到的所有方法都有。

上過PMP的人應該都知道,補習班老師會告訴大家Earned Value(實獲值)是必考重點,而且會要大家把CPI、SPI、CV、SV的公式都背下來,甚至坊間還有「實獲值管理實務」課程,老師會出幾個計算題,讓大家計算,然後檢討答案對不對,這讓我想起小時候被媽媽逼上什麼「公文數學」,其實想想,那稱不上「數學」,充其量只能說是「算數」。我在這裡也要跟大家重申,實獲值管理這套方法的重點,根本不是套用那些公式。因為台灣實在太少人真正接觸過實獲值管理,多數的PMP老師只好自己把公式先背一背就來教學生。那麼。實獲值管理的重點是什麼?PMBOK其實有點到:

The term EV is often used to describe the percentage completion of a project. A progress measurement criteria should be established for each WBS component to measure work in progress.

- P.182 PMBOK 4th edition.

關鍵就是這個”progress measurement criteria”(進度評估基準)。而且是每個WBS component都要個別制定專屬的進度評估基準。什麼意思?一個專案裡面,有可能包含寫程式,包含採購,包含寫文件等等各式各樣類型的工作,每類工作評估進度的方式勢必不同,所以想導入EVM管理,專案規劃初期就要(A)適當地區分工作包(Work Package),(B)搭配負責的團隊,(C)選擇適合的評估基準,ABC三者合一形成所謂的Control Account(管制帳戶,Ex. 採購工作包+採購小組+.里程碑法),接下來才能合理地計算EV值,並且進一步地彙總、計算指標。之前聽到一位PMP名師在講台上誤把Control Account和會計科目混為一談,我想藉此特別澄清。

工作進度的認定,是一件比多數人想像要麻煩,也比多數人想像要關鍵的工作。但好處是,一旦建立起一個清楚的評分基準,你的專案就會朝向「科學管理」邁進一大步,團隊成員間對於工作現況的溝通會更明確(Ex. 採購完成30%大家都知道做到什麼程度了)。另外,就算你的專案不導入實獲值管理,只要有標準的進度評估機制,基本上距離「客觀的績效評估」這個目標已經相距不遠。

Ok,本篇文章100%完成!

12 則讀友回應

  1. Klaus Chen 2012-08-09 23:06:30 第 12 則

    關於"錢"的事,動則上千萬的專案,所謂的共識,就是在分多少嗎....?

  2. summer 2012-08-08 17:54:16 第 11 則

    相關人對於「完成」的「定義」要有「共識」

  3. IT肥蝦 2012-08-08 12:35:57 第 10 則

    肥蝦個人以為:
    軟體專案的量度一直有多的問題,尤其在台灣的環境,更是讓這些問題加劇!
    Klaus Chen與Kristy Liao大大的看法與想法,肥蝦都很認同,也感同身受!

    就像那軟體功能項目的完工!這就很麻煩,工時與有形的資源投入是比較能衡量,但是產出就很麻煩!PG,SD,SA,PM,需求提出者,驗收者,大家的認定常有很大的出入!

  4. Klaus Chen 2012-08-07 23:00:20 第 9 則

    我一直很希望像Bryan說的方式作業,但是軟體專案感覺上用了很多管制手段,到最後就像Bryan說的,只有Status,Progress跟是否可以On schedule就很難落實。到最後就變成Forcast可達到的狀態與時間。之後就一直等到快驗收了才驚覺差很多....。

    撇開事情的本質及難易度,如果歸咎於人之間的互動,我想重點不是在如何算EVM,而是如何做好Communication Management這個課題.....?

  5. Kristy Liao 2012-04-26 18:30:24 第 8 則

    原來以前很多問題,都來自這個看似清楚'其實錯誤的進度回報方式!感謝!