項目管理新方法—關鍵途徑分析

作者： techrepublic.com.com
Thursday, May 20 2004 9:55 AM 如果一個項目的復雜程度沒有達到令人難以置信的地步，那么不妨采用一下關鍵途徑分析（Critical Path Analysis），它提供的是一種幾乎完全非技術性的項目管理方法。


對于一個項目的最終成功來說，于項目的時間安排是怎么強調是都不為過份的。來自Standish Group的"噪聲報告（Chaos Report）"和來自KPMG Canada的一項名為“不成功的信息技術項目問題在哪兒？”的調查均認為：項目時間安排的不合理是造成項目失敗的主要原因之一。

現(xiàn)在市場上有很多功能強大的工具可以幫助管理人員對所有類型、所有規(guī)模的項目進行管理，Microsoft Project就是其中的一種。應用這些工具可以對資源進行分配，完成報告的制作，并且對各項任務進行時間規(guī)劃。但是，由傳統(tǒng)的水平線和里程標所構成的標準的Gantt圖表并不是對項目中所有任務進行表示和分析的唯一途徑。Critical Path Analysis（CPA）是項目經(jīng)理們可以應用的另外一種有價值的工具。

連點成線
要完成CPA，不需要應用價格昂貴的項目管理軟件，只需要借助一支鉛筆和一張紙就夠了。當一個項目處于格式化的階段，基本的任務都已經(jīng)確定的時候，這種方法就尤其有效了。如圖A所示，每項任務在得到確定之后都可以用一條直線來表示，在直線的兩端各畫上一個圓點，分別代表任務的起點和終點以及預計所需的完成時間。

圖A：


與Gantt圖表相同，圖A中的直線起于左端而終于右端，所以有些人喜歡在右端標上一個向右的箭頭，如圖B所顯示的那樣。

圖B：


數(shù)據(jù)庫應用實例
下面就讓我們以一個簡單的數(shù)據(jù)庫應用項目為例，來對CPA進行說明。

如下所示是一個簡化了的任務清單和預計的完成時間：


必要準備：1天

設計數(shù)據(jù)庫：3天

創(chuàng)建數(shù)據(jù)庫：7天

創(chuàng)建觀察點：2天

創(chuàng)建存儲程序：2天

設計類別：2天

業(yè)務規(guī)則編碼：4天

CRUD操作編碼：5天

錯誤日志編碼：2天

設計GUI：7天

創(chuàng)建菜單：3天

建立應用導航：3天

創(chuàng)建數(shù)據(jù)輸入窗口：4天

建立用戶注冊：2天

創(chuàng)建報告：4天

終端用戶培訓：3天
必須有始有終
在列出了上面所示的清單之后，接下來要做的就是排列各項任務的完成順序。在我們所舉的這個簡單的例子當中，在數(shù)據(jù)庫設計完成之前，是無法進行數(shù)據(jù)庫的創(chuàng)建的，但是一旦數(shù)據(jù)庫創(chuàng)建完成，其他的一些任務，比如觀察點和存儲程序的創(chuàng)建，就可以同步進行了。如圖C所示，當一項任務的開始要依賴于另外一項任務的完成時，代表該項任務的直線的起點就應該設在另外一項任務的終點。

圖C：


當多項任務同步開始進行時，代表這些任務的直線就可以變成從同一個起點開始，到同一個終點結束的曲線，如圖D所示。這里就沒有必要一定要用直線來表示了。

圖D：


應用這種方法，我們現(xiàn)在就可以建立一個包含了所有任務的圖表。如果你手頭現(xiàn)在有一張比較大的紙，你就可以做一個比較大的圖表，從左向右依次表示各項任務。你還可以做一系列比較小的圖表，就像我在圖E、F、G、H、I中為大家演示的一樣。

圖E：


圖F：


圖G：


圖H：


圖I：


確定關鍵途徑
接下來要做的就是對已經(jīng)做好的圖表進行檢查，按照從點到點的方法把最長的途徑連接起來。這就是我們所說的關鍵途徑：要完成所有必須完成的任務可能花費的最短時間。

在我們舉例的這個數(shù)據(jù)庫應用項目當中，關鍵途徑是：


必要準備：1天

設計數(shù)據(jù)庫：3天

創(chuàng)建數(shù)據(jù)庫：7天

創(chuàng)建觀察點：2天

設計類別：2天

CRUD操作編碼：5天

設計GUI：7天

創(chuàng)建數(shù)據(jù)輸入窗口：4天

創(chuàng)建報告：4天
完成以上各項任務，所需要的最短時間共計為35天。

要在我們制作出的圖表上確定出關鍵途徑，最簡單的方法就是使用著重色。著重表示那些需要單獨完成的任務和那些可以同步進行的任務當中耗時最長的任務。大家現(xiàn)在已經(jīng)知道，各項任務必須要絕對按時完成（或者更快）。在關鍵途徑上的任何一項時間推遲都會造成其他依賴于它的任務完成時間的推遲，進而造成整個項目完成時間的推遲。在關鍵途徑上的項目應該交給那些你最可以信任的、最可靠的人來完成。那些需要時間較短的平行項目相對來說條件比較寬松，可以交給那些經(jīng)驗不太豐富的員工去完成。在這些相對較為寬松的項目完成之后，富余出來的資源可以被應用到那些關鍵途徑上的任務中去，更好的完成這些任務。

調整變化
在項目的進行過程當中，你可能會找到一些途徑，對任務進行調整變化，或是為了保證項目的按期完成而把一些任務從關鍵途徑上轉移。你可能還會找到一些途徑來縮短整個項目的工期。在我們上面所舉的這個例子當中，如果我們決定在進行CRUD操作編碼、業(yè)務規(guī)則編碼和錯誤日志編碼之前進行類別設計并不重要，那么這四項任務就可以同步進行，這樣一來，完成關鍵途徑上的各項任務所需要的時間就縮短了兩天。終端用戶的培訓也可以更早的開始——比如說可以在GUI的設計完成之后——但是這項任務的預計完成時間本來就已經(jīng)很寬松了，所以改變它的起始時間并沒有多大的意義，不會在整體上節(jié)省項目時間。

如果在開始制表的過程當中你忘記了某項要完成的任務，可以在制表過程完成之后將這項任務加進去。比如說，在上面所舉的數(shù)據(jù)庫應用項目的例子當中，我們忘了DLL編碼這項需要五天時間來完成的任務。把這項任務需要依賴的前一個項目的終點當作這個項目的起點——在我們所舉的例子當中，前一項任務就是類別設計。把要依賴這項任務的下一項任務的起點當作這項任務的終點——在我們所舉的這個例子當中，下一項任務就是終端用戶培訓。在添加完這項任務之后，重新對兩點之間的關鍵途徑進行審查，看看新添加的項目是否會對兩點之間的項目時間產(chǎn)生影響?，F(xiàn)在，兩點之間的關鍵途徑上的任務包括：


CRUD操作編碼：5天

設計GUI：7天

創(chuàng)建數(shù)據(jù)輸入窗口：4天
總計時間為16天。

由于完成兩點之間的關鍵途徑上的各項任務一共需要16天的時間，遠遠超出了完成新添加的任務所需要的五天時間，要完成這項新任務的時間條件就非常寬松了，因此，新任務的添加不會給整體的項目時間帶來影響。如果完成新添加的任務所需要的時間要比完成原來的關鍵途徑上的任務所需要的時間長，那么新添加的任務也就成為了新的關鍵途徑上的任務了，整個項目的預計完成時間也要相應的延長了。

利弊分析
盡管從理論上來說，應用我們所介紹的這種簡單的方法進行時間規(guī)劃的任務的數(shù)量是沒有限制的，但是，當可以同步完成的任務的數(shù)量很多時，情況可能就會比較混亂。與此同時，一些大的調整變化，比如說同時添加多項新任務，可能會使圖表的重新制作成為必須。

盡管如此，從另外一個方面來看，CPA仍然不失為一種對項目進行時間規(guī)劃和追蹤的快捷方式。特別是在一些小型項目上，它的應用就尤其具有吸引力。因為那些專業(yè)化的項目管理軟件對于小型項目來說不是大材小用了，就是根本沒有什么用處。

【?發(fā)表評論?0條?】