【案例正文】
我2007年9月接手了一個已經開發(fā)接近尾聲的項目，項目也不大，前期需求、開發(fā)、測試做的也比較好、比較規(guī)范，接手的時候感覺問題不大。項目前期的整個過程也和客戶進行了詳細的討論和分析確認，但在我們安排實施人員現場實施的過程中，客戶在業(yè)務流程環(huán)節(jié)卻有著許多細微的變化。
<br>
<br>剛開始第一次實施時，客戶針對演示講解后的系統(tǒng)進行了討論和分析，同時提出了許多變更的細節(jié)，問題到不大，系統(tǒng)修改后很快進行了第二次實施，第二次客戶又對系統(tǒng)提出的改進的需求，也是一些細節(jié)的內容，導致第二次實施后又回去修改系統(tǒng)，接著第三次，整個過程導致我們實施人員很惱火，說是需求變更吧，也不完全是，有些細節(jié)的東西是無法一次性滿足客戶的……，直到2008年5月，這個小項目才算達到試運行，從第一次拿到客戶現場的系統(tǒng)和最后一次試運行的系統(tǒng)的功能的對比來看，系統(tǒng)功能需求的確發(fā)生了很大的變化，但是從第一次和第二次的功能比較來看，只是一些細節(jié)性的變化。
<br>
<br>對于這些細節(jié)性的變更，應該如何處理和控制？

分析1：其實像案例中描述的系統(tǒng)，需求方面已經不存在很大的問題，所以才會導致"細微的變動"。
這些細節(jié)上的變化，也許僅僅是一些用戶習慣等等，而提出變更請求的用戶，也未必能代表其他用戶的意見，需要讓他們內部先充分討論，讓用戶領導確認，明確成本，避免往復修改。
再者，用戶和客戶的概念也是不一樣的，只要不是客戶，用戶提到，可以再做做工作嘛~~~~~

分析2：可能的原因：
1、需求調研分析不到位?？蛻舨粫o緣無故變動，要么是之前沒有做到位，要么就是政策發(fā)生了變化，目前來看應該是前者；
2、沒有變更流程。任何的變更都應該有流程，沒有規(guī)矩不成方圓，我相信客戶也應該能理解；
3、實施時，同客戶交流的不到位。特別是一些細節(jié)的問題，交流時盡量全面；
處理方法：
1、建立需求變更流程，變更單表明修改內容，工作量大小，雙方簽字確認（對于當前這個項目，多次變更后就可以把這個單子拿出來同客戶交流，情況好的話可以拿到一些補償，情況差的也能體現實施方的辛苦工作）；
2、需求交流，盡量能討論的仔細一些，避免以后現在的情況；
3、在項目開始時就確定關于變更的處理方法，如是項目內做，還是項目外做，允許項目內變更多少工作量等等。

分析3：1、找對合適的人去做需求調研，如有必要需要設計出原形。
2、合同中定義好項目范圍、變更流程及變更費用的計算。
3、可以從另一個方面考慮，用戶的新的想法及思路通過整合說不定會給我們系統(tǒng)的不斷完善帶來很大的幫助。

分析4：、在項目實施之前，盡可能的了解客戶的業(yè)務和實際的需求，要對客戶的業(yè)務盡量的熟悉，很多時候客戶想要的和實際需要的東西是不一致的，搞不清楚，客戶就容易變更，畢竟客戶是上帝，乙方不可能很強硬的對抗甲方的。
2、在客戶描述不清楚實際需求的時候，做好陪著著做一個原型，讓客戶結合原型再修改，這樣可以在修改后一次到位
3、在項目啟動的時候，要給客戶講解一下項目管理方面的知識，比如講一下項目管理三角形，讓客戶了解范圍、進度、費用之間的關系，客戶理解之后也會知道項目的變更會對項目造成影響。
4、項目的變更要走流程，哪怕是一個小的變更，要不容易養(yǎng)成客戶隨意變更的壞毛病

分析5：. 既然前面的環(huán)節(jié)比較規(guī)范，那么可以從已經確定的變更需求中發(fā)現，新的變更是否在受控范圍，如果是新需求則走需求變更流程
2 需求變更流程：提交新需求，完成提交，CCB控制委員會影響分析完成評估 ，評估結果為接納或拒絕，如果接納則實施變更還要進行驗證，如果拒絕則給出正確的影響分析理由， 這些都必須有一個成文的流程和規(guī)矩，實際上就是讓新需求走受控的過程。
3 建立變更控制系統(tǒng)
合理的變更控制系統(tǒng)，減少盲目的變更，降低變更的隨意性，
很多需求會誰客戶的理解和時間發(fā)生變化，如果沒有變更正式的書面確認過程和有效的控制系統(tǒng)來規(guī)避相關事件，則項目范圍和當初會大相徑庭。
4 偏差分析
5 重新規(guī)劃
總得說來，就是正式化 書面化變更流程，并及時更新項目范圍，進行影響分析和偏差分析，使之處于受控狀態(tài)，而不是失控狀態(tài)