-前情提要-
Alex召集了幕僚討論Eric專案進度報告。 原本大家以為實獲值這進度認列的方法是欺騙人的障眼法。 但在大家深入討論後暫且同意，問題似乎出在Eric為了讓專案繼續所以刻意設計出漂亮的報表。

但如果我們能預先把「工作查核點」講定的話，其實是可以避免Eric亂喊進度的問題，也可以讓專案進度更加客觀。

只是，光這樣似乎還不夠…

(上圖，Eric原始報表)

會議中

之前寫黑板的女生在思考過後舉手提問：「老大，我想了想發現好像還是有點地方怪怪的。 可是又不太知道怎麼說…」

Alex鼓勵她：「沒關係、你盡量講講看。 問題畢竟要能真的解決才有用啊！」

寫黑板的女生慢慢地說：「我們剛剛說要把工作拆解成幾個步驟並預先講定進度認定的標準，也就是工作查核點。 這雖然可以避免各說各話的問題，可是Eric報告中所有的問題還是存在啊！」

Alex還沒來的及開口..

「喔？ 怎麼說呢？」坐在她旁邊的工程師已經先急躁的發問起來。

她蹙著眉停頓著、想著該怎麼解說才好，等了好一下才緩緩的開口：「我…」。

這時候，那個戴著眼鏡高瘦的工程師倒先舉起手來並搶著開口說：「我知道妳的意思，讓我來幫妳說明吧！」

一邊說著，一邊站了起來走到旁邊的印表機：「剛剛你們討論時，我把你黑板上的一部分內容加到Eric的報表上，大家可以先看一下我改的報表。」

他把印出來的報表傳給大家。

等大家都拿到後，他說：「我雖然都改了，但請大家先看左上角就好了。 因為其他部分都滿類似的。」

(上圖，新修改的報表。註：底色綠色的部分是WBS、藍色的是工作)

「大家都拿到了嗎？ 妳們看，若照著剛剛黑板上寫的新分割架構來設定報表的話，會因此多增加了一項「生產」的工作。」

他指著表上藍色字樣的「生產」工作接續說：「我們剛剛討論說要把發包裡面設定更詳細的進度認定規則，也就是查核點。 透過這樣事先講定的查核事項，我們將可以解決發包這工作中因為主觀認定造成可能各說各話的問題。 」

「但是」他頓了頓，「各位看一下我圈起來的地方。」

「你們看，在之前還沒有增加生產這項工作前，Eric的報表看起來其實是還合情合理。 可是一旦增加生產這工作後，他成本結構這部分看起來可就有點不太對勁了。」

他接續說：「發包這工作雖然是指把硬體元件發包出去製造，可是其實都只是些採購的活動，如比價、議價、簽約甚麼的。 用Hardware的製造金額來計算所謂預計花費不是有點奇怪嗎？」

另一個工程師開口說到：「啊！ 原來如此！ 所以發包也應該計算人力就好吧。 而把硬體的費用移到生產這工作下？ 這樣就能更貼近現況了吧！」

Alex這時候開口：「還要在考慮更深一層喔！」

他環顧一下會議室的眾人：「生產歸生產，但就算對方生產好後，我們還要做驗收做QC。 QC時也有可能發現東西不通過並要對方修改，若硬體金額一下就算進去，我們不是可能吃虧嗎？」

Alex接續說：「就像剛剛提到買冷氣的例子。 我既然是客戶，我或許會在購買時付一部分的訂金；但很可能要等裝好並驗收才付最後一部分的錢。 可能是1比9；可能是2比8。 但照你的方法來看的話，Eric專案的QC工作下面只有我們內部人員的薪水。 這並不能說不對，但是對我們控制承包商來說不就不太合理了嗎？」

剛剛的工程師辯說：「難道我們不能扣款嗎？ 等到驗收通過才付尾款？」

他停了一停，想了一想，又很興奮的繼續說：「而且扣尾款還有好處啊！」

寫黑板的女生抬起頭不解的問他：「好處？ 為何會有甚麼好處啊？」

他急忙的回說：「你..你想，如果我們生產這工作的預定金額是85萬。 那當工作都完成時，我們實獲值自然也是85萬；可是若我們扣款不撥的情況下，AC不就小於85萬嗎？ 這時候CPI不就大於一嗎？ 那不就是好處了嘛！！」

聽到CPI大於一，大家不由得開始露出興奮的表情。

Alex一開始也愣住了，但他反應很快，下一瞬間就大罵了起來：「笨蛋！ 這算是甚麼好處？ 這做法不就跟Eric目前的搞法是一樣的了嗎？」

大家又再想想，發現確實是如此。

Eric目前報表的問題就在於所以已經發包但還沒付款的工作他都讓EV(Earned Value)得到全額認列，但卻拖說因為還沒付款所以AC(Actual Cost)為零；換句話說，他故意營造出Actual Cost低於Earned Value的假象。 之所以這是假象，是因為這AC並非是「低於」預期的支出，而僅僅是「還沒」支出而已。 一但下個月或是甚麼時候承包商來請款時，這AC恐怕會爆表的。 所以目前這報告根本只是唬人的東西。 畢竟AC要反映的這工作「真實超支或是低於規劃」的狀況時，這三個數值(AC、EV、PV)才有比較的意義。

想通這點後，寫黑板的女生接續著說：「所以，站在管理的立場而言，與其去看是甚麼成本名目或是成本結構，或許更重要的是要看這樣的成本結構跟時間還有工作是不是有意義的結合囉？」 「如果我們把成本可能發生的時間跟我們真正準備要投入或支付的方式(如合約)結合在一起時，那這實獲值展現出來的數據才有比較的意義！」

她邊說邊轉頭繼續在黑板上寫了起來：「目前Eric是這樣設定的。」

「但假設我們打算把硬體的款項保留35%等驗收完成後才認定或是支付。 那我們其實應該設成這樣吧？」她劃掉85萬的數字，並把這金額分配到其他工作中。

「當我們把認定的硬體費用拆到三個工作中。 如採購是十萬、生產是四十五萬、最後QC達成後認定三十萬。 這樣的認定方式可以跟我們發包的合約相結合，這樣就完全不會有爭議了；付款跟進度也就可以真的結合在一起。 更好的事情是，當之後我們講到實獲值是55萬時，大家不會認為這數字有古怪、或是不了解那代表甚麼涵義。」

Alex含首：「這樣確實就比較理想，也就不會有Eric報表中的弊端了。 嗯，看來實獲值這東西比我原本想像的深奧多了。 但看來，只要規劃正確的話，其實滿可以反映出狀況的，也將對日後管理幫助很大呢！」

Alex繼續說：「所以看來，之前的問題並非是Earned Value方法的缺陷，而是我們一開始並沒有為這樣的檢測方法先調整好我們專案的做法與WBS的切法。 若下次換個方法來認定進度、並好好切割WBS的話，其實應該是會很好用的囉？」

大家都點頭同意。

這時候，Alex又沉吟了起來：「雖然我們解決了大部分的問題。 只是呢，我發現討論到這邊似乎又衍生出了另一個新問題….」

(待續)