范圍管理總的來說是兩方面的內容，一方面是范圍的圈定、劃分，另一方面是如何有效應對范圍的變更，以避免對項目進度、成本帶來的負面影響，增加了項目風險。
一、范圍的圈定及劃分
范圍管理到底這其中的范圍指的是什么?籠統來講，就是項目的參與人員、時間、成本、管理以及所有涉及該項目的其它雜七雜八事宜。
既然范圍管理涉及的東西這么多，那我們就得好好謀劃謀劃，這就要求我們很有必要做好范圍管理的前期準備工作，即先要弄出《范圍計劃編制》和《范圍說明書》兩樣東西來，以便我們能夠以科學發(fā)展的工作思路指引我們在項目中如履薄冰。
《范圍計劃編制》其實是依附于《項目管理計劃》之上的，無非就是寫一些項目概述、織架構及人員、進度、方方面面的約束條件而已。
《范圍說明書》主要闡述項目的來龍去脈、目標以及最終交付給用戶的成果清單。
我覺得以上兩者都是說是順從《項目管理計劃》，或者說是在它的基礎之上稍微細化了一點，其實很多都是照抄的，而范圍管理真正需要的東西是《范圍定義》，所以還得再遵循以上兩者進行一次細化，就自動變成了《范圍定義》，在《范圍定義》中要把項目的參與人員、時間、成本、管理以及所有涉及該項目的其它雜七雜八事宜好好細化一遍，中要詳盡描述哪些工作該做，哪些工作不應該做，定出邊界，明確所有的輸入輸出。
范圍定義搞清了，基本上這范圍也就圈定了，接下來就要做范圍的劃分了。
范圍的劃分，俗稱工作任務分解(WBS)，好像項目進度管理中也有一個WBS，這兩者是一脈的，是相互對應的，只是一個強調的是范圍，一個強調的是時間，所以在細化上有所區(qū)別。
對于軟件開發(fā)而言，總的范圍劃分，除了需求、概要、設計、編碼、測試等主體工作外，還有文檔撰寫、項目管理等工作，所有這些都得安排好人去做，要做到協調一致，不要主體工作一直向前沖，文檔撰寫跟不上，或者因為項目管理上出了問題，影響到主體工作的有序推進。
無疑范圍的主體工作任務是我們要關注的重點，這就涉及到劃分，只有分清楚了，分到人了，項目經理心里才會有底，以免扯皮，銜接不上。那一個系統應該如何劃分?通常是自上而下的方式進行，劃子系統、劃工作包。
引述一個名詞，啥叫工作包?是指比子系統更小、更易管理、更易懂的工作單元，反正是可以獨立工作的東西。
再引述一個名詞，WBS字典?就是在WBS的工作包中要附一個資源性的說明，比如誰來做，完工的起止時間，跟其它工作包或子系統的銜接等等。
二、范圍的變更控制
項目經理換了、已參加開來的項目組人員跳槽了，這是范圍中的人員變更。
項目被要求提前上線，或者因故延期了，這是范圍中的進度變更。
以上兩者發(fā)生概率還算小，或者已有一套成熟的解決方案，但對于不同的項目，需求的變更是難免的，所以也得有一套范圍中需求變更控制流程。在這些變更之中，我們總是忽略一些小的需求變更，所以也總在不經意口頭答應一些小的需求變更，這會是致命的。因為…在這里還有必要引述一個名詞，范圍蔓延：指的是不斷接受一些看似很小的需求變更，當所有小的變更匯總后，才發(fā)現需要的付出的工作量比較大，且已影響到成本和進度。
除了眾多小的變更，還有一些大的變更，除了項目之內的變更，還有項目之外的如政策因素的影響等，綜觀所有可能的變更，都逼得我們要制定一套變更控制流程來進行應對，在這流程中要界定好變更的批準權限，無論誰來批準，一定要先經過項目組或專門委員會進行充分的評估，以降低項目風險。
