成任务。
出现概率：低
影响程度：高
处理建议：如果进度改变不可避免，必须重新制定详细计划，并利用非工作时间加班或增加人手来缩短工期，如无论如何都无法完成需事先向需求方说明，并将项目拆分，先尽量完成表现部分保证上线要求。
8、人员变动风险：项目组成员流动比较频繁，交接不顺利或管理不到位，造成项目的进度和质量受到影响。
出现概率：中
影响程度：中
处理建议：完善文档管理制度，所有重要岗位备有相应的替换人员，同时考虑采用一些快速开发工具，尽量减少纯手写代码，严格要求注释格式，增强可读性。
9、团队配合风险：开发团队内部或多个开发团队之间沟通不够，导致程序员对系统设计的理解上有偏差。
出现概率：低
影响程度：中
处理建议：实施方各个开发团队都应有科学的管理方式，并在实施前做好相关约定，确保统一认识。
10、备份风险：没有有效的系统备份方案，遇到硬件瘫痪等严重故障后无法重建系统或造成重要数据丢失。
出现概率：低
影响程度：高
处理建议：实施者在开发系统时应及时备份并事先准备应急预案。
11、测试计划风险：没有切实可行的测试计划，导致测试的功能点不全，有些潜在的问题没参在测试阶段及时发现。
出现概率：低
影响程度：低
处理建议：业主与实施者应配合建立详细的测试计划，将技术测试和业务测试分开，责任到人，并严格按照问题修改机制操作。
12、测试人员经验风险：没有专业的测试人员或测试人员对业务不熟悉，测试经验不足。
出现概率：低
影响程度：低
处理建议：参与测试的人员应具备相关知识和经验，大的项目可以请专业的测试机构进行测评。
D、收尾阶段
1、质量风险：编码结束后总体或部分系统质量差，如速度慢，易用性差等。
出现概率：低
影响程度：高
处理建议：实施管理者要分阶段严格控制代码规范性，逐步测试，必要时引入专业分析工具定位造成质量问题的代码位置并安排修正。
2、使用者不满意风险：业主方有时并不是最终的使用者，当系统基本完成后相关使用者对系统不满意造成需求变更。
出现概率：中
影响程度：高
处理建议：业主应在项目的各阶段组织使用者参与意见，边测试边改进，不要在系统接近完成时再征求使用者的意见。
3、采购风险：由于政府采购需要一定的时间周期，当系统需要上线时必需的设备或系统软件没有按时到货。
出现概率：低
影响程度：低
处理建议：业主方要按照相关规定及时安排采购提前量，尤其是需要走公开招标流程的，必须提前足够长的时间启动招标工作。
4、产出过低风险：未达到预期的投入产出效果，包括社会影响等。
出现概率：低
影响程度：低
处理建议：通常电子政务项目缺乏必要的投入产出评估，但作为业主应该有相应的考量，除了对系统本身不断完善外，相关的商务、推广等工作也要全面配合，以获得最大收益。
E、运维风险
1、大流量风险：面向公众的服务很难评估实际访问量，过高估计会造成投资浪费，过低估计，系统将无法承受，造成访问速度慢甚至宕机。
出现概率：低
影响程度：高
处理建议：设计时要充分考虑，软件系统要支持分布式布署，并准备好足够的硬件备机，当出现过高流量时立即启用负载均衡方案、高速缓存方案等高可用解决方案。
2、系统应用安全风险：任何系统都无法保证不存在任何漏洞，尤其是通过互联网访问的系统。
出现概率：中
影响程度：中
处理建议：重要的系统可以采用限制使用者IP地址或通过数字证书认证等方式加强访问的安全性。
3、客服支持能力风险：如果是面向公众的应用系统，由于受众太多，业主方很难安排足够多的客服人员解决所有的与系统相关的咨询和建议。
出现概率：低
影响程度：低
处理建议：采用外包的方式与呼叫中心等专业机构合作，设立足够多的客服座席，配合知识库，尽量减少业主方的客服压力。
4、客服人员素质风险：由于客服人员对系统了解的程度或服务态度等问题影响运维质量。
出现概率：低
影响程度：低
处理建议：需要对客服人员进行有针对性的系统相关知训培训，并严格管理制度，杜绝态度问题。
由于笔者经验有限，暂时只总结了这些常见的电子政务项目风险，供大家在实际工作中参考，希望各位读者批评指正。转贴于：http://www.leadge.com