項目生命周期

出自 MBA智库百科(https://wiki.mbalib.com/)

項目生命周期（Project Life Cycle）

　　項目的生命周期是描述項目從開始到結束所經歷的各個階段，最一般的劃分是將項目分為 "識別需求、提出解決方案、執行項目、結束項目"四個階段。實際工作中根據不同領域或不同方法再進行具體的劃分。在項目生命周期運行過程中的不同階段里，由不同的組織、個人和資源扮演著主要角色。

　　當需要被客戶（願意提供資金，使需求得到滿足的個人或組織）所確定時，項目就誕生了。例如，對於一個正在擴大的家庭來說，可能會需要一間更大些的房子，而對於一個公司來說，問題可能是製造過程的高廢品率使它的成本高於期競爭對手，產品生產時間長於競爭對手。客戶必須得到確定需求或問題，有時問題會被迅速確認，如在災難（例如地震或爆炸）發生時。而在另外一些情況下，可能會花去幾個月的時間，顧客才能清晰地確認需要，收集問題的有關資料，確定解決問題的個人、項目團隊或承約商所需滿足的條件。

　　項目生命周期確定了項目的開端和結束。例如，當一個組織看到了一次機遇，它通常會做一次可行性研究，以便決定是否應該就此設立一個項目。對項目生命周期的設定會明確這次可行性研究是否應該作為項目的第一個階段，還是作為一個獨立的項目。

　　項目生命周期的設定也決定了在項目結束時應該包括或不包括哪些過渡措施。通過這種方式，我們可以利用項目生命周期設定來將項目和執行組織的連續性操作鏈接起來。項目的整個生命周期由項目的各個階段構成，每個項目階段都以一個或一個以上的工作成果的完成為標誌。

　　項目生命周期的第1階段涉及需求、問題或是機會的確認能導致客戶向個人、項目團隊或是組織（承約商）徵詢需求建議書，以便實現已確認的需求或解決問題。具體要求通常由客戶在一個叫做需求建議書（request for proposal, RFP）的文件里註明。通過RFP，客戶可以要求個人或承約商提交有關他們如何在成本約束和進度計划下解決問題的申請書。一對需要新房的夫婦，可能會花時間來確認對房子的要求——大小、樣式、風格、房間數、地點、他們預算能藥的最大錢數以及他們想搬進去的日期，他們可能會寫下這些要求，然後要求幾個承約商分別提供房屋計劃和成本估算。一個把升級它的電腦系統作為需求的公司，可能會以RFP的方式把它的需求用文件證實下來，並把文件分別送給幾家電腦咨詢公司。然而，並不是所有的情況下都有一個正式的RFP。如在一組單個個體之間召開的會議或講座人們通常會很隨便地定義需求。某些人可能會自願或是被要求準備一份申請書，以決定項目是否由其承擔，並滿足需求。這類情況可能是醫院的管理層想為本醫院雇員的孩子們建造一個當地的日護理中心，管理團隊或某個經理可能會在文件里寫下這些要求，交給一個內部項目團隊，而內部項目團隊將會提交一份有關如何建立護理中心的申請書。在這種情況下，承約商是醫院自己內部的項目團隊，客戶是醫院的經理或者可能是董事會。確定一個正確的需求是很重要的。例如，某個需求是要提供一個體地的護理中心，還是旨在為醫院雇員的孩子提供幼兒護理？“本地”是需求必不可少的組成部分嗎？

　　項目生命周期的第2個階段，是提出解決需求或問題的方案。這個階段將會導致某個人或更多的人、組織（承約商）向客戶提交申請書，他們希望客戶為今後成功執行解決方案而付給他們酬勞。在這個階段，承約商的努力變得很重要。對回覆RFP感興趣的承約商，可能會花幾個星期時間來提出一種解決問題的方案，並估計所需資源的種類、數量，設計執行解決方案所需花費的時間。每個承約商都會以書面申請的方式，把有關信息用文件的方式證實下來。所有的承約商都把申請書提交給客戶。例如，幾個承約商可能會同時向一個客戶提交有關開發和執行一個自動開發票和結帳系統的申請書。在客戶評估了申請書並選出中標者後，客戶和中標的承約商將協商簽署合同（協議）。在許多情況下，可能並不會有外部承約商的參與和競爭需求建議書，以最終取得項目執行權。公司自己內部的項目團隊，就可能提出一份響應管理者所定義的需求的申請書。在這種情況下項目將由公司自己的雇員執行，而不是由外部承約商執行。

　　項目生命周期的第3個階段是執行解決方案。此階段開始於客戶已決定了哪個解決方案將能最好地滿足需求，客戶與會上人或提交申請書的承約商之間已簽訂了合同後。此階段即執行項目階段，包括為項目制定詳細的計劃，然後執行計劃以實現項目目標。在執行項目期間，將會使用到不同類型的資源。例如，有關設計並建造一幢辦公樓的項目，項目努力的方向可能首先包括由幾個建築師和工程師制定一個建樓計劃。然後，在建設工程進行期間，大量增加所需資源，包括煉鋼工人、木匠、電工、油漆工等等。項目在蓋好樓之後結束，少數其他工人將負責完成美化環境的工作和最後的內部裝修。此階段將會導致項目目標的最終實現。使客戶滿意於整個工作高質量地在預算內按時完成。例如，如果一個承約商已經完成了客戶自動系統的設計、安裝，並且系統順利通過績效測試，客戶也接受了此自動系統；或是公司內部的項目團隊已按管理層的要求完成了項目，把公司的兩個設備合併成一個，那麼這第3個階段的完成就是圓滿的。

　　項目生命脈周期的最後階段是結束項目階段，當項目結束時，某些後續的活動仍需執行。例如，確定一下所有應交付的貨物是否已提交給了客戶，客戶接收了嗎？所有的款項已經交付結清了嗎？所有的發票已經償付了嗎？這一階段的一個重要任務就是評估項目績效，以便從中得知該在哪些方面改善，在未來執行相似項目時有所借鑒。這一階段應當涉及從客戶那兒獲取反饋，以查明客戶滿意度和項目是否達到了客戶的期望等活動。同樣也應從項目團隊那兒得到反饋，以便得到有關示來項目績效改善方面的建議。

　　項目生命周期的長度從幾個星期到幾個不等，依項目內容、複雜性和規模而定。而且，並不是所有項目都必然經歷項目生命周期的4個階段。例如，一組社會志願者決定，他們要用自己的時間、才智和資源，為遠有可歸者組織一次進餐比賽，他們可能只涉及第3個階段——計劃和執行，項目生命周期的前兩個階段可能就與這個項目不相關了。同樣，如果一家公司的總經理決定改變工廠設備的佈局以提高效率，她可能簡單地批示，讓製造部經理主持這一項目，並用本公司的職工去執行項目。在這種情況下，將不會存在來自外部承約商的書面註建議書。

　　在另外一些情況下，例如雇佣承約同來重建房屋這一項目，客戶可能會以一種不太有內在結構性的、更隨便的方式經歷項目生命周期的前兩個階段。他可能並不把所有要求都寫下來，並要求幾個承約商去做估算。相反，他可能會邀請在過去曾為自己或其鄰居提供過令人滿意的工作的承約商，向其解釋一下他想做什麼，並且要求這個承約商提供一些引起草案和成本預算。

　　一般來說，當項目在商業環境中執行時，項目生命周期會以更正式，更有內在結構性的方式展開。當項目由私人或志願者執行時，項目生命周期則趨向於較隨便、不太正式。

　　大多數項目生命周期的說明具有以下共同的特點：

　　(1)對成本和工作人員的需求最初比較少，在向後發展過程中需要越來越多，當項目要結束時又會劇烈地減少。

　　(2)在項目開始時，成功的概率是最低的，而風險和不確定性是最高的。隨著項目逐步地向前發展，成功的可能性也越來越高。

　　(3)在項目起始階段，項目涉及人員的能力對項目產品的最終特征和最終成本的影響力是最大的，隨著項目的進行，這種影響力逐漸削弱了。這主要是由於隨著項目的逐步發展，投入的成本在不斷增加，而出現的錯誤也不斷得以糾正。

　　大多數項目生命周期確定的階段的前後順序通常會涉及到一些技術轉移或轉讓的，比如設計要求、操作安排、生產設計。在下階段工作開始前，通常需要驗收現階段的工作成果。但是，有時候後繼階段也會在它的前一階段工作成果通過驗收之前就開始了。當然要在由此所引起的風險是在可接受的範圍之內時才可以這樣做。這種階段的重疊在實踐中常常被叫"快速跟進"。

　　我們選擇以下項目生命周期的劃分方法來解釋應用中所採用的方法是有所不同的。這裡所給出的案例是具有代表性的，但它們既不是推薦的方法，也不是首選的方法。在每一個案例中，階段的名稱和階段的主要工作成果是由作者自己確定的。

　　防禦設備的添加。美國國防部1993年2月修訂的第5000.2指令明確了一系列添加防禦設備的里程牌事件和階段劃分，如下圖：

• 導彈需求的確定--以“方案的研究許可”為結束標誌。
• 方案探討和界定--以“方案的演示許可”為結束標誌。
• 演示和確定效力--以“開發許可”為結束標誌。
• 設計和生產開發--以“生產許可”為結束標誌。
• 管理與生產開發--與連續性運作和支持重合。

　　建築。莫裡斯（Morris）在下圖中分析了一個建築項目的生命周期。

• 可行性--項目陳述，可行性研究和策略規劃及許可在該階段不需要得出對項目取捨的決定。
• 規劃和設計--基礎設計、成本和進度、合同條款和詳細設計。在該階段末要將主要的合同分包出去。
• 實施--製造、運輸、輔助機件、安裝、測試。在該階段來完成全部安裝工作。
• 啟用和運轉--最後測試和維修。在該階段末全面運行該項設施。

　　製藥。墨菲在下圖中解釋了在美國開發一種新藥品的項目生命周期。

• 發現和甄別--包括基礎研究和應用研究，確定可以用作預臨床試驗的藥物。
• 臨床前研製--包括為了確定藥物安全性和有效性所作的實驗和動物試驗及其準備工作，並填寫新藥調查申請表。
• 整理註冊--包括Ⅰ、Ⅱ、Ⅲ階段的臨床試驗和其準備工作，填寫新藥申請表。
• 後續工作--包括了由於食品藥物管理局對新藥申請進行複查所要求做的額外工作。

　　軟體開發。莫切<Mvench>在下圖中描繪了一個軟體開發的螺旋型模型，在此模型中有四個迴圈和四個象限。

• 構思求證周期--包括商業需求、確定構思求證的目標，進行概念性的系統設計、設計和構造構思、求證，制定可行性測試計劃，進行風險分析以及製作與下一周期連接的介面
• 第一個編製周期--明確系統要求，明確第一期編製的目標，進行邏輯順序設計，設計和完成第一期編製、製作系統測試計劃，完善第一期編製以及製作與下一周期連接的介面。
• 第二個編製周期--明確子系統要求，明確第二期編製的目標，進行具體內容設計、第二期編製，製作系統測試計劃，完善第二期編製以及作與下一周期連接的介面。
• 最後一個編製周期--滿足單元要求，進行最後的設計。完成最後一期編製，執行單元，子系統，系統以及可行性測試。

　　項目生命周期中有三個與時間相關的重要概念：檢查點（CheckPoint）、里程碑（Mile Stone）和基線（Project Baseline），描述了在什麼時候（When）對項目進行什麼樣控制。

　　檢查點指在規定的時間間隔內對項目進行檢查，比較實際與計劃之間的差異，並根據差異進行調整。可將檢查點看作是一個固定"採樣"時點，而時間間 隔根據項目周期長短不同而不同，頻度過小會失去意義，頻度過大會增加管理成本。常見的間隔是每周一次，項目經理需要召開例會並上交周報。

　　里程碑完成階段性工作的標誌，不同類型的項目里程碑不同。里程碑在項目管理中具有重要意義，我們用一個例子說明：

　　情況一：你讓一個程式員一周內 編寫一個模塊，前3天你們可能都挺悠閑，可後2天就得拼命加班編程式了，而到周末時又發現系統有錯誤和遺漏，必須修改和返工，於是周末又得加班了。

　　情況二：實際上你有另一種選擇，即周一與程式員一起列出所有需求，並請業務人員評審，這時就可能發現遺漏並即時修改；周二要求程式員完成模塊設 計並由你確認，如果沒有大問題，周三、周四就可讓程式員編程。同時自己準備測試案例，周五完成測試；一般經過需求、設計確認，如果程式員合格則不會有太大 問題，周末可以休息了。

　　第二種方式增加了"需求"和"設計"兩個裡程碑，這看似增加了額外工作，但其實有很大意義：首先，對一些複雜的項目，需要逐步逼近目標，里程碑 產出的中間"交付物"是每一步逼近的結果，也是控制的對象。如果沒有里程碑，中間想知道"他們做的怎麼樣了"是很困難的。其次，可以降低項目風險。通過早 期評審可以提前發現需求和設計中的問題，降低後期修改和返工的可能性。另外，還可根據每個階段產出結果分期確認收入，避免血本無歸。

　　第三，一般人在工作時 都有"前松後緊"的習慣，而里程碑強制規定在某段時間做什麼，從而合理分配工作，細化管理"粒度".

　　基線指一個（或一組）配置項在項目生命周期的不同時間 點上通過正式評審而進入正式受控的一種狀態。基線其實是一些重要的里程碑，但相關交付物要通過正式評審並作為後續工作的基準和出發點。基線一旦建立後變化 需要受控制。

　　項目生命周期可以分成識別需求、提出解決方案、執行項目和結束項目四個階段。項目存在兩次責任轉移，所以開始前要明確定義工作範圍。 項目應該在檢查點進行檢查，比較實際和計劃的差異併進行調整；通過設定里程碑漸近目標、增強控制、降低風險；而基線是重要的里程碑，交付物應通過評審並開始受控。