用專案總結來減少問題的重複發生(轉)

用專案總結來減少問題的重複發生
案例

　　A公司是一家國內中型IT系統整合公司，有多年的行業系統整合經驗。通過多年的經驗積累和管理探索，建立了一些專案管理流程和專案管理資訊系統。

　　在一次大型專案的招投標專案上，公司副總任命James為本次投標專案的負責人，來組織和管理整個投標過程。

　　James接到專案任務後，得知必須在15天內完成，隨後立即召集了商務部、售前技術部、銷售部、客服部和質量部等相關部門，進行了一次專案內部啟動說明會，並把各自的分工和進度計劃進行了部署。

　　然而，在投標前三天進行投標檔案評審時，發現技術方案中所配置的裝置在以前專案使用中是有問題的，必須更換。James和方案編制人員經過加班加點，終於修改完成。到了正式評標會上，James又遇到了一點麻煩，原來授權代表宣告和投標方案中寫的不一致，影響了評標分數。不過還好，專案最終拿了下來，並和使用者確定了合同。根據公司流程，James把專案移交給了售後實施部門，由他們具體負責專案的執行和驗收。

　　實施部門接手專案後，Bob被任命為實施專案經理，負責專案的實施和驗收工作。Bob發現由於專案前期自己沒有儘早介入，許多專案前期的事情都不很清楚，而導致後續跟進速度較慢，影響專案的進度。同時，Bob還發現設計方案時，售前工程師沒有很好地瞭解使用者需求，也沒有書面的需求分析調研報告。在接手專案後，必須重新開始瞭解使用者需求，編制實施方案，這樣無形中增加了實施難度和實施成本。

　　等到這一切理出了頭緒，在商務下單訂貨過程中，又發現由於商務人員的工作失誤，導致少採購了幾臺裝置，並且裝置模組配置功能錯誤而不能符合要求。

　　而在A公司中，由於售後和售前是兩個獨立的部門，在專案執行中，特別是專案執行完畢後，沒有一套明確而完善的專案總結和閉環的問題分析和關閉流程，導致許多專案中重複出現相同或類似的錯誤或失誤（包括：技術方面和商務方面），進而導致投標失敗、專案成本較高、專案執行中困難重重、使用者滿意度較低等諸多風險。

　　基於以上諸多原因，A公司管理領導層要求系統整合部門負責人Paul就此問題提出合理的改進辦法，同時編制一份各個專案可以參考的專案總結模板。希望將專案完成後各部門不同階段的總結反饋給相關部門和人員，形成一個閉環的流程，以便避免和減少類似問題的重複發生。那麼Paul是如何通過有效的專案總結和流程來解決這些問題呢？

　　說起專案總結，大家都認為它很重要。然而，在實際工作中，人們很少把它與進度、成本等同等對待，總認為它是一項可有可無的工作。因而，在專案實施過程中，專案干係人就很少會注意經驗教訓的積累，即使在專案運作中碰得頭破血流，也只是抱怨運氣、環境或者團隊配合不好，很少系統地分析總結，或者不知道怎樣總結，以至於同樣的問題不斷出現。

　　在上面的案例中，A公司在專案中重複出現相同的錯誤或失誤，從而導致專案進度延誤、專案執行成本較高甚至客戶滿意度下降等問題。這也是系統整合公司或軟體公司在專案中經常會出現的問題。

　　專案中問題出現後，大家不知如何做到防微杜漸，如何通過有效的專案總結做到亡羊補牢，避免在下一個專案中在出現類似的問題。這實際上就是通過有效的總結從而使專案過程形成一個閉環的反饋機制，最終避免和減少問題的發生。

　　經過調查和分析公司的多個專案後，A公司的部門負責人Paul認識到了做好專案總結工作是其中的關鍵之處。並且，在與專案經理和專案成員溝通後，Paul發現要做好專案總結的工作，首先就應該在專案啟動時將其加以明確規定，比如專案評價的標準、總結的方式以及參加人員（如專案辦公室、商務部、售前部、市場部、儲運部等）等。

　　當然，除此以外，如果可能，專案總結大會上還應吸收使用者及其它相關專案干係人參加，以保證專案總結的全面性和充分性。

　　事實上，專案總結工作應作為現有專案或將來專案持續改進工作的一項重要內容，同時也可以作為對專案合同、設計方案內容與目標的確認和驗證。正如上文所說的，專案總結的目的和意義在於總結經驗教訓、防止犯同樣的錯誤、評估專案團隊、為績效考核積累資料以及考察是否達到階段性目標等。總結專案經驗和教訓，也會對其他專案和公司的專案管理體系建設和專案文化起到不可或缺的作用。完善的專案彙報和總結體系對專案的延續性是很重要的，例如專案完成後專案的售後維護、裝置保修等。特別是專案收尾時的專案總結，專案管理機構應在專案結束前對專案進行正式評審，其重點是確保能夠為其它專案提供可利用的經驗，另外還有可能引申出使用者新的需求而進一步擴充市場。

　　專案總結的資訊來源

　　那麼，總結專案經驗所需的資訊應來自哪些方面呢？在專案實施中，專案經理有時會發現，以前專案中的總結資訊很零散，每個部門只從本部門出發，總結自己的問題，而沒有其他部門或人員的參加。而實際上，它應該來自專案的各個方面，其中包括來自專案組、客戶及其它專案干係人的反饋及專案管理資訊系統（PMIS）。同時，使用這些資訊以前，應確保收集這些資訊的系統、組織和流程能夠正常執行，並且應建立專案資訊的收集、釋出、存貯、更新及檢索系統，確保有效地利用專案中的各種資訊資源。

　　從管理的觀點來說，專案生命週期的每個階段或者稱之為里程碑，都應該進行評估總結，以確定是否實現了此階段的目標，專案是否可以正式開展下一個階段工作。總之，專案的不同階段都應該有完善的專案總結，只不過總結的形式、內容、編寫者和閱讀物件等側重點不同而已。

　　在編寫專案總結報告時，應該首先明確編寫的目的，同時也應簡述專案概況、專案背景和專案進展情況。因為既然叫專案，就有其獨有性、時間性，這樣專案總結的內容才能夠更具有針對性、時效性和持續改進的意義。

　　最後，Paul根據美國專案管理協會（PMI）的專案管理框架，把專案總結的框架提綱分成以下幾個方面來進行。

　　專案總結的框架

　　1、專案進度

　　按照專案整體計劃或專案滾動計劃編寫的計劃工期與實際工期之間差距和原因分析。其間有哪些變化？對工作量的估計如何？以便為專案經驗庫提供相應資料，提高下次計劃的準確性。

　　2、專案質量

　　專案的最終交付物與客戶實際需求的符合度。需要注意的是“客戶”，他可以是一般意義上的外部客戶，也可以指內部的客戶。專案質量管理不但包括對專案本身的質量管理，也包括對專案生產的產品進行的質量管理。具體可以從質量計劃、質量控制、質量保證入手，以保證專案質量的持續改進。具體可以採用ISO9000質量保證體系，加上完善的質量管理工具、圖表等輔助工具加以統計分析，得出改進建議。

　　3、專案成本

　　就計劃成本、實際成本對比成本構成明細的差距和原因分析及建議，也包括專案合同款執行情況的分析總結。IT專案經理一般可控制的成本主要是人工費，對於未建立專案級核算的組織，可以用加權人天數表示，對不同級別的人員（專案經理、高階工程師、一般工程師）賦予不同的權重。

　　4、專案風險

　　就風險識別、風險分析和風險應對中的經驗和教訓進行總結，包括專案中事先識別的風險和沒有預料到而發生的風險等風險的應對措施的分析和總結。也可以包括專案中發生的變更和專案中發生問題的分析統計的總結。

　　5、專案資源

　　專案資源不但包括人力資源情況，而且還包括裝置、材料等其它資源的合理使用、開發情況。特別是專案成員的績效統計分析和評價，以便更加有效地開發和利用人力資源。通常，可以採用直觀的圖表形式來反映專案的資源情況。

　　6、專案範圍

　　專案範圍包括產品範圍和專案範圍。其中，產品範圍定義了產品或服務所包含的特性和功能；專案範圍定義了為交付具有規定特性和功能的產品或服務所必須完成的工作。合同中所規定的產品範圍和專案範圍以及使用者確認的計劃等都屬於專案中要控制的範疇，另外還包括實際執行情況的差距和原因分析。

　　7、專案溝通

　　溝通是人員、技術、資訊之間的關鍵紐帶，是專案成功所必須的。在國內，不少專案經理對溝通不夠重視，或者不知如何做好專案中的溝通工作，這都需要各級專案管理人員對其加以重視。在專案總結時，可以就專案過程中的內部、外部溝通交流是否充分，以及因為溝通而對專案產生的影響等方面進行總結。

　　8、專案採購

　　國內IT專案的專案經理一般對專案採購接觸不多或接觸不到，多由商務和財務部門負責。如果是專案級的核算，採購管理是很重要的組成部分，否則可能因採購過程中的成本、風險、進度、技術和資源等方面引起很多問題。

　　9、專案文件

　　專案文件，包括硬拷貝文件和電子文件，都應該收集、整理、編制、控制和移交，以便統一歸檔儲存和進一步開發利用。文件是過程的蹤跡，它提供專案執行過程的客觀證據，同時也是對專案有效實施的真實記錄。專案文件記錄了專案實施軌跡，承載了專案實施及更改過程，併為專案交接與維護提供便利。此外，專案文件還是專案實施和管理的工具，用來理清工作條理、檢查工作完成情況，提高專案工作效率。所以每個專案都應建立文件管理體系，並做到製作及時、歸檔及時，同時文件資訊要真實有效，文件格式和填寫必須規範，符合標準。

　　10、專案評價

　　專案評價是對專案交付物的生產率，產品質量，採用的新技術、新方法、專案特點等的總結。另外還應該包括專案客戶滿意度收集統計和分析。客戶滿意度調查內容不但包括專案管理或流程層面，也應包括技術層面。同時，有必要說明本專案與以往專案相比的特別之處。例如：特殊的需求、特殊的環境、資源供應、新技術新工藝等，總之是具有挑戰性的、獨特的事件以及關鍵的解決方案和實施過程。

　　11、遺留亟待解決問題

　　說明專案有無遺留亟待解決問題。如果有，必須針對這些問題進行深入分析，明確責任，提出解決方案。

　　12、經驗教訓及建議

　　不斷將實施過的專案中的技術經驗、管理經驗以及教訓等進行總結，積累起來就可以成為公司的財富。

　　在上面的案例中，Paul總結出的專案總結模板和專案總結流程在A公司的推廣和使用，在加上公司領導層的重視，以前A公司專案中重複發生的問題得到了有效的控制。

　　以上是專案總結時應該包括或者應該注意的幾個方面。總之，專案總結應該根據不同的彙報物件，提供有針對性的內容。因為不同的報告閱讀者需求不一樣。例如，像公司級專案主管領導，他可能只關注專案收款及影響收款進度的原因、專案驗收計劃、專案中的重大事故或問題。技術經理可能更關心專案中新技術、新流程、新工藝的採用情況及效果。質量經理可能更重視專案的質量控制、變更、風險、問題報告。專案經理應該儘可能要求專案團隊所有成員提交專案總結報告，因為每個人都會根據自己的知識、經驗和能力，就所承擔的不同工作、不同專案階段，提出不同的問題和建議，這樣能夠從不同側面來總結專案，更好地為下一階段或以後的專案提供有意義的參考。

　　最後，需要強調的是，專案總結不能報喜不報憂，特別是對於失敗的專案，總結會不應該成為批鬥會，要堅持對事不對人的原則。這樣專案總結才能夠順利開展，並對今後工作有指導意義。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7942439/viewspace-21372/，如需轉載，請註明出處，否則將追究法律責任。