閱讀以下關於資訊系統專案管理過程中專案範圍管理方面問題的敘述，回答問題1至問題3.
2.3.1案例場景
希賽資訊科技****(csai )剛剛和m簽訂了乙份新的合同，合同的主要內容是處理公司以前為m公司開發的資訊系統的公升級工作。公升級後的系統可以滿足m公司新的業務流程和範圍。由於是乙個現有系統的公升級，專案經理張工特意請來了原系統的需求調研人員李工擔任該項目的需求調研負責人。在李工的幫助下，很快地完成了需求開發的工作並進入設計與編碼。由於m公司的業務非常繁忙，m公司的業務代表沒有足夠的時間投入到專案中，確認需求的工作一拖再拖。張工認為，雙方已經建立了密切的合作關係，李工也參加了原系統的需求開發，對業務的系統比較熟悉，因此定義的需求是清晰的。故張工並沒有催促業務代表在需求說明書中簽字。
進入編碼階段後，李工因故移民加拿大，需要離開專案組。張工考慮到系統需求已經定義，專案已經進入編碼期，李工的離職雖然會對專案造成一定的影響，但影響較小，因此很快辦理好了李工的離職手續。
在系統交付的時候，m公司的業務代表認為已經提出的需求很多沒有實現，實現的需求也有很多不能滿足業務的要求，必須全部實現這些需求後才能驗收。此時李工已經不在專案組，沒有人能夠清晰地解釋需求說明書。最終系統需求發生重大變更，專案延期超過50%, m的業務代表也因為系統的延期表示了強烈的不滿。
【問題1】(8分)
請以400字對張工在專案管理工作中的行為進行點評。
【問題2】(9分)
請從專案範圍管理的角度找出該專案實施過程中的問題，以500字內回答。
【問題3】(8分)
請結合你本人專案經驗，談談應如何避免類似的問題，以500字內回答。
2.3.2 案例分析
這是乙個失敗的軟體專案，與很多失敗的軟體專案一樣，在系統需求上栽了跟頭。開發與定義軟體系統的需求在整個軟體開發過程中是最重要的一環，這是每個從事資訊系統建設的專案經理都清楚的事情，但往往又因為一時的疏忽而造成需求的重大缺陷，最終導致專案的失敗。案例中的專案經理張工就是既重視需求又沒有控制好需求的乙個例子。·
在案例中，張工接手了乙個系統公升級的軟體專案。對於這樣的專案，首先需要熟悉原有的系統，然後才能談公升級的問題。因此張工專門找到了原系統的需求調研人員李工來解決新系統的需求問題。這無疑是乙個很好的辦法，可以快速準確地把握新系統的需求。從這一點上來說，張工是成功的，找到了合適的資源進行需求的開發與定義。李工也沒有讓張工失望，很快就整理出了新系統的需求，並進入了設計和編碼階段，除了客戶太忙沒有時間確認需求外，一切盡在張工的掌握之中。這是乙個陽光燦爛的開端，如果一切順利的話，專案的成功也就是早晚的事情。就如同大多數經典的悲劇故事一樣，故事的序幕是美好的。
晴朗的天空飄來一塊烏雲，李工要移民加拿大。不過僅僅是一片烏雲而已，並沒有下起雨來。開發出的需求都已經過設計，一些編碼工作也已經開始，李工的工作已近圓滿完成，畢竟，一些細枝末節的問題還可以同客戶直接溝通。
經過專案組努力，專案終於完成開發，準備發布了。這時，烏雲開始下雨，問題爆發了。客戶不認可專案組的工作，認為很多需求沒有實現，實現的功能也與需求不符。
誰是這個專案組的罪人呢？李工？還是張工？換乙個思路考慮一下，如果李工沒有離開專案組，結果又會是什麼樣呢？客戶會因為李工還在專案組就認可這個系統嗎？很顯然，不會。至多可以在雙發的協商下少一些變更，專案延期不是50%,而是30％而已。如果非要區分50％和30％的區別，也不過是五十步笑百步而已。
從專案管理的角度來說，專案範圍直接決定了工作量和工作目標，所以專案經理必須管理專案的範圍。在範圍管理中，範圍定義、範圍確認和範圍控制又是最核心的三項活動，缺一不可。範圍定義是基礎的活動，不進行範圍定義就不能進行範圍確認和範圍控制。範圍確認則是基線化已定義的範圍，是範圍控制的依據。範圍控制的作用在於減少變更，保持專案範圍的穩定性。在案例中，由於張工沒有進行範圍確認，最後的範圍控制也就變成了無本之木，控制過程肯定變成了討價還價，失去本身的意義。
在軟體系統的開發中，系統需求就是專案的範圍。從軟體誕生至今的幾十年中，人們探索出了很多獲取系統需求的方法，但是熟悉軟體開發的人都知道，無論哪種方法都不可能定義出完美無誤的需求，需求中的缺陷必然存在，無法完全避免。因此需求確認或者說是範圍確認就顯得更為重要。
有人可能會說，很難說服客戶在需求上簽字，很難讓客戶為需求的缺陷負責。以現在軟體行業的情況，這種說法是不無道理的。讓客戶在需求上簽字很困難，但並不等於就不需要進行範圍確認，而且範圍確認的方法也不僅僅只有需求簽字這一種方法。召集客戶的業務代表對需求進行評審、詳細記錄最原始的調研材料，讓客戶確認調研報告、採用迭代開發逐步確認系統需求，都是可以採用的方法。這些方法雖然沒有直接確認需求分析報告，但至少可以讓現有需求在專案組和客戶之間達成一致，提供範圍控制的基準，一樣可以達到範圍確認的目的。
再回到這個案例，專案經理張工樂觀認為李工開發的需求沒有什麼問題，也誤認為雙方已經有良好的合作，在不緊逼要求客戶代表簽字顯得不近人情，於是就抱著僥倖資訊進入了開發。然而最終的結果是，專案延期嚴重，業務代表反而更不滿意，張工也要承擔專案延期造成的成本增加的責任。
有了上面的分析，後面問題的答案就不難得出。首先看第乙個問題，對張工的行為進行點評。前面已經提到，張工注意到了需求的問題，專門找到了原系統需求負責人李工進行需求開發，這是對專案有利的一面。但由於缺少需求評審和確認的過程，造成需求中的缺陷沒有被及時發現，系統需求沒有與客戶確認，造成缺少需求控制的基準，最終導致需求的重大變更。
對於第二題，聯絡範圍管理的知識，我們不難發現張工在範圍確認和範圍控制中都有重大的缺陷，在範圍定義中也由於缺乏評審造成需求的質量問題。
在完成第二題後，第三題就水到渠成了，第三題的要點見參***，此處不再贅述。
2.3.3參***
【問題1】(8分)
(1)張工為了更明確地把握系統需求，聘請了原系統的需求調研人員李工，提高了需求定義的效率和質量。(2分)
(2)張工沒有對李工開發的系統需求進行評審和複查，從而使得需求的缺陷沒有被及時發現。
(3)張工沒有要求使用者對已經定義的需求進行確認，從而導致需求理解的偏差。(2分)
(4)張工對需求的不能進行缺乏有效控制，最終造成專案延期50%.(2分)
【問題2】(9分)
該專案實施過程中的主要問題包括：
(1)在範圍定義中，張工沒有對李工定義的需求進行評審，造成需求中的質量缺陷沒有被及時發現。(3分)
(2)在範圍確認中，張工沒有主動地要求使用者對需求進行確認。(3分)
(3)在範圍控制中，張工無法進行有效的範圍控制，最終造成了重大的需
求變更。(3分)
【問題3】(8分)
對於本案例，專案經理需要對需求定義的結果進行質量控制，採取評審等方式減少需求中的問題。對已經定義的需求需要與使用者進行確認，保證雙方理解的一致。在發生需求變更時，也應該採取靈活的手段，在滿足使用者需求的前提下，儘量減少需求變更的範圍。
範圍變更管控案例 專案範圍管理案例
第 章專案範圍管理案例 案例 面對專案範圍管理上出現的混亂局面，劉工應該如何處理？某軟體公司承擔了 a公司的乙個 erp系統開發專案，在專案的實施過程中，系統需求似乎永遠無法確定，使用者說不清楚自己的需求，怎麼做他們都不滿意，功能不斷增加，使用者上週說要這個功能，今天說要這個功能，李部長認為這個功 ...
專案範圍管理
專案範圍管理 部落格分類 專案管理 範圍管理 wbs需求分析矩陣 變更管理 pmp專案場景 與微保合作的乙個專案在實施過程中出現了兩個比較嚴重的問題，乙個是需求變更頻繁導致上線時間一再延誤，另乙個是上線後，系統問題大大小小層出不窮，嚴重影響客戶體驗。問題分析 需求變更頻繁是專案開發中經常遇到的問題，...
控制軟體專案的範圍變更
範圍管理是專案成功的基礎和重要因素。如果不能合理界定專案範圍，專案就無法啟動，無法進行專案管理，意外的變更將會隨時出現，專案也會返工 費用上公升甚至不能完成。專案範圍管理的核心就是控制專案範圍變更。目前，專案在實施過程中由於受到內外多種因素的影響，使得專案範圍的變更已經不可避免，也無法避免。所以，控...