1-14, 省力而非費力

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

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

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


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

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

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

黑板上的字

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

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

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

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

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

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

站在黑板旁的人,就在黑板上寫下了實獲值的公式: 
EV=Budget*進度完程度

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

黑板旁的人聽到Alex計算時,也把這計算結果寫在公式的下面: 
EV=?

看著黑板上的公式與數值,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這兩天重新給我們一份更可靠的進度狀況。 那我們自己,恐怕得先預做最壞的打算。 如果報告不如預期,或是這兩天他做不出來,我們可能就先朝解除合約的方向做吧? 妳也先再看一看我們跟客戶的合約,有甚麼問題晚點我們再討論。」

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

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

 

 

 

(待續)

若有轉貼需求,請來信討論。 轉貼時禁止修改內容及標題、須保持所有連結、禁止商業使用,並且必須註明原文標題、連結、及作者訊息。
覺得這篇文章好嗎? 請分享給您的朋友
歡迎「讚」一下我們的粉絲專頁,接收最新文章!
張國洋 Joe Chang

現為識博管理顧問執行長,也在台灣百大上市櫃公司擔任管理講師與專案顧問。歷年客戶包含工研院、台積電、廣達、富智康、光寶集團、台灣大哥大、遠傳電信、中鼎工程、建國工程、台橡公司、大同公司、三陽工業、TVBS、特力屋集團、城邦集團、誠品集團等。 為了對抗雙魚座的感性,一直在努力強化理性思維與邏輯思考。 相信邏輯發展能解構任何事物,並讓我們找到合宜的人生策略與方向。

Joe G+ ICON Joe LInkin ICON

2 則讀友回應

  1. 黃弟弟 2009-03-13 05:14:33 第 2 則

    新角色... 現在在公司聽到“新角色“都會一驚. 很怕公司又請個新 VP 來,把員工大砍特砍之後,又光榮退休. 然後公司可以坦然的跟員工說 “沒辦法,那是那個 VP 的風格. 公司是不砍人的“

    • Joe Chang 2009-03-13 15:46:57

      哈 我這故事的新角色倒不是這麼可怕的角色.... XD

  2. 小戴 2009-03-09 22:22:54 第 1 則

    好久沒上線,一上來就看到久違的Alex,真好。
    繼續期待後續中。

    • Joe Chang 2009-03-10 16:32:29

      下集要出現新角色啦~~~