關鍵詞:IT範圍管理變更控制
壹.前言
範圍管理是項目管理中的壹個特殊詞匯。其主要任務是定義項目包含所有需要完成的工作，並指導其他項目管理工作，以保證項目所有過程的順利完成。
壹般來說，當項目範圍確定後，項目的工作邊界就確定了，項目的項目目標和主要交付成果也就確定了。對於信息系統集成項目來說，如果項目範圍不能明確界定和有效控制，將會產生非常嚴重的後果。比如，項目的實際需求包括:客戶因無法提供完整詳細的描述而未能明確界定範圍，導致項目的最終解決方案不可用；另壹方面，項目範圍的擴大或頻繁變化會影響項目成本和進度。
根據筆者負責和參與多個項目的實踐經驗，範圍擴散是壹件非常可怕的事情，客戶總想在壹個系統中實現自己的所有需求，導致項目結果臃腫而不切實際。客戶有壹個想法是非常不可取的:“(開發者)做好了就放在那裏，即使不用。萬壹他們以後用上了呢？”。此外，在項目過程中，尤其是項目後期，客戶不斷提出修改移交系統的建議，有時甚至剛重新設計就開始改，客戶要求改回來或者換另壹個型號。“無底洞”是國內大部分項目經理在信息系統集成項目中的相同感受。
“為什麽項目總是沒完沒了？!"
二、原因分析項目經理作為項目的承擔者，利用有限的資源，在規定的時間內保質保量完成項目，讓客戶和公司都滿意是最終目標。
但是滿足客戶就是滿足客戶無止境的需求？這會導致項目最終失敗嗎？我們應該分析範圍變更中出現問題的根本原因。
1.簽訂合同時缺乏熟悉信息系統集成項目的人員，導致項目目標描述不清，給後期實施帶來混亂。
2.客戶和項目組都希望把項目做好。但是，客戶可能對信息系統項目缺乏全面的了解，項目團隊也沒有完全了解客戶需求的細節，對實現需求的途徑的理解也存在差異。項目初期，雙方都沒有意識到溝通不暢，導致系統移交時問題暴露。
列舉作者遇到的幾個具體問題:
a、IT項目的客戶往往認為電腦是萬能的。有了它們，他們只需要輸入幾個參數，什麽都不用擔心。其實任何技術都有局限性。
b、某客戶知道自己需要壹款庫存管理軟件，但是是引入新的庫存管理思路還是沿用當前的模式還沒有考慮，開發人員已經到位，所以要求項目組先按照當前的模式來做。後來客戶想改變管理模式，問題就出現了。設計變更導致大量模塊重寫，工期不可避免延長。
c，壹個客戶要求“方便”的查詢設備的位置，於是開發者設計了壹個根據各種條件查詢設備位置的界面。在移交系統時，客戶發現與他預期的不壹樣。原客戶的“方便”是指以圖形界面的形式直觀表現。項目組不得不將該功能的開發推遲幾天。項目經理聯盟文章，深度討論。
3.項目組成員分不清客戶的真實需求和鍍金需求，完全接受客戶的變更請求。當然這也是為了滿足客戶，但實際上未必能達到目的。
三、範圍變更管理首先需要在簽訂合同時明確項目的範圍，這當然需要熟悉信息系統集成項目的人參與合同談判。合同中明確的項目範圍可以為以後的工作打下堅實的基礎。
其次，合同中的工程範圍應該只是壹個粗略的約定，必須細化和深化。範圍規範和範圍管理計劃的編制是其中的壹個重要部分。範圍聲明應包括項目演示、產品介紹、主要交付成果、驗收標準等。此外，必須為項目團隊預留足夠的時間來調查詳細的需求，並提出工作分解結構(WBS)和需求分析報告。WBS可以為項目績效評估和項目控制提供壹個基準。
在系統需求分析階段，項目團隊成員與客戶的深入溝通是項目成功的關鍵。但是，雙方的誤解通常會導致溝通困難。AMT的劉立軍先生總結的為什麽、做什麽、怎麽做，可以非常有效地讓溝通變得順暢。簡單來說，在項目初期，項目經理首先需要考察客戶為這個項目做了什麽，也就是“為什麽”，這樣才能真正從客戶的角度考慮系統設計；接下來要總結整個項目在“做”什麽，總結每個子任務，讓開發人員很好的把握項目內容的大方向；當然，最重要的是“怎麽做”。對於信息系統集成項目來說，在這個階段花更多的時間肯定是值得的。還有壹些小技巧:需求分析報告要用客戶認為易讀易懂的方式寫，也要幫助開發者開發出真正需要的系統；項目組成員最好能把需求分析報告詳細告訴客戶，達成* * *理解。這裏溝通手段很重要。另外，在需求確認後，最好讓客戶的管理層書面簽字，作為終止需求分析過程的標誌，但絕不是拒絕範圍變更的手段。
四、有效的變更控制壹個項目的範圍計劃可能很好，但是想不變更幾乎是不可能的。
項目經理和項目團隊必須意識到範圍變更本身沒有任何問題。事實上，很多時候它會讓妳的系統更加健壯和實用。客戶通常不能在壹開始就確定所有的需求，隨著時間的推移情況會發生變化。如果他們不能適應變化，最終的解決方案可能達不到應有的價值。
但是如果變更失控，後果會非常嚴重，甚至導致整個項目的失敗。根據standish公司在1995的研究結果，最容易導致IT項目失敗的前三個因素是:缺乏用戶參與、需求和描述不完整、需求和描述易變，這些因素都與範圍變更管理直接或間接相關。
因此，必須進行範圍變更管理。潘東先生認為:“變更控制的目的不是控制變更的發生，而是管理變更，保證變更有序進行。”
為了實施變更控制，必須建立有效的範圍變更流程。這個過程應該包括確認變更，評估變更的業務價值，分析變更對項目的影響，並將其提交給項目發起人進行評估，以確定是否實施變更。
但是，只有範圍變更過程不足以真正控制變更，因為項目團隊外部的壓力很多，而且與缺乏有效的變更控制手段密切相關。本文轉自項目經理聯盟。
目前流行的變更管理思想認為，範圍變更過程中有四個關鍵點必須嚴格控制，即誰有權確認變更，需要實施什麽樣的變更，變更的影響有多大，客戶是否接受變更的成本。
1.誰有權確認變更:
不應允許客戶的業務人員直接聯系開發人員以節省時間，因此無法控制更改。必須事先明確客戶誰有權提出變更請求，項目組誰有權接受變更，變更請求必須有書面材料。
我在參與壹個大型信息系統集成項目的實施時深有感觸:項目經理曾經提醒過我們，客戶付錢給我們去實施，這應該算是壹件“公對公”的事情。如果用戶以“個人感受”為由要求改變範圍，開發者可以拒絕。項目經理聯盟，項目管理問題。
當時，如果用戶發現因業務變化導致需求發生變化，需要向客戶的項目負責人提交書面申請，由項目負責人審批後，交給實施者的項目經理。
這樣雙方的項目負責人就能知道所有的變化。而且用戶在提交書面變更申請時更加謹慎，壹般都是在自己部門內部討論後進行，減少了因用戶內部觀點不同而導致的重復變更。
2.需要實施哪些變革:
不是所有的更改都需要修改，也不是所有的更改都需要立即修改。必須審查客戶提出的範圍變更，以決定哪些變更需要修改以及何時修改。
客戶普遍對信息系統集成項目不太了解，認為簡單的事情可能會被計算機復雜化。因此，項目經理和項目團隊應該冷靜分析用戶想要實現什麽，抓住本質需求。如果用戶的建議難以實現，妳可以和用戶溝通，詢問用戶是否可以通過其他方式達到他的目的。
根據筆者的經驗，壹般來說，用戶對鍍金的需求是可以推遲甚至忽略的。如果用戶的新需求不影響核心業務的實現，可以在現有功能完善後安排。
3.變化的影響是什麽？
項目團隊的所有成員都應該意識到改變是有代價的。需要評估變更的成本和對項目的影響，讓客戶了解變更可能存在的問題，判斷是否還應該壹起進行變更。
更多工程/服務/采購招標信息，提高中標率，可點擊官網客服底部免費咨詢:/#/？source=bdzd