凡是做過不止乙個國內的專案的專案主管人員可能都經歷過這種場合：公司的銷售人員興沖沖的拿來乙份與客戶簽訂的合同交給你，聲稱這專案又搞定了，但是當你拿過來合同(或者任務委託書)一看，關於專案範圍的說明只有寥寥數行，要麼是一些高舉高打的套話，要麼只說專案都包含什麼樣的模組，而對具體的業務只是一兩句話就完事兒了，如果是一位身經百戰的管理者並且對於專案的具體業務很熟悉還可以，如果不是那該如何開始這個專案呢？還有一種情況，客戶在專案程序中，不斷對移交的系統提出修改意見，更可氣的是，有些問題開始提出更改，某一天客戶突然就發現情況不對，又要求你給改回來，看起來客戶的需求總是無窮無盡，作為專案的承擔者該如何應對這種令人沮喪的局面呢？
一、客戶需求為何過渡膨脹
作為專案的承擔著，在規定時間用有限的資源來保質保量的完成專案，讓公司和最終客戶都滿意是專案組的神聖職責。但是為了讓客戶滿意就要滿足客戶所有的需求嗎？因為不斷滿足客戶的需求會不會導致專案失敗怎麼辦呢？為了弄清楚這些原因，首先應該找到這些問題發生的根源。
1. 簽訂合約的時候，專案範圍描述不清楚。這是最常見的問題之一，也正是早期的這些問題沒有引起專案組的足夠重視，導致後期專案無窮無盡的修改。
2. 客戶和專案組對寫成紙面檔案的需求理解不一致。這種情況也較常見，雖然客戶已經確認了專案組提交的專案範圍說明書，專案組也是完全按照這個檔案規定的內容做的，但是客戶還要求改，當專案組拿著紙面的檔案與客戶對質的時候，才發現客戶也認可這需求，但是同一件事情，客戶的認知和專案組的認知完全不同。舉個簡單的例子：客戶要求系統能夠電子簽名，專案組的成員就模擬了乙個，自動產生客戶的簽名在系統中，但是當移交給客戶的時候才發現，客戶要求的電子簽名實際上是想把原來手寫簽名的工作也移植到電子化的系統中，讓領導能夠通過畫圖的方式產生乙個手寫的簽名在文件中應該落簽字的地方！有時候就是當初一點點疏忽，導致專案後期大量修改甚至專案延期。
3. 客戶總有在結項之前把每一件事情都做得淋漓盡致的初衷。一般來講，在專案結項之前，客戶都會把所有的想法盡量逼著專案組解決，因為一般的客戶心理都會認為：一旦結項了，再想找專案組成員對業務系統進行修改可就難了，因為it公司人員流動性強的特點，即便以後能夠找到承包商，當初做專案的專案組成員也不一定在了，或者很多公司因為業務繁忙，已經顧不得原來已經結款的客戶了。
4. 專案組人員總是無條件遷就客戶，客戶有求必應。這種做法的出發點是好的，目的是要客戶完全滿意，但是實際上這種做法不一定能達到目的。一般的客戶需求都是無底洞，這樣做對整個專案經常也會帶來很多負面影響。當然，如果過分控制客戶的需求，客戶肯定也不會滿意。
二、解決辦法
針對上述專案問題以及發生的原因，結合以前一些專案的教訓經驗，我感覺可以通過以下幾點來有效遮蔽客戶需求過渡膨脹的問題，讓專案完成得更加漂亮。
未雨綢繆：
專案初期一定要制定清晰的目標和專案範圍，並且讓專案主要干係人(最重要的當然是最終客戶了)確認。
不管通過什麼途徑得到的專案，作為專案主管，在專案前期，可以分三步走。
第乙個想到的問題應該是「為什麼」，也就是客戶做專案有什麼目的，知道這些以後，才能在以後的工作中更加想客戶之所想，不至於專案方向錯誤，最終爭取達到雙贏得局面。
知道了「為什麼」以後，接下來就要非常清晰的知道「做什麼」，有乙個比較好的辦法就是用一兩句非常簡潔的話概括出來整個專案，並且能夠用這種方法概括出專案中的各個子任務，並且能夠讓前台業務人員和後台研發人員都能夠心領神會，那麼說明專案主管對專案的內容在大方向上已經有很好的把握了。
最後就要弄明白「怎麼做」了，對於比較陌生的專案來講，這一階段工作量比較大也很重要，在這個階段多花點精力絕對值得，當然，根據具體的情況，也可以在這個需求調研階段簡化一些不必要的工作，這需要專案主管具備平衡那些彼此衝突的專案目標的能力。在實際的工作中，這需要乙個過程，值得注意的是，在需求整理完畢形成文件以後，最好先讓專案組人員把自己總結的需求跟客戶比較詳細的講一遍，在實際的操作中，這種做法不僅能夠把專案人員與客戶在業務層面的歧義問題數量大大降低，還可以很好的發先潛在的問題，並且掌握一些溝通技巧，也會讓客戶更能深刻的感覺到承包商對他們的重視。另外，如果專案前期得需求人員對技術非常不了解，根據實際情況最好在需求每次提交給客戶前與研發人員溝通，以避免不必要的給客戶的承諾，更加準確的界定工作量。總之，有效的計算出專案範圍將會占用一定的時間，但是同樣會節省資源、資金以及解決專案今後令人頭疼的問題，例如：需求(範圍)變更。
另外乙個很值得注意的問題是：專案的需求經過幾次確認以後，要讓有權力的客戶明確確認，最好有書面簽字，這個有說服力的檔案會在以後客戶發生需求變更的時候起到很好的作用，很顯然，因為客戶已經簽字確認，總是反悔肯定理虧呀，即便因為業務變化不得不對專案進行大的調整以至於專案延期，這種情況下也會是專案組處於有利地位，不至於讓自己的公司非常不滿，甚至可以以此為依據來要求客戶重新考慮專案經費。當然，對於客戶來講，通過這些很好理解的需求的闡述，也會以此作為以後交付產品的依據，做到心裡有數，消除不必要的疑慮，這個對雙方有同等的約束力，很有好處。
靈活應變：遇到變更要與客戶溝通
經常有這種情況，專案都已經執行到最後階段，客戶突然提出了新的要求或者要求對已有需求進行更改，這會讓專案主管非常為難：一方面要盡量滿足客戶的需求，另一方面又不能對系統做太大的改動，影響進度計畫。這種情況發生除了和需求階段有關以外，同時說明在實施過程中沒有與客戶有密切的聯絡，缺乏溝通。
從客戶的心理來分析。由於軟體的特殊性，客戶通常非常關注後期的服務，尤其是在國內大家做的軟體絕大多數都是與實際業務緊密相連的。作為專案管理者，非常忌諱的是在做專案的過程中對客戶置之不理，而最後交付的時候才與客戶突然發生大量接觸，本來後期的實施過程出現問題的可能性最大，之前與客戶又比較生疏，很可能會造成非常大的風險。比較穩妥的辦法就是在專案程序中也要讓專案組與客戶保持聯絡，相互了解，建立更加融洽和諧的溝通氣氛，為以後關鍵的實施移交階段可能與客戶發生的衝突做好準備。值得一提的是：在專案程序中階段性的給客戶呈現一下專案的進展狀況，讓客戶對專案有乙個更加直接視覺化的認識，更能及早的發現解決問題免除後患，在不斷的溝通過中，應該讓客戶認識到專案組時時站在客戶角度著想，讓客戶的主要負責人也能深深的感覺到他們是專案組的重要組成部分、榮辱與共，並且專案組能為客戶提供完善持續的後續服務，這樣可以有效的避免客戶絞盡腦汁想把所有的事情在第一次結項之前做完。
即便前期工作做得再好，很多情況下，需求變更是不可避免的。專案主管通過良好的溝通機制隨時掌握變更情況和可能發生的變更，一旦發生了變更，專案組一定要冷靜處理這些問題，一般可以按照產品分析—〉成本/收益分析—〉備選方案—〉專家判斷這四個步驟來首先評估需求變更，並且盡快形成專案範圍變更書面的說明書，它是以後專案決策的基礎，當然比較穩妥地辦法還是讓客戶對明顯發生的變更做出確定(選擇簽字最好)，尤其是在評估了變更可能導致的工作量增加以後，讓客戶認識到過多的變更很顯然會造成專案延期，客戶對此也要負責任。
在客戶提出需求變更的時候，一定要掌握一定的溝通技巧，一定不要總是無條件遷就客戶。一般來講客戶對it都不太熟悉，他們認為很簡單的事情，可能要花費專案組大量的無謂得多餘精力，所以千萬不要認為客戶所說的就一定是他想得到的！大部分客戶都是第一時間突然腦海裡面冒出的火花，所以專案組人員要冷靜的分析一下：客戶到底想要實現什麼目的，抓住問題得本質。一般來講，實現客戶本質的需求有很多種辦法。在與客戶的溝通中，一定避免與客戶正面衝突。在初期認真傾聽客戶意見，多問一些「您還有什麼想法」之類的問題，等客戶把他的想法都表述清楚以後，專案組成員成員最好迅速評估一下客戶的建議，如果實現起來實在太困難，可以給客戶一些更加中肯的提議，多問些「您看這樣行不行？其實可以達到同樣的目的。」之類的問題，最後還有乙個重要的過程就是要與客戶確認這次溝通的結論。
總之，專案整體管理是平衡那些彼此衝突的專案目標的一種能力。看起來簡單，但是實際上很複雜，專案主管在專案程序中要學會如何對常見變更進行控制，控制客戶需求的肆意膨脹，保證專案健康穩定的進行。
1. 在專案啟動時，公司會批准乙個新的專案階段的開始。
2. 在範圍計畫編制的過程中，將制定乙份說明書來描述在專案中將做什麼。
3. 在範圍定義中，專案的主要部分被分成更小的部分。
4. 在範圍審核時，需要驗收專案的範圍。
5. 在範圍變更控制中，隨著時間的過去，需要對專案範圍變更進行監督。
專案管理中如何更好的控制客戶的需求？
做專案管理經常會遇到這樣的場景 公司的銷售人員興沖沖的拿來乙份與客戶簽訂的合同交給你，聲稱這專案已經搞定了，但是當你拿過來合同 或者任務委託書 一看，關於需求，專案範圍的說明只有寥寥數行，要麼是一些高舉高打的套話，要麼只說專案都包含什麼樣的模組，而對具體的業務只是一兩句話就完事兒了，如果是一位身經百...
IT專案管理如何做到更好
it專案管理如何做到更好?利用目標管理的方法，能夠做到更加有效的專案管理。但是，目標管理要做到有效果，還是有定的難度的。如何對目標進行量化?如何做好員工目標的考核?怎樣制定目標才能夠更加合理?這些都非常值得深思的問題。目標管理，知易行難 目標管理是一種程式或過程，專案管理者通過目標對下級進行管理，當...
如何做好IT專案管理的需求管理
摘 要 隨著it在現代生活起到越來越重要的作用，根據本人參與的專案管理 售前調研 系統開發的多年經驗結合最新的專案管理知識，我們就需求管理這個領域來 討論it專案的需求管理，特別是如何建立完善的需求說明書，以及採用那些相關的需求管理模板檔案來實現需求變更控制。本 從技術工具 模板和經驗相結合 的方法...