在專案的規劃階段,PM經常會遇到一個難題,如何取得預估的工時?

在專案前期,有很多狀態是不明朗的,充滿變數的。

而PM的重責大任就是在一片混沌當中,撥雲見日,排除許多的不確定因此,讓專案可以逐步推進。


PM要取得預估的工時,經常會遇到以下的困境:


信息尚未正式發布

這是PM經常會遇到的難題,公司必須審核通過完整的專案計劃,才會正式公佈(尤其是人力調派),而PM要完成這個完整的專案計劃,使用的大多是非正式的資源。

當專案的信息還沒公佈的時候,這個專案會不會通過,以及這位組員是不是一定會編列在這個專案當中,都是未定之數,換言之,專案PM並沒有實質的管理權限


專案團隊尚未正式籌組

這個問題跟上面的困境是息息相關的,由於專案團隊還沒有正式建立,因此,此時PM們手上的問題,通常會被列為重要而不緊急。(甚至當成不重要又不緊急)

此外,當專案團隊尚未正式籌組時,還有一個問題,那就是,專案組員的職等有可能是比專案PM高的,在這個時候,PM經常會遇到雙重的壓力,一方面來自於專案計劃的進度,一方面來自於專案組員候選人的不配合

這是一個全新的專案

對於專案組員來說,這是一個很大的挑戰

例如:當Vista上市時,OEM的軟體必須取得Vista的認證,那同時也表示,公司內沒有人做過這件事

作業系統的更新,或是新平台的介接,核心引擎的更新等等,都屬於這種全新專案的類型。



PM可以運用的資源有以下數種

善用組織過程資產

PM必須有調閱公司以往專案開發資料的權限。

無論是紙本或是電子檔案,甚至是公司內的網域權限。

在專案的啟動階段,PM最好能先找出類似的專案,尤其是其中的人力、費用與風險紀錄。

當PM有了這些以往的紀錄資料,可以用來跟專家討論,做為進一步收斂的素材。

剛才有提到,如果PM手上拿到的是全新的專案,組織過程資產還有效嗎?其實,還是有功用的。

以上述的Vista認證為例,雖然公司沒有取得過Vista認證,至少曾經取得過商標、專利,這些都是可以參考的。


專家判斷

根據PMP的說明,專家判斷是成本最低的工時預估方式

而且經常是不精確的。

專家判斷能夠精確的前提是,這次的專案跟以往的某個專案的相似度非常高,那麼,這種狀況下的專家判斷的可信度就很高。

例如:公司之前做過展場的文字雨,而這次的專案內容也是要做文字雨,不同的是,把文字變成卡通的圖案。

這樣PM就可以把預估的重點放在兩個專案的差異上。

專家判斷經常會使用類比估算法,又稱為上而下估算(Up-Bottom estimating)。

例如:公司曾經花2個人月整合出力回饋裝置。

2個人月是上層的工時,必須逐步由上而下拆解,例如:美術人力佔多少?工程人力佔多少?軟硬體的比例?整合與測試的時間等等。

注意,不同的平台,有時會讓專家跌破眼鏡;專家判斷給PM的是一個參考值,但是這個參考值並非是一個保證。

尤其是介接在不同的系統上,會讓變數提高,這必須進入風險判斷的流程內。


參數估算

當PM要預估某一個階段任務時,可以善用參數估算。

例如:測試階段的bug數量的預估公式、貨艙容積或貨櫃數量計算公式,這些參數估算可以協助PM取得數字,並且釐清這個任務的規模。

但是,在使用參數估算的數學模型時,請一併考慮人的因素

資深有經驗的組員,跟沒有經驗,第一次加入專案的組員,在數值的反應上是不一樣的。

比較好的做法是,替人力加上條件與變數

而人力條件反應出經驗。

例如:工程組長的出錯率是0.3%,緩衝時間是0.2%,新進人員的出錯率是0.6%,緩衝時間是1.5%,當然,這些變數必須要有組織過程資產做為依據。


三點估算法則

三點估算法的公式是這樣的:

工期=(最理想的工期+4X最可能的工期+最悲觀的工期)/6

但是,最理想的工期、最可能的工期,以及最悲觀的工期,要從哪裏得知?

這三個數字最好是務的執行者自己評估出來給PM,這樣結果才會正確。

如果PM是因為公司或主管的壓力,自行設定看起來很漂亮的數值,這樣是沒有多大的意義的。

 

關鍵路徑

受過專案管理訓練的PM,都會專注在關鍵路徑上,因為那是專案的瓶頸。

但是,在專案的實際執行狀況下,PM會發現,非關鍵路徑上的任務很少,有寬餘時間(Slack Time)的情況也不多。

更令人沮喪的是,非關鍵路徑上的任務總是會變成關鍵路徑上的任務,造成專案的大膨脹。

要如何避免這種狀況?慎重判斷關鍵路徑與非關鍵路徑

如果可以的話,由具備經驗的人來出任這項任務,確實的將瓶頸界定出來。

否則你將會發現,專案裏頭處處是地雷,每一個任務都在關鍵路徑上。


其它的補充

關鍵鏈

相對於關鍵路徑上的方法,關鍵鏈也是一種工時預估的做法。

關鍵鏈是由高德拉特博士所獨創的。

高德拉特博士在《關鍵鏈》一書中,指出專案的三個共通問題:

1.成本超出預算

2.時間超出期限

3.經常犧牲設計內容


在《關鍵鏈》一書中,高德拉特博士也明白的告訴我們,執行者通常都會隱藏性的加上安全時間,讓自己不要受到時間的壓力。

因此,PM取得的資訊,都是已經加上很多緩衝時間的,當PM再以這種時間為基底列入計劃,專案的預估時間一定會超過

PM要如何使用關鍵鏈呢?PM可以將各個任務的緩衝時間減少,而增加專案後期的緩衝時間。

例如:

我們取得的工時是:程式修改5天,美術2天,整合2天,測試4天

我們會在專案期限內加上安全期間:程式修改5天+1天,美術2天+0.5天,整合2天+0.5天,測試4天+1天 (總共加上3天的緩衝期)

關鍵鏈的做法是:程式修改5天+0.5天,美術2天+0.25天,整合2天+0.25天,測試4天+0.5天 + 1.5天緩衝期 (緩衝期工時不變,由各階段中的時間移至專案後期,如果各階段的緩衝期全部刪除,在真正執行上也會有問題,例如:信任與溝通)


PM逐步收斂法

在真正執行的時候,有可能遇到同事(尚未編列為專案組員)不配合的狀況,要怎麼辦?

我們不可能空等一個預估值。

這時候PM可以採取一種做法,透過組織過程資產或其它的專家,先提出一個預估值,再由這位同事去做細部的規劃,這種方式可以加速專案的前進,不至於讓進度懸在一個未知的狀態。




PM如何取得預估的工時?

在專案的規劃階段,PM經常會遇到一個難題,如何取得預估的工時?

在專案前期,有很多狀態是不明朗的,充滿變數的。

而PM的重責大任就是在一片混沌當中,撥雲見日,排除許多的不確定因此,讓專案可以逐步推進。


PM要取得預估的工時,經常會遇到以下的困境


信息尚未正式發布

這是PM經常會遇到的難題,公司必須審核通過完整的專案計劃,才會正式公佈(尤其是人力調派),而PM要完成這個完整的專案計劃,使用的大多是非正式的資源。

當專案的信息還沒公佈的時候,這個專案會不會通過,以及這位組員是不是一定會編列在這個專案當中,都是未定之數,換言之,專案PM並沒有實質的管理權限。


專案團隊尚未正式籌組

這個問題跟上面的困境是息息相關的,由於專案團隊還沒有正式建立,因此,此時PM們手上的問題,通常會被列為重要而不緊急。

此外,當專案團隊尚未正式籌組時,還有一個問題,那就是,專案組員的職等有可能是比專案PM高的,在這個時候,PM經常會遇到雙重的壓力,一方面來自於專案計劃的進度,一方面來自於專案組員候選人的不配合。

這是一個全新的專案

這對於專案組員來說,是一個很大的挑戰。

例如:當Vista上市時,OEM的軟體必須取得Vista的認證,那同時也表示,公司內沒有人做過這件事。

作業系統的更新,或是新平台的介接,核心引擎的更新等等,都屬於這種全新專案的類型。



PM可以運用的資源有以下數種

善用組織過程資產

PM必須有調閱公司以往專案開發資料的權限。

無論是紙本或是電子檔案,甚至是公司內的網域權限。

在專案的啟動階段,PM最好能先找出類似的專案,尤其是其中的人力、費用與風險紀錄。

當PM有了這些以往的紀錄資料,可以用來跟專家討論,做為進一步收斂的素材。

專家判斷

根據PMP的說明,專家判斷是成本最低的工時預估方式。

而且經常是不精確的。

專家判斷能夠精確的前提是,這次的專案跟以往的某個專案的相似度非常高,那麼,這種狀況下的專家判斷的可信度就很高。

例如:公司之前做過展場的文字雨,而這次的專案內容也是要做文字雨,不同的是,把文字變成卡通的圖案。

這樣PM就可以把預估的重點放在兩個專案的差異上。

專家判斷經常會使用類比估算法,又稱為上而下估算(Up-Bottom estimating)。

例如:公司曾經花2個人月整合出力回饋裝置。

2個人月是上層的工時,必須逐步由上而下拆解,例如:美術人力佔多少?工程人力佔多少?軟硬體的比例?整合與測試的時間等等。

注意,不同的平台,有時會讓專家跌破眼鏡;專家判斷給PM的是一個參考值,但是這個參考值並非是一個保證。

尤其是介接在不同的系統上,會讓變數提高,這必須進入風險判斷的流程內。


參數估算

當PM要預估某一個階段任務時,可以善用參數估算。

例如:測試階段的bug數量的預估公式、貨艙容積或貨櫃數量計算公式,這些參數估算可以協助PM取得數字,並且釐清這個任務的規模。

但是,在使用參數估算的數學模型時,請一併考慮人的因素。

資深有經驗的組員,跟沒有經驗,第一次加入專案的組員,在數值的反應上是不一樣的。

比較好的做法是,替人力加上條件與變數。

條件反應出經驗。

例如:工程組長的出錯率是0.3%的,緩衝時間是0.2%,而新進人員的出錯率是0.6%,緩衝時間是1.5%,當然,這些變數必須要有組織過程資產做為依據。


三點估算法則

三點估算法的公式是這樣的:

工期=(最理想的工期+4X最可能的工期+最悲觀的工期)/6

但是,最理想的工期、最可能的工期,以及最悲觀的工期,要從哪裏得知?

這三個數字最好是由任務的執行者自己評估出來給PM,這樣結果才會正確。

如果PM是因為公司或主管的壓力,自行設定看起來很漂亮的數值,這樣是沒有多大的意義的。

關鍵路徑

受過專案管理訓練的PM,都會專注在關鍵路徑上,因為那是專案的瓶頸。

但是,在專案的實際執行狀況下,PM會發現,非關鍵路徑上的任務很少,有寬餘時間(Slack Time)的情況也不多。

更令人沮喪的是,非關鍵路徑上的任務總是會變成關鍵路徑上的任務,造成專案的大膨脹。

要如何避免這種狀況?慎重判斷關鍵路徑與非關鍵路徑。

如果可以的話,由具備經驗的人來出任這項任務,確實的將瓶頸界定出來。

否則你將會發現,專案裏頭處處是地雷,每一個任務都在關鍵路徑上。


其它的補充

相對於關鍵路徑上的方法,關鍵鏈也是一種工時預估的做法。

關鍵鏈是由高德拉特博士所獨創的。

高德拉特博士在《關鍵鏈》一書中,指出專案的三個共通問題:

1.成本超出預算

2.時間超出期限

3.經常犧牲設計內容

在《關鍵鏈》一書中,高德拉特博士也明白的告訴我們,執行者通常都會隱藏性的加上安全時間,讓自己不要受到時間的壓力。

因此,PM取得的資訊,都是已經加上很多緩衝時間的,當PM再以這種時間為基底列入計劃,專案的預估時間一定會超過。

PM要如何使用關鍵鏈呢?PM可以將各個任務的緩衝時間減少,而增加專案後期的緩衝時間。

例如:

我們取得的工時是:程式修改5天,美術2天,整合2天,測試4天

我們會在專案期限內加上安全期間:程式修改5天+1天,美術2天+0.5天,整合2天+0.5天,測試4天+1天 (總共加上3天的緩衝期)

關鍵鏈的做法是:程式修改5天+0.5天,美術2天+0.25天,整合2天+0.25天,測試4天+0.5天 + 1.5天緩衝期 (緩衝期工時不變,由各階段中的時間移至專案後期)


PM逐步收斂法

在真正執行的時候,有可能遇到同事(尚未編列為專案組員)不配合的狀況,要怎麼辦?

我們不可能空等一個預估值。

這時候PM可以採取一種做法,透過組織過程資產或其它的專家,先提出一個預估值,再由這位同事去做細部的規劃,這種方式可以加速專案的前進,不至於讓進度懸在一個未知的狀態。



萊行樂 發表在 痞客邦 PIXNET 留言(0) 人氣()