电子政务项目风险管理（上）
生活随笔
收集整理的這篇文章主要介紹了
电子政务项目风险管理（上）
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
風險管理是項目管理中非常重要的環節。電子政務項目由于受到政府預算體系、領導個人意志、層層審批決策機制以及實施方對政府業務特點把握能力等多種客觀因素的影響，風險種類更多，如果不能很好地進行管理，會對整個項目的進展造成嚴重影響，甚至導致項目失敗。 筆者作為電子政務項目業主方的管理人員，經過長時間的實踐積累和經驗總結，將電子政務項目中常見的風險和相應對策歸納如下： 一、非系統風險<?XML:NAMESPACE PREFIX = O NS = "urn:schemas-microsoft-com:office:office" /> 所謂非系統風險，主要是指一些與項目本身無關，但又會直接影響到項目實施效果的客觀因素造成的風險，其作用范圍為項目全過程。充分地認識和正確地處理非系統風險經常是電子政務項目最終成功的關鍵。 電子政務項目中的非系統風險主要包括如下幾類： 1、政策風險：中央政府或地×××府頒發了與為項目提供支持依據的條文產生全部或部分沖突的法規、文件或者為項目提供支持依據的條文失效。 出現概率：低 影響程度：小 處理建議：工期較長的項目有可能遇到此類風險，由于通常情況下要遵循地方服從中央、局部服從整體的政策原則，因此遇到政策改變時要及時報請業主部門進行決策，盡量爭取將項目納入政策允許的例外范圍，特事特辦。 2、領導決策風險：由于政府是層層決策機制，很難在一開始就得到高層領導的指示，而每一級領導通常都會有自己的看法，經常出現項目實施已接近完成，卻被主管領導一票否決的情況。 出現概率：高 影響程度：大 處理建議：高層領導考慮的多是戰略層面的問題，基層領導考慮的多是細節層面的問題，通常難以統一，想讓需求一次性確定基本是不可能的。因此在做方案的時候要盡量使架構靈活，可擴充性強。軟件開發盡可能采用構件或模塊方式，增強重用性，最大限度適應需求頻繁變更。在正式實施前多通過靜態原型等手段匯報溝通，充分了解各級領導的偏好后再確定方案。另外正式實施前要多請示，階段工作要常匯報，在讓上級領導決策前要盡量說明前期已完成工作，并預先指出哪些變更會對項目產生顛覆性的影響，以免領導在未做詳細了解的情況下主觀表態。 3、其它部門干預風險：系統設計時未充分考慮外部因素，實施過程中受到其它強力政府部門以不符合某方面規劃等理由對系統提出較大幅度的更改要求。 出現概率：高 影響程度：大 處理建議：建設前期盡量與各主管部門及所有可能涉及到的業務部門加強溝通，全面征求意見，事先取得支持，同時在技術實現上盡可能采用開放標準和可擴展的架構。 4、既得利益風險：需要多部門配合的系統可能會涉及到某個或某幾個部門的既得利益，在建設和推廣過程中受到阻撓。 出現概率：高 影響程度：大 處理建議：一方面要與相關部門的主管領導溝通爭取得到支持，另一方面要想辦法盡量減低對各部門既得利益的損傷，并與所有的既得利益者商議如何通過新系統獲得新的利益均衡，必要時需要請監察局等部門進行協調或報請更高層的領導批示。 5、戰略改變風險：主管部門發展戰略改變，不再需要建設該系統。 出現概率：低 影響程度：大 處理建議：通常只有大的人事變動或者大的政策變化才會影響到一個部門的整體戰略，因此要經常與主管部門溝通，保持與各相關部門尤其是規劃部門的密切聯系，確保項目目標與部門戰略的長期一致性，如果無法避免戰略變更，應通過多層面溝通，爭取在制定新戰略時優先考慮加入與項目相關的戰略內容。 6、管理風險：政府部門的項目管理人員管理經驗不足，對項目控制力度不夠或控制過度。 出現概率：高 影響程度：大 處理建議：項目承擔者需要經常與業主方項目管理者溝通，除了項目內容之外，還要包括項目管理知識等周邊內容，同時要注意工作細節，有隱患時應主動提示業主，增強業主的信任度，確保業主的必要協調力度，避免業主不必要的干預。 7、進度風險：不能在預期的時間范圍內完成任務。 出現概率：中 影響程度：中 處理建議：要盡量將項目切塊，分清輕重緩急，通常高層領導主要關注表現層，要確保表現穩定準確，其它部分可以放在后期實現，由于需求變化的不可控性，項目超期不能結束的情況較多，因此更需要嚴格控制實施方的計劃，強化管理，根據實際情況采取并行實施或加班等方式保證領導要求或文件規定的上線工期，將一些不可見的隱蔽工程放在上線后實施。 8、成本風險：項目投入超出預算范圍。 出現概率：中 影響程度：中 處理建議：一方面要控制需求，另一方面要優化開發方式或創新管理，盡量減低人工成本。如果確因客觀原因造成超預算，應與業主協商，從其它經費中協調，或追加預算。 9、法律風險：合作雙方在許可權、專利、合同失效、訴訟等情況發生。 出現概率：低 影響程度：低 處理建議：很多電子政務工程在協議中會約定知識產權歸甲方所有，但是政府本身又不可能通過銷售已建系統盈利，因此至少應保證產權共有，雙方在簽定合同時應仔細審核合同條文，明確責權，本著互利和推動產業發展的原則制定條款，不宜生搬硬套。 10、不可抗力發生：自然災害、電信故障等不可抗力發生。 出現概率：低 影響程度：高 處理建議：天災人禍純屬意外，如果是重要系統，應盡可能建議業主設立異地容災中心，以確保安全。 二、系統風險 所謂系統風險，指的是與項目本身相關的人或事物對項目造成的影響而產生的風險。在項目的不同階段面臨的風險是不同的。系統風險可能是由于業主的原因造成的，也有可能是由于實施方的原因造成的，不管怎樣，問題都需要雙方鼎力配合才能得到妥善解決。 A、初始階段 1、目標風險：業主或實施方對項目目標不清晰，沒有明確、實際的目標描述。 出現概率：低 影響程度：高 處理建議：業主和實施方要組織專題論證會，明確項目目標，并確定考核目標實現的方法。 2、范圍風險：業主未明確項目范圍，需求外延不斷變化。 出現概率：高 影響程度：中 處理建議：由于業主通常不是專業人士，同時電子政務的很多項目都沒有可參照樣板，因此很容易出現項目范圍不明確的情況，實施方需要幫助業主完成對項目范圍的界定，并在實施過程中控制范圍，超出部分建議業主分期實現。 3、溝通風險：實施方缺乏與業主溝通或業主難于溝通造成理解偏差。 出現概率：高 影響程度：中 處理建議：實施方要主動加強與業主溝通，要嘗試通過會議、電子郵件、聊天工具等多種途徑進行溝通。同時要學會換位思考，多從業主角度出發考慮問題。 4、業務了解風險：實施方需求分析人員同于知識缺陷，無法全面理解相關業務。 出現概率：中 影響程度：高 處理建議：實施方的需求人員要安排足夠多的時間加強對與需求相關的業務了解，避免無法理解需求的真實含義。可以引入可視化輔助工具盡量使雙方的表達一致。 5、需求理解風險：實施人員沒有對需求仔細研究，出現誤解需求或部分理解需求等情況。 出現概率：中 影響程度：中 處理建議：實施方項目管理人員應組織所有參與人員集中討論需求，并取得一致理解，通過靜態原型等方式加強相互理解。 6、可行性風險：由于時間倉促等原因，實施方案沒有進行可行×××。 出現概率：中 影響程度：高 處理建議：重要項目應請專業的機構和人員進行可行性分析，并出具相關報告。因為技術并不是萬能的，一定要界定好技術實現的時間與資金等前提條件。 7、細節需求頻繁變更風險：業主不斷變化需求細節，積少成多，產生很多額外工作量。 出現概率：高 影響程度：中 處理建議：實施方要科學控制需求變更，通過項目組集體決策的方式確定變更，除了嚴重影響使用外，細節變更要批量修改，不要一事一改。 8、需求變更缺乏管理風險：業主缺少有效的需求變化管理。 出現概率：中 影響程度：中 處理建議：實施方協助業主加強對需求變更的管理，責任到人，簽字確認。 9、文檔管理風險：實施方缺乏有效的文檔管理體系。 出現概率：高 影響程度：低 處理建議：應建立嚴格的文檔管理制度，包含對錯誤的管理，建立完善的錯誤追蹤管理系統。 10、需求變更缺乏分析風險：實施方對需求的變化缺少象原始需求一樣的分析過程。 出現概率：高 影響程度：低 處理建議：實施管理者要對所有需求的變更與原始需求一樣重視，要逐條進行詳細分析，確定對原設計的影響，全面變更實施計劃后再進行變更實施。 B、設計階段 1、項目團隊經驗風險：實施方項目隊伍缺乏經驗，或缺乏有經驗的核心技術人員。 出現概率：中 影響程度：高 處理建議：業主加強對開發團隊的審核，包括團隊合作、組成人員資質和經驗等。 2、實施者自行變更風險：實施者根據自己的經驗或考慮自身成本利益等原因在未得到業主允許的情況下私自變更需求或需求的實現方式。 出現概率：低 影響程度：中 處理建議：要明確約定實施者不得隨意變更用戶需求，如需變更需得到需求者認可方可實施。 3、計劃風險：倉促計劃，盲目制定工期，造成進度無法按計劃控制。 出現概率：低 影響程度：中 處理建議：科學制定詳細的開發計劃，并經過共同論證后再嚴格實施。 4、漏項風險：由于設計人員的疏忽某個功能沒有考慮進去。 出現概率：低 影響程度：中 處理建議：設計后需要多方復核，仔細對比需求說明書與設計說明書的各相關項。 （未完待續） ?
?/*原創文章，轉載請注明出處，傳統媒體轉載須經作者授權*/
轉載于:https://blog.51cto.com/wangzhe/11035
總結
以上是生活随笔為你收集整理的电子政务项目风险管理（上）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： mysql 视图 分页_mysql查看所
- 下一篇： dotnet程序优化心得（三）