專案（Explore）總結之專案整合管理

§1.2  專案整合管理

專案整體管理是為完成專案，滿足顧客與其他干係人的要求，管理他們的期望而必須採取的貫穿專案整體的至關重要的行動，包括制定專案章程、制定初步專案範圍說明書、制定專案管理計劃、指導和管理專案執行、監控專案執行、整體變更控制和專案收尾等七個過程。

§1.2.1                  制定專案章程

專案章程是正式批准專案的檔案，制定專案章程過程的目的是核實為專案制定與頒發章程所做的各項決定。

可以這麼說，Explorer專案從一開始就是不怎麼規範，專案章程自然是沒有制定。中標後，在公司內部，由事業部老總召集召開啟動會議，主要是明確專案組成員和職責，說明該專案對於公司、事業部的意義，由於當時沒有指定筆錄，也就沒有留下會議紀要了。會議完畢後，由事業部老總髮布專案經理任命書《Explorer_SOW.doc》，說明相關人員的任命以及職責，專案的總體時間安排和專案關閉要求，就這樣專案就算啟動了。

專案啟動時，同時確定了專案管理使用的相關工具：

1.      使用MS Project+Word制定整體計劃、月度計劃和周計劃；

2.      使用公司自行研發的Bug Manager跟蹤系統缺陷；

3.      使用svn作為配置管理工具。

專案啟動過程產生了專案經理任命書，但由於該文件只指明瞭PM的任命，與標準的流程相比較，主要存在以下幾點問題：

1.      沒有明確專案目的和目標。問題：專案組成員認識不一致，步調不一；

2.      缺少了專案干係人的初步分析和要求。問題：需求分析和系統設計時缺少權衡各個干係人利益的考慮；

3.      缺乏細化的里程碑進度。問題：無法有效監控專案，規避風險，等到真正出問題的時候才意識到專案已不可控；

4.      缺乏財務上的指標等。問題：掙了虧了，與專案組無關，埋頭苦幹，沒有理會財務指標。

§1.2.2                  制定初步專案範圍說明書

在1.2.1提到在SOW中說明了“專案的總體時間安排”，這個時間安排是內部根據以往經驗拍腦袋憑感覺做出來的，缺乏必要的依據，這其中就有關鍵依據之一的《專案範圍說明書》。

由於簽訂合同時，沒有製作工作說明書作為合同附件，導致專案範圍自始至終只能以招標檔案為唯一標準，而招標檔案所描述的範圍泛而廣，並沒有清晰的界定那些是需要做的，那些是不需要做的，這給後面專案範圍管理帶來了較大的隱患。

§1.2.3                  制定專案管理計劃

由於缺乏足夠的資訊輸入（範圍不清的招標檔案），該過程的產出《專案管理計劃》自然就很不準確了。當時按照監理要求的格式，制定了一份專案管理計劃，包括了人員安排計劃、配置管理計劃以及專案進度計劃（使用MS Project製作），其他如範圍管理計劃、質量管理計劃、風險管理和應對計劃、專案過程選擇、基準測量方法和技術等均沒有提及。可以看到，專案管理是不完備而且有較大缺陷，主要原因是缺乏管理意識和知識，沒有形成一套行之有效的專案管理思路。

雖然沒有形成文字材料，不過專案還是“自發”的形成了生命週期，先前在“背景”章節已經提及過，劃分為多個階段分批上線，除了技術和人員積累不夠外，還有一個主要原因是整體的專案範圍不清晰、國家政策變動頻繁，因而選擇分階段迭代的方式以規避風險。

§1.2.4                  指導和管理專案執行

指導和管理專案執行是要求專案經理和專案團隊採用多種行動執行專案管理計劃，完成專案範圍說明書中明確的工作。專案管理計劃不完善，專案範圍說明書缺少，可以想象，指導和管理專案執行會是什麼情況。結果演變為做到那算那，嘗試過、出現問題再說，基本無整體計劃性可言。

專案費用上，由於沒有財務指標，基本不控；進度上，由於第一階段的X1系統做得不甚理想，運維任務過大，除該階段勉強按計劃進度完成後，之後的各個階段基本失控；風險管理上，沒有風險意識，憑感覺、意識去判斷，結果可想而知了；專案資訊收集上，團隊內部溝通和交流不夠，上一階段的經驗教訓不能有效的反饋到下一階段，同樣的問題屢次發生，苦不堪言。

§1.2.5                  監控專案工作

監視和控制專案工作過程是監視和控制專案所必需的各個過程，採取預防或糾正行動控制專案的實施效果。監視和控制簡單來說就是拿當前的工作實施情況與基準進行比較，透過發現問題和不足，透過控制措施使專案按計劃執行，確保專案可控，其中比較基準就是專案管理計劃。

具體到專案中，監視週期設定是周，每週均有專案週報提交到公司高層和客戶，同時在每月召開建設方、監理和承建方的三方會議。第一、二階段偏離計劃後沒有變更整體計劃，之後基本沒有變更過配置庫中專案計劃，當時的情況是，誰都不知道何時會完成，雖然每一個子系統均有制定計劃，但從整體進度來看，基本處於無監控狀態。

另外，由於公司沒有專門的過程控制部門，導致公司沒有第三方力量監控專案，無法在問題發生前提出預防措施，問題發生後沒有糾正專案過程中的種種問題，導致問題一再發生。

§1.2.6                  整體變更控制

專案很少可以按照專案進度計劃執行，因而需要整體變更控制。整體變更控制應有對其負責的組織，即變更控制委員會（CCB），由該組織確定是否接納變更，組織相關人等對變更作影響分析，變更如何實施等，未經CCB同意的變更不予處理。

Explorer專案沒有CCB這一提法，如出現變更，一般的做法是由專案核心成員（一般是子系統負責人和PM）會同資訊部門對變更進行分析，確定變更的型別、影響的模組清單、大概的工作量等，實施時，由各子系統負責人分配任務給開發人員，經測試人員和客戶驗證後釋出。由於管理不規範，有些變更直接跳過了客戶資訊部門，有些則沒有上報給PM，有些則客戶直接找開發人員要求變更，如此種種，第一階段十分的混亂，之後才規範為剛才所述的做法。

§1.2.7                  專案收尾

這個階段的重要標誌是：客戶驗收，商務收款，專案關閉。如前所述，由於缺乏工作說明書，在專案後期，客戶仍然要求專案組對照招標檔案中的範圍，完成未完成的子系統和模組。在專案做了差不多一年半的時候，回頭發現還有很多招標檔案上有但沒有開發的子系統的時候，會是什麼感覺？鬱悶透頂。不過，幸好，出於某些政治上的考慮，同時也透過一些商務手段，在專案接近兩週年時總算完成專案驗收，但遺留了不少的“未完成”任務，這些任務在驗收後的兩個月後才基本完成。

-------------------------- 本文可任意轉載，但請註明作者和出處 ----------------------------