項目範圍管理

時間 2019-12-13

標籤項目範圍管理简体版

原文原文鏈接

5.1 範圍管理概述

　　項目範圍管理須要作如下三個方面的工做：編程

　　　　（1）明確項目邊界，即明確哪些工做是包括在項目範圍以內的，哪些工做是不包括在項目範圍以內的。併發

　　　　（2）對項目執行工做進行監控，確保全部該作的工做都作了，並且沒有多作。對不包括在項目範圍內的額外工做說「不」杜絕作額外工做。框架

　　　　（3）防止項目範圍發生蔓延。範圍蔓延是指未對時間、成本和資源作相應調整，未經控制的產品或項目範圍的擴大。工具

5.1.1 產品範圍與項目範圍

　　1、產品範圍是指產品或者服務所應該包含的功能，項目範圍是指爲了可以交付產品，項目所必須作的工做。開發工具

　　2、產品範圍是項目範圍的基礎，產品範圍的定義是產品要求的描述；而項目範圍的定義是產生項目管理計劃的基礎。測試

　　3、項目的範圍基準是通過批准的項目範圍說明書、WBS和WBS詞典。編碼

　　4、判斷項目範圍是否完成，要以範圍基準來衡量。而產品範圍是否完成，則根據產品是否知足了產品描述來判斷。spa

　　5、產品範圍描述是項目範圍說明書的重要組成部分，所以，產品範圍變動後，首先受到影響的是項目的範圍。設計

5.1.3 範圍管理的過程

　　1、項目範圍管理主要是經過規劃範圍管理、收集需求、定義範圍、建立WBS、確認範圍和控制範圍六個過程來實現的。日誌

　　2、範圍管理各過程

　　3、範圍管理各過程輸入、輸出、工具和技術

5.2 規劃範圍管理

　　1、規劃範圍管理是編制範圍管理計劃，書面描述將如何定義、確認和控制項目範圍的過程，其主要做用是在整個項目中對如何管理範圍提供指南和方向。

　　2、規劃範圍管理過程的輸入有項目管理計劃、項目章程、事業環境因素和組織過程資產，使用的工具與技術有專家判斷和會議，輸出有範圍管理計劃和需求管理計劃。

5.2.1 範圍管理計劃

　　1、範圍管理計劃是制訂項目管理計劃過程和其餘範圍管理過程的主要輸入，包含以下內容

　　　　（1）如何制訂項目範圍說明書。

　　　　（2）如何根據範圍說明書建立WBS。

　　　　（3）如何維護和批准WBS。

　　　　（4）如何確認和正式驗收已完成的項目可交付成果。

　　　　（5）如何處理項目範圍說明書的變動，該工做與實施總體變動控制過程直接相聯。

　　2、項目範圍管理計劃可能在項目管理計劃之中，也可能做爲單獨的一項。根據不一樣的項目，能夠是詳細的或者歸納的，能夠是正式的或者非正式的。

5.2.2 需求管理計劃

　　1、需求管理貫穿於整個過程，它的最基本的任務就是明確需求，並使項目團隊和用戶達成共識，即創建需求基線。另外，還要創建需求跟蹤能力聯繫鏈確保全部用戶需求都被正確地應用，而且在需求發生變動時，可以徹底地控制其影響範圍，始終保持產品與需求的一致性。

　　2、需求管理計劃描述在整個項目生命週期內如何分析、記錄和管理需求。主要包括如下內容。

　　　　（1）如何規劃、跟蹤和彙報各類需求活動。

　　　　（2）需求管理須要使用的資源。

　　　　（3）培訓計劃

　　　　（4）項目干係人蔘與需求管理的策略

　　　　（5）判斷項目範圍與需求不一致的準則和糾正規程

　　　　（6）需求跟蹤結構，即哪些需求屬性將列入跟蹤矩陣，並可在其餘哪些項目文件中追蹤到這些需求

　　　　（7）配置管理活動

5.3 收集需求

5.3.1 需求的分類

　　（1）業務需求：整個組織的高層級須要，例如，解決業務問題或抓住業務機會，以及實施項目的緣由。

　　（2）干係人需求：是指干係人或干係人羣體的須要。

　　（3）過渡需求：從當前狀態過渡到未來狀態所需的臨時能力，例如，數據轉換和培訓需求。

　　（4）質量需求：用於確認項目可交付成果的成功完成或其餘項目需求的實現的任何條件或標準。QFD對質量需求進行了細分，分爲基本需求、指望需求和意外需求。

5.3.2 收集需求的工具與技術

　　1、收集需求的工具與技術主要有訪談、焦點小組、引導式研討會、羣體創新技術、羣體決策技術、問卷調查、觀察、原型法、標杆對照、系統交互圖、文件分析等。

　　2.焦點小組：將預先選定的干係人和主題專家集中在一塊兒，瞭解他們對所提議產品、服務或成果的指望和態度。由一位受過訓練的主持人引導你們進行互動式討論。焦點小組每每比一對一的訪談更加熱烈。焦點小組是一種羣體訪談而非一對一訪談，能夠有以有6~10個被訪談者參加。針對訪談者提出的問題，被訪談者之間開展互動式討論，以求獲得更有有價值的意見。

　　3、引導式研討會：經過邀請主要的跨職能幹系人一塊兒參加會議。引導式研討會對產品需求進行集中討論與定義。研討會是快速定義跨職能需求和協調幹系人差別的重要技術。因爲羣體互動的特色，被有效引導的研討會有助於創建信任、促進關係、改善溝通，從而有利於參加者達成一致意見。該技術的另外一個好處是，可以比單項會議更快地發現和解決問題。

　　4、羣體創新技木是指能夠組織一些羣體活動來識別項目和產品需求，羣體創新技術包括頭腦風暴法、名義小組技術、德爾菲技術、概念/思惟導圖、親和圖和多標準決策分析等。

　　　　（1）頭腦風暴：各抒己見

　　　　（2）名義小組技術：經過投票來排列最有用的創意，以便進行進一步的頭腦風暴或優先排序。名義小組技術是頭腦風暴法的深化應用，是更加結構化的頭腦風暴法

　　　　（3）德爾菲技術：能夠防止我的的觀點被不正確的放大

　　　　（4）概念/思惟導圖：是將從頭腦風暴中得到的創意，用一張簡單的圖聯繫起來，以反映這些創意之間的共性與差別，從而引導出新的創意。

　　　　（5）親和圖又稱爲KJ法，是針對某一問題，充分收集各類經驗、知識、想法和意見等語言、文字資料，經過圖解方式進行彙總，並按其相互親和性概括整理這些資料，使問題明確起來，求得統一認識，以利於解決的一種方法。親和圖的核心是頭腦風暴法，是根據結果去找緣由。

　　　　（6）多標準決策分析是藉助決策矩陣，用系統分析方法創建諸如風險水平、不肯定性和價值收益等多種標準，從而對衆多方案進行評估和排序的一種技術。

　　5、羣體決策就是爲達成某種指望結果而對多個將來行動方案進行評估。羣體決策技術可用來開發產品需求，以及對產品需求進行歸類和優先排序。

　　　　（1）一致贊成。全部人都贊成某個行動方案。

　　　　（2）大多數原則。得到羣體中50%以上的人的支持，就能作出決策。參與決策的人數定爲奇數，防止因平局而沒法達成決策。

　　　　（3）相對多數原則。根據羣體中相對多數者的意見作出決定，即使未能得到一部分人的支持。一般在候選項超過兩個時使用該原則，例如，某個軟件構件的功能有3種實現方案（標記爲A、B、C）在羣體決策時，贊成A方案的人有40%，贊成B方案的人有35%，贊成C方案的人有25%，則最終肯定採用A方案。

　　　　（4）獨裁。由某一我的（例如，項目經理）爲羣體作出決策。

　　6、原型法是一種根據干係人初步需求，利用產品開發工具，快速地創建一個產品模型展現給干係人，在此基礎上與干係人交流，最終實現干係人需求的產品快速幵發的方法。

　　7、標杆對照將實際或計劃的作法與其餘相似組織的作法（例如，流程、操做過程等）進行比較，以便識別最佳實踐，造成改進意見，併爲績效考覈提供依據。標杆對照所採用的「相似組織」能夠是內部組織，也能夠是外部組織。

　　8、系統交互圖是對產品範圍的可視化描述，顯示系統（過程、設備、信息系統等）與參與者（用戶、獨立於本系統以外的其餘系統）之間的交互方式。系統交互圖顯示了業務系統的輸入、輸入提供者、業務系統的輸出和輸出接收者。

　　9、文件分析就是經過分析現有文檔，識別與需求相關的信息來挖掘需求。可供分析的文檔不少，包括商業計劃、營銷文檔、協議、投標文件、建議邀請書、業務流程、邏輯數據模型、業務規則庫、應用軟件文檔、用例文檔、其餘需求文檔、問題日誌、政策、程序和法規文件等。

5.3.3 需求文件

　　1、收集需求過程的主要輸出有需求文件和需求跟蹤矩陣。需求文件描述各類單一的需求將如何知足與項目相關的業務需求。

　　2、需求文件的內容包括（但不限於）如下幾個方面：

　　　　（1）業務需求

　　　　（2）干係人需求

　　　　（3）解決方案需求

　　　　（4）項目需求

　　　　（5）過渡需求。

　　　　（6）與需求有關的假設條件、依賴關係和制約因素。

5.3.4 需求跟蹤

　　1、需求管理包括在產品開發過程當中維持需求一致性和精確性的全部活動，包括控制需求基線，保持項目計劃與需求一致，控制單個需求和需求文檔的版本狀況，管理需求和聯繫鏈之間的聯繫，或管理單個需求和項目其餘可交付物之間的依賴關係，跟蹤基線中需求的狀態。

　　2、可跟蹤性是項目需求的一個重要特徵，需求跟蹤是將單個需求和其餘元素之間的依賴關係和邏輯聯繫創建跟蹤，這些元素包括各類類型的需求、業務規則、系統組件，以及幫助文件等。

　　3、每一個配置項的需求到其涉及的產品（或構件）需求都要具備雙向可跟蹤性。所謂雙向跟蹤，包括正向跟蹤和反向跟蹤，正向跟蹤是指檢查需求文件中的每一個需求是否都能在後繼工做產品（成果）中找到對應點；反向跟蹤也稱爲逆向跟蹤，是指檢查設計文檔、產品構件、測試文檔等工做成果是否都能在需求文件中找到出處。具體來講，需求跟蹤涉及五種類型。如圖：

　　4、箭頭表示需求跟蹤能力聯繫鏈，它能跟蹤需求使用的整個週期，即從需求建議到交付的全過程。

　　5、從用戶原始需求可向前追溯到需求文件，這樣就能區分出項目過程當中或項目結束後因爲變動受到影響的需求，也確保了需求文件中包括全部用戶需求。一樣，能夠從需求文件回溯到相應的用戶原始需求，確認每一個需求的出處。

　　6、因爲在項目實施過程當中，產品需求轉變爲設計和測試等實現元素，因此經過定義單個需求和特定的產品元素之間的聯繫鏈，能夠從需求文件追溯到產品元素。這種聯繫鏈使項目團隊成員知道每一個需求對應的產品元素，從而確保產品元素知足每一個需求。第四類聯繫鏈是從產品元素回溯到需求文件，使項目團隊成員知道每一個產品元素存在的緣由。若是不能將設計元素或測試案例回溯到一個需求文件，就可能出現鍍金行爲。固然，若是某個孤立的產品元素代表了一個正當的功能，則說明需求文件漏掉了一項需求。

　　7、第五類聯繫鏈是需求文件之間的跟蹤，這種跟蹤便於更好地處理各類需求之間的邏輯相關性，檢查需求分解中可能出現的錯誤或遺漏。

　　8、表示需求和其餘產品元素之間的聯繫鏈的最廣泛方式是使用需求跟蹤（能力）矩陣，需求跟蹤矩陣是將產品需求從其來源鏈接到能知足需求的可交付成果的一種表格。

　　9、應在需求跟蹤矩陣中記錄每一個需求的相關屬性這些屬性有助於明確每一個需求的關鍵信息。需求跟蹤矩陣中記錄的典型屬性包括惟一標識、需求的文字描述、收錄該需求的理由、全部者、來源、優先級別、版本、當前狀態（例如，進行中、已取消、已推遲、新增長、已批准、已分配、已完成等）和狀態日期。

5.4 定義範圍

　　定義範圍是制定項目和產品詳細描述的過程，其主要做用是明確所收集的需求哪些將包含在項目範圍內，哪些將排除在項目範圍外，從而明確產品、服務或成果的邊界。

5.4.1 定義範圍的工具和技術

　　1、定義範圍過程的主要工具與技術有專家判斷、產品分析、備選方案生成和引導式研討會。

　　2、產品分析是一種有效的工具。一般，針對產品提問並回答，造成對將要開發的產品的用途、特徵和其餘方面的描述。

　　3、備選方案生成是一種用來指定儘量多的潛在可選方案的技術，用於識別執行項目工做的不一樣方法。

5.4.2 項目範圍說明書

　　1、做爲定義範圍過程的主要成果，項目範圍說明書是對項目範圍、主要可交付成果、假設條件和制約因素的描述。項目範圍說明書記錄了整個範圍，包括項目範圍和產品範圍，詳細描述項目的可交付成果，以及爲提交這些可交付成果而必須開展的工做。

　　2、項目範圍說明書包括以下內容。

　　　　（1）產品範圍描述。

　　　　（2）驗收標準。定義可交付成果經過驗收前必須知足的一系列條件，以及驗收的過程。

　　　　（3）可交付成果。

　　　　（4）項目的除外責任。一般須要識別出什麼是被排除在項目以外的。明確說明哪些內容不屬於項目範圍，有助於管理干係人的指望。

　　　　（5）制約因素。列出並說明與項目範圍有關且限制項目團隊選擇的具體項目制約因素。

　　　　（6）假設條件。

　　3、項目範圍說明書的主要做用以下。

　　　　（1）肯定範圍

　　　　（2）溝通基礎。

　　　　（3）規劃和控制依據。

　　　　（4）變動基礎。

　　　　（5）規劃基礎。

5.5 建立工做分解結構（WBS）

　　建立WBS是將項目可交付成果和項目工做分解成較小的、更易於管理的組件的過程。

5.5.1 WBS的層次

　　1、里程碑標誌着某個可交付成果或者階段的正式完成。重要的檢查點是里程碑、重要的里程碑是基線。

　　2、工做包是位於WBS每條分支最底層的可交付成果或項目工做組成部分，工做包應該很是具體，以便承擔者能明確本身的任務、努力的目標和承擔的責任。工做包的大小須要遵循8/80原則。

　　3、控制帳戶是一種管理控制點。是WBS某個層次上的要素，既能夠是工做包，也能夠是比工做包更高層次上的一個要素。若是是後一種狀況，一個控制帳戶中就包括若干個工做包，但一個工做包僅屬於一個控制帳戶。項目管理團隊在控制帳戶上考覈項目的執行狀況，即在控制帳戶的相應要素下，將項目執行狀況與計劃狀況進行比較，以便評價執行狀況好壞，並發現與糾正誤差。

　　4、規劃包是指在控制帳戶之下，工做內容已知但尚缺詳細進度活動的WBS組成部分。是在控制帳戶之下、工做包之上的WBS要素是暫時用來作計劃的。隨着狀況的逐漸清晰，規劃包最終將被分解成工做包以及相應的具體活動。

　　5、WBS詞典，在製做WBS的過程當中，要給WBS的每一個部分賦予一個帳戶編碼標誌符，它們是成本、進度和資源使用信息彙總的層次結構。須要生成一些配套的文件，這些文件須要和WBS配套使用，稱爲WBS詞典。WBS詞典也稱爲WBS詞彙表，它是描述WBS各組成部分的文件。

5.5.2 分解

　　1、建立WBS過程的工具與技術主要有分解和專家判斷，要將整個項目工做分解爲工做包，一般須要開展如下活動：

　　　　（1）識別和分析可交付成果及相關工做。

　　　　（2）肯定WBS的結構和編排方法。

　　　　（3）自上而下逐層細化分解。

　　　　（4）爲WBS組件制定和分配標識編碼。

　　　　（5）覈實可交付成果分解的程度是恰當的。

　　2、分解的原則

　　　　（1）功能或者技術原則。在建立WBS時，須要考慮將不一樣人員的工做分開。

　　　　（2）組織結構。對於職能型的項目組織而言，WBS也要適應項目的組織結構形式

　　　　（3）系統或者子系統。總的系統劃分爲幾個主要的子系統，而後對每一個子系統再進行分解

　　3、在進行WBS分解時，能夠有以下三種方式

　　　　（1）將項目生命週期的各階段做爲分解的第二層

　　　　（2）主要可交付成果做爲分解的第二層

　　　　（3）子項目做爲分解的第二層

　　4、WBS不是某個項目團隊成員的責任，應該由全體項目團隊成員、用戶和項目干係人共同完成和一致確認。

　　5、較經常使用的WBS表示形式主要有分級的樹型結構（組織結構圖式）和表格形式（列表式）。

　　6、樹型結構圖的WBS層次清晰、直觀性和結構性強，但不容易修改，對大的、複雜的項目很難表示出項目的全貌。

　　7、表格形式的直觀性比較差，但可以反映出項目全部的工做要素。

　　8、值得注意的是，雖然有些參考文獻也使用魚骨圖形式的WBS，但這種形式並不經常使用。

　　9、在分解的過程當中，應該注意如下8個方面。

　　　　（1）WBS必須是面向可交付成果的。項目的目標是提供產品或服務，僅僅是一連串特別的活動。

　　　　（2）WBS必須符合項目的範圍。WBS必須包括，也僅包括爲了完成項目的可交付成果的活動

　　　　（3）WBS的底層應該支持計劃和控制。WBS是項目管理計劃項目範圍之間的橋樑，WBS的底層不但要支持項目管理計劃，並且要讓管理層可以監視和控制項目的進度和預算。

　　　　（4）WBS中的元素必須有人負責，並且只由一我的負責，儘管實際上可能須要多我的參與

　　　　（5）WBS的指導。做爲指導而不是原則，WBS應控制在4~6層。固然，大項目能夠超過6層。

　　　　（6）WBS應包括項目管理工做，也要包括分包出去的工做。

　　　　（7）WBS的編制須要全部（主要）項目干係人的參與，須要項目團隊成員的參與。

　　　　（8）WBS並不是是一成不變的。在完成了WBS以後的工做中，仍然有可能須要對WBS進行修改。

5.5.3 WBS的做用

　　1、當一個項目的WBS分解完成後，項目干係人對完成的WBS應該給予確認，並對此達成共識。WBS的目的和用途主要體如今如下8個方面。

　　　　（1）明確和準確說明項目範圍，項目團隊成員可以清楚地理解任務的性質和須要努力的方向。

　　　　（2）清楚地定義項目的邊界。

　　　　（3）爲各獨立單元分派人員，規定這些人員的職責，能夠肯定完成項目所須要的技術和人力資源。

　　　　（4）針對獨立單元，進行時間、成本和資源需求量的估算，提升估算的準確性。

　　　　（5）爲計劃、預算、進度安排和費用控制奠基共同基礎，肯定項目進度和控制的基準。

　　　　（6）將項目工做和項目的財務帳目聯繫起來。

　　　　（7）肯定工做內容和工做順序，將項目分解成具體的工做任務，就能夠按照工做任務的邏輯順序來實施項目。WBS可使用圖形化的方式來查看工做內容，任何人都可以清楚地辨別項目的階段、工做單元，並根據實際狀況進行調節和控制。

　　　　（8）有助於防止需求蔓延。

5.6 確認範圍

　　確認範圍是正式驗收項目已完成的可交付成果的過程。確認範圍包括與客戶或發起人一塊兒審查可交付成果，確保可交付成果已圓滿完成，並得到客戶或發起人的正式驗收。

5.6.1 確認範圍概述

　　1、確認範圍的主要工具與技術是檢查和羣體決策技術。檢査也稱爲審查、評審、審計、走查、巡檢、測試等。

　　2、確認範圍應該貫穿項目的始終，通常步驟以下。

　　　　（1）肯定須要進行範圍確認的時間。

　　　　（2）識別範圍確認須要哪些投入。

　　　　（3）肯定範圍正式被接受的標準和要素。

　　　　（4）肯定範圍確認會議的組織步驟。

　　　　（5）組織範圍確認會議。

　　3、項目干係人進行範圍確認時，通常須要檢查如下6個方面的問題。

　　　　（1）可交付成果是不是肯定的、可確認的。

　　　　（2）每一個可交付成果是否有明確的里程碑，里程碑是否有明確的、可辨別的事件。

　　　　（3）是否有明確的質量標準。

　　　　（4）審覈和承諾是否有清晰的表達。

　　　　（5）項目範圍是否覆蓋了須要完成的產品或服務進行的全部活動，有沒有遺漏或者錯誤。

　　　　（6）項目範圍的風險是否過高，管理層是否可以下降可預見的風險發生時對項目的衝擊。

5.6.2 干係人關注點

　　1、管理層所關注的項目範圍，是指範圍對項目的進度、資金和資源的影響，這些因素是否超過了組織承受範圍，是否在投入產出上具備合理性。

　　2、客戶主要關心的是產品的範圍，關心項目的可交付成果是否足夠完成產品或服務。

　　3、項目管理人員主要關注可交付成果是否足夠和必須完成，時間、資金和資源是否足夠，主要的潛在風險和預備解決的方法。

　　4、項目團隊成員主要關心項目範圍中本身參與的元素，經過定義範圍中的時間，檢査本身的工做時間是否足夠，本身在項目範圍中是否有多項工做，而這些工做又有衝突的地方。

5.6.3 幾個術語的比較

　　1、確認範圍與覈實產品

　　　　覈實產品是針對產品是否完成，在項目（或階段）結束時由發起人或客戶來驗證，強調產品是否完整；確認範圍是針對項目可交付成果，由客戶或發起人在階段末確認驗收的過程。

　　2、確認範圍與質量控制

　　　　確認範圍與質量控制的不一樣之處在於：

　　　　　　（1）確認範圍主要強調可交付成果得到客戶或發起人的接受；質量控制強調可交付成果的正確性，並符合爲其制定的具體質量要求（質量標準）。

　　　　　　（2）質量控制通常在確認範圍前進行，也可同時進行；確認範圍通常在階段末尾進行，而質量控制並不必定在階段末進行。

　　　　　　（3）質量控制屬內部檢查，由執行組織的相應質量部門實施；確認範圍則是由外部干係人（客戶或發起人）對項目可交付成果進行檢查驗收。

　　3、確認範圍與項目收尾

　　　　確認範圍與項目收尾的不一樣之處在於：

　　　　　　（1）雖然確認範圍與項目收尾工做都在階段末進行，但確認範圍強調的是覈實與接受可交付成果，而項目收尾強調的是結束項目（或階段）所要作的流程性工做。

　　　　　　（2）確認範圍與項目收尾都有驗收工做，確認範圍強調驗收項目可交付成果，項目收尾強調驗收產品。

5.7 控制範圍

　　1、控制範圍是監督項目和產品的範圍狀態、管理範圍基準變動的過程

　　2、範圍變動的緣由

　　　　（1）政府政策的問題。

　　　　（2）項目範圍的計劃編制不周密詳細，有必定的錯誤或遺漏。

　　　　（3）市場上出現了或是設計人員提出了新技術、新手段或新方案。

　　　　（4）項目執行組織自己發生變化。

　　　　（5）客戶對項目、項目產品或服務的要求發生變化。

　　3、範圍變動控制的主要工做以下

　　　　（1）影響致使範圍變動的因素，並儘可能使這些因素向有利的方面發展。

　　　　（2）判斷範圍變動是否已經發生。

　　　　（3）範圍變動發生時管理實際的變動，確保全部被請求的變動按照項目總體變動控制過程處理。

補充

　　1、「需求蔓延」、「範圍蔓延」須要理解，在作案例的時候能夠用。就是不受控制了WBS分解的越細，那麼對該工做的計劃、管理和控制的能力就越強，然而大量的分解工做會致使生產效率下降、資源浪費、工做效率低下。

　　2、需求工程：與需求相關的活動都叫作需求工程，分爲2類：一類是需求開發、一類是需求管理。

　　3、需求開發主要包含：需求獲取（捕獲用戶的需求）、需求分析（將需求信息進行分析、抽象描述、創建概念模型）、需求定義（編制《需求規格說明書》）、需求驗證（對需求文檔進行評審，確認需求。）在需求開發中，完成需求驗證過程後將肯定需求基線。

　　4、需求管理包含：制定需求管理計劃（如何進行需求管理的）、求得對需求的理解（確保項目干係人對需求正確理解）、求得對需求的承諾（實現需求所需的活動人員之間達成一致和創建承諾）、管理需求變動（經過變動流程對需求進行管理，防止需求蔓延）、維護對需求的雙向跟蹤性（需求文檔和產品之間的雙向跟蹤）、識別項目工做與需求之間的不一致性（識別項目計劃和工做產品與需求之間的不一致之處）。