項目計劃修訂（上）

（本文是學習筆記，與大家分享）

       本文按照如下的順序進行：

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業内的從業人員在個人成就的階梯上不斷攀登，人員在各個公司之間來來往往，或者在一個公司内部不斷升職。當一個隊員因為辭職而離開團隊，你必須立即采取行動為他找到一個替代者，這不是一個容易的事情，如果幸運的話，可以從公司内部找到一個可以從原來的隊員離開的地方開始工作的人員。最有可能的是讓一個新隊員加入團隊，你将面臨評估這個新隊員的技能并重新安排資源來按進度表完成項目。你也可能沒有其他辦法，而隻好雇傭一個獨立的承包商或者咨詢人員。