這是乙個比較理想的控制模型，但是，在實際的專案實施中，往往出現專案範圍變動，而且一般是向外擴大的現象，在這種情況下，上述計算模型中成本的控制就失去了基本線的限制，c、q、t、s之間就存在著難以計算的複雜關係，對專案的管理和控制難度就擴大，甚至失控。
對於專案範圍的控制，我認為業主方比專案實施方占有更多的控制主動權，而且在專案範圍的把控上更具有權威性和判別性。在這裡，我要提醒各個實施業主方的人員注意，專案管理是實施雙方共同努力的，而不單純是實施方的責任，因為對於業主方本身而言，專案範圍的失控同樣會帶來自身管理成本的浪費，專案的滯後等不良的影響。要走出「專案需求（範圍）越多越好」的誤區，實事求是把握住專案範圍的「度」，才是實現良好專案控制的手段。
二、企業資訊部門要注意好把握專案實施範圍的「度」：
專案範圍將如何定義才 「合適」呢？這個問題在專案實施雙方衡量的標準是不一致的，或許我們暫且用「多」和「少」這兩個相反的字眼來反映業主方和實施方對專案範圍的衡量標準。當然了，在實際的專案管理當中，我們並不能那麼簡單就把這個因素用這兩個簡單而相反的字眼來概括，因為專案範圍本身涉及到不同利益雙方之間的關係，而且還涉及到業主本身複雜的業務邏輯，在專案開始時描述專案的需求範圍時對專案範圍邊界的定義上就存在著一定的模糊性和不確定性，這些都將成為隱藏的風險。
一般來說，專案範圍的定義是業主根據內部管理的需求提出來的乙個框架性的條目，這個框架的定義一般會涉及到多塊的業務，如財務管理、採購管理、庫存管理、訂單管理等等。而在這些範圍的描述當中，一般以粗條目方式列出，並沒有細化，細化的工作會在專案實施的過程中通過需求調研的方式來具體化。換而言之，這個需求包含的內容可能是「廣泛」的，其深度和廣度本質上來說是模糊的，因此在專案實施全過程當中，時刻都要注意對專案範圍的控制，這樣才能對專案的質量、時間和成本達到有效的控制。
在這一點上，我認為業主責無旁貸要把握好這個關，不能讓需求「氾濫」，同時也要滿足業務的需要，保證專案的質量。那麼，這個尺度該由誰去把握會比較合適呢？我認為企業內部的資訊部門是最適當的人選。
第一、 資訊部門對企業內部的業務比較熟悉，而且在專案需求提出的初期會參與全過程，對需求描述範圍把握比較準確。
第二、 資訊部門本身對技術有較深的認識，在把握技術實現難易程度時會給出專業的判斷。
第三、 資訊部門作為實施的關鍵部門，在協調業務部門和實施方之間的關係中起到重要的作用。
綜合上述三點，資訊部門應該能在業務和技術兩者之間權衡乙個平衡點，因此在判斷專案範圍的環節上能站在乙個比較中立的立場上給出客觀的判斷。
三、專案範圍控制要素分析：
1．專案範圍定義的依據
1.1關鍵業務需求
企業在定義其專案實施範圍時，要注意緊緊圍繞著企業的戰略目標以及核心業務，以內部價值鏈為主線，而非全部業務，一應俱全。實施資訊系統的目的是提高企業的競爭力和內部管理效率，因此我們要定位在能夠為企業的效益和效率產生最大價值的方面，而不是涵蓋企業的全部業務。要避免出現主次不分，鬍子眉毛一把抓的現象。
2．專案範圍控制要素
一般來說，在啟動專案初期，業主就應該提出乙個比較穩定的專案範圍，為專案的實施提供乙個牢固的前提和框架，同時也是為後期的專案管理劃出乙個明晰的「圈」，所有專案活動的開展，包括專案成本、質量和時間的控制也應該在此範圍內進行。但是，在實際的操作過程中，這個「圈」的邊界有可能會出現模糊、擴大的現象，甚至這些擴大和模糊的部分給專案帶來風險。我們從下圖看：
如果專案範圍即既定的的面積s不變，c、q、t就可以在乙個固定的s的邊界限制下給出乙個約束的關係模型。但是，如果s的值並不是固定，就如上圖所示出現邊界模糊或者向外擴充套件時， c、q、t就失去可依賴的邊界限制，其之間的約束關係就會變得複雜。因此，我們在對專案範圍進行控制時，一是要保證專案初期的s是準確可靠的，儘量減少邊界的模糊性；二是要保證專案實施過程中s的穩定，盡量避免擴大化，或是說讓擴大化受到合理的控制。
2.1內部價值鏈
可以看出價值鏈中的每個環節構成了企業內部的核心業務，因此，我們在定義專案範圍的時候就可以貫穿著這個價值鏈，把價值鏈中的每個環節定義成具體的專案需求和範圍，並且遵循乙個閉環的原則來進行描述，如下述對專案預算範圍定義中，從預算編製開始到預算回歸分析，接著又進行預算編製，形成乙個完整的閉環。
通過上述的定義，我們就可以為價值鏈定義出多個閉環，而每個閉環將構成乙個整體的閉環，同時也構成專案範圍的邊界。
2.2內部管理成本
業主在實施專案過程中，對超出了原專案範圍內定義的需求我們可以用以下的標準來作出判斷。
2.2.1是否對關鍵業務構成關鍵的影響
專案實施中，在對業務部門進行詳細需求調研的階段，業務部門不可避免地會提出很多與其業務相關聯的業務，或者是一些新的想法，當遇到這種情況的時候，業主方的資訊部門要作出乙個合適的判斷，是否可以包含在專案範圍內。
首先，這個業務需求是否在關鍵業務描述中已經涵蓋，或者說這個需求是否對關鍵的業務構成足夠的影響力。如果不是，建議可以不納入專案的範圍內，或者暫時不納入本次的專案範圍內，而作為日後乙個擴充套件的功能。
其次，如果此需求對關鍵業務構成必要的影響，那麼資訊部門應該進一步作以下分析：
（1） 目前系統功能是否可以解決這個需求？如果可以，實現難度如何？
（2） 如果實現難度不大，可以納入專案範圍。如果實現難度大，那麼進行成本分析。
2.2.2專案成本分析
（1） 內部資源是否足夠應付新需求的實現？包括業務部門人員、技術人員、軟硬體支撐。
（2） 在整體專案計畫當中是否允許作這樣的調整？能否在專案計畫時間內完成？
（3） 是否能保證專案的質量？會不會對其他功能造成影響？
如果上述成本分析回答都是肯定的，那麼就可以把需求納入實施範圍，如果全為否，建議就不把其納入本專案範圍。但是由於該項需求是乙個關鍵業務需求，可以考慮把此專案作為擴充套件功能在以後實現，目前可以採用其他靈活的方式處理。如果上述的回答中有肯定也有否定的，那麼我認為首先要以內部資源的問題作為重點，如果此條件不能滿足，即使勉強把其納入專案範圍內也只會造成專案的延遲，還不如乾脆等條件滿足的情況下再實施，目前先採取其他靈活的方式處理，這樣既保證當前專案在原既定範圍內完成，新需求在新的專案中實現。
如果內部資源條件滿足，那就要判斷是否對專案的計畫和質量造成影響或者說造成多大的影響？這種影響能否被接受和控制等等。如果會失去控制，建議不納入範圍而採取其他方式解決。
四、在控制專案範圍時要注意控制好實施雙方之間的利益關係：
專案成本控制對專案實施雙方來說，特別是對專案範圍的理解上常會存在著利益衝突關係，因此業主方在控制專案範圍時要注意切實把握好關鍵業務的範疇，把控住專案的成本，而且此成本不光是指實施一方消耗的成本，還要注意結合自身內部資源的問題，重點考慮好內部的管理成本。企業實施資訊系統本身是一項高管理成本的專案，如果專案範圍本身控制不當，很容易造成無形的內部管理成本的巨大消耗，而在實際的管理效益上獲得的收益卻不高，在這種低的效益/投資比下，無疑是一種不可取的專案管理方向，因此，企業進行資訊化專案管理的時候，要站在中立、客觀的立場上分析範圍的「度」，採取適度則取，過度則收的原則。
如何把握資訊化專案管理
三是系統風險。系統在這裡指的是由資訊化相關要素組成的動態聯絡的有機體系。主要指的是使用者自身的組織規範化 組織的觀念轉變 組織責任與控制體系的適應性等。乙個資訊化專案如果沒有相適應的組織體系和觀念體系做保障，很難想象專案不會面臨風險。專案管理方法及專案風險防範 針對專案管理的三個內容 專案規劃 專案...
如何把握資訊化專案管理
根據美國hackett公司的一項調查發現，只有37 的資訊化專案在計畫時間內完成，只有42 的資訊化專案在預算內完成。那麼如何去定義資訊化專案的成敗？如何分析專案存在的風險？如何進行有效的專案管理？以及如何進行資訊化專案風險的防範？本文將從以下四個方面予以 資訊化專案成敗的判定標準資訊化專案如何衡量...
計算機資訊系統整合專案中如何進行範圍管理
一.本文從範圍管理的基本內容和範圍管理的基本過程出發，對計算機資訊整合專案中範圍 管理常見問題及解決辦法進行 和總結。二.簡述專案範圍管理 1.專案範圍 專案範圍指的是工作範圍的界定，即 專案工作的完成為的是能交付乙個有特殊的特徵和 功能的產品。專案範圍的完成情況參照計畫來檢驗的。通俗地講，專案範圍...