（本文是學習筆記，與大家分享）
本文按照如下的順序進行：
l定義變更需求
l建立變更控制
l實現項目變更
l 問題處理會議
l推遲項目
一條你沒有走過的路，當你開車在錯誤的方向上走了20分鐘後才發現,你該如何辦？IT項目中經常會遇到類似的情形，無論你做過多少的研究，測試過多少次開發過程，計劃制定的有多麼的細緻，仍然沒有人能夠預測到未來是什麼樣子的，IT項目經常是由於在開始的時候，由於偶然或者設計的原因出了錯誤，幸運的話，可能在實現之前發現這個錯誤，而另外的情況是來自管理層或者是客戶需求的變更可能使得項目的實現方向改變，另外的情況是由於項目經理的原因導致了項目方向的變更。
1. 定義變更需求：任何變更，即使是想更好的方向的變更，都伴隨着挫折和痛苦。在IT項目管理領域，變更不應該是一個簡單的在原來基礎上加入的過程。每個IT項目都有項目範圍，項目範圍陳述了項目應該提交什麼和不應該提交什麼，項目範圍是將來項目做決策的參照，他是完成項目要做的工作，而且是僅需要完成的工作，一旦完成了項目陳述，需要得到需求方的認可，他就可以避免不必要的變更。但是這個在中國不合適。
然而對於IT項目，由於其自然屬性必然要導致變更，打補丁，軟件新版本，缺陷，安全問題，項目相關人員的新要求都是導致變更的原因。所有的變更請求都應該文檔化，而且要評估變更的成本、時間、風險和相關的迴歸任務，另外，每個請求必須進行文檔記錄，跟蹤實施變更或者拒絕變更。
然而在項目中經常的情況是將這些變更硬性的加入到項目範圍中，即使他是最終可交付成果的全新設計，然後項目經理會竭盡全力使得項目計劃適應這些新的和改善的要求，這種做法很少湊效，他會使得項目團隊成員的士氣低落，感到挫折，使得最終達不到要交付的要求，最後使得項目經理失去對項目的控制，當這些變更確實必要的，爲了避免以上的情況發生，你必須要有控制變更和實現變更的一套有效地程序。
2. 建立變更控制：變更控制是一個內部管理的過程，項目經理可以一次來阻止任何人（包括管理層）在沒有正當理由的情況下變更項目的交付規格和要求，變更控制要求請求者必須要有足夠的理由才能提出變更要求，然後再評估提出的變更對項目的各個方面的影響。變更控制系統是項目中的評估、評審、批准變更的一個正式的文檔化過程。CSS是如何評審變更的價值，成本、進度影響，風險以及可行性等過程，CSS也是對批准或者拒絕變更進行跟蹤、記錄的方法。
在一些企業中，變更控制系統包括變更控制委員會（CCB），CCB對申請的變更進行分析，以便於確定變更的影響，並作出決定，管理層和客戶可能有成打的理由對項目的可交付成果作出變更，最糟糕的情況是項目可交付成果的接受者有一天突然來到你的辦公室，再與你探討了項目的實現情況之後，突然對你說，哦，對了，你的項目還要如何如何修改，還有另外的一種痛苦情況，就是團隊內部要求做出變更，因爲有人發現正在實現的技術根本不適合這個項目，選用的技術不能真正的使用交付，新技術與已有的技術衝突，或者是在安裝期間就落伍了。在一個缺乏IT員工的組織中，IT人員每週工作60-80個小時是很常見的事情，他們將從事如此多的實現計劃和項目開發，同時還要履行日常的職責，以至於讓他們跟上項目計劃對他們來說在體力上是不可能的，在這種情況下，除了增加新的資源，沒有其他的辦法，項目在初期的變更比在後期的變更更容易些，這是一個一般性的規則，也就是說，項目越接近結束，變更交付成果越困難，避免這些的最好的方法就是預防，和項目管理的其他方面一樣，紮實的前期調研，計劃，與項目可能影響的各類用戶的深入的瞭解都是至關重要的，可以使用以下的方法避免以上情況的發生，1，作爲調研階段的一部分，會晤產品的客戶，詳細執行這一步將會確保最終產品滿足目標要求，2.在進入實現階段以前，要徹底地研究和測試所採用的技術，具備一個仿真工作環境的測試實驗室對IT項目是必須的。3.在項目實現前檢查所需要的資源，實事求是的檢查員工是否有時間和知識 來實現所提議的技術。
l 變更的影響:在項目管理中，總會發生的事情就是項目計劃的變更，對項目計劃的正式變更而言，無論這個變更是誰的事情，都是一件嚴肅的事情，不管這些變更在表面上看起來是多麼的小，或者是造成的原因是多麼的無辜，從項目週期這點上來說，你的項目網絡圖是緊湊的，難以變更的，在你的PND中，已經標示了關鍵路徑，在不延長工期的情況下沒有假如額外的工作的空間，但是工期的延長是不可以接受的，另外，增加額外的可交付成果需要額外的花費，對項目範圍的變更可能意味着需要額外的資金，內部的或者外部的，而且你的預算也可能支付不了這些變更，變更意味着額外的軟件或者硬件成本，一般來說，如果變更項目的範圍，就需要變更額外的資金。開發組的士氣可能一落千丈，面對你的團隊成員，並告訴他們到目前爲止所做的計劃，研究和工作的完成都要加入新的標準，這不是一個好消息，處理這樣的消息，你需要拿出你的智慧，並且講究技術。
l項目變更請求，當變更不可避免時，項目經理必須有一套正式的程序，來把這些變更加入到項目中去，這個正式的程序叫做項目變更請求表。變更控制表對來自任何人的向項目經理的變更請求給出了形式化的描述，這個表格可以是電子版的，也可以是紙質的，也可以是電子班的，變更請求者，項目經理甚至CCB如果認爲需要進行變更，就提交變更請求表，他要求請求者不僅要描述變更，還要給出理由說米高爲什麼這些變更是必須得，一旦請求者完成了這個表格，項目經理，項目發起人和其他項目相關人員就可以判定這個變更是否真的必須，或者應該給與拒絕，或者把這個變更推遲到當前項目完成之後再予以實現。
3. 變更影響說明 變更影響說明是項目經理對於項目變更請求表發出人的正式迴應，它概述了項目經理對於如何加入變更的建議計劃。通常這是一個可行的途徑和項目經理願意實現的折中方案的清單，有些時候，這個變更影響說明可以同其他迴應文件一同提交給客戶，項目經理可以在變更影響說明中使用7種不同的迴應：
u 對不起，建議的變更不能批准，變更不能加入到當前的項目範圍內，這些額外增加的要求將會使得項目失控，範圍擴大，並且浪費資金，時間和資源。
u 好消息，你所建議的變更可以再當前的時間線，用當前的資源來完成，變更很簡單，不需要額外的資源或者時間。
u 你所建議的變更可以使用當前的資源來完成，但是需要延長時間線，變更請求將會花費額外的時間來完成項目，不過當前的資源可以來完成這些額外增加的事情。
u你所建議的變更可以完成，但最後的期限需要向後推遲並且需要額外的資源，基於變更請求，現在的時間線不再現實，而且以當前的項目團隊完成這些變更也是不可能的，這些都源於當前的項目團隊成員都不具有增加的組件所需要的技術。
u 你所建議的變更可以完成，但可交付成果將以分層的策略來實現，這種反應接受了提議的變更，但根據這個變更做出的可交付成果將優先根據客戶需求來發布。
u壞消息，如果不對項目計劃做出相當大的變更，建議的變更就不可能實現，對項目建議的變更是如此之大以至於它將使得當前的計劃完全作廢，要做出這種變更就需要充分的理由。因爲這將使得前面所有的艱苦工作，時間和到目前爲止投入到項目中的資金完全丟棄。
4. 項目內部的麻煩：對於項目計劃的變更，最困難的是來自於項目團隊內部，這些變更通常都是由於每個項目中都恆定的一個變量引起的：人爲因素。
人爲因素是一個可以預測的問題，它通常是那些沒能完成他們的分配任務，沒能與其他人交流而發現困難和缺點，或者對工作失去興趣的團隊成員引起的，這些大錯特錯都是領導失誤的表現，作爲一個項目經理，你必須在項目的實現階段起到積極的作用，能像消防隊員可以嗅到煙味一樣發現正在發生的麻煩，你必須充滿活力的投入到這些任務中去，從問題的源頭解決問題，在它羽翼豐滿，能夠導致你的項目被推遲之前就把他壓制住。在做長期的項目時，每一個人都容易在實現階段失去激情，一旦一個團隊的成員對一個項目失去了激情，他就會失去興趣，耐心和動力，一旦到了這個點上，再激發他們的動力就比較困難了，一個項目經理應該在團隊成員真正失去激情之前就早早的意識到這一點。
IT項目經理經常遇到的問題就是問題的反覆，正如你所瞭解的那樣，IT業內的從業人員在個人成就的階梯上不斷攀登，人員在各個公司之間來來往往，或者在一個公司內部不斷升職。當一個隊員因爲辭職而離開團隊，你必須立即採取行動爲他找到一個替代者，這不是一個容易的事情，如果幸運的話，可以從公司內部找到一個可以從原來的隊員離開的地方開始工作的人員。最有可能的是讓一個新隊員加入團隊，你將面臨評估這個新隊員的技能並重新安排資源來按進度表完成項目。你也可能沒有其他辦法，而只好僱傭一個獨立的承包商或者諮詢人員。