在 2009 年 3 月， 我參與了 “蘇州工業(yè)園區(qū)企業(yè)綜合信息管理應用平臺” 項目的建設。 在項目中擔任項目經理職務。 整個項目以園區(qū)管委會信息中心為依托， 面向園區(qū)管委會所有 部門和園區(qū)各垂直管理的條線部門（如：工商、質監(jiān)、國稅、地稅、公安、海關等）以及所 有的園區(qū)企業(yè)。該項目分為二個階段：第一階段，將園區(qū)各條線部門和園區(qū)管委會內部部門的企業(yè)信息根據統(tǒng)一的業(yè)務主鍵和采集規(guī)則進行采集合并從而建立一個全面的、 準確的園區(qū)企業(yè)綜合信息庫；第二階段，在園區(qū)企業(yè)綜合信息庫的基礎上，將現(xiàn)有的“園區(qū)企業(yè)網上服務系統(tǒng)”改造成“園區(qū)政企交互平臺” 。本文結合了我的經驗就項目的風險管理作了翔實的論述，包括風險管理計劃編制、風險識別、風險分析、風險應對、風險監(jiān)控等過程；以及風險識別技術：如頭腦風暴法，風險檢查表，借鑒風險歷史數(shù)據庫的方法；風險分析技術：如風險概率和影響評估、決策樹分 析等。此外，本文也討論了在該項目中針對風險管理的不足而做出的彌補措施。

 

由于以前蘇州工業(yè)園區(qū)管委會內部部門和外部垂直管理的條線部門都是獨立進行信息化應用系統(tǒng)的規(guī)化、設計及實施，相互之間缺少協(xié)調和溝通，比如，很多部門根據自身的 業(yè)務需要，都建有自己的企業(yè)信息庫，企業(yè)信息大都由各部門自行創(chuàng)建和維護，數(shù)據庫重復 建設，相互之間沒有共享。很多部門由于缺乏企業(yè)信息的有效獲取和維護手段，往往數(shù)據初始化和創(chuàng)建時還相對比較準確，隨著社會的發(fā)展，企業(yè)的變更、注銷信息大多沒有及時更新， 導致數(shù)據越來越差，園區(qū)內、外各業(yè)務部門迫切需要一套準確、規(guī)范、更新及時的企業(yè)綜合 信息數(shù)據庫來滿足業(yè)務工作要求；另外，園區(qū)企業(yè)網上服務系統(tǒng)是在2002年開發(fā)實施的， 隨著企業(yè)網上服務業(yè)務的推進和發(fā)展，園區(qū)企業(yè)網上服務系統(tǒng)在許多業(yè)務流程和政企互動方 面已經顯的落后， 園區(qū)管委會的領導也希望通過在新的園區(qū)企業(yè)綜合信息庫基礎上，將老系統(tǒng)進行翻新，加了更多的政企互動的元素，讓政府與企業(yè)能夠更好的溝通、交流和發(fā)展。 因為該項目的項目干系人多、業(yè)務涉及面廣、需協(xié)調的部門多、軟件接口多、各部 門提供的數(shù)據格式多樣化，數(shù)據范圍和數(shù)據值不統(tǒng)一。

在這種情況下，項目面臨的風險之大 是可想而知的。 項目風險是一種不確定事件或條件，一旦發(fā)生，會對項目目標產生某種正面或負面 的影響。風險有其成因，同時，如果風險發(fā)生，也導致某種后果。當事件、活動或項目有損 失或收益與之相聯(lián)系，涉及到某種或然性或不確定性和涉及到某種選擇時，才稱為有風險。 以上三條，每一個都是風險定義的必要條件，不是充分條件。具有不確定性的事件不一定是風險。 項目風險管理就是要爭取避免風險的發(fā)生或盡量減小風險發(fā)生后的影響。 項目風險管理實際上就是貫穿在項目開發(fā)過程中的一系列管理步驟：制定風險管理計劃、風險識別、風定性分析、風險定量分析、制定風險應對策略、風險跟蹤與監(jiān)控。

綜合來看，該項目有四個特點：⑴項目干系人多，業(yè)務涉及面廣。工業(yè)園區(qū)企業(yè)綜合 信息管理應用平臺是面向園區(qū)管委會所有部門和園區(qū)各垂直管理的條線部門（如：工商、質 監(jiān)、國稅、地稅、公安、海關等）以及所有的園區(qū)企業(yè)。項目涉及面廣、用戶量大。需要調研各垂直管理的條線部門他們各自能夠共享的企業(yè)信息以及希望獲取的企業(yè)信息。 政企交互平臺集政府通告、企業(yè)活動報名、企業(yè)問卷調查、政企互動、信息薈萃、企業(yè)用戶管理、企業(yè)基礎信息數(shù)據權限、應用系統(tǒng)管理以及統(tǒng)一身份認證(SSO)于一體，涉及到政企交互的方方面面；⑵需求不確定，一直在變；⑶參與人員少，時間太短，前后僅有6個月的時間； ⑷采用了 Framework3.5 架構、Sql Server2008 大型數(shù)據庫、FusionCharts 圖表、指數(shù)平滑法預測和 Reporting Services報表等先進的技術，工作難度大。盡管如此，但在大家的共同努力下，基本按時完成了項目。那么我們是如何克服的呢？

首先，識別項目風險，編制風險管理計劃和風險應對計劃。

風險的類型包括項目風險、技術風險、管理風險。 項目風險主要是該項目需求不明確， 而且變更頻繁， 屬于新業(yè)務， 客戶和我們都沒有絕對的把握。 技術風險主要是采用了時下流行的 Framework3.5 架構、 Sql Server2008 大型數(shù)據庫、 FusionCharts 圖表、 指數(shù)平滑法預測和 Reporting Services 報表, 因為人員少，每個人兼多個角色，不過，幸運的是可以復用別的項目一部分源代碼，如數(shù)據庫操作類、權限管理類等。管理風險主要體現(xiàn)在人員分布在三地辦公，無疑增加了溝通的難度，不過我之前擔任過多個項目的項目經理，所以項目管理工作經驗還是比較足的。所以項目一啟動，在基本了解客戶需求的情況下，我就召集開發(fā)人員、銷售人員、公司領導，甚至有項目組人員坐到一起，采用“頭腦風暴法” ，大家都來分析該項目存在的風險，同時借鑒歷史數(shù)據庫中的風險數(shù)據，取出我們沒想到而確實存在的風險條目， 也添加到風險列表里， 然后分析每個風險條目發(fā)生的概率、風險級別，而且針對該風險條目制定的應對措施，并形成一個風險記錄表。風險管理貫穿項目的始終，風險管理計劃和風險應對計劃缺一不可。因為風險一直在變，所以在項目的每個階段都在更新。

其次，制定項目管理計劃，化解開發(fā)進度的風險。

該項目時間實在太短，僅有六個月 時間。 作為項目經理， 我的壓力非常大， 所以我做開發(fā)進度計劃的時候， 根據最終交付日期， 采取倒推法，將時間逐一分配到各個任務上，同時盡量考慮到任務的并發(fā)執(zhí)行，而且要細化到小時，我使用 MS Project2007 軟件，利用PERT 技術，在工作分解結構（WBS）上定義每個任務的開始時間、結束時間，識別關鍵路徑（CPM） ，然后從甘特圖就能自動顯示人力資源狀態(tài)圖，能自動統(tǒng)計每個人每個任務或者每個時間段的工作量，而且通過這個軟件，可以非常方便的拆分任務，定義里程碑事件等。 接著，進行軟件需求管理，降低項目范圍的風險。在和客戶的初步溝通中，確定了需求的大致范圍，定下了 12 個模塊，然后就針對每個模塊討論實現(xiàn)的功能、數(shù)據的流向、模 塊之間的接口等。 因為有些業(yè)務包括客戶在內都不在清楚，所以在需求討論的時候經常很難達成一致共識。于是，我使用了 WORD 版本控制的功能，幾易其稿，需求基本趨向一致。形成了軟件功能規(guī)格說明書，確定了產品范圍，雙方簽字確認。然后，我用 Excel 做了一個軟件需求跟蹤矩陣，實際為一個二維表，每行就是一個功能，而且是按層次分解的，每列是一個階段，從需求定義階段開始，到設計、編碼、測試、交付、維護等階段。在每個階段結束 時都來更新這個需求矩陣，主要是更新每個任務的狀態(tài)（如已批準、已實現(xiàn)、已確認、已刪 除等） ，如果功能點的變化，可以在上面增加或者修改、刪除該功能點，管理起來非常有效 和方便。另外，我們采用原型開發(fā)模式，主要分為兩個階段迭代。我將需求按優(yōu)先級排序， 先完成客戶最想要的功能,在整個開發(fā)過程中我都跟項目組成員灌輸敏捷開發(fā)的思想：個體 和交互勝過過程和工具，可以工作的軟件勝過面面俱到的文檔，客戶合作勝過合同談判，響 應變化勝過遵循計劃。

再次, 制定溝通計劃，解決項目溝通的風險。

在該項目中，開發(fā)人員、公司領 導、銷售人員、客戶分別在三個地區(qū)，溝通不太方便?；镜耐ㄐ攀强?Email 聯(lián)系，大家約 定都用 Outlook Express 收發(fā)郵件（設定每 3 分鐘檢測一次） ，因為同一個郵件，回復次數(shù)往往比較多，使用同樣的郵件軟件，查閱比較方便，跟綜起來也容易。而且，郵件溝通有個非常大的好處是溝通的內容都落實在紙面上，便于將來分清責任。其次，是電話聯(lián)系、電話溝通可能就比較直接，尤其是和客戶溝通，效果可能更好。此處，我還建了一個項目組的QQ 群，只要項目成員一有問題，都可以在 QQ 群里及時溝通，增強了溝通的時效性和項目組成員之間的互動性。 我經常把開發(fā)進度表打印出來貼在每個開發(fā)人員的桌面上，讓開發(fā)人員 “心中有數(shù)” ，增強緊迫感。而需要眾人一起討論的問題，則放到每周項目例會上討論，較 緊急的問題召開臨時性會議。 通過以上方法， 基本實現(xiàn)了有關各方及項目組內部的有效溝通， 及時發(fā)現(xiàn)問題、解決問題，避免因各方立場不一致造成嚴重對立而影響項目進度，避免了因 交流不暢形式重大質量問題。

現(xiàn)在回顧這個項目，我們是在一個周密的開發(fā)計劃下，在非常短的時間、非常有限的 人力資源的情況下，一一化解了項目的風險，按時完成了項目，客戶很滿意，也得到了我們 公司管理層的高度評價。我想，這歸功于整個團隊的配合。作為項目經理，我也充分的利用 了各種項目管理工具（軟件）在風險監(jiān)控、進度把握、需求跟蹤等各方面的作用。

雖然基本按時完成任務，但也有很多不足之處：

第一，因為工期緊，開發(fā)人員少，所 以經常加班，大家非常的疲憊，而且加班費很少。我也采取了一些彌補措施，如請示管理層 在精神方面做了一些鼓勵和表揚，適當?shù)某鋈ゾ鄄?、看電影、參加健身運動，一定程度上緩 解了緊張的氛圍，而且大家也沒有太多的怨言，否則就要另當別論了。

第二，測試的時間太短，在性能測試這方面沒有專業(yè)的測試人員，沒有全面而系統(tǒng)的測試，所以系統(tǒng)交付之后， 發(fā)現(xiàn)了不少問題，雖然沒有威脅到系統(tǒng)的運行，但作為項目經理，我覺得如果多給一些時間 和人員，我們會做的更好。后來，該系統(tǒng)在別的客戶現(xiàn)場實施時，我們做了多方面的改進， 系統(tǒng)也更趨于完美了；在以后的工作中，我還需要不斷的學習，總結經驗和教訓，為我國電子信息化事業(yè)盡一份綿薄之力。