一個專案從其一成立開始，專案各方干係人都會期望專案能夠根據既定的計劃一步步順利地導向最後的成功。影響專案的最後成功的因素是多方面的，包括專案管理的九大知識領域（包括專案的整體管理、範圍管理、時間管理、費用管理、質量管理、人力管理、溝通管理、風險管理和採購管理），無一對專案的最後成功不產生積極影響。然而，要這九大知識領域對專案成功產生的影響的輕重程度上進行比較的話，我認為其中專案範圍管理是最為重要的。

什麼是專案範圍管理

那麼，什麼是專案範圍和專案範圍管理呢？專案範圍是指產生專案產品所包括的所以工作及產生這些產品所用的過程。專案干係人必須在專案要產生什麼樣的產品方面達成共識，也要在如何生產這些產品方面達成一定的共識。

專案範圍管理是指對專案包括什麼與不包括什麼的定義與控制過程。這個過程用於確保專案組和專案干係人對作為專案結果的專案產品以及生產這些產品所用到的過程有一個共同的理解。

專案範圍與專案其它約束條件的相互影響

制約一個專案的條件是專案“三約束條件”——範圍、時間、成本。

在一個專案中這三個條件是相互影響、相互制約的，而且往往是由於範圍影響了時間和成本。專案一開始確定的範圍小，那麼它需要完成的時間以及耗費的成本必然也小，反之亦然。很多專案在開始時都會粗略地確定專案的範圍、時間以及成本，然而在專案進行到一定階段之後往往會變成讓人感覺到不知道專案什麼時候才能真正結束，要使得專案結束到底還需要投入多少人力和物力，整個專案就好象一個無底洞，對專案的最後結束誰的心裡也沒有底。這種情況的出現對於公司的高層來說，他們是最不希望看到的，然而這樣的情況出現並不罕見。造成這樣的結果就是由於沒有控制和管理好專案的範圍。可見專案的三約束中最主要還是範圍的影響最主要。

範圍管理案例

失敗案例：我瞭解到這樣的實際案例，這是一個軟體開發的專案，整個專案已經進行了兩年多之後專案何時結實還是處於不明確的狀態，因為使用者不斷有新的需求出來，專案組也就要根據使用者的新需求不斷去開發新的功能。這個專案實際是一個無底洞，沒完沒了地往下做，專案成員“肥的拖瘦，瘦的拖死”，實在做不下去只能跑了。大家對這樣的專案已經完全喪失了信心。

這個專案其實就是一開始沒有很明確地界定整個專案的範圍，在範圍沒有明確界定的情況下，又沒有一套完善的變更控制管理流程，任由使用者怎麼說，就怎麼做，也就是說一開始遊戲規則沒有定好，從而導致整個專案成了一個爛攤子。

成功案例：同樣是一個軟體開發的專案，這個專案也比上面案例講到的專案要小一些，這時候公司已經開始實施CMM對軟體開發活動進行管理，有相對完善的軟體開發管理過程。專案在一開始就先明確使用者需求，而且需求基本上都是量化的、可檢驗的。而且專案組在公司CMM的變更管理過程的框架指導下制定了專案的範圍變更控制管理過程，在專案的實施過程中，使用者的需求變更都是按照事先制定好的過程執行。

因此，這個專案完成的比較成功，專案的時間和成本基本上是在一開始專案計劃的完成時間及成本的情況下略有增加。

造成範圍界定不清的原因

既然專案範圍界定不清是一種很常見的現象，而這種現象又是大家所不想見到的。那麼，我們必須分析出現這種現象的原因。我認為造成這種現象的出現有以下三方面的原因：

首先，是企業一級的責任——沒有完善的專案管理體系來指導專案的管理。這種情況是最糟糕的，如果是這種原因，那麼專案的成敗往往需要靠專案經理個人的管理、領導能力。這種情況專案成功的可能性非常小，大部分專案都是以失敗而告終；

第二，是企業及專案組共同的責任——對專案沒能制定出清晰規範的範圍變更控制過程。企業有管理體系，但不夠完善和規範，對專案組的變更過程的制定沒能起到有效的指導作用。變更是不可避免的，只要有效地加以管理、控制，同樣可以達到各方滿意的結果；

第三，是對範圍的定義不夠明確，做不到可量化、可驗證程度。很多時候都是一些定性的要求、而不是定量的，例如“介面友好，可操作性強，提高使用者滿意度”等。類似這些模糊的需求就是導致後續專案扯皮的根源。專案範圍的明確定義，有經驗的專案經理及系統分析員將起到至關重要的作用。

由以上的論述，我們可以得出結論：完善的專案範圍管理是整個專案最終成敗的關鍵。那麼，怎樣才能做好專案範圍管理呢？下面大量篇幅將對這一問題進行詳細的論述。

如何管理好專案範圍

既然已經認識到專案範圍管理如此重要，那麼我們應該怎樣才能管理好專案的範圍呢？從上面的論證過程，我們清楚地看到造成專案範圍不好管理的一些原因，那麼要管理好專案範圍就必須對症下藥，才能管理好專案範圍。

首先，我們必須先了解專案範圍管理的一些科學過程。做好專案管理應該包含下面過程：啟動、範圍計劃、範圍定義、範圍核實及範圍變更控制。下面將詳述如何做好這些過程：

啟動過程

啟動是指組織正式開始一個專案或繼續到專案的下一個階段。啟動過程的一個輸出就是專案章程。專案章程是一個重要的文件，這個檔案正式承認專案的存在並對專案提供一個概覽。

啟動過程明確指定這一過程有一個重要的輸出文件——專案章程，專案章程將粗略地規定專案的範圍，這也是專案範圍管理後續工作的重要依據。專案章程中還將規定專案經理的權利以及專案組中各成員的職責，還有專案其他干係人的職責，這也是在以後的專案範圍管理工作中各個角色如何做好本職工作有一個明確的規定，以致後續工作可以更加有序地進行。因此，千萬不能忽略專案的啟動過程。

範圍計劃過程

範圍計劃是指進一步形成各種文件，為將來專案決策提供基礎，這些文件中包括用以衡量一個專案或專案階段是否已經順利完成的標準等。作為範圍計劃過程的輸出，專案組要制定一個範圍說明書和範圍管理計劃。

古語云：“預則立，不預則廢！”。一個專案經理要想真正管理好專案範圍，沒有必要的技術和好的方法是肯定不行的。

要做好一個專案首先強調的就是周密地做好範圍計劃編制。範圍計劃編制是將產生專案產品所需進行的專案工作（專案範圍）漸進明細和歸檔的過程。做範圍計劃編制工作是需要參考很多資訊的，比如產品描述，首先要清楚最終產品的定義才能規劃要做的工作，專案章程也是非常主要的依據，通常它對專案範圍已經有了粗線條的約定，範圍計劃在此基礎上進一步深入和細化。

前面講到這個過程有一個輸出是範圍說明書，那麼範圍說明指的是什麼呢？範圍說明是在專案參與人之間確認或建立了一個專案範圍的共識，作為未來專案決策的文件基準。

範圍說明中至少要說明專案論證、專案產品、專案可交付成果和專案目標。專案論證是商家的既定目標，要為估算未來的得失提供基礎；專案產品是產品說明的簡要概況；專案可交付成果一般要列一個子產品級別概括表，如：為一個軟體開發專案設定的主要可交付成果可能包括程式程式碼、工作手冊、人機互動學習程式等。任何沒有明確要求的結果，都意味著它在專案可交付成果之外；專案目標是要考慮到專案的成功性，至少要包括成本、進度表和質量檢測。專案目標應該有標誌（如：成本、單位）和絕對的或相對的價值。儘量避開不可量化的目標（如：“客戶的滿意程度”），因為它將讓你的專案承擔很高的風險。

範圍計劃又是什麼呢？範圍管理計劃是描述專案範圍如何進行管理，專案範圍怎樣變化才能與專案要求相一致等問題的。它也應該包括一個對專案範圍預期的穩定而進行的評估（比如：怎樣變化、變化頻率如何及變化了多少）。範圍管理計劃也應該包括對變化範圍怎樣確定，變化應歸為哪一類（當產品特徵仍在被詳細描述的時候，做到這點特別困難，但絕對必要）等問題的清楚描述。

範圍定義過程

範圍定義是指將專案主要的可交付成果細分成較小的、更易管理的組分。這個過程中，專案組要建立一個工作分解結構（WBS）。

WBS的建立對專案來說意義非常重大，它使得原來看起來非常籠統、非常模糊的專案目標一下子清晰下來，使得專案管理有依據，專案團隊的工作目標清楚明瞭。如果沒有一個完善的WBS或者範圍定義不明確時，變更就不可避免地出現，很可能造成返工、延長工期、降低團隊士氣等一系列不利的後果。

制定好一個WBS的指導思想是逐層深入。先將專案成果框架確定下來，然後每層下面再把工作分解，這種方式的優點是結合進度劃分直觀，時間感強，評審中容易發現遺漏或多出的部分，也更容易被大多數人理解。

範圍核實過程

範圍核實是指對專案範圍的正式認定，專案主要干係人，如專案客戶和專案發起人等要在這個過程中正式接受專案可交付成果的定義。

這個過程是範圍確定之後，執行實施之前各方相關人員的承諾問題。一旦承諾則表明你已經接受該事實，那麼你就必須根據你的承諾去實現它。這也是確保專案範圍能得到很好的管理和控制的有效措施。

範圍變更控制過程

範圍變更控制是指對有關專案範圍的變更實施控制。主要的過程輸出是範圍變更、糾正行動與教訓總結。

再好的計劃也不可能做到一成不變，因此變更是不要避免的，關鍵問題是如何對變更如何進行有效的控制。控制好變更必須有一套規範的變更管理過程，在發生變更時遵循規範的變更程式來管理變更。通常對發生的變更，需要識別是否在既定的專案範圍之內。如果是在專案範圍之內，那麼就需要評估變更所造成的影響，以及如何應對的措施，受影響的各方都應該清楚明瞭自己所受的影響；如果變更是在專案範圍之外，那麼就需要商務人員與使用者方進行談判，看是否增加費用，還是放棄變更。

因此，專案所在的組織（企業）必須在其專案管理體系中制定一套嚴格、高效、實用的變更程式。執行好以上專案範圍管理的五個過程，我認為對專案範圍的管理、控制將是行之有效的！
[@more@]

專案範圍是專案成敗的關鍵（轉）

相關文章