項目計劃修訂（上）

（本文是學習筆記，與你們分享）

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

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業內的從業人員在我的成就的階梯上不斷攀登，人員在各個公司之間來來每每，或者在一個公司內部不斷升職。當一個隊員由於辭職而離開團隊，你必須當即採起行動爲他找到一個替代者，這不是一個容易的事情，若是幸運的話，能夠從公司內部找到一個能夠從原來的隊員離開的地方開始工做的人員。最有可能的是讓一個新隊員加入團隊，你將面臨評估這個新隊員的技能並從新安排資源來按進度表完成項目。你也可能沒有其餘辦法，而只好僱傭一個獨立的承包商或者諮詢人員。