1.了解做好項目范圍管理的重要。
2.討論需求收集和記錄的方法，以滿足利益相關者的需求和期望。
3.解釋范圍定義的過程，描述項目范圍說明書的內容。
4.討論運用類比法、自上而下法、自下而上法、心智圖法構建工作分解結構的過程。
5.解釋范圍驗證的重要性及其與范圍定義和范圍控制的相互關系。
6.理解范圍控制的重要性，以及解決與IT項目范圍相關的問題的方法。
7.描述軟件在項目范圍管理中發揮的作用。
開篇案例
　　Kin Nguyen主持了首次項目團隊會議，意在為IT升級項目構建工作分解結構。這個項目對于公司正在開發的幾項高度優先的并且以互聯網為基礎的應用軟件來說非常有必要。這個IT升級項目要在9個月內創建并實施一項計劃，以發揮所有員工的信息技術技能，來滿足公司的新標準。這些標準詳細說明了每臺臺式電腦或筆記本電腦所需的最少設備，包括處理器類型、存儲量、硬盤大小、網絡連接類型以及軟件。Kim知道要實施升級項目，必須首先掌握整個公司內2000名員工當前所有的硬件、網絡及軟件的詳細清單。
　　Kim已經同其他利益相關者一起制定了項目章程以及初步范圍說明書。這個項目章程包括項目的大致費用及時間進度估計，還有關鍵的利益相關者的簽名；初步范圍說明書除提供了與項目范圍相關的信息外，還在界定硬件、軟件及網絡需求方面開了一個好頭。Kim及其團隊和其他利益相關者召開了電話會議，以進一步界定項目范圍，包括項目涉及內容、誰將做些什么以及如何避免潛在的范圍蔓延。她想獲取每個人對上述各個方面的意見。公司新上任的CEO,沃爾特·施米茨，一直以來都密切關注如此重要的項目。公司已經開始使用一種新型的項目管理信息系統。這一系統能使每個人都能詳盡、高水平地了解項目實施的狀態。Kim知道，建立一個好的工作分解結構是項目范圍管理、時間管理和成本管理取得成功的基礎，但是她從未領導過項目團隊去構建工作分解結構，或者是根據工作分解結構來分攤費用，Kim應該從哪里入手呢？ 
5.1 什么是項目范圍管理
　　回顧第1章可知，有多種因素影響著項目能否取得成功。其中許多因素，如用戶參與度、清晰的業務目標、一個最小化的或清晰界定的范圍，以及公司的基本需求，都是項目范圍管理的基本要素。凱勒管理研究生院的項目主管威廉。萊班曾經做過論證，他認為缺乏適當的項目定義和項目范圍是項目失敗的主要原因。
　　因此，項目管理中最重要也是最難的問題之一就是定義項目范圍。范圍(scope)是指生產項目的產品所牽涉到的丁作和用來生產產品的過程。回顧第2章可知，可交付成果(deliverable)是指作為項目一部分產生的產品。可交付成果可以是與產品相關的，如一套硬件或一段軟件代碼；也可以是與過程有關的，如一份規劃文件或會議記錄。項目的利益相關者必須在項目究竟要產生什么樣的產品上達成共識，以及在一定程度上還要就如何生產這些產品以提交所有的可交付成果達成共識。
　　項目范圍管理（project scope management）是指界定和控制項目中應包括什么和不包括什么的過程。這個過程確保了項目團隊和項目的利益相關者對項目的可交付成果以及生產這些可交付成果所進行的工作達成共識。項目范同管理包含5個主要階段：
　　(1)需求收集(collecting requirements)是指定義并記錄項目最終產品的特點和功能，以及創造這些產品的過程。需求收集階段的輸出是項目團隊編制的利益相關者需求文檔和需求跟蹤矩陣。
　　(2)范圍定義(scope definition)是指評審項目章程、需求文檔和組織過程資產來創建范同說明書，并且隨著需求的擴展及變更請求得到批準，在規劃過程中增加更多的信息。范圍定義的主要輸出有項目范同說明書以及項目文件的更新。
　　(3)創建工作分解結構(creating the WBS)就是將主要的項目可交付成果分解成更細小和更易管理的部分。它的主要輸出包括工作分解結構(WBS)、WBS詞典、范圍基線、項目變更請求，以及項曰范圍說明書和項目文件的更新。
　　(4)范圍核實(scope verification)是指將項目可交付成果的認可正式化。關鍵的利益相關者，如項目的客戶及項目發起人，在這一過程中進行審查，然后正式接受項目的可交付成果。如果不接受現有的可交付成果，客戶或項目發起人通常會請求做些變更。因此，該階段的主要輸出包括被接受的可交付成果及變更請求。
　　(5)范圍控制(scope control)是指對整個項目生命周期內范圍的變化進行控制，這對于許多IT項目來說是很有挑戰性的。范圍變更經常影響團隊實現項目的時間目標和成本目標的能力。因此，項目經理必須仔細權衡范圍變更的成本及收益。這一階段的主要輸出包括變更請求；建議的糾正措施；項目范圍說明書、WBS和WBS詞典、范圍基線、項目管理計劃及組織過程資產的更新。
　　圖5-l總結了這些階段及其輸出情況，并說明了在特定項目中各階段可能發生的時間。

5.2需求收集
　　項目范圍管理的第一步即需求收集，通常是最困難的。不能準確定義需求的主要后果是重復工作，這很可能會耗費項目總成本的一半之多，特別是對于軟件開發的項目。正如圖5-2所示，在項目接近收尾時才發現軟件的缺陷并加以彌補，其成本比在需求收集階段就發現并修正的成本要高得多。

需求收集的一個難點在于，人們往往對需求缺乏一致性的定義，包括什么是需求、如何收集需求、如何編制需求文件。
5.2.1什么是需求
　　IEEE軟件工程標準詞匯表（1990年）中定義軟件需求為：
　　-用戶解決問題或達到目標所需的條件或能力。
　　-系統或系統部件要滿足合同、標準、規范或其他正式規定文檔所需具備的條件或能力。
　　-一種反映上面兩點所描述的條件或能力的文檔說明。
　　PMBOK指南第4版對需求的定義與上述第二項的內容基本相同。需求(requirement)是指根據合同、標準、規格或其他正式的強制性文件，某個系統、產品、服務、成果或部件必須達到的條件或具備的能力。
　　項目執行中，將需求詳細地記錄下來以便于日后測量，這一點非常重要。畢竟，滿足這些需求是實現項目范圍目標的基礎。
　　比如，開篇案例提到的通過升級IT資產滿足公司標準的項目。這些標準說明了每臺電腦或筆記本電腦所需要的最少設備，包括處理器類型、存儲量和硬盤大小。因此，需求記錄包括每臺電腦都應配置英特爾處理器、4CB內存和160G硬盤。
　　對于一些IT項目，可以將需求分為啟示、分析、詳細說明和驗證。這四類包含了軟件或軟件相關產品需求的收集、評估和記錄的各種活動。而反復定義需求也很重要，因為在項目開始時，需求通常并不清晰。
5.2.2如何收集需求
　　收集需求的方法有很多。與利益相關者一對一訪談是一種很有效的方法，盡管成本高，且很花時間。而使用焦點小組會議、引導式研討會、群體創新和決策技術法來收集需求，比一對一訪談法更快、成本更低。問卷調查法是一種行之有效的方法，前提是關鍵的利益相關者能夠提供誠實而全面的信息。觀察法也是很好的收集需求的技術，特別是對于需要改進工作流程或程序的項目。軟件開發項目中，還有一種需求收集的常用技術，即原型法。此外，還有一些幫助收集和管理需求的軟件工具，在下文和“對在哪里”的內容中將舉例說明。
對在哪里
　　Genesys電信實驗星以提供開創性的電話通信方案而享有廣泛聲譽。這蒙會司通過開發軟件，管理與客戶的電話、網絡和電子郵件互動，其在全球擁有超過4 000個客戶和l500名員工。但是，隨著公司的發展，他們不得蘋開發新產品，以應對保持競爭優勢的挑戰。例如，Ceriesys現在使用的Accept軟件，是一項計劃與創新方面的管理應用產品，獲得了2006 -2008年產品管理優秀獎。在應用Accept軟件之前，Genesys的產品計劃過程很費時，而且版本之間難以復制。產品管理與戰略副總裁保羅-蘭說，Accept軟件為他們提供了一個單一的系統，包含了多年度、多階段項目的多種產品的全部規劃數據。使用Accept，新產品曲定義和開發過程會逐步連貫、可重復且可預測。同時，他們可以定義哪些信息中包含了需求，并在相應的過程中強化鋮練。蘭說：“每巾需求都必須注明由誰提出，為什么提出，并且將這些需求與公司的戰略、產品和發售主題相關聯。”
　　要花費多大的精力去收集需求，取次于項目的規模、復雜程度、重要性和其他因素。例如，如果一個團隊正在為一個擁有50多個地區分公司、數十億美元資產的企業去更新整個公司的會計系統，那么該團隊應該花相當多的時間來收集需求。與之相反的情況是，對于為一個只有5名員工的小型會計公司而做的軟件和硬件升級項目而言，就只需要花很少的精力收集需求。無論如何，對一個項目團隊來說，為其承擔的項目收集和管理需求是非常重要的。如第4章所述，關鍵的利益相關者的投入，以及使整個項目范圍的關鍵方面與企業戰略相匹配是極其重要的。
5.2 3如何記錄需求
　　正如收集需求的方法有很多種，記錄需求的方法也不少。項目組最先閱讀的應該是項目章程，因為它包含了項目的高層次需求或者指出其他列出需求的文件。他們還應該查閱利益相關者評論，以確保所有關鍵利益相關者在決定需求時都有所表述。需求文件的格式多種多樣，既可以是在一頁紙上列出全部需求的清單，也可以是堆滿整個房間的記錄各種需求的筆記本。參加過復雜項目（比如建造新飛機）的人員深知：一份記錄飛機需求的文件比飛機本身更有價值！需求文件通常由軟件制作，可以是文檔、圖像、程序、錄像和其他媒介，也可將需求分類，如功能需求、服務需求、性能需求、質量需求、培訓需求等。
　　除了將利益相關者需求文件作為需求收集過程的輸出外，項目組經常會創建需求管理計劃和需求跟蹤矩陣。需求管理計劃( recluiremenk management plan)是描述如何分析、記錄和管理需求的計劃。需求跟蹤矩陣（reqmrements traceability matrix，RTM）是描述需求、需求源并對需求狀態進行跟蹤的表格。
　　以開篇案例中的IT更新項目為例，引入需求跟蹤矩陣，如表5-1所示。需求跟蹤矩陣可以包含很多變量。比如，用它記錄軟件需求時，將每個有關聯的需求交叉引用( cross-references)，并列出具體測試來證明這些需求已被滿足。記住，需求跟蹤矩陣的主要目的是通過對需求的分解、執行和驗證來保持每個需求源的聯系。

5.3范圍定義
　　項目范圍管理的下一步是要進一步定義項目所需開展的工作。合理的范圍定義對項目的成功非常重要，因為項目定義有助于提高時間、成本及資源估計的精確度，定義績效測量及項目控制的基線，幫助理清和明確工作職責。在范圍定義中，使用的主要工具及技術包括專家判斷、產品分析；可供選擇的T作方法識別和引導式研討會等。范圍定義的主要輸出是項目范圍說明書和項目文件更新。
　　項目范圍說明書的關鍵輸入包括：項目章程、需求文件、組織過程資產（如政策、范圍說明書的相關程序）、項目文件以及以前做過的類似項目的經驗教訓。表5-2描述了“開篇案例”所述IT升級項目的項目章程。注意項目章程中的信息是如何為進一步定義項目范圍做鋪墊的。項目章程描述了為實現項目整體目標的范圍、時間和成本目標、項目成功標準、完成項目目標的大致方式以及關鍵利益相關者的角色和責任。

盡管內容各異，但是項目范圍說明書至少應該包括：產品范圍描述、產品可接受標準、所有可交付成果的詳細信息。它還有助于將其他與項目范圍相關的信息文檔化，如項目界限、項目的限制條件和假設條件。項目范圍說明書也應參考一些支持性文件，如產品的具體說明，它會影響到生產或購買什么樣的產品；以及經營政策，它可能影響到如何提供產品或服務。許多IT項目也需要開發軟件的功能和設計說明，這些都應該在范圍說明書中詳細闡述。
　　隨著時間的推移，一個項目的范圍應該變得更加清晰和具體。例如在表5-2中所示的IT升級項目，其項目章程巾包括了關于服務器、其他計算機，還有IT升級項目可能涉及的軟件的簡短說明。而表5-3舉例說明了在項目范同說明書的版本1和版本2中，范圍是如何逐步細化的。

從表5—3中可見，項目范圍說明書通常是指一些相關的文件，如產品規格說明、產品手冊或者其他計劃。隨著與項目范圍相關的信息以及決定的增加，例如將要購買的具體產品或已批準的變更，項目團隊應當不斷更新項目范圍說明書，可以把范圍說明書的不同版本命名為版本1、版本2等。其他項目文件可能也需要隨之變更。例如，如果公司必須從以前從未合作過的供應商那里購買項目所需的服務器，那么范圍管理計劃應該包含與新供應商合作的信息。
　　擁有一份最新的項目范圍說明書對于建立和確認項曰范圍的一般共識是非常重要的。它具體描述了項目要完成的工作，并且如本章后面所述的，它還是確保顧客滿意及預防范圍蔓延的一個重要丁具。
　　回顧第1章中提出的項目管理的3個限制條件——實現項目的范圍、時間和成本目標。時間及成本目標一般是很簡單的。例如，IT升級項目的時間目標是9個月完成，成本目標是l500萬美元。而描述、接受并實現許多項目的范圍目標則要困難得多。
5.4創建工作分解結構
　　完成范圍計劃及定義過程之后，項目范圍管理的下一步就是創建工作分解結構。工作分解結構( work breakdown structure．WBS)以可交付成果為中心，將項目中所涉及的工作進行分解，定義出項目的整體范圍。因為大多數項目涉及很多人，以及很多不同的可交付成果，所以根據工作開展的方式，組織好工作并將其合理地進行分解是非常重要的。WBS在項目管理中是一個功能性的文件，因為它為計劃并管理項目的時間進度、成本、資源及變更提供了基礎。WBS定義了項目的全部范圍，由此一些項目管理專家認為，不包括在WBS中的工作就不應該去做。所以，創建一個良好的WBS是至關重要的。
　　創建工作分解結構的主要輸入是：項目范圍說明書、利益相關者需求文件和組織過程資產。需要的主要工具或技術是分解( decomposition)，即將項目可交付成果分解為更小的部分。制作WBS這一階段的輸出為WBS、WBS詞典、范圍基線及項目文件更新。
　　WBS是什么樣子的呢？WBS通常畫成以任務為導向的各種活動組成的家譜形式，類似一個組織結構圖。項目團隊經常圍繞項目產品、項目階段，以及使用項目管理過程小組來構建WBS。很多人喜歡首次用圖表形式制作WBS，以便能夠認清整個項目及其主要的組成部分。例如，圖5-3就是一個內聯網項目。注意產品結構為其組織結構提供了基礎。在此例中，WBS上有主要的模塊或分組，包括網頁設計、內聯網主頁、市場營銷部頁面及銷售部頁面等。

與之相對應，同樣的內聯網項目的WBS也可以圍繞項目階段來組織編制，如圖5-4所示。注意項目階段中的概念、網站設計、網站開發、推出及支持階段為組織結構設計提供了基礎。
　　注意圖5-4中的層級。工作分解結構中的最高層級即層級1，注明了項目名稱。下一層級稱為層級2，是層級l的主要分支，包含了工作的主要分組。層級的序號是根據項目管理協會( PMI)的《工作分解結構實踐標準》第2版（2006年）編制的。這些分支都可以分解為若干子分支，以體現工作的等級。PMI用“任務”來表示WBS中每一個層級的工作。例如，在圖5—4中，以下層級的內容都可用“任務”命名：層級2的內容稱為“概念”，層次3的內容稱為“定義需求”，層級4的內容稱為“定義用戶需求”。將任務進一步分解后的部分，稱為簡要任務。圖5-4是分別用圖表和表格形式制作的WBS樣本。注意，兩種形式包含的信息是相同的。許多文件，如合同都使用這種表格形式。項目管理軟件也使用這種形式。在Microsoft Project軟件中，WBS是“任務名稱”欄的內容，而任務層級以任務識別及編號的形式體現。圖5-4下半部分左側的表格編號與Microsoft Project或其他軟件的編號方式一致，右側的表格序號是根據項目管理協會(PMI)的《工作分解結構實踐標準》（第2版）編制的。因此，創建工作分解結構時，請確認組織使用哪種編號系統。

在網5-4中，WBS的最低層為層級4。工作包(Work package)即為WBS最低層的一項任務。圖5-4中，任務1 2 1，1.2.2，1.2 3和1.2 4（基于左側的編號系統）都是工作包。其他任務很可能將被進一步分解。但是，WBS的層級2或層級3的一些任務可以保留，其他的可能要分解為層級5或層級6，這要根據工作的復雜程度而定。工作包也代表了項目經理用來監控項目的工作層級。你也可以把工作包理解為問責制和匯報的實施單元。如果一個項目要在短期內完成，并且需要每周都進行進度報告，那么一個工作包可能代表一周或更短時間內的工作。另一方面，如果項目進行時問較長，需要按季度做進度報告，那么一個工作包可能代表一個月或更長時間的工作。工作包也可能是一種或多種具體產品的采購，比如從外部購買這些產品。
　　另一個考慮工作包的方法是，把數據輸入項目管理軟件。你可以僅僅輸入工作包的工期估計，而WBS條目則是工作包的分組或匯總。軟件會根據每個工作包輸入的數據及WBS層級自動為各種WBS層級計算工期估計。用Project 2007制作WBS的具體說明見附錄A。
　　圖5=5顯示了以項目階段為導向的內聯網WBS，這一工作分解結構使用與圖5-4相同的編號計劃，并且使用Project 2007制作的甘特圖形式。注意，工作分解結構位于任務名稱欄下方圖示的左邊，相應的時間進度位于右邊。在第6章中還將詳細介紹甘特圖。

這里展示的WBS樣本看起來相對比較容易制作，也容易理解。然而，真正創建一個好的WBS是很困難的。為制作良好的WBS，你必須了解項目及其范圍，并將利益相關者的需求及支持包括進去予以綜合考慮。項目經理及項目團隊必須決定，作為一個小組如何組織工作，以及WBS中應包括多少層級。許多項目經理發現，重點將WBS最高層次工作做好比陷入更多的細節之中要好得多。
　　許多人將WBS中的任務與具體丁作混淆了。WBS中的任務代表了為完成項目所需開展的工作。例如，你正在為重新設計廚房制作一個WBS，那么層級2可能包括設計、采購、地板材料、墻壁、廚具及設施。但在“地板材料”這一條目下，你可能還有很多工作要做，例如要去除舊地板材料，鋪上新材料及配飾等。你不可能一下子細到像“12:14輕質櫟木板”或“地板必須耐用”這樣的任務和要求。
　　另外，制作WBS時要注意的是，如何編制WBS，以使其為項目時間進度提供基礎。你應該關注的是，什么工作需要完成及如何完成，而不是什么時候完成。換句話說，任務不必排成一個有序的清單。你如果打算以時間流程為基礎來工作，則可以利用項目管理過程組，即啟動、計劃、實施、監控及收尾。作為WBS中的層級2來制作WBS，這樣做的活，不僅可以使項目團隊遵守了良好的項目管理實踐，也使WBS任務能更容易地以時間為軸來進行安排。例如，圖5-6顯示了內聯網項目的WBS及甘特圖，它們就是通過5個項目管理過程組來進行組織的。啟動條目下的任務包括選擇項目經理、組建項目團隊及制定項目章程。計劃條目下的任務包括制作范圍說明書、構建WBS、制定及改進其他計劃。還可以將這些任務分解得更為詳細一些，以使其成為一個真正的項目。在圖5-4中，概念、網站設計、網站開發及推出等任務曾是WBS的層級2中的條目，現在成為實施條目之下的WBS層級3的條目。在項目與項目之間，實施條目的任務差別最大，而其他項目管理過程組的條目下的大多數任務刈所有項目來說是很相似的。在WBS中，如果不使用項目管理過程組，你可以將層級2條目設置為項目管理，以確保將與管理項目相關的任務都考慮進來。記住，所有工作都要包括在WBS之中，包括項目管理。
　　JWD咨詢公司使用了項目管理過程組作為第3章中項目管理內聯網項目的WBS的層級2條目。在分解實施過程中的任務時，項目團隊要重點關注他們為產出項目的產品而提供的可交付成果。表5-4顯示了團隊列于WBS中這個部分建立的相應條目。一些項目團隊喜歡列出需要提交的每一個可交付成果，然后用它們作為制作全部或部分WBS的基礎。由前面所介紹的內容可知，范圍說明書必須羅列并描述項目要求的所有可交付成果。因此，保證項目章程、范圍說明書、WBS及甘特圖的一致性，精確地確認項目范圍是非常重要的。

讓項目團隊及客戶參與創建并商討WBS也是非常重要的。從事具體工作的人應通過制作WBS來幫助為這些T作制定計劃。另外，如果大家都來參與的話，召開團隊會議來創建WBS會使每個人都能認識到，要完成整個項目必須要做什么工作，以及如何去做。這電有助于認清在不同的工作包之間有哪些地方需要做好協調工作。

5.4.1  制作工作分解結構的方法
    你可以使用以下幾種方法來制作丁作分解結構：
     -使用指南；
     -類比法：
     -自上而下法：
     -自下而上法：
     -心智圖法。
1.使用指南
　　如果要制作WBS的指南，那么遵循這一指南非常重要。一些組織，例如美國國防部(DOD)規定了特殊項目的形式和內容。許多DOD項目要承包者根據DOD提供的WBS準備他們的方案。這些方案必須包括WBS中的具體層次及總結層次的每一任務的成本估算。整個項目的成本必須通過所有WBS低一級任務成本加總計算得來。當DOD的人員評價成本方案時，他們必須要將承包者的預算與DOD的預算估計進行對比。如果一項既定的WBS任務在成本方面存在大的偏差，那通常意味著在必須要完成的工作方面出現了異議。
　　下面來看美國空軍的一個大的自動化項目。在20世紀80年代中期，空軍提出了一個地方聯線網絡系統( LONS)項目，要求15個空軍系統的司令部基地實現聯網自動化。這一2.5億美元的項目包括提供硬件，以及為共享文件，如合同、規格、征求建議等開發軟件。空軍建議性的指南包括在要求承包商準備預算方案時所遵循的WBS。WBS的層級2條目包括硬件、軟件開發、培訓和項目管理等。硬件條曰由幾個層級3條目構成，如服務器、工作站、打印機和網絡硬件等。空軍人員通過對比同樣依據此WBS做出的內部預算估計來重新評審承包商的預算方案。預先指定的WBS可以幫助供應商準備其預算方案，并幫助空軍來評價這些方案。
　　除了應用過去項目中的WBS樣本，許多組織還為制作WBS提供指南和模板。Microsoft Project2007有幾個模板，在微軟的專用網站上還可以找到更多的模板。在很多成員的要求下，美國項目管理協會建立了一個WBS實施標準，為制作及使用項目管理中的WBS提供了指導。這份文件包括了各種行業中多種多樣的項目的WBS樣本，例如網站設計、通信、服務外包及軟件開發等項目。
　　但是，為了更有效地為特定的項目開發WBS，項目經理及其團隊應重視自己項目的適當信息。例如，在“開篇案例”中，在為制作WBS召開團隊會議之前及期間，Kim Nguyen及其關鍵團隊成員應該仔細考慮公司的WBS創建指南、模板及其他相關信息。
    2.類比法
　　構建WBS的另一種方法是類比法。在類比法(analogy approach)中，會使用一個類似項目的WBS作為起點。比如在“開篇案例”中，Kim Nguyen可能會獲悉，其公司的一個供應商去年做過一個類似的IT升級項目。因此她可以詢問一下他們，看看是否可以共享這一項目的WBS，這樣就為自己的項目提供了一個起點。
　　麥道公司，現在是波音的一部分，給我們提供了一個制作WBS時使用類比法的例子。麥道公司設計并制造了幾種不同的戰斗機。當為一種新飛機設計制作WBS時，開始是根據過去的經驗使用74種提前定義的制造戰斗機的子系統來進行的。飛機結構屬于WBS的層級2條目，它由諸如前部機身、中部機身、尾部機身及機翼這樣的層級3條目構成。這種以產品為導向的WBS為定義新飛機項目的范圍，并為新飛機設計進行成本估算提供了一個起點。
　　一些組織還設立專門的地方將WBS及其他項目文件存檔保存起來，以幫助人們繼續做項目。Project 2007及許多其他軟件工具都包含幫助用戶制作WBS及甘特圖的樣本文件。通過瀏覽其他類似項目的WBS樣本，能夠使你了解到更多制作WBS的不同方法。
    3.自上而下法和自下而上法
　　其他兩種制作WBS的方法是自上而下法和自下而上法。多數項目經理認為，自上而下構建WBS的方法是較為常用的。在使用自上而下法(top-doWn approach）時，要從項目最大的條目開始，并將它們分解為低層次的條目。這一過程要將工作精煉為更加具體的層級。例如，圖5-4展示了內聯網項目的部分工作是如何被分解到層級4的。在此過程完成之后，所有的資源將被分配到工作包層級。自上而下法對于有深刻的技術洞察力及視野廣闊的項日經理是最適用的。
　　在自下而上法( bottom-up approach)中，團隊成員首先盡可能多地辨清與項目有關的具體任務，然后聚集這些具體任務并將其匯總成總體性的活動或WBS中更高的層級活動。例如，如果一個小組負責設計電子商務設施制造的WBS，那么他們不是先尋找如何制作WBS的指南依據，也不是先查閱類似項目的WBS，而是一開始就列舉他們認為制造此設施需要執行的具體任務。在列舉出具體任務后，他們會將任務歸類，然后將這些類別再組成更高層級的類別。有人發現，將所有可能的任務先記錄下來，然后貼在墻上，可有助于看清項目所需要的所有工作，并為開展工作進行合理分組。例如，項目團隊的業務分析師知道，他們必須要為電子商務設施項目定義用戶需求及內容需求。這些任務可能是他們必須要完成的且作為項目可交付成果之一的需求文件的一部分。硬件專家知道他們必須要定義系統需求和服務器需求，這些也是需求文件的一部分。作為一個群體，他們可能會決定將這4部分任務放在更高一級條目“定義需求”之下，這一條目會產生作為可交付成果之一的需求文件。然后他們會認識到，同其他與概念設計相關的任務類別一樣，定義需求應該放在電子商務設施項目中“概念設計”這一更宏大的分類之中。出上可見，自下而上法非常費時，但同時也是非常有效的制作WBS的方法。項目經理經常將自下而上法用于描述新系統，或作為完成工作的方法，或幫助創造團隊建立共識和互信。
    4.心智圖法
　　有些項目經理喜歡使用心智圖法來幫助構建WBS。心智圖法（mind mapping）是一種結構分解的技術，通過從一種核心理念發散出來，將思想和想法結構化。心智圖法不是將任務列成清單或立即試圖構建任務結構，而是讓人們寫下甚至用非線條方式畫出心智圖。它是一種更加可視化、結構限制少、先定義后再組織任務的方法，可以發揮個人的創造力，并提高團隊的參與度和士氣。
　　圖5-7顯示了如何使用心智圖法來為第3章中的IT升級項目制作WBS，是用Mindjet的Mind-manager軟件制作的。中心的圓圈代表整個項目，從中心輻射出的4大主枝，每枝代表WBS的主要任務或層級2條目。在使用和制作此心智圖的人中，不同人在項目中扮演不同的角色，以此來幫助確定項目的任務及WBS結構。例如，Kim雖然想要注重所有的項目管理任務，而她可能也知道，自己僅僅有能力忙于一個單獨的預算分類。類似地，熟悉獲取或安裝硬件、軟件的人可能會關注獲取或安裝工作等。從主任務“更新庫存”中分離出來的是兩個子任務：“進行實物盤點”及“數據庫升級”。“進行實物盤點”下的子任務是3個更細的子分支，標記為建筑A、建筑B及建筑C等。直到想不出還有什么T作需要做了，團隊才會不再繼續增加分支及條目。

在使用心智圖技術開發出WBS條目及結構后，你可以將有關信息轉換為如前所述的圖表或表格形式。MmdManager軟件的特點在于，你可以將做出的心智圖導人Microsoft Project軟件。Microsoft Project根據心智圖，自動創建WBS結構，并在“任務清單”欄中生成WBS。圖5-8是IT升級項目中生成的Project 2007文檔。

在使用白上而下法或自下而上法制作WBS時都可以應用心智罔法。例如，如果要為整個IT項目繪制心智圖，可通過在一個文件的中心列出整個項目，增添從中心輻射出來的主要類別分支，然后增添相應子類別分支。當然，你也可以為每一個可交付成果制作不同的心智圖，然后將其合并組成整個項目的大圖。還可以不用遵循嚴格的自上而下法或島下而上法，而是在心智圖繪制文件上隨處增添條目。當完成心智圖繪制文件后，也可將其轉換為WBS的圖表形式。
5.4.2  WBS詞典及范圍基線
　　如同你從WBS的樣本中所看到的，列出的許多條目是相當含糊的。例如，“數據庫升級”確切地說是什么意思？負責此任務的人可能認為，這樣就可以了，無須再往下分解了。然而，對此任務還必須更詳盡地予以描述，以便每個人都能對其所包含的內容有相同的理解。如果其他人實施此任務的話，他會做些什么呢？你要告訴他做什么？完成此任務要花費多少時間？因此，還需要更詳盡的信息來回答這些問題，以及其他一些問題。
　　WBS詞典(WBS dictionary)是一個描述WBS每項條目詳細信息的文件。WBS的格式可根據項目的需要而定，有時僅用簡短篇幅描述一下每一工作包就可以了。但對更為復雜的項目而言，丁作包描述可能需要一整頁甚至更多。有些項目可能要求對每一個WBS的條目都要描述負責的組織、資源需求、預算費用以及其他一些信息。
　　Kim應該和她的凼隊及項目發起人一起共同決定WBS詞典所需要的詳細程度。他們還應當確定這些信息需要輸入到哪里，以及如何進行更新。項目團隊通常會參考類似任務的WBS詞典條目，以便更好地了解如何編制這些條目。對IT升級項目來說，Kim和她的團隊決定遵循部門的相關指南，將所有WBS詞典的信息輸入到公司的項目管理系統。表5-5是一個條目的詞典示例。

核準的項目范圍說明書及其相關的WBS和WBS詞典構成了范圍基線。實現項目范圍目標的績效依據的就是這個范圍基線。
5.4.3構建WBS及WBS詞典的建議
　　如前所述，構建一個好的W-BS并不是一項簡單的任務，一般要遵循幾項要求。通常最好是將幾種方法結合起來構建項目的WBS。這里有一些基本原則可以適用于構建任何良好的WBS及WBS詞典。
　　 -一個工作單元應該只出現在WBS中一次。
　　 -一個WBS條目的工作內容是它下一級WBS條目的總和。
　　 -一個WBS條目僅有一人自責，盡管可能有很多人在為其工作。
　　 -WBS必須與實際開展工作的方式保持一致；它必須首先為項目團隊服務，然后如果可行的話，再服務于其他目的。
　　 -項目團隊成員應當參與建立WBS，以確保一致和遵從。
　　 -每一WBS條目必須記載在WBS詞典中，以確保大家都能準確明白該條目包含及不包含哪些工作范圍。
　　 -在根據范圍說明書進行項目工作內容控制時，WBS必須是一個能靈活變通的工具，以應對一些不可避免的變更。
5.5范圍核實
　　為一個項目制定出好的項目范圍說明書及WBS是很難的。特別是對IT項目而言，要核實范圍并將范圍變更最小化則更難了。一些項目團隊一開始就知道，范圍非常不明確，并且他們必須與項目客戶密切合作，共同設計并產出各種可交付成果。在這種情況下，項目團隊必須為滿足特殊項目需求的范圍驗證建立一個流程；必須設立詳細的步驟確保客戶得其所需，并且項目團隊有足夠的時間和資金來產m所需的產品和服務。
　　就算界定了項目范圍，許多IT項目還是會遭遇范圍蔓延——項目范同越來越大的趨勢。有很多由于范圍問題，如范圍蔓延（scope creep），導致IT項目失敗的可怕的事例，一些典型的例子可參考下文“錯在哪里”，因此在貫穿項目生命周期的整個過程中與用戶一起更新項目范圍并為控制范圍變化設立流程是非常必要的。
錯在哪里
　　一個項目的范圍如冪太寬泛、龐大將會引發許多問題。范圍蔓延以及出于技術考慮過分強調技術，導致了一個大制藥公司--總部設在德州的FoxMeyer藥物公司破產了。994年，公司CIO開發了一個價值6500萬美元的系統來管理公司的關鍵運營。然而他并不相信把事情做簡單的意義何在。公司將1000萬美元投在先進的硬件和軟件上，并通過簽訂合同將項目的管理工作外包給一家有威望且收費昂貴的咨詢公司。據知情人說，項目包括建設造價1800萬美元的機械化貨倉，此貨倉看起來像出自一部科幻電影。項目范圍變得越來越炙且更加不切實際。這一精心打造的貨倉并沒有按時完成，幫系統引發的秩序混亂使FoxYkyer藥物會司在無法挽回的過量運輸土損失了1500萬美元。1996年7月，公司第4個財政季度損失了3400萬美元。當年8月，FoxMleyer藥物公司申請破產。6范圍蔓延的另一個例子是麥當勞餐館。2001年，該快餐連鎖店開始了構建內聯網的項目。此內聯網將總部與所有的餐館聯系起來，可以賓時提供詳細的運營信息。例如，總部要知道銷售顫是否下降或每家后鋪燒烤溫度是否正確--在120多個國家的所有3萬家店里。麥當勞沒有透露詳細信息，但他們承認此項目規模及范圍太大。在花費了l7億美元用于咨詢及初期執行計劃后，麥當勞認識到要控制并完成到這一項目是太困難了。
　　IT項目的另一個主要范圍問題是缺少用戶參與。在20世紀80年代末期，在Northrop Grumman，一家專業生產國防電子產品、信息技術、高端飛行器、造船度空問技術的公司里，一個IT項目團隊認為能夠且應該將審查和批準政府建議的過程自動化。固阻開發了一個強有力的工作流程系統來管理整個過程。不幸的是，此系統的最終用戶是航天技術工程師，他們喜歡以更加輕松、隨意的方式工作．他們稱此系統為“納粹軟件”并拒絕使用。此例展現的是一個耗費數百萬美元構建一個與最終用戶工作方式并不一致的系統的IT項目。
　　不遵守良好的、規范的項目管理過程并應用現成的軟件，也會導致范圍問題。坐落于加刺福尼亞Woodland I-1ills的21世紀保險集團支付了l億美元給一家電腦技術公司，要為業務管理建立一個系統，包括管理保險政策、賬單、賠償及客戶服務。5年后，也就是2002年，該系統仍在建設之中，并且僅可以支持不到2%的公司業務。Joshua Greenbauni是企業應用咨詢的一個分析師，他稱此項目為一個“巨大災難”，并質疑保險公司的能力“能否管理好最新流行的過程，我懷疑使用現有的東西來建立他們需要的系統并降低風險是沒法實現的。”
　　范圍核實（scope verification）是由利益相關者對已界定的項目范圍進行的正式確認。這一確認通常由客戶檢查完成，然后由關鍵利益相關者來收尾。為獲得項目范圍的正式驗證，項目團隊必須建立項目產品和程序的清晰的文檔存儲，以評價項目團隊在產出產品和遵守程序上是否正確及令人滿意。如第4章所述，配囂管理專家會確認并將項目產品的功能特性和物理特性存檔，記錄并報告出現的變更，審核產品并證明其是否與需求一致。要將范圍變更最小化，做好配置管理及項目范圍核實工作很關鍵。
　　項目管理計劃、需求文件、需求跟蹤矩陣和成果驗證是范圍核實工作的主要輸入。開展范圍核實的主要工具是檢查。工作結束后由客戶、項目發起人或用戶進行檢查。范圍核實的主要輸出是驗收的可交付成果、變更請求、項目文件更新等。例如，假設Kim的團隊成員將升級的電腦交付給用戶作為IT升級的一部分。可能有幾個用戶會提出抱怨，因為電腦沒有他們由于醫學需要的特殊鍵盤。有關人員會商討這一變更需求，并采取相應的糾正措施，如在得到項目發起人的許可后購買特殊的鍵盤。
5.6范圍控制
　　如第4章集成變更控制部分所講的，在項目中出現變更是無法避免的，尤其是押項目的范圍變更。范圍控制( scope control)是指控制項目范圍的變更。用戶通常不明確他們想要的系統界面看起來是什么樣子的，或者他們實際上需要什么功能來改善經營業績。開發商不能明確是否準確理解了用戶需求，而且他們還要面對不斷變化的技術環境。
　　范圍控制的目的是對那些引起范圍變化的因素施加影響，確保變更能依據集成變更控制建立的程序有序進行，并管理已發生的變更。如果沒有做好需求收集、范圍定義和驗證工作，就不可能做好范圍控制工作。如果你沒有同意做某項工作，并且發起人還未證實計劃的工作得到驗收，那你如何預防范圍蔓延？所以你需要為要求并監測項目范圍變更設立一個流程，應該激勵利益相關者針對有益于整個項目的變更提出建議，同時拒絕那些項目不需要的變更建議。
　　范圍控制的主要輸入有：項目范圍管理計劃、工作績效信息、需求文件、需求跟蹤矩陣和組織過程資產。范圍控制的主要工具是實施偏差分析。偏差（vanance）是指計劃與實際績效的差異。比如，供應商本該提供5個鍵盤，而你只收到了4個，那么偏差是1個鍵盤。范圍控制的輸出包括工作績效測量結果、組織過程資產更新、變更請求、項目管理計劃更新以及項目文件更新。
　　表l-2曾列舉了有助于IT項目成功的前10大因素。在這10個因素中，有4個與范圍核實和控制相關：客戶參與、明確的目標、較小或清晰定義的范圍以及公司的基本需要。因此，為避免項目失敗，對IT項目經理及其團隊來說，至關重要的是要共同致力于提高用戶投入程度，減少不完整且不斷變化的需求及說明書。
　　下面的內容提供了更多的有關改進IT項目范圍管理的建議。
5.6.1  提高用戶投入的建議
　　缺少用戶的投入導致了管理范圍蔓延及控制的變更。如何管理這些重要的問題呢？下面是提高用戶投入的一些建議。
　　-為IT項目設立良好的選擇過程。要確保所有項目都有來自用戶組織的發起人。項目發起人應該既不是IT部門中的某個人，也不是項目經理。要確保項目信息，包括項目章程、項目管理計劃、項目范圍說明書、WBS及WBS詞典，在組織中很容易獲得。獲得基本的項目信息可以幫助避免重復勞動，并保證最重要的項目正是人們在做的項目。
　　-項目團隊中有用戶參與。一些組織要求項目經理來自項目的業務領域而非IT部門。一些組織任命IT項目的合作項目經理，一個來自IT部門，一個來自主要的經營部門。應該將用戶全職分配給大的IT項目，兼職配置給小的項目。美國西北航空公司ResNet項目的一個關鍵成功因素是培訓預訂系統代理人——用戶如何為他們新的預訂系統編寫程序代碼。因為精通經營知識，所以銷售代表提供了優質的輸入信息并且實際開發了大多數軟件。
　　-在既定日程舉行定期會議。常規性會議顯然是需要的，但是很多IT項目失敗是因為項目團隊成員沒有與用戶定期進行相互溝通。沒有得到直接的反饋信息，他們就自認為知曉了用戶所需。為促進這種相互溝通，用戶應該在會議上提交的關鍵可交付成果上簽字。
　　-定期向項目的用戶和項目發起，人交付一些成果。如果是硬件或軟件之類的，應確保優先完成。
　　-不要承諾在特殊的時間框架內交付不能交付的成果。應確保在項目時間進度中有足夠時間產生可交付成果。
　　-用戶和開發商共處一處辦公室。空間距離接近時，人們通常更容易了解對方。如果用戶在整個項目期間不能搬至鄰近承包商處，他們應拿出一些時間來共處。
5.6 2減少不完整的和不斷變化的需求的建議
　　對IT項目來說，可以預計會發生某些需求變更，而許多項目出現了太多的需求變更，特別是在項目生命周期末期實施變更困難的時候。有關改進需求過程的建議如下：
　　-設立并遵循一個需求管理過程。這一過程包括確定初步需求的程序。
　　-利用某些技術工具，如原型制作、用況模型創建法及合作應用技術程序設計來全面了解用戶需求。原型制作( prototyping)是指設計一個系統或系統某些方面的工作模型。這些工作模型可能是一次性的或者是可交付系統附屬的部分。原型制作是為了獲得對需求的認識、確定需求的可行性及解決用戶界面不確定性而使用的一個有效工具。用況模型創建法( use case modeling)是一個辨識業務經營事件并將其建模的過程，例如誰引發這些事件，系統如何應對這些事件等。它是了解信息系統需求的有效工具。合作應用程序設計(jointapplication design，JAD)使用高層組織的、深入的專題討論會將項目利益相關者--項目發起人、用戶、業務分析師、程序員等聚集在一起，共同定義并建立信息系統。這些技術也可幫助用戶更好地參與定義系統的需求。
　　-記錄所有的需求信息，隨時更新，并且隨時可獲得。要想自動實施此功能，有幾種工具可行。比如，一種叫做“需求管理工具”的軟件可幫助獲取并保存需求信息，還可及時存取信息，并幫助建立需求與其他工具構建的信息之間的必要關系。
　　-為文檔化及控制需求構建需求管理數據庫。計算機輔助軟件工程( CASE)或其他技術可幫助存儲項目數據。一個CASE工具的數據庫也可用于存儲和控制需求。
　　-進行適當的測試，以證明項目產品能否滿足需求。測試要貫穿整個項目生命周期。在第8章包含了更多的關于測試的信息。
　　-從系統角度使用某種過程方法來審視所要求的需求變更。比如，要確保項目范圍變更中有相應的成本及時間進度的變更；要獲得適當的利益相關者的同意。對項目經理而言，至關重要的是要領導團隊致力完成認可的范圍目標，并且不能把重點轉到額外的工作上。例如，Andy Crowe在他的《阿爾法項目經理》中試圖揭示“最佳的”或“阿爾法”項目經理與其他項目經理做事的區別。其中一位阿爾法項目經理提到了他是如何學習一節有關范圍控制重要一陛的課程的：
　　“在我做過的一些項目接近結束時，經理們真的讓其團隊工作了太長時間。當這種事情接二連三發生時，我僅僅以為事情本來就是這樣的。其后我與另一位經理共事，這位經理把任何事情計劃得非常好，始終使團隊按節拍運轉，并且我們一直遵守時間進度安排。當發現項目如期進行時，客戶試圖增加范圍，但這次我們有一個優秀的經理，沒有調整基準，她不會讓客戶這么做的。那是第一次我所工作的項目的所有事情都按時按預算完成。對她為何如此輕松地完成工作我感到很驚訝。”;
　　-強調完工日期。比如，在密蘇里州堪薩斯市的Farmland Industries公司里有一位項目經理．通過設定項目的截止時間，使一個歷時15個月、耗資700萬美元的一體化供應鏈項目按部就班地完成了。她說：“5月1日是最后期限，其他所有事情都要以此為依據。用戶如果來我們這里并要求我們做某事，那么我們就要問他們放棄什么來交換。堅持此日期是我們管理范圍蔓延的一個方法”。
　　-為處理變更需求專門分配資源。例如，美國西北航空公司的Peeter Kivestu與他的ResNet團隊獲悉，用戶要求他們增強正在開發的預訂系統。為滿足用戶請求，他們在ResNet屏幕上增加了一個特殊的功能鍵，并且項目安排了3名專職程序員來處理這些請求。用戶提出了11000多個強化請求。發起4名主要軟件應用項目的經理梳理了軟件強化請求的優先次序，并作為一個小組決定同意哪些變更。然后這3名程序員按優先次序，在給定時間內處理盡可能多的變更條目。盡管他們僅處理了強化請求的38%，但是這部分卻是最重要的，并且用戶對系統及過程感到非常滿意。
5.7利用軟件輔助項目范圍管理
　　項目經理及其團隊可以使刷幾種軟件輔助項目范圍管理。正如本章的各種圖表所示，你可以使用文字處理軟件來編輯與項目范圍相關的文件；也可以像大多數人那樣，使用電子表格或演示軟件來構建范圍管理相關的各種圖表、瞌線圖和模型，也可以用心智圖軟件創建WBS。項目利益相關者也利用各種溝通軟件，如電子郵件和各種基于網絡的應用系統，來傳輸項目范圍管理的信息。
　　項目管理軟件可以幫你建立WBS，進而為構建甘特圖、分配資源、分擔成本等提供基礎。你還可使用各種項目管理軟件附帶的模板為項目制作WBS。關于使用Project 2007的詳細信息可參見附錄A中項目范圍管理部分。
　　你也可以使用各種專業化軟件來支持項目的范圍管理。許多IT項目使用特殊軟件來進行需求管理，像原形制作、建模及其他與范圍相關的工作。范圍是項目管理中至關重要的部分，因此有許多可行的軟件產品可以幫助管理項目范圍。
　　項日范圍管理非常重要，特別是對于IT項目。篩選項目后，組織必須計劃開展項日工作的內容，將丁作分解為便于管理的部分。要與項目利益相關者共同驗證范圍，并管理項目范同的變更。應用本章所講的基本項目范圍管理概念、工具及技術司成功地實施項目范鬧管理。
案例結局
　　Kim Nguyen再次審視了由公司愛其他渠道獲得的構建WBS的相關指南。她與3位項目團隊領導召開了一次會議，著手計劃他們可提供的輸人。在商討了幾種樣本文件后，他們決定根據最新的庫存清單，將項目工作分組，包括獲取需要的硬件和軟件，安裝硬件和軟件，實旋項目管理。在確定了基本方法后，Kim與整個項目團隊共計12個人又召開了會議。她匪顧了項匿章程和利益相關者記錄，說明了收集需求和定義項目范圍的基本方法，評論了一些WBS樣本。Kim請大家暢所欲言，提出問題，并非常自信地進行了解答。然后她讓每個豳隊主管與自己的成員起共同開始撰寫詳細的范圍說明書以及ViBS和ViBS詞典的相應部分。每個人都參加了會議，分享了個人的專業技能，公開提問。Kim看到項目有了一個良好的開端。