- 前情提要 -
Alex跟團隊開會，發現Ericr這份報表是基於「生產不是自己做，所以一旦發包出去就覺得那項交付標的之硬體價值已經完全取得」所做出的。 加上實際的付款期限往往在驗收後，所以透過此「時間差」，Eric的報表就顯得實獲值(EV)似乎大幅超越實支(AC)的假象。

但這樣的報表其實並不合邏輯。 透過Alex與團隊後續的討論，他們發現實務上Eric應該要在專案規劃時就思考到之後金錢流出的時間點，並讓進度跟支出的模式有相同的連結。 唯有如此，之後判定出來的進度才有參考價值。

但這時，Alex似乎又發現了一個新問題…

Alex皺著眉頭對大家說：「雖然我們把交付項目所要做的Activity拆成了三個。 也把硬體的認定價值分別拆到這三個工作中。 但我們恐怕還有一個問題沒能解決。」

「喔？？」聽到還有問題，在座的大家不約而同的發出了聲音。

Alex指著黑板上2.2，也就是「生產」這項工作說到：「這部分我們其實是發包出去的。 所以我們要怎麼認定進度呢？」

Alex停頓了一下，發現大家似乎沒弄懂他的意思，所以繼續說：「我們恐怕很難取得生產過程中的進度數值吧？」

一個工程師不解的回答：「為何不行，我們請承包商回報進度值不就好了？ 現在我們一般都是每個禮拜追蹤一次專案進度。 那之後每個禮拜也請承包商對口的PM報個進度值來不就好了？」

Alex知道這位工程師比較少對外，大部分時間都埋首於實驗室的工作，有這樣的誤解也可以理解，所以耐著性子回答他說：「這當然是可以的，可是承包商一來未必願意。 那這部分還好解決，下次把這樣的要求直接列在合約條款中就好。 但另一個比較麻煩的問題在於，就算他給了個數值，比方說32.54%好了。 你又如何知道那個32.54%是可信的呢？」

寫黑板的那個女生這時候不解的舉起了手：「老大，可是我不懂。 這數值有很重要嗎？」

Alex回答說：「有很重要！ 一來這可能涉及我們將怎麼付款；二來，若根據書上實獲值的公式，這似乎是計算上的關鍵喔！」

大家一聽，慌忙翻起了手邊講專案管理的書。

站在黑板旁的人，就在黑板上寫下了實獲值的公式： 

Alex看著黑板上的公式繼續說到：「所以，若生產這部分原始規劃的總價值是45萬元的話。 那當廠商跟我們回報32.54%進度時，表示我們…欸…就有取得大概15萬左右的實獲值吧？」 他一邊說著又一邊在桌邊的計算機上敲著：「嗯，算出來是14萬6千多」

黑板旁的人聽到Alex計算時，也把這計算結果寫在公式的下面： 

看著黑板上的公式與數值，Alex旁邊的年輕工程師有點茫然的問到：「Alex，我不懂，這有甚麼問題嗎？」

Alex看他一眼，有點訝異怎麼大家還沒聽懂，於是繼續說到：「你們沒發現嗎？ 照實獲值的認定標準，PV是跟時間會有連動的影響啊。 」

Alex指著書上的公式：「你們看！ PV的計算方式是跟著Baseline的時間而走。所以若隨便回報一個數字而沒根據時，那進度上就會有落差了。 換句話說，EV跟PV就有了差距。」

他繼續說：「從監控的角度而言，我們將會因此而變得無法掌握專案真正的狀況！ 也等於開了一個讓PM可以作弊的方便之門。」

Alex嘆口氣繼續說：「更糟的是，在這種整段外包的情況下，如果付款條件還不是所謂的Progress Payment的話，那很可能連EV跟AC也有可以各自解讀的空間啦！」

大家低頭開始思考。

其中一個工程師舉手：「我們難道不能派人到承包商那邊去稽核進度，然後做嚴謹的進度回報嗎？」

Alex看著天花板想了幾秒，回答他說：「不，這方法有點不切實際。 一來這樣等於多耗費人力物力，但我們管理應該朝省力有效的角度思考。 再來，就算派個人過去算恐怕也沒幫助的喔！」

這回答讓提問的工程師嚇一跳：「是..是這樣嗎？」

Alex看他一眼又說到：「我們大多是Lump sum的合約，也就是總價承攬。 在總價承攬下，我們往往是做完驗收後才付款、中間往往不太介入去管理。 事實上，之所以會走Lump Sum的合約，就是生產過程我們並不想管；如果今天我們還要派人去詳細的監督，那不就失去意義了嗎？」

Alex繼續又說：「當然，這些問題並非不能靠合約的制定來做規範。 但是實務上我們也未必有專精那些元件的人去當監工。 就算勉強派去了，恐怕也未必就真有辦法去認定他們的真實進度…」

「所以這該如何是好呢？」Alex搔起頭髮來。

坐在Alex旁邊的工程師一直在翻著手上那本講Earned Value的書，這時候他突然指著其中一段並說起來「啊！ 若我們用這條所謂0/100的認定方式，不就是處理這類工作的一種認定方式嗎？」

他興奮的繼續說道：「既然我們付款是工作完成時，那沒完成前不管做多少都可以用0%來認定。 除非廠商最後做完並交付給我們，否則我們都不承認進度呢？ 這樣不就能讓EV的認定與付款條件連結在一起了，或許還有實際出金的時間差、但那往往已經可以忽略不計了。」

Alex點點頭：「這樣的認定方式或許有些嚴苛，但在剛剛描述的情境中，似乎是一種能跟實情更貼切的認定方法。」

Alex又問道：「但萬一跟承包商的合約時間很長，我們不是結束才付款，而是中間會有幾次付款的話呢？ 這又該怎麼辦？」

這工程師又指著另一段文章說：「若是這樣的情況，那我們或許可以根據查核里程碑的方法來認定！」

他頓了一下，突然靈光一閃：「這其實不就是我們稍早討論過的方法嗎？ 預先訂好認定的查核點，一旦有達到條件就得到進度，並可得到合約議定好的比例貨款。 這樣不管是付款條件或是進度認列就都可以結合在一起啦！」

看著書的另一章節，他接續著又說：「所以另外這章提到50/50的進度認列方法，或許就適合那種Downpayment是50%而工作做完才結清尾款的類型囉？ 若還有其他的付款條件，也可能按照狀況再另外設定的。」

Alex點頭：「所以照我們目前討論的結論而言，規劃還是最重要的。 如果沒有一個明確定義好的規劃，那專案最後很可能變成各說各話，用甚麼方法來判定都會失真。這樣萬一案子碰到困難時，就很難導正回來了！」

Alex拿起Eric的報表繼續說道：「我可以理解Eric希望案子繼續的想法，只是在此之前，恐怕他需要再提供更詳細的資料給我們大家。 而我也很擔心，最後可能我們會發現這案子是得先停損的。 目前我的直覺告訴我，案子的AC恐怕是大幅超過EV的，且完成時的總成本很可能會很嚇人。」

他轉頭面對那個女生工程師：「無論如何，你去請Eric這兩天重新給我們一份更可靠的進度狀況。 那我們自己，恐怕得先預做最壞的打算。 如果報告不如預期，或是這兩天他做不出來，我們可能就先朝解除合約的方向做吧？ 妳也先再看一看我們跟客戶的合約，有甚麼問題晚點我們再討論。」

接下來他環顧會議室：「那大家對這結論覺得如何？ 如果沒問題我們就先這麼進行吧！」

大家點頭，也就各自散會離開了。

(待續)