專案外包的衝突與兩難–delay的處理

「專案外包」的過程當中,除了硬體成本之外,時間就是最大的成本來源,而Delay所造成的影響,不但是客戶滿意度的降低,更是承包商成本的提高。所以,當Delay這件大家都最不願意的事情發生後,所謂的解決之道,就是在成本和滿意度中間求取一個平衡。

而在求取平衡的過程當中,筆者有幾個心得與大家分享。

心得一:管理客戶事前的預期

當客戶對功能、Schedule、品質,有著不切實際的期待時,就很容易會產生極大的不滿意。尤其是客戶在專案進行的過程中,很容易就蹦出新的想法出來,或者是試圖將專案規格書做另外一種新的詮釋,以達成客戶真正的Needs,但是往往這種行為,會造成專案的開發方向和所需資源也跟著改變了,在這種情況下,若是期待專案還能按照原本的時程進行,其實是不太切實際的。

為了不能讓客戶有錯誤的預期,以免到時候預期過高造成不滿意,PM需要透過不斷的跟客戶解釋為何此項要求是Out of Scope,來調整客戶的預期。當然,Out of Scope不是不能做,只是雙方要透過談判來達成協議,看是是要做Scope的取捨,還是要對Schedule進行取捨。

在這談判的過程當中,唯一的黃金規則就是,表達出協助客戶完成Business Goal的決心。至於談判的底限到底在哪,有時候要看案子的金額大小、有時候要看後續合作機會、有的則是要看這樣的需求是不是Common Sense…等,不可能全讓,但也不可能全不讓,完全都是得視情況而定。

心得二:管理模糊不清的需求

需求定義的越清楚,專案的時間就越容易估計的準確,但是在接外包案的過程當中,往往都會接到需求定義的不太清楚的案子,這種時候,承包商的業務和PM之間,溝通就要有默契,在報價的時候,就要把架構大翻修的風險,估進報價當中。

而且在面對需求不確定的專案上,承包商要當一個「真小人」,事先就要讓客戶知道,因為需求的模糊,所以在專案的進行中,會根據Prototype demo的結果,反應在Schedule的修正上。如此一來,客戶才不會有錯誤的預期,造成對承包商的不滿意。

心得三:管理雙方認知落差

承包商和客戶間對Scope的認知,其實是一個連續且動態的收斂過程,也就是說專案初期的Scope,和最後實作出來的Scope通常都不一樣,所以讓Scope收斂加速,讓專案不要一直做了又改,錯了再改,就是讓專案能meet schedule的重點。

這點筆者就很推崇XP開發法中所主張的「透過經常的Demo得到客戶端的回應」,透過經常的小規模的Demo,可以得知是否雙方對規格書的理解有出入,早期發現早期治療,到專案快收尾才發現做錯,對承包商和對客戶,都不是好事情。

心得四:隨時監督Schedule的Delay風險

承包商對於Schedule的評估應該是一個連續的過程,隨時監督著是否可以Meet Schedule。因為專案的delay通常是結構性的原因,通常你miss掉一個milestone的時候,常常就會發生後面的milestone也會連續miss掉。所以說,若是承包商發現專案開始miss掉milestone時,就該事先預警,好讓管理階層能夠先進行動作,諸如:承包商再投入更多一點的人力、和客戶協商修改上線相關的行銷活動、縮短決策流程,有什麼事情就當場討論當場解決…等,重新安排資源。

心得五:管理delay後的彌補方案

當delay發生的時候,因應delay而提出的第二次時間表,幾乎就是承包商最後的一次機會了,所以這次不管怎麼樣,絕對要將規格規範清楚,然後估計一個較為準確的時間表。

心得六:因應風險作不同控管方式

面對Delay的重要精神,就是早期發現早期治療。當專案不確定比較高的時候,Milestone和check point就要設立的比較多一些,並且將客戶較重視的功能和技術難度比較高的Task,盡量排在專案初期進行,讓專案剩餘的風險較能掌握。

留言