PMP项目管理
第二章 專案生命週期與組織
專案和專案管,是在一個大於專案本身的環境中進,的。專案管,團隊必須,解這個大於專案的環境,只有這樣才能選擇適合於專案的生命週期的階段、過程、工具和技術。本章介紹專案管,環境的某些主要方面。本章討,的題目包括,
專案生命週期 專案,害關係人 組織機構的影響 專案生命週期
專案經,或組織可以把每一個專案劃分成,干個階段,以,有效地進,管,控制,並與該專案實施組織的日常運作,繫起,。這些專案階段合在一起稱為專案生命週期。許多組織,別出一套具體的生命週期供其所有的專案使用。
2.1.1 專案生命週期的特徵專案生命週期確定,將專案 的開始和結束,接起,的階段。,如,當某個組織發現 一個可以考慮,用的機會時,它通常會責成有關人員進 ,可,性研究,以決定該專案是否值得,項。專案生命 週期的定義有助於專案經,,清是否應將該項可,性研 究視為專案的第一個階段,或者
將其當作一個單獨的專案。當這種初步努,的結果無法,別清楚時,最
好將其當作單獨的專案處,。專案生命週期的階段與第3 章詳細介紹的專案管,過程組,同。
從專案生命週期的一個階段轉到另一階段通常是某種形式的技術交接,這種階段轉移通常也由這種技術交接確定。前一階段產生的可交付成果通常要接受是否已
經完成和是否準確的審查,在驗收之後才能開始下一階段的工作。但是,如果認為所涉及的風險是可以接受的話,後一階段可以在前一階段可交付成果通過驗收之前開始。這種將通常按照先後順序完成的,個階段重迭的做法是應用所謂快速跟進進,壓縮技術的一個,子。
目前沒有確定專案生命週期的唯一最好辦法。某些組織的既定方針是用一個專案生命週期以標準的方式處,所有的專案,而另外一些單位則允許專案管,團隊為其專案選擇最適合的專案生命週期。另外,,業的通用做法經常造成本,業內部使用某種約定俗成的專案生命週期。
專案生命週期的定義還將確定專案開始與結束時的哪些過渡,動應包括在專案範圍之內,而哪些則,應包括在內。這樣,就可以用專案生命週期的定義把專案和專案實施組織持續的日常運作業務,繫在一起。
專案生命週期通常規定,
? 專案的各個階段應當從事何種技術工作,,如,建築師的工作應放在專案的哪個階段完成,,
? 專案各階段可交付成果應何時生成,以及如何審查、核實和確認 之
? 專案各階段由哪些人員,與,,如,並,工程要求實施人員,與制訂要求,明書和設計本身,
? 如何控制和批准專案各個階段。,明專案生命週期時可以十分,統,也可以非常詳細。非常詳細的
,明可以包括許多表格、圖表和核對表,使其條,清楚,,於控制。 大多,專案生命週期的,明具有,干共同特點,
? 專案階段一般按順序首尾銜接,通常根據某種形式的技術資訊傳遞或技術部件交接確定。
? 人,投入和成本,開始時低,隨之而增高、而在專案接近收尾時迅速下,。這種模式如圖2-l 所示。
圖2-1,專案成本與人,投入水準在專案生命週期中的典型分佈
? 專案開始時,成功地完成專案的可能性最低,因此風險和,確定性最高。隨著專案繼續進展,成功地完成專案的可能性通常,逐漸上升。
? 專案開始時,專案,害關係人對專案產品最後特點和專案最後成本的影響,最強,而隨著專案的進展,這種影響逐步減弱。圖2-2 形象地,明瞭這一點。造成這種現象的主要原因是隨著專案的進展,變,計畫和糾正失誤的代價通常與日俱增。
圖2-2,,害關係人影響隨著時間的變化
儘管許多專案生命週期具有彼此相似的階段名稱,所要求的可交付成果名稱也極其相似,但其內容絕少,同。某些專案有4 或5 個階段,但另一些專案可多達9 個階段以上。即使在某單一應用,域內,也會有很大差別,一個組織的軟體發展生命週期可能只有一個設計階段,而另一個組織卻可能將其分為功能設計和詳細設計,個單獨的階段。
專案內的子專案也可以有明顯的專案生命週期。,如,一家建築師事務所受雇為他人設計新辦公,時,首先在設計時,與,業主的設計要求制訂階段,隨後又在協助施工時,與,業主的實施階段,協助施工。但建築師本身的設計專案也有自己的一系,階段,包括專案構思、要求制訂、實施、直至專案收尾。這位建築師甚至可以把辦公,的設計和對施工的協助視為,個,同的專案,分別包括各自的明顯階段。 2.1.2 專案階段的特徵每個專案階段,以一個或,個可
交付成果的完成為其標誌。可交付成果是某種有形的、 可驗證的工作成果,,如,技術規定,明書、可,性研 究報告、詳細設計檔或可以工作的樣品。某些可交付成 果可能對應著專案管,過程,而另外一些則是該專案構
思時設想的最終產品或產品的組成部分。可交付成果, 因而相應的階段是為保證恰當地控制專案,達到專案目 的,即取得希望的產品或服務而設計的一般為按順序首 尾銜接的過程的一部分。任何具體的專案,由於規模、 複雜程,、風險水準和現,,制約等方面的原因,階段
可以進一步劃分為子階段。為,,於監視與控制,每 一個子階段,要與一個或多個具體的可交付成果,繫起,。這些事項的大多,,同基本階段可交付成果相,繫,而且階段一般,根據這些事項命名,要求,明書、設計、建造、試驗、試,、交接和其他等等,具體視情況而定。
專案階段的結束通常以對完成的工作與可交付成果的審查為標誌,目的是確定是否驗收,是否仍然需要增加工作,或者是否考慮結束這一階段。經常舉,管,層審查以,決定在,結束當前階段的條件下開始下一階段的活動,,如當專案經,將快速跟進選為,動步驟時即為如此。某資訊技術公司選擇可同時進展的多專案階段的重複生命週期也是這種,子。在收集和分析顧客對一個模組的要求,設計與製作這一模組的同時,對第二個模組進,分析,還可以平,地開始收集和分析顧客對第三個模組的要求。
同樣,在未決定是否啟動任何其他階段時,也可以結束一個階段。,如,當專案已經完成,或者認為風險太大,,允許專案繼續下去時即為如此。
階段的正式完成,包括核准隨後的階段。為,有效的控制,每一階段,要正式啟動,,要根據該階段的具體情況提交為該階段規定允許和預期哪些事項的一項成果。圖2-3 所表示的就是這種情況。階段末可以進,一次審查,明確的目的是取得對結束當前階段並啟動下一階段的核准。有時候,一次審查可以核准,件事。上述階段末審查往往稱為階段
放,口、階段關卡或驗收站。
圖2-3,專案生命週期內的典型階段序,
2.1.3 專案生命週期與產品生命週期的關係許多專案,與實施組織的日常,續業務相,繫。某些組織僅在完成可,性研究、制定出初步計畫或某種其他,似形式的分析之後才正式批准專案。在這種情況下,初步規劃或分析採取,單獨專案的形式。,如,在啟動研製最終產品的專案之前,在研製和試驗樣機或樣品的過程中可能會發現需要增加階段。某些形式的專案,特別是內部服務或新產品研製專案可以提前一段時間非正式啟動,以,為增加的階段或活動取得正式的批准。激發專案的推動,,一般叫做問題、機會或經營要求。這些壓,的後果是,管,層一般必須根據其他潛在專案的需要和資源要求確定這一專案要求的輕重緩急。專案生命週期的確定還會在專案結束時,為,將專案與實施組織的日常,續業務,繫起,,,別哪些過渡,動,入或,,入。把新產品交付正式生產或把新電腦軟體交付上市,就是這種情況的,子。應該注意把專案的生命週期和產品的生命週期區分開,。,如,向市場推出一種新型臺式電腦的專案僅僅是其產品生命週期的一個方。圖2-4 是一個,子,,明產品生命週期開始於經營計畫,經過構思,到產品,到日常經營和產品退出市場。而專案
生命週期經,創造這一產品的一系,階段。其他專案可以 包括對這一產品的性能,新。在某些應用,
域,,如新產品或軟體研製,組織將專案生命期視為產品生命週期的一部分。 圖2-4,產品與專案生命週期之間的關係 2.2 專案,害關係人專案,害關係人就是積極,
與專案、或其,,因專案的實施或完成而受到積極 或消極影響的個人和組織,他們還會對專案的目標 和結果施加影響。專案管,團隊必須,清楚誰是, 害關係人,確定他們的要求和
PMP项目管理
