【zz】如何建立專案的里程碑

        偶爾跟一些業內人士交流，發覺部分人士對“里程碑”的作用與如何建立里程方面有很大的意見差異，難怪一些技術人員對工作分解架構（WBS）感覺困擾。
        當我們在路上行走的時候，會在沿途觀看路標，當到達某一個心目中的路標時，我們便知道還有多少路或多少時間才能夠到達終點。這些路標是我們在旅程中的里程碑，讓我們可以清楚地知道目前所在，離開目的地有多遠，讓我們能估算何時才能夠到達目的地。
        讓我們利用硬體供應商或渠道商的供應里程碑來作一個簡單的說明，硬體裝鉗完成後或收到廠家運到的產品時便是一個里程，把商品送到客戶辦公室讓客戶簽收後便是另一個里程，安裝測試後讓客戶驗收便成為最後一個里程。完成這三個里程後便知道專案已經完結。

軟體開發的里程碑

        當進行軟體開發的時候，我們也需要建立開發專案的里程碑，才能夠知道本身的進度，但最重要的是里程碑可以用來建立收費的關口。為什麼有這個說法呢？
        軟體開發服務的企業，往往在簽訂協議時收取一筆定金，然後需要支付數月所需的開發組員薪資，而且軟體開發服務商往往未能在指定時間內完成開發的專案，各種原因導致專案延誤，那麼便需要企業應用本身的流動資金來應付。
        為什麼客戶往往在簽訂協議後，付了首期定金，然後到專案差不多完結的時候才再支付一部分，但還是扣起部分款項到維護期後才把餘款付給服務商。這可能需要好長的一段時間才能夠把餘款收回。其中一個主要原因是因為客戶在開發過程中看不到里程碑，對能否達到預期的目標沒有信心。

哪裡才算里程碑？

        如何才算是一個里程碑呢？簡單的說是到達一個階段可以讓客戶看到部分結果的地方。就以軟體開發為例（如左圖），要開發一套軟體，我們需要經過一定的流程或階段。分別為資訊蒐集、需求分析、系統設計、系統開發、系統測試。但只有四個階段產生交付物，分別在資訊蒐集階段後將產生一份《需求說明書》、在需求分析後產生一份《功能說明書》、在系統設計階段後產生《系統邏輯說明》及《DFD（Data Flow Diagram）圖》和在系統測試階段後產生《測試報告》。每一份交付物的完結說明我們已經完成了一個階段的工作，在客戶確認這一份工作成果後我們才進入下一個階段的工作。
        每一份交付物將是整個系統開發過程中的“里程碑”。所以里程碑的建立必需連帶交付物，而這交付物必需讓客戶確認。當客戶確認我們的交付物後，也是客戶確認我們已經在系統開發的過程中到達某一個指定的階段，完成某一部分的工作。

確認里程碑的交付物

        當我最初執行專案管理的時候，往往把交付物送交客戶確認後，兩三各星期下來都沒有回應，不斷跟進也沒有多大的進展，相信很多從業人員往往會說“客戶需要太長的時間來進行確認，將影響專案的進度”；又或者會說“客戶不會確認過程中的任何交付物，因為......（很多理由和原因）......”！這便是一個專案經理的經驗問題，而不是客戶會不會、或者願意不願意確認的問題。
        當我們進行專案啟動集會的時候，專案經理便應該跟專案贊助人很明確地說明“確認”專案過程中所產生的交付物的重要性，同時更應該清楚地說明交付物在沒有確認前將不能夠開展下一階段的工作，在沒有得到客戶確認一個階段的交付物時，繼續開展下一階段的工作對專案會帶來莫大的風險，因為任何的工作都可能被客戶推翻，可能變成廢物，或需要不斷進行修改。這不但浪費組員的時間及士氣，更嚴重地延誤專案的進度，延誤專案的最終交付，導致專案的超時、超支。

明確的溝通

        在啟動集會中我們更應該透明化。應該很詳細地讓專案贊助人及其他參與集會的專案涉及人清楚地理解專案的整個流程和進度時間計劃。讓他們對專案的運作有初步的認識和了解，好能跟專案小組互相配合。同時更需要採用各種不同的軟技巧（參閱“專案管理技巧新探”）來讓客戶依時確認交付物，讓我們能夠進入下一階段。
        當客戶確認我們所提交的交付物後，便是客戶同意我們已經完成了某一個階段的工作，如果我們在合約談判的時候把服務收費時間按專案交付物來讓客戶支付，那麼我們不但能夠有助企業的資金流動，更不用為收費的事情因專案的延誤跟客戶發生爭執。故此在專案建立的初步階段，我們便應該建立有關專案的里程碑和工作架構分解。讓我們能更有效的管理專案的進度。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12231076/viewspace-92/，如需轉載，請註明出處，否則將追究法律責任。