摘要：信息系統集成項目中，由于客戶(hù)通常不能確定最終解決方案的全部功能和需求，所以范圍變更是經(jīng)常的事。對此，項目經(jīng)理和項目小組既不能一味拒絕，也不能全盤(pán)接受。本文分析了出現范圍變更的原因，提出了范圍變更管理需要進(jìn)行的任務(wù)，最后認為，建立行之有效的變更控制手段來(lái)管理項目范圍變更是項目全生命周期內最重要的部分之一。

　　關(guān)鍵字：IT 范圍管理 變更控制

　　一、 前言

　　范圍管理（Scope Management）是項目管理中的一個(gè)專(zhuān)用詞匯，它的主要任務(wù)是界定項目包含且只包含所有需要完成的工作，并對項目其他管理工作起到指導作用，以保證順利完成項目的所有過(guò)程。

　　一般來(lái)說(shuō)，確定了項目范圍，也就確定了項目的工作邊界，明確了項目目標和項目主要可交付成果。對于信息系統集成項目，如果不能明確的定義和有效的控制項目范圍，將會(huì )產(chǎn)生非常嚴重的后果。例如：項目實(shí)際需要包含，客戶(hù)因不能提供完整、詳細的描述而未能明確定義范圍，從而導致項目最終解決方案的不可用；另一方面，項目范圍的蔓延或頻繁變更，從而影響項目成本、進(jìn)度。

　　以筆者主管和參與多個(gè)項目的實(shí)際經(jīng)歷來(lái)看：范圍蔓延是非�？膳碌氖�，客戶(hù)總是想把所有的需求都在一個(gè)系統里實(shí)現，從而導致項目成果的臃腫和不切實(shí)際�？蛻�(hù)有種想法是非常不可取的：“（開(kāi)發(fā)人員）做好了先放在那兒，即使不用也好，以后萬(wàn)一用上了呢？”。還有，客戶(hù)在項目進(jìn)程中，尤其是到了項目后期，不斷對移交的系統提出修改意見(jiàn)，甚至有時(shí)剛剛重新設計完成開(kāi)始更改，客戶(hù)又要求改回去或改成另一種模式�！盁o(wú)底洞”是國內大部分項目經(jīng)理進(jìn)行信息系統集成項目的共同感覺(jué)。

　　“項目為什么總是做不完？！”

　　二、  原因分析項目經(jīng)理作為項目的承擔者，在規定時(shí)間內利用有限資源保質(zhì)保量的完成項目，讓客戶(hù)和公司都滿(mǎn)意是最終目標。

　　但是讓客戶(hù)滿(mǎn)意就是不斷滿(mǎn)足客戶(hù)無(wú)窮無(wú)盡的需求嗎？這樣會(huì )不會(huì )導致項目的最終失敗呢？我們應該分析范圍變更出現問(wèn)題的根源原因。

　　1、簽訂合同時(shí)缺乏對信息系統集成項目熟悉的人員參加，導致項目目標描述不清，為后期的實(shí)施工作帶來(lái)困惑。

　　2、客戶(hù)和項目組均希望將項目做好。但是客戶(hù)可能對信息系統項目缺乏全面的了解，項目組對客戶(hù)需求細節的了解也不充分，而且雙方對實(shí)現需求的方式的理解也存在差異。而雙方在項目初期又均未意識到這種溝通上的不暢，導致移交系統時(shí)才使問(wèn)題暴露出來(lái)。

　　列舉幾個(gè)筆者碰到的具體問(wèn)題：

　　A、IT項目的客戶(hù)往往認為計算機是萬(wàn)能的，有了它，自己只需要輸入幾個(gè)參數就什么都不用管了。而實(shí)際上任何技術(shù)都有局限性。

　　B、某客戶(hù)知道自己需要一個(gè)庫存管理軟件，但是，是引進(jìn)新的庫存管理思想還是沿用目前的模式卻還沒(méi)有考慮好，而開(kāi)發(fā)人員已經(jīng)到位，于是要求項目組先按目前模式做。當后來(lái)客戶(hù)想要更改管理方式時(shí)，問(wèn)題出現了，設計的更改導致大量模塊的重寫(xiě)，工期不可避免的延長(cháng)。

　　C、某客戶(hù)要求“方便”的查詢(xún)設備位置，于是開(kāi)發(fā)人員設計了一個(gè)界面可以按各種條件來(lái)查詢(xún)設備的所在位置。當移交系統時(shí)，客戶(hù)發(fā)現與預想的不一樣，原來(lái)客戶(hù)的“方便”是指用圖形化界面的方式直觀(guān)的表現。項目組只好延期幾天來(lái)開(kāi)發(fā)這一功能。項目管理者聯(lián)盟文章，深入探討。

　　3、  項目組人員不能區分客戶(hù)真正需求和鍍金需求，全盤(pán)接受客戶(hù)的變更請求。當然這樣做也是為讓客戶(hù)滿(mǎn)意，但是實(shí)際上不一定能達到目的。

　　三、范圍變更管理首先，簽訂合同時(shí)就需要明確定義項目的范圍，這當然需要熟悉信息系統集成項目的人員參加合同談判。合同中定義好的項目范圍可以為以后各項工作的開(kāi)展奠定深厚的基礎。

　　其次，合同中的項目范圍應該還只是粗線(xiàn)條的約定，必須進(jìn)行細化和深入。編制范圍說(shuō)明書(shū)和范圍管理計劃是其中重要的部分。范圍說(shuō)明書(shū)應該包括項目論證、產(chǎn)品簡(jiǎn)介、主要可交付物、驗收標準等。另外必須為項目組預留足夠的時(shí)間來(lái)進(jìn)行詳細需求的調研，并提出工作分解結構（WBS）和需求分析報告。WBS可以為項目執行績(jì)效評測和項目控制提供一個(gè)基準。

　　在系統需求分析階段，項目組成員和客戶(hù)的深入交流是項目成功的關(guān)鍵。但是由于雙方的誤解通常使交流難以進(jìn)行。AMT的劉立軍先生總結的Why、What、How方式可以非常有效的使溝通順暢。簡(jiǎn)單的說(shuō)，在項目初期，項目經(jīng)理首先需要考察客戶(hù)做這個(gè)項目有什么用處，就是“為什么”，這樣才能真正從客戶(hù)的角度來(lái)考慮系統的設計；接下來(lái)需要總結出整個(gè)項目是“做什么”，并能概括出各個(gè)子任務(wù)，讓開(kāi)發(fā)人員對項目?jì)热莸拇蠓较蛴泻芎玫陌盐�；最重要的當然是“怎么做”了，對信息系統集成項目而言，這個(gè)階段多花點(diǎn)時(shí)間絕對值得。其中也有些小技巧：需求分析報告應以客戶(hù)認為易于翻閱和理解的方式進(jìn)行編寫(xiě)，同時(shí)也要有助于開(kāi)發(fā)人員開(kāi)發(fā)出真正需要的系統；項目組成員最好就需求分析報告給客戶(hù)詳細的講述，并達成共識，溝通手段在這里很重要；另外，需求確認之后，最好讓客戶(hù)方管理層書(shū)面簽字，作為終止需求分析過(guò)程的標志，但是絕不是作為拒絕范圍變更的手段。

　　四、 行之有效的變更控制一個(gè)項目的范圍計劃可能制訂的非常好，但是想不出現任何改變幾乎是不可能的。

　　項目經(jīng)理和項目小組必須意識到范圍變更本身并沒(méi)有什么不對，事實(shí)上很多時(shí)候這會(huì )讓你的系統更健壯、更實(shí)用�？蛻�(hù)通常不能一開(kāi)始就確定所有需求，而且情況會(huì )隨時(shí)間而變化，如果不能包容變更，那么最終解決方案可能就達不到應有的價(jià)值。

　　但是如果變更失控，后果也非常嚴重，甚至于導致整個(gè)項目的失敗。根據1995年斯坦迪什公司的研究結果，最可能引起IT項目失敗的前三個(gè)因素分別為：缺乏用戶(hù)參與、不完整的要求和說(shuō)明、易變的要求和說(shuō)明，這幾個(gè)因素都直接或間接與范圍變更管理有關(guān)。

　　因此，必須進(jìn)行范圍變更管理。潘東先生認為：“變更控制的目的不是控制變更的發(fā)生，而是對變更進(jìn)行管理，確保變更有序進(jìn)行�！�

　　為執行變更控制，必須建立有效的范圍變更流程。這個(gè)流程應該包括確認變更、評估變更的商業(yè)價(jià)值、分析變更對項目的影響，以及提交給項目發(fā)起人進(jìn)行評價(jià)以確定是否執行變更。

　　但是僅有范圍變更流程尚不足以真正控制變更，這是因為項目組的外部有許多壓力，同時(shí)與缺乏行之有效的變更控制手段密切相關(guān)。本文轉自項目管理者聯(lián)盟

　　目前流行的變更管理思想認為在范圍變更流程中有四個(gè)關(guān)鍵點(diǎn)必須嚴格控制，既：誰(shuí)有權確認變更、什么樣的變更需要執行、變更的影響多大、客戶(hù)是否接受變更的代價(jià)。

　　1、誰(shuí)有權確認變更：

　　不應當為節省時(shí)間而允許客戶(hù)的業(yè)務(wù)人員與開(kāi)發(fā)人員直接聯(lián)系，這樣無(wú)法控制變更。必須事先明確客戶(hù)方有權提出變更請求的人員和項目組有權受理變更的人員，變更請求必須有書(shū)面材料。

　　在筆者參與實(shí)施某大型信息系統集成項目感受頗深：項目經(jīng)理曾提醒我們，客戶(hù)出錢(qián)請我們來(lái)做實(shí)施，這應該算是“公對公”的事情，如果有用戶(hù)以“私人感情”為由要求范圍變更，開(kāi)發(fā)人員可以拒絕。項目管理者聯(lián)盟，項目管理問(wèn)題。

　　當時(shí)用戶(hù)如果發(fā)現由于業(yè)務(wù)變化而引起的需求變更，需要向客戶(hù)方項目負責人提出書(shū)面申請，由客戶(hù)方項目負責人審批后移交實(shí)施方項目經(jīng)理。

　　這樣對所有的變更，雙方的項目負責人都能做到心里有數。而且用戶(hù)在遞交書(shū)面變更申請時(shí)比較慎重，一般都在自己科室內部經(jīng)過(guò)討論后進(jìn)行，這樣減少了因用戶(hù)內部看法不同導致的反復變更。

　　2、什么樣的變更需要執行：

　　不是所有的變更都需要修改，更不是所有的變更都需要立刻修改。必須對客戶(hù)提出的范圍變更進(jìn)行審核，來(lái)決定哪些變更需要修改和什么時(shí)候修改。

　　客戶(hù)一般對信息系統集成項目不甚了解，他們認為很簡(jiǎn)單的事情，可能由計算機來(lái)解決會(huì )很復雜。因此項目經(jīng)理和項目小組要冷靜的分析：用戶(hù)到底想要實(shí)現什么目的，抓住本質(zhì)的需求。如果用戶(hù)建議很難實(shí)現，可以和用戶(hù)進(jìn)行溝通，詢(xún)問(wèn)用戶(hù)是否可以用其他方式來(lái)實(shí)現其目的。

　　以筆者的經(jīng)驗來(lái)看，一般來(lái)說(shuō)用戶(hù)的鍍金（Golden Plating）需求可以延期解決甚至不考慮。用戶(hù)的新增需求如果不是影響到核心業(yè)務(wù)的實(shí)現，也可以安排在現有功能的完善之后。

　　3、變更的影響多大：

　　項目組成員都要認識到變更都是有代價(jià)。必須評估變更的代價(jià)和對項目的影響，并且要讓客戶(hù)了解到變更可能會(huì )發(fā)生的問(wèn)題，一起判斷變更是否依然要進(jìn)行。

　　例如筆者參與的一個(gè)軟件開(kāi)發(fā)項目需要某項重要數據，原本計劃從已有的相關(guān)系統中讀取，但是需要對該系統做變更。用戶(hù)認為很簡(jiǎn)單，但是經(jīng)過(guò)評估，發(fā)現需要對該已有系統做重大變更，變更所花費的人力物力遠超過(guò)在本項目中另外開(kāi)發(fā)。最終決定在本項目中另外開(kāi)發(fā)，并用接口的方式從已有系統讀取基本信息數據。

　　4、客戶(hù)是否接受變更的代價(jià)

　　上面在代價(jià)評估和與客戶(hù)討論過(guò)程中，客戶(hù)已經(jīng)參與進(jìn)來(lái)。這時(shí)需要客戶(hù)一起判斷：“修改是沒(méi)有問(wèn)題的，但是你能接受由此引起的……（進(jìn)度延遲、費用增加、性能下降等）嗎？”http://bbs.mypm.net

　　一般來(lái)說(shuō)，如果客戶(hù)認為該變更是必須的（非常有可能變更是其上級領(lǐng)導提出的），就會(huì )接受這些后果，通過(guò)與客戶(hù)的協(xié)商，項目組可能會(huì )得到回報或者即使沒(méi)有回報也不會(huì )招致公司和客戶(hù)雙方的埋怨。如果客戶(hù)認為該變更雖然有必要但是可以暫緩，雙方簽署備忘錄后留待以后解決。如果客戶(hù)認為該變更可有可無(wú)，多數情況下會(huì )取消變更。

　　這時(shí)，比較穩妥的做法是讓客戶(hù)對于明顯的變更做出確認，一般是簽字確認。這樣即可防止頻繁變更，也讓客戶(hù)認識到變更帶來(lái)的工作量加大是項目延期的原因。

　　項目主管必須學(xué)會(huì )如何對范圍變更進(jìn)行控制，控制客戶(hù)需求的增加或頻繁變更，保證項目健壯的進(jìn)行。

　　最后，變更進(jìn)行時(shí)必須保證最終方案的唯一性和完整性。同時(shí)，要對所有變更進(jìn)行跟蹤和驗證，確保變更按要求完成。

　　結論范圍變更對信息系統集成項目成敗有重要影響，造成變更的原因是多方面的。但是歸結為一點(diǎn)：就是沒(méi)有執行好范圍變更管理。范圍變更管理主要包括明確的項目目標、范圍說(shuō)明書(shū)、WBS等，最重要的是建立行之有效的變更控制手段。事先要嚴格定義，事中要嚴格執行。變更控制流程中有四個(gè)關(guān)鍵控制點(diǎn)：授權、審核、評估、確認。在變更過(guò)程中要跟蹤和驗證，確保變更被正確執行。