一、專案管理中，什麼是範圍蔓延？
範圍蔓延和特徵蔓延是專案失敗的原因
專案超出計畫的目標，通常被稱為範圍蔓延。範圍蔓延就是： 在系統專案進行期間不期望的需求緩慢增加。
特徵蔓延：不受控制地增加技術特徵到乙個專案中。你本來想更好更出色的完成專案，但你不斷增加新的想法...可能會失去巨集觀上對專案的把握，反而失敗。
二、專案範圍蔓延案例：
公司最近的乙個專案，從去年四月份就開始，整整的一年過去了，現在還在調整談需求，談流程。其中乙個主要問題是甲方部門的領導換了，原來的領導認可的東西，現任領導覺得不好。很擔心按照這樣下去什麼時候專案才能夠結束。本來計畫去年底就結束的，專案已經拖延了5個月。這是典型的專案範圍蔓延問題。追究這個專案發展成這樣的根源，主要包含如下幾個部分：
1> 專案初期對專案需求理解不透徹，甲方對專案的目標定得過高，乙方需求分析不夠，對專案的估算出現偏差。
2> 沒有嚴格的按照變更要求來執行變更，變更是由雙方的專案經理確定的。商務上籤的合同是總價合同，但是這些變更都沒有額外的預算費用。
3> 專案成員流動性很大。現在專案組的人大部分都是去年才進入公司的，由於公司其它專案的需要，很多有經驗的人只是前期參與了一部分，後期都做其它的專案去了。
計畫在七月份結束專案，然後開始專案的二期工程，這只是商務上處理的一種方式而已。對於本專案而言，對比開始制定的專案範圍，還有很多是沒有完成的，比如專案在全國推廣，試點應用的接入等等。無論是從技術的角度還是從使用者的角度，在這個時候重新審視這個專案，發現很多需求的實現都複雜了。對乙個大的企業來說，實施乙個全企業範圍內的專案需要從簡單開始，然後逐漸的增加內容，增加流程。想要一開始就完美的規劃出來，然後按照規劃來做，是有很大的難度的。
三、當專案出現範圍蔓延時，如何應對"範圍蔓延"？
專案經理有責任清楚、準確地定義範圍變更---或者"範圍蔓延"（scope creep）---對專案造成的影響，以及在推進或拒絕這種變更時所產生的後果。他還必須站在整個組織的高度上去看待這些變更。但是，怎樣才能確認範圍蔓延的真正影響並且將它明白無誤地指出來？
以如下專案為例，該專案擬以全新的網路服務取代陳舊的呼叫中心。此專案預計歷時10個月，成本為50萬美金。專案完成後，每月在運作成本節約方面的投資回報可達5萬美金。
現在考慮在第五個月對專案範圍做一次變更。即在程式中增加乙個匯報與管理工具，這個變更預計歷時兩個月，費用為10萬美金，每月在成本節約方面的投資回報是1萬美金。
這一範圍變更是專案進展過程中所意料不到的。計畫改變了，人事也重新安排了。為了做出決策，身經百戰的專案經理必須確認並指出這一變更所需的真實費用。但是，在多數情況下，人們都以為專案僅為此花費了10萬美金。這種短視的觀點將嚴重危及專案的投資回報率。
圖表"發現範圍蔓延的真實成本"清晰地列出了與這一變更申請相關的分解細目及全部成本。圖表還顯示，這一變更所需的真實費用是最初預計的10萬美金的兩倍多。另外，投資回報期更長，是原預計的兩倍有餘。可見，站在乙個更廣闊的角度去看待變更申請，可以更準確地評估它所需的成本，並就是否推進該變更做出更準確、更理智的決策。
成功管理乙個專案，關鍵在於：了解你所面臨的挑戰，現實地應對專案範圍蔓延。只是做到在預算之內按時完成任務還不夠。專案成果必須與組織目標相呼應。如果你發現了範圍蔓延，請停下來對它進行分析。然後利用知識型決策慣例，決定是推進還是牴觸這一變更。對範圍蔓延有乙個透徹的了解，是專案成功的根本。
四、專案開始前，如何避免專案範圍蔓延？
為什麼範圍蔓延經常發生？該做些什麼事情才能管理好範圍？
你是否曾在邊界擴大了的專案裡工作過？
或者更為重要是，你是否曾在範圍沒有擴大的專案裡工作過？
範圍蔓延通常被定義為：計畫之外的專案規模擴大。我們如何避免它？是否可以既有效率又有效果地控制和管理我們的業務流程改進專案？答案是，完全可以！幾乎每個參與過專案工作中的人都遇到過專案範圍蔓延的問題。這就像壓縮海綿，當它掉入水中時會發生膨脹，變成原來尺寸的10-20倍，這是因為它的邊界（塑料膠囊）被溶解了。同樣，專案邊界的消失也會導致專案範圍蔓延。為了防止範圍蔓延，我們有必要正確地去定義問題根源。
如果我們分析範圍蔓延的根本原因，可以發現以下主要問題：
1、 錯誤地定義了流程以及沒有認識到所有流程都是相互連線的。
這些問題不是與我們做過的工作有關，而是與沒做過的有關。所有問題皆始於組織如何定義業務流程。當問及業務流程如何定義時，我經常得到這樣一些回答：它是使輸入變成生產結果的一組業務活動。流程有兩個特點很少被提到：第一，幾乎所有的流程都是跨職能的。第二，幾乎所有流程都是相互連線的。如果你專案中的乙個「流程」只包含了乙個職能部門，那麼極有可能是：你原始的專案範圍只包含了流程的一部分，到最後，專案範圍將包含整個流程。
比如乙個公司希望改進應付賬款「流程」，這做得到麼？應付賬款確實是使輸入變成生產結果的一組業務活動。但是，我們必須要問：為什麼非要乙個輸入？當每月信用卡賬單寄來的時候，我也不得不問同樣的問題。我有賬單，因為購買了物品。因此，在乙個公司裡，如果我們想改進應付賬款，就必須檢查在採購這個環節上發生了什麼。然後，如果我們購買了物品，接下來發生了什麼？我們接收了這項物品。現在，我們也應該把接收包含在內，因為我們不願意為那些沒有接收到的物品付錢。當我們接收到物品後，如不直接使用的話，它們就會入庫。那麼我們就要同庫存人員溝通，以確保不出現庫存問題。在使應付賬款「流程」確實有效之前，我們必須確保充分利用了所有協商好的折扣條款。這些條款是通過合法協商而得到的，這樣的話，就需要法務部參與到專案中。最後乙個問題：誰來選擇**商？有**商篩選流程麼？我們可以暫且認為篩選流程發生在市場部。我們還可以列出更多的情況，但在這裡只是舉個簡單的例子。專案的範圍變化了多少？從乙個職能部門內的應付賬款開始，拓展到採購、接收、庫存控制、法務、市場。現在，我們的專案與一開始相比大了5倍。
另一方面，我們可以僅僅改進應付賬款，畢竟包含其他類別的話會讓專案更加複雜，那意味著有人不得不去協調跨職能所需的資源。在這種情況下，我們要對應付賬款「流程」進行重新設計以便產生更有效率的付帳單。然而，我們從來沒有充分利用折扣，我們從十個**商那裡購買辦公用品，為我們從來沒有接收到的物品付款，或者為我們接收了但漏到了不合適的組織部門裡的物品付款。有人會產生疑問：為什麼沒有從應付賬款改進專案中獲得商業利益？
2、錯誤的人在定義範圍。
引起流程改進專案範圍蔓延的第二個原因是：我們並不經常有正確的成員來定義流程。成員們必須是相關職能部門的高階經理，他對業務及存在的問題有非常全面的認知。定義流程的邊界是這些成員的職責。比如，確定流程從**開始**結束。這些團隊成員還必須具備調動資源的權利。以防專案邊界被界定了，但是專案所需的資源卻找不到的情況發生。
讓我們再來看看訂單管理流程改進專案。這個流程是否開始於**鈴響？或者開始於簽訂單？還是開始於信用被認可，產品的有效性被確認？這個流程在什麼時候結束？它是否結束於「已發運」？還是結束於產品送達或產品驗收完畢？我們定義專案邊界所採用的方式會一次又一次地影響專案本身。這會影響到我們從什麼人那裡得到輸入，我們的核心團隊應該包含哪些人，我們要衡量什麼，我們如何設立我們的願景，當我們重新設計流程或者改進流程時，哪些範圍的變化應該被列入。
當由正確的團隊來定義範圍時，這個團隊也可以保證資源的獲得。不要讓任何其他人來做你的工作，這會給範圍蔓延以可乘之機。
如何避免專案範圍蔓延
如何避免專案範圍蔓延 為什麼範圍蔓延經常發生？該做些什麼事情才能管理好範圍？你是否曾在邊界擴大了的專案裡工作過？或者更為重要是，你是否曾在範圍沒有擴大的專案裡工作過？範圍蔓延通常被定義為 計畫之外的專案規模擴大。我們如何避免它？是否可以既有效率又有效果地控制和管理我們的業務流程改進專案？答案是，完全...
專案整合專案管理之專案範圍管理
7.1專案範圍和專案範圍管理 7.1.1專案範圍的定義 專案範圍 為完成具有規定特徵和功能的產品 服務或結果，而必須完成的專案工作。7.1.2專案範圍管理的作用 確定在專案內包括什麼工作和不包括什麼工作 由此界定的專案範圍在專案的全生命週期內可能因某種原因而變化，專案範圍管理也對這種變化進行管理。專...
範圍管理和範圍蔓延
1 範圍管理的前提 前提是專案的定義。專案是企業哪個戰略方向下的產物，專案想完成哪些具體目標？只有定義明確了，才有範圍。範圍必須緊密圍繞著定義來開展。範圍不足或範圍蔓延都會對專案產生影響 1 範圍管理包括了兩部分 一部分是實體的產品，比如開發出來的一套軟體 另一部分是專案的商業方案 銷售方案 服務體...