1、電子政務項目風險管理風險管理是項目管理中非常重要的環節。電子政務項目由于受到政府預算體系、領導個人意志、層層審批決策機制以及實施方對政府業務特點把握能力等多種客觀因素的影響，風險種類更多，如果不能很好地進行管理，會對整個項目的進展造成嚴重影響，甚至導致項目失敗。筆者作為電子政務項目業主方的管理人員，經過長時間的實踐積累和經驗總結，將電子政務項目中常見的風險和相應對策歸納如下：一、非系統風險所謂非系統風險，主要是指一些與項目本身無關，但又會直接影響到項目實施效果的客觀因素造成的風險，其作用范圍為項目全過程。充分地認識和正確地處理非系統風險經常是電子政務項目最終成功的關鍵。電子政務項目中的非系統風

2、險主要包括如下幾類：1、政策風險：中央政府或地方政府頒發了與為項目提供支持依據的條文產生全部或部分沖突的法規、文件或者為項目提供支持依據的條文失效。出現概率：低影響程度：小處理建議：工期較長的項目有可能遇到此類風險，由于通常情況下要遵循地方服從中央、局部服從整體的政策原則，因此遇到政策改變時要及時報請業主部門進行決策，盡量爭取將項目納入政策允許的例外范圍，特事特辦。2、領導決策風險：由于政府是層層決策機制，很難在一開始就得到高層領導的指示，而每一級領導通常都會有自己的看法，經常出現項目實施已接近完成，卻被主管領導一票否決的情況。出現概率：高影響程度：大處理建議：高層領導考慮的多是戰略層面的問題

3、，基層領導考慮的多是細節層面的問題，通常難以統一，想讓需求一次性確定基本是不可能的。因此在做方案的時候要盡量使架構靈活，可擴充性強。軟件開發盡可能采用構件或模塊方式，增強重用性，最大限度適應需求頻繁變更。在正式實施前多通過靜態原型等手段匯報溝通，充分了解各級領導的偏好后再確定方案。另外正式實施前要多請示，階段工作要常匯報，在讓上級領導決策前要盡量說明前期已完成工作，并預先指出哪些變更會對項目產生顛覆性的影響，以免領導在未做詳細了解的情況下主觀表態。3、其它部門干預風險：系統設計時未充分考慮外部因素，實施過程中受到其它強力政府部門以不符合某方面規劃等理由對系統提出較大幅度的更改要求。影響程度：大

4、處理建議：建設前期盡量與各主管部門及所有可能涉及到的業務部門加強溝通，全面征求意見，事先取得支持，同時在技術實現上盡可能采用開放標準和可擴展的架構。4、既得利益風險：需要多部門配合的系統可能會涉及到某個或某幾個部門的既得利益，在建設和推廣過程中受到阻撓。出現概率：高影響程度：大處理建議：一方面要與相關部門的主管領導溝通爭取得到支持，另一方面要想辦法盡量減低對各部門既得利益的損傷，并與所有的既得利益者商議如何通過新系統獲得新的利益均衡，必要時需要請監察局等部門進行協調或報請更高層的領導批示。5、戰略改變風險：主管部門發展戰略改變，不再需要建設該系統。出現概率：低影響程度：大處理建議：通常只有大的

5、人事變動或者大的政策變化才會影響到一個部門的整體戰略，因此要經常與主管部門溝通，保持與各相關部門尤其是規劃部門的密切聯系，確保項目目標與部門戰略的長期一致性，如果無法避免戰略變更，應通過多層面溝通，爭取在制定新戰略時優先考慮加入與項目相關的戰略內容。6、管理風險：政府部門的項目管理人員管理經驗不足，對項目控制力度不夠或控制過度。出現概率：高影響程度：大處理建議：項目承擔者需要經常與業主方項目管理者溝通，除了項目內容之外，還要包括項目管理知識等周邊內容，同時要注意工作細節，有隱患時應主動提示業主，增強業主的信任度，確保業主的必要協調力度，避免業主不必要的干預。7、進度風險：不能在預期的時間范圍內

6、完成任務。出現概率：中影響程度：中處理建議：要盡量將項目切塊，分清輕重緩急，通常高層領導主要關注表現層，要確保表現穩定準確，其它部分可以放在后期實現，由于需求變化的不可控性，項目超期不能結束的情況較多，因此更需要嚴格控制實施方的計劃，強化管理，根據實際情況采取并行實施或加班等方式保證領導要求或文件規定的上線工期，將一些不可見的隱蔽工程放在上線后實施。8、成本風險：項目投入超出預算范圍。出現概率：中影響程度：中處理建議：一方面要控制需求，另一方面要優化開發方式或創新管理，盡量減低人工成本。如果確因客觀原因造成超預算，應與業主協商，從其它經費中協調，或追加預算。9、法律風險：合作雙方在許可權、專利

7、、合同失效、訴訟等情況發生。出現概率：低影響程度：低處理建議：很多電子政務工程在協議中會約定知識產權歸甲方所有，但是政府本身又不可能通過銷售已建系統盈利，因此至少應保證產權共有，雙方在簽定合同時應仔細審核合同條文，明確責權，本著互利和推動產業發展的原則制定條款，不宜生搬硬套。10、不可抗力發生：自然災害、電信故障等不可抗力發生。出現概率：低影響程度：高處理建議：天災人禍純屬意外，如果是重要系統，應盡可能建議業主設立異地容災中心，以確保安全。二、系統風險所謂系統風險，指的是與項目本身相關的人或事物對項目造成的影響而產生的風險。在項目的不同階段面臨的風險是不同的。系統風險可能是由于業主的原因造成的

8、，也有可能是由于實施方的原因造成的，不管怎樣，問題都需要雙方鼎力配合才能得到妥善解決。A、初始階段1、目標風險：業主或實施方對項目目標不清晰，沒有明確、實際的目標描述。出現概率：低影響程度：高處理建議：業主和實施方要組織專題論證會，明確項目目標，并確定考核目標實現的方法。2、范圍風險：業主未明確項目范圍，需求外延不斷變化。出現概率：高影響程度：中處理建議：由于業主通常不是專業人士，同時電子政務的很多項目都沒有可參照樣板，因此很容易出現項目范圍不明確的情況，實施方需要幫助業主完成對項目范圍的界定，并在實施過程中控制范圍，超出部分建議業主分期實現。3、溝通風險：實施方缺乏與業主溝通或業主難于溝通造

9、成理解偏差。出現概率：高影響程度：中處理建議：實施方要主動加強與業主溝通，要嘗試通過會議、電子郵件、聊天工具等多種途徑進行溝通。同時要學會換位思考，多從業主角度出發考慮問題。4、業務了解風險：實施方需求分析人員同于知識缺陷，無法全面理解相關業務。出現概率：中影響程度：高處理建議：實施方的需求人員要安排足夠多的時間加強對與需求相關的業務了解避免無法理解需求的真實含義。可以引入可視化輔助工具盡量使雙方的表達一致5、需求理解風險：實施人員沒有對需求仔細研究，出現誤解需求或部分理解需求等情況。出現概率：中影響程度：中處理建議：實施方項目管理人員應組織所有參與人員集中討論需求，并取得一致理解，通過靜態原

10、型等方式加強相互理解。6、可行性風險：由于時間倉促等原因，實施方案沒有進行可行性研究。出現概率：中影響程度：高處理建議：重要項目應請專業的機構和人員進行可行性分析，并出具相關報告。因為技術并不是萬能的，一定要界定好技術實現的時間與資金等前提條件。7、細節需求頻繁變更風險：業主不斷變化需求細節，積少成多，產生很多額外工作量。出現概率：高影響程度：中處理建議：實施方要科學控制需求變更，通過項目組集體決策的方式確定變更，除了嚴重影響使用外，細節變更要批量修改，不要一事一改。8、需求變更缺乏管理風險：業主缺少有效的需求變化管理。出現概率：中影響程度：中處理建議：實施方協助業主加強對需求變更的管理，責任

11、到人，簽字確認。9、文檔管理風險：實施方缺乏有效的文檔管理體系。出現概率：高影響程度：低處理建議：應建立嚴格的文檔管理制度，包含對錯誤的管理，建立完善的錯誤追蹤管理系統。10、需求變更缺乏分析風險：實施方對需求的變化缺少象原始需求一樣的分析過程。出現概率：高影響程度：低處理建議：實施管理者要對所有需求的變更與原始需求一樣重視，要逐條進行詳細分析，確定對原設計的影響，全面變更實施計劃后再進行變更實施。B、設計階段1、項目團隊經驗風險：實施方項目隊伍缺乏經驗，或缺乏有經驗的核心技術人員。出現概率：中影響程度：高處理建議：業主加強對開發團隊的審核，包括團隊合作、組成人員資質和經驗等。2、實施者自行變

12、更風險：實施者根據自己的經驗或考慮自身成本利益等原因在未得到業主允許的情況下私自變更需求或需求的實現方式。出現概率：低影響程度：中處理建議：要明確約定實施者不得隨意變更用戶需求，如需變更需得到需求者認可方可實施。3、計劃風險：倉促計劃，盲目制定工期，造成進度無法按計劃控制。出現概率：低影響程度：中處理建議：科學制定詳細的開發計劃，并經過共同論證后再嚴格實施4、漏項風險：由于設計人員的疏忽某個功能沒有考慮進去。出現概率：低影響程度：中處理建議：設計后需要多方復核，仔細對比需求說明書與設計說明書的各相關項C、實施階段1、開發環境風險：開發軟件環境沒有準備好或與實際環境不同，導致產品無法裝載到運行環

13、境。出現概率：低影響程度：低處理建議：需要雙方技術人員共同確認環境的一致性，要精確到產品的版本號及補丁情況。2、整合風險：所實施的項目中涉及對舊有異構數據和系統的整合。出現概率：中影響程度：低處理建議：在實施前應做充分調查，了解相關系統的所有技術細節，采用比較成熟和穩定的整合方案，并制定接口規范，規劃時盡量減少新系統的異構。3、布署風險：運行環境和產品開發環境差異，尤其是開發機器與服務器硬件配置差異等原因造成布署困難。出現概率：低影響程度：低處理建議：盡量保證開發時使用與最終布署環境相同的硬件條件，如果布署環境硬件條件過高則應事先與廠商了解硬件相關特性，確保布署可能性。4、設計風險：由于系統設

14、計錯誤帶來實施困難。影響程度：高處理建議：系統設計方案完成后，需要業主方組織成立技術專家組共同確認設計方案，及時發現設計漏洞。5、人員能力風險：程序員開發能力差，或程序員對開發工具不熟。出現概率：高影響程度：低處理建議：所有的項目組成員要做預先業務能力審核，如遇更替人員也要進行相應的審核，確保人員具備足夠的業務能力。6、項目范圍改變風險：已經開始實施后用戶突然要增加或變更一些結構性的功能，需要重新考慮架構設計。出現概率：低影響程度：高處理建議：架構設計盡量靈活，采用構件開發等方式增加應變能力，同時要加強前期的靜態原型細度并將可能存在的問題及時提交給業主，避免實施過程中發生結構性修改。7、項目進

15、度改變風險：由于特殊事件或得到上級領導指示，業主方要求提前完成任務。影響程度：高處理建議：如果進度改變不可避免，必須重新制定詳細計劃，并利用非工作時間加班或增加人手來縮短工期，如無論如何都無法完成需事先向需求方說明，并將項目拆分，先盡量完成表現部分保證上線要求。8、人員變動風險：項目組成員流動比較頻繁，交接不順利或管理不到位，造成項目的進度和質量受到影響。出現概率：中影響程度：中處理建議：完善文檔管理制度，所有重要崗位備有相應的替換人員，同時考慮采用一些快速開發工具，盡量減少純手寫代碼，嚴格要求注釋格式，增強可讀性。9、團隊配合風險：開發團隊內部或多個開發團隊之間溝通不夠，導致程序員對系統設計

16、的理解上有偏差。出現概率：低影響程度：中處理建議：實施方各個開發團隊都應有科學的管理方式，并在實施前做好相關約定，確保統一認識。10、備份風險：沒有有效的系統備份方案，遇到硬件癱瘓等嚴重故障后無法重建系統或造成重要數據丟失。出現概率：低影響程度：高處理建議：實施者在開發系統時應及時備份并事先準備應急預案。11、測試計劃風險：沒有切實可行的測試計劃，導致測試的功能點不全，有些潛在的問題沒參在測試階段及時發現。出現概率：低影響程度：低處理建議：業主與實施者應配合建立詳細的測試計劃，將技術測試和業務測試分開，責任到人，并嚴格按照問題修改機制操作。12、測試人員經驗風險：沒有專業的測試人員或測試人員對

17、業務不熟悉，測試經驗不足。出現概率：低影響程度：低處理建議：參與測試的人員應具備相關知識和經驗，大的項目可以請專業的測試機構進行測評。D、收尾階段1、質量風險：編碼結束后總體或部分系統質量差，如速度慢，易用性差等。出現概率：低影響程度：高處理建議：實施管理者要分階段嚴格控制代碼規范性，逐步測試，必要時引入專業分析工具定位造成質量問題的代碼位置并安排修正。2、使用者不滿意風險：業主方有時并不是最終的使用者，當系統基本完成后相關使用者對系統不滿意造成需求變更。出現概率：中影響程度：高處理建議：業主應在項目的各階段組織使用者參與意見，邊測試邊改進，不要在系統接近完成時再征求使用者的意見。3、采購風險

18、：由于政府采購需要一定的時間周期，當系統需要上線時必需的設備或系統軟件沒有按時到貨。出現概率：低影響程度：低處理建議：業主方要按照相關規定及時安排采購提前量，尤其是需要走公開招標流程的，必須提前足夠長的時間啟動招標工作。4、產出過低風險：未達到預期的投入產出效果，包括社會影響等。出現概率：低影響程度：低處理建議：通常電子政務項目缺乏必要的投入產出評估，但作為業主應該有相應的考量，除了對系統本身不斷完善外，相關的商務、推廣等工作也要全面配合，以獲得最大收益。E、運維風險1、大流量風險：面向公眾的服務很難評估實際訪問量，過高估計會造成投資浪費，過低估計，系統將無法承受，造成訪問速度慢甚至宕機。出現概率：低影響程度：高處理建議：設計時要充分考慮，軟件系統要支持分布式布署，并準備好足夠的硬件備機，當出現過高流量時立即啟用負載均衡方案、高速緩存方案等高可用解決方案。2、系統應用安全風險：任何系統都無法保證不存在任何漏洞，尤其是通過互聯網訪問的系統。出現概率：中處理建議：重要的系統可以采用限制使用者IP地址或通過數字證