一.本文從範圍管理的基本內容和範圍管理的基本過程出發，對計算機資訊整合專案中範圍
管理常見問題及解決辦法進行**和總結。
二.簡述專案範圍管理
1.專案範圍
專案範圍指的是工作範圍的界定，即：專案工作的完成為的是能交付乙個有特殊的特徵和
功能的產品。專案範圍的完成情況參照計畫來檢驗的。
通俗地講，專案範圍是界定專案包括什麼和不包括什麼，做什麼和不做什麼，同時，也包括對如何實現這些目標的控制過程的定義。需要注意的是，過程中的工作成果也屬於專案範圍範疇，專案最終的工作成果是由過程中所有工作成果的集合。專案範圍目標是專案其
他三個目標即進度、成本、質量目標的基礎。
2.範圍管理
範圍管理是用以保證專案包含且只包含所有需要完成的工作，以順利完成專案所需要的所有過程。這個過程確保了專案組和專案干係人對作為專案結果的專案產品以及生產這些產
品所用到的過程有乙個共同的理解。
3.專案範圍管理過程
科學的範圍管理是專案成功的第一步，它的基礎是乙個科學的範圍管理流程。範圍管理的基本內容包括：專案啟動、範圍計畫編制、範圍定義、範圍驗證、範圍變更控制這五個要
素，由於專案啟動實際上屬於企業戰略管理內容，在本文中不做詳細討論：
1)專案啟動—啟動專案，闡述組織為什麼要做這個專案。
2)範圍計畫--寫出乙份書面報告，作為未來專案決策基礎。
3)範圍定義--把主要的專案工作細目分解成更小、更易管理操作的單元。
4)範圍驗證--專案範圍的正式驗收。
5)範圍變更控制--對專案範圍的變更進行控制。
以下分別介紹範圍計畫編制、範圍定義、範圍驗證、範圍變更控制四個要素：
1)範圍計畫和範圍說明書：
ü 範圍計畫編制是將產生專案產品所需進行的專案工作（專案範圍）漸進明細和歸檔的過
程。ü 專案範圍說明書說明專案論證、專案產品、專案可交付成果和專案目標。專案論證是商家的既定目標，要為估算未來的得失提供基礎；專案產品是產品說明的簡要概況。
ü 範圍說明在專案參與人之間確認或建立了乙個專案範圍的共識，作為未來專案決策的文
檔基準。
ü 範圍管理計畫描述專案範圍如何進行管理，專案範圍怎樣變化才能與專案要求相一致等問題的。它也應該包括乙個對專案範圍預期的穩定而進行的評估。範圍管理計畫也應該包
括對變化範圍怎樣確定，變化應歸為哪一類）等問題的清楚描述。
2)範圍定義與工作分解結構(wbs)
ü 正確的範圍定義是專案成功的關鍵。範圍定義包括分解這個主要工作細目的子專案，使它變成更小、更易管理、操作的東西。以便於提高估算成本、時間和資源的準確性。
並為績效測量和控制確定乙個基準線。同時，使工作變得更易操作的，責任分工更加明確。
ü 工作分解結構進行範圍定義的工具，它通過層層分解把專案主要的可交付成果分成更容
易管理的單元。
3)範圍驗證
ü 範圍核定是通過參與者（倡議者、委託人和顧客等）的行為正式確定專案範圍的過程。
它要求回顧生產工作和生產成果，以保證所有專案都能準確地、滿意地完成。
ü 如果這個專案已提前終止，這個範圍核實過程也應該證實並應以書面檔案的形式把它的
完成情況記錄下來。
ü 驗收檔案是當事人、專案發起人或投資者已經認可了這個專案產品或某個階段的檔案，
他們必須為完成這項工作準備條件，做出努力。
4)範圍變更控制
ü 範圍變更控制是指對有關專案範圍的變更實施控制。主要的過程輸出是範圍變更、糾正
行動與教訓總結。
ü 規範的變更控制過程有助於有效控制範圍變更。
三.範圍管理在計算機資訊系統整合專案的重要性
資訊系統專案實施失敗的原因，包括專案管理九大知識體系的方方面面。由於實施資訊系統專案實施周期長、對業務的依賴性強，特別是一些跨業務的專案，要完全把企業的全業務流程穩定下來，並通過系統實現，需要較長的時間來鞏固。因此常常出現一些需求不穩定、需求變更，專案範圍失控的現象。
在資訊化整合專案中專案範圍管理顯得尤為重要，
較之其它八個領域更為關鍵。
專案範圍是專案其它三個要素即質量、進度、成本目標的基礎，專案所有管理工作和技術工作均以基線化的專案範圍為基礎。要做好資訊化整合專案，首先要做好專案範圍管理。
四.範圍管理知識領域常見問題及解決辦法
1.需求獲取l問題描述
乙個專案的各種不同干係人有各種不同的需求，而且由缺乏專門知識，難以將其需求確切、清晰地表達出來，因此，僅依賴於使用者獲取的需求總是不能真實反映使用者業務。專案干係人在提出其需求時，不可能充分地考慮了其實現的可能性，需求往往比較零散且無法實現。
l解決辦法
可建立需求分析組，通過專案干係人責任矩陣明確職責和義務並文件化。小組成員除了需求分析專家外，還應有系統設計人員，使用者方代表。這裡需要強調的是，使用者方代表應為使用者各項業務的代表，他們能代表大多數使用者需求。
必要的話，需明確使用者需求的最終確
認人。專案需求分析組需制定需求調研計畫，**需求調研方法。業界通用的專案調研方法用問卷調查或面對面交談(由調研方提問)等方法。
無論採用哪一種辦法，在需求調研開始之前，進行調研方法的培訓和使用者業務流程的培訓是非常必要的。這樣，有利於調研雙方充分合
作，獲取到較為清晰的專案範圍。
由於專案的唯一性特點，調研雙方應明白專案需求是漸進明細的過程，一定範圍的需求變
更是正常的。當然，需求文件經評審基線後不可隨意更改。
2. wbs分解l問題描述
大多數專案經理認為wbs分解的維度和粒度不好把握。
l解決辦法
wbs分解的維度和粒度應根據專案具體特點來把握。一般來講，wbs分解從工作成果和工作進度兩個維度進行佔大多數。較上層的以工作成果來分，形成大的成果框架，每層下面再把工作分解。
當然，比較常用的方式是兩者相結合，這種方式的優點是結合進度劃分直觀，
時間感強，專案配置項也不容易被遺漏。
到於wbs分解的粒度問題，我們在完成wbs後，不妨回答以一下以下問題就可以確認wbs
是否夠細了：
ü 劃分更低層次的細目是否必要和充分？
ü 每個工作細目都要有明確的、完整的定義嗎？
ü 是否每個工作細目都有適當的日程表、預算能分配給特殊的組織單位？
ü 誰能擔負起滿意地完成這個專案的任務？
3.範圍驗證l問題描述
系統測試是範圍驗證的一種方法，但僅依靠系統測試是不夠的。我曾遇到過這樣一種情況，
那就是系統測試人員本身對需求的理解就是錯誤的。
很多軟體專案通過需求功能審計來驗證專案範圍的實現程度，但是多數情況下流於形式，
沒有起到很好的作用。
還有很多人認為範圍驗證僅發生在專案結項的時候。
l解決辦法
理想的做法是在專案的各個階段，請需求分析組(特別的使用者代表)、專案發起人、投資方
參與評審和驗證。每個階段由工作成果的作者進行宣講。
當然，在條件不允許的情況做一些必要的變通也是可以的，但至少在系統提交系統測試前
必須得到使用者方的驗證。
範圍驗證的乙個重要的方法就是進行需求編號，為各階段成果建立必要的追溯關係。
4.範圍控制l問題描述
ü 溝通：使用者通常認為專案的管理和控制是專案實施方的責任，使用者方可以不考慮範圍的
限制，只需無條件的提出自己的需求，需求提得越多越好。
ü 需求範圍蔓延：範圍蔓延指的是當專案在不經過仔細考慮而接受了太多小的變化之後造成超出預算，延誤工期的現象。很多專案經理能夠意識到大的範圍改變，但是對於小的改
變卻沒有那麼敏感了。
ü 變更決策的有效性：很多看似合理的變更在沒有有效決策的前提下導致專案陷入困境。
乙個典型的問題就是有權決定這種變更的人—發起人，並沒有同意這樣做。
ü 專案小組的責任：專案小組成員不明白知道在範圍變化管理方面職責和權力。他們經常
自己答應進行一些額外的工作，從而危及整個專案的進行。
l解決辦法
控制好變更必須有一套規範的變更控制過程，變更控制過程明確規定提交變更、影響範圍分析、決策、執行、通知受影響各方、配置歸檔等的流程。專案變更嚴格按變更流程執行。
在變更控制計畫中，應明確專案的變更控制委員會(ccb)組織及職責，變更控制委員會由主
席負責。需要特別注意的是，變更控制委員會必須包含使用者或使用者代表。
此外，在變更控制過程中，變更控制委員會(ccb)的決策標準是什麼呢？我認為可以這樣考
慮：ccb首先判斷這個業務需求是否對關鍵業務構成關鍵的影響。如果不是，建議不納入專案範圍內，或者暫時不納入本次的專案範圍內，而作為日後乙個擴充套件的功能。
如果此需求對關鍵業務構成必要的影響，則進一步分析目前系統功能是否可以解決這個需求？如果可以，實現難度如何？如果實現難度不大，可以納入專案範圍。
如果實現難度大，那麼進行成本
分析。專案成本分析可以從以下三個方面來分析：
（1）內部資源是否足夠應付新需求的實現？包括業務部門人員、技術人員、軟硬體支撐。
（2）在整體專案計畫當中是否允許作這樣的調整？能否在專案計畫時間內完成？
（3）是否能保證專案的質量？會不會對其他功能造成影響？
如果上述成本分析回答都是肯定的，那麼就可以把需求納入實施範圍，如果全為否，建議就不把其納入本專案範圍。但是由於該項需求是乙個關鍵業務需求，可以考慮把此專案作為擴充套件功能在以後實現，目前可以採用其他靈活的方式處理。如果上述的回答中有肯定也有否定的，那麼首先要以內部資源的問題作為重點，如果此條件不能滿足，則目前先採取其他靈活的方式處理，這樣既保證當前專案在原既定範圍內完成，新需求在新的專案中實現。
如果內部資源條件滿足，那就要判斷是否對專案的計畫和質量造成影響或者說造成多大的影響？這種影響能否被接受和控制等等。如果會失去控制，建議不納入範圍而採取其
他方式解決。
5.假設因素的合理性
l問題描述
假設因素必須具有科學性、真實性和確定性。
l解決辦法
不妨將不確定的假設當作乙個風險進行管理。
結束語：
企業資訊化整合專案要求更為嚴格、更為科學的範圍管理。同時，範圍管理需完善的專案管理體系來指導。企業資訊化整合企業應積極採取這一有效的手段和方法來優化管理，提
高核心競爭力
計算機資訊系統整合專案管理
1 前言 上週參加了為期一周的計算機資訊系統整合專案管理培訓，前三天講解了pmbok的基本內容，中間兩天著重於專案管理實踐。通過這一周的培訓，基本了解了pmbok的主要內容。在以前做專案的過程中，專案管理的各個領域都有涉及，但是都是根據個人的感覺或者是自己他人的經驗來處理，沒有乙個系統的整體的專案管...
計算機資訊系統整合執行標準
一 綜合條件 1 企業變革發展歷程清晰，從事系統整合兩年以上 2 企業主業是系統整合，系統整合收入是企業收入的主要 3 企業產權關係明確，註冊資本200萬元以上 4 企業經濟狀況良好，近三年系統整合年平均收入1500萬元以上，財務資料真實可信，並須經會計師事務所核實 5 企業有良好的資信，近三年沒有...
計算機資訊系統整合資質四級資質
第十二條申請資質認證的單位應具備的條件 一 具有獨立法人地位。二 獨立或合作從事計算機資訊系統整合業務兩年以上 含兩年 三 具有從事計算機資訊系統整合的能力，並完成過三個以上 含三個 計算機資訊系統整合專案。四 具有勝任計算機資訊系統整合的專職人員隊伍和組織管理體系。五 具有固定的工作場所和先進的資...