專案管理之工作的估算

在專案規畫階段，即使大部分專案管理的文書作業都忽略不看，WBS或甘特圖通常還是很重要的一項，因為有了初階的工作計畫，PM才有辦法進行後續的追蹤。既然WBS是規劃的產出，那麼勢必要有參考或估算的基準，也因為估算難免與實際狀況會有些許落差，因此才需要不斷進行監控與改善。我們常說WBS是將專案工作拆解到足以掌控的大小(例如以80小時工作量為一個工作包之單位)，但如何拆解成工作包又是一門學問。

雖然專案管理知識告訴我們，進行工作包拆解的過程暫不需考量時間、成本(有其先後順序與相關性)，但實務上這些東西都是環環相扣，往往PM能估算的時間有限(今天被接收到專案，過幾天就必須提報規畫初稿)，因此PM只能快速、綜合性評估，所以我們在拆解WBS時，也常引用了成本管理中裡常用的類比估算法，也就是拿過去相似的經驗來套用，或是再加上部分的變異參數(例如兩個專案的人員程度不同)，快速初估工作項目、時程後，再同樣類比推估出所需的成本。

CMMI(能力成熟度模型)中提供了軟體開發專案的另一種估算方式，叫做功能點數，簡單來說，功能點數是將預定開發的軟體系統，依據系統開發範疇(邊界)，將功能區分為外部輸入(External Input File，簡稱EI，例如新增、刪除)、外部輸出(External Output File，簡稱EO，例如訊息輸出)、外部查詢(External Inquire File，簡稱EQ)、外部介面檔案(External Logical File，簡稱EIF，例如與其系統外的資料庫進行介接)，以及內部邏輯檔案(Internal Logical File，簡稱ILF，也就是在系統內部自行判斷的邏輯程序)，如下圖。透過點數估算出來的專案規模，再引入組織內部的人力產值，即可估出相對應的時間、人力成本。

這種做法有別於實務上的常用方法，實務上雖然也是從功能->工作量->工時->成本的邏輯逐一推算，但大部分取決於技術人員(或主管)主觀對功能難易度的認定，若沒有過去經驗參考，估算的準確度就會有比較大的差異。而功能點數是以使用者角度去檢視專案功能，純粹由上述五個層面去計算專案的規模，這種算法的好處是摒除了主觀意見，但缺點是，主觀意見是由於專案本身由"人"在執行，技術人員(或主管)在估算工作量時，勢必會考量自身的loading、公司的需求、專案的急迫性等各個環節，這些考量雖然沒有量化的數據，但我們不得不認同這些因素真的都存在，一旦我們太客觀去拆解專案工作，很可能又會衍生出其他潛在的風險。