如何避免專案範圍蔓延
為什麼範圍蔓延經常發生？該做些什麼事情才能管理好範圍？
你是否曾在邊界擴大了的專案裡工作過？
或者更為重要是，你是否曾在範圍沒有擴大的專案裡工作過？
範圍蔓延通常被定義為：計畫之外的專案規模擴大。我們如何避免它？是否可以既有效率又有效果地控制和管理我們的業務流程改進專案？答案是，完全可以！幾乎每個參與過專案工作中的人都遇到過專案範圍蔓延的問題。這就像壓縮海綿，當它掉入水中時會發生膨脹，變成原來尺寸的10-20倍，這是因為它的邊界（塑料膠囊）被溶解了。同樣，專案邊界的消失也會導致專案範圍蔓延。為了防止範圍蔓延，我們有必要正確地去定義問題根源。
如果我們分析範圍蔓延的根本原因，可以發現以下主要問題：
錯誤地定義了流程以及沒有認識到所有流程都是相互連線的。
錯誤的人在定義範圍。
與專案相關的術語沒有被定義。
沒有定義流程之間的高層次介面。
忽略了對這些分介面的「體檢」工作。
沒有意識到這樣乙個問題：專案的某些方面會使專案規模變得很大以至於無法管理。
1、 錯誤地定義了流程以及沒有認識到所有流程都是相互連線的。
這些問題不是與我們做過的工作有關，而是與沒做過的有關。所有問題皆始於組織如何定義業務流程。當問及業務流程如何定義時，我經常得到這樣一些回答：它是使輸入變成生產結果的一組業務活動。流程有兩個特點很少被提到：第一，幾乎所有的流程都是跨職能的。第二，幾乎所有流程都是相互連線的。如果你專案中的乙個「流程」只包含了乙個職能部門，那麼極有可能是：你原始的專案範圍只包含了流程的一部分，到最後，專案範圍將包含整個流程。
比如乙個公司希望改進應付賬款「流程」，這做得到麼？應付賬款確實是使輸入變成生產結果的一組業務活動。但是，我們必須要問：為什麼非要乙個輸入？當每月信用卡賬單寄來的時候，我也不得不問同樣的問題。我有賬單，因為購買了物品。因此，在乙個公司裡，如果我們想改進應付賬款，就必須檢查在採購這個環節上發生了什麼。然後，如果我們購買了物品，接下來發生了什麼？我們接收了這項物品。現在，我們也應該把接收包含在內，因為我們不願意為那些沒有接收到的物品付錢。當我們接收到物品後，如不直接使用的話，它們就會入庫。那麼我們就要同庫存人員溝通，以確保不出現庫存問題。在使應付賬款「流程」確實有效之前，我們必須確保充分利用了所有協商好的折扣條款。這些條款是通過合法協商而得到的，這樣的話，就需要法務部參與到專案中。最後乙個問題：誰來選擇**商？有**商篩選流程麼？我們可以暫且認為篩選流程發生在市場部。我們還可以列出更多的情況，但在這裡只是舉個簡單的例子。專案的範圍變化了多少？從乙個職能部門內的應付賬款開始，拓展到採購、接收、庫存控制、法務、市場。現在，我們的專案與一開始相比大了5倍。
另一方面，我們可以僅僅改進應付賬款，畢竟包含其他類別的話會讓專案更加複雜，那意味著有人不得不去協調跨職能所需的資源。在這種情況下，我們要對應付賬款「流程」進行重新設計以便產生更有效率的付帳單。然而，我們從來沒有充分利用折扣，我們從十個**商那裡購買辦公用品，為我們從來沒有接收到的物品付款，或者為我們接收了但漏到了不合適的組織部門裡的物品付款。有人會產生疑問：為什麼沒有從應付賬款改進專案中獲得商業利益？
2、錯誤的人在定義範圍。
引起流程改進專案範圍蔓延的第二個原因是：我們並不經常有正確的成員來定義流程。成員們必須是相關職能部門的高階經理，他對業務及存在的問題有非常全面的認知。定義流程的邊界是這些成員的職責。比如，確定流程從**開始**結束。這些團隊成員還必須具備調動資源的權利。以防專案邊界被界定了，但是專案所需的資源卻找不到的情況發生。
讓我們再來看看訂單管理流程改進專案。這個流程是否開始於**鈴響？或者開始於簽訂單？還是開始於信用被認可，產品的有效性被確認？這個流程在什麼時候結束？它是否結束於「已發運」？還是結束於產品送達或產品驗收完畢？我們定義專案邊界所採用的方式會一次又一次地影響專案本身。這會影響到我們從什麼人那裡得到輸入，我們的核心團隊應該包含哪些人，我們要衡量什麼，我們如何設立我們的願景，當我們重新設計流程或者改進流程時，哪些範圍的變化應該被列入。
當由正確的團隊來定義範圍時，這個團隊也可以保證資源的獲得。不要讓任何其他人來做你的工作，這會給範圍蔓延以可乘之機。
3、與專案相關的術語沒有被定義。
我們必須要討論與專案相關的術語，以便讓所有專案參與者及流程當事人對術語的含義達成共識。大多數時候，我們「假定」每個人對流程的理解保持一致，這是流程專案過程中的眾多「假定」之一，這些假定通常都不準確。我們雖然假定每個人對流程及流程中用到的術語都有乙個清晰的認識，但不幸之處在於，這些假定僅僅是假定，並非事實。只有當我們深入專案並開始質問、反思時，我們才能精確地定義出這些術語。通常，術語的定義也會使專案定義發生改變。舉個例子，提到美國的批薩，我們腦海中就會形成乙個非常明確的畫面。但是，假如你在義大利、匈牙利或者其他國家點乙份批薩時，送來的很可能是非常新奇的類似於矩形的批薩，有些批薩上面還有有煎蛋和玉公尺。這表明，我們不能假定所有人都理解專案中所使用的術語。比如對於會計人員，fasby應該是fasb（美國財務會計準則委員會），但你如果不是會計人員，就不會明白這個雙關語，可能會以為這只是乙隻狗的名字。
4、沒有定義流程間的高層次介面。
流程間的高層次介面必須定義，為此必須要知道專案所考慮的流程是什麼，該流程與其他流程的分介面是什麼。換句話說，哪些流程影響了該流程，或者被該流程影響了，是什麼產生了介面，或者是什麼在流程及其他利益相關者之間流動。我們把這些介面定義為igoes（輸入、支配、輸出、使能）。通常，乙個組織很難定義這些介面，因為他們連流程本身都還沒有定義清楚。因此，如果乙個組織沒有定義它的流程，那如何能確定專案的範圍？典型的情況是，專案中涉及很多的組織職能模組，這說明我們從一開始就意識到範圍會蔓延（缺乏準確的流程定義）。因此，我們需要定義一些高層次流程介面。
那麼，需要花多長時間來定義高層次流程？我們的專案時間有限，而且不能在與專案無直接關聯的事情上投入太多時間。通過經驗可得，如果有正確的人在會議室內，這項工作在半天內就可以輕鬆完成。從一開始就投入時間來定義高層次流程是值得的，這能確保你知道流程改進專案在這個大流程圖中處在哪個位置。大流程圖的真正價值在於我們能不斷地用到這張圖，當我們知道所有的流程介面時，就完成了所說的範圍分析。
5、忽略了對這些分介面的「體檢」工作。
我們需要對所有介面進行分析，以確定每個介面都是完好的。這樣做的目的是把我們的精力集中在真正重要的地方，切實地知道能影響什麼不能影響什麼。為此我們必須問一些問題：哪些運作得好，哪些不好？哪些不可能改變？哪些會在給定的資源和時間限制內耗費我們大量的時間？這種新認識的結果就是範圍變更。這意味著，所有包含在邊界裡的東西都有可能以某種方式發生改變。這就是我們的專案範圍定義。
6、沒有意識到這樣乙個問題：專案的某些方面會使專案變得很大以至於無法管理。
我們必須把現實情況考慮在專案範圍中。比如，如果專案範圍是乙個大型金融機構的支付流程，我們需要考慮，是檢查所有的支付類別，還是只檢查少數幾種主要的（對組織的風險和期望酬金有最大影響）支付類別。
總之，專案範圍可以管理得更好嗎？當然可以！流程改進專案的挫敗通常是不知道怎麼處理專案範圍問題所造成的。你現在已經有知識、有能力既有效率又有效果地去控制你的專案了！
專案管理之 專案範圍蔓延
一 專案管理中，什麼是範圍蔓延？範圍蔓延和特徵蔓延是專案失敗的原因 專案超出計畫的目標，通常被稱為範圍蔓延。範圍蔓延就是 在系統專案進行期間不期望的需求緩慢增加。特徵蔓延 不受控制地增加技術特徵到乙個專案中。你本來想更好更出色的完成專案，但你不斷增加新的想法.可能會失去巨集觀上對專案的把握，反而失敗...
範圍管理和範圍蔓延
1 範圍管理的前提 前提是專案的定義。專案是企業哪個戰略方向下的產物，專案想完成哪些具體目標？只有定義明確了，才有範圍。範圍必須緊密圍繞著定義來開展。範圍不足或範圍蔓延都會對專案產生影響 1 範圍管理包括了兩部分 一部分是實體的產品，比如開發出來的一套軟體 另一部分是專案的商業方案 銷售方案 服務體...
範圍管理和範圍蔓延
1 範圍管理的前提 前提是專案的定義。專案是企業哪個戰略方向下的產物，專案想完成哪些具體目標？只有定義明確了，才有範圍。範圍必須緊密圍繞著定義來開展。範圍不足或範圍蔓延都會對專案產生影響 2 範圍管理包括了兩部分 一部分是實體的產品，比如開發出來的一套軟體 另一部分是專案的商業方案 銷售方案 服務體...