项目风险检查表.docx

膄风险严重性等级

螂参数羃等级节值莇描述

芆风险蚂很高聿5肅例如进度延误大于30 ％，或者费用超支大于30 ％

肃严重性膃比较高肃4薇例如进度延误20% － 30 ％，或者费用超支20% －

30％

肈中等芃 3膀例如进度延误低于20 ％，或者费用超支低于20 ％

例如进度延误低于10 ％，或者费用超支低于10 ％艿比较低袇 2

很低1例如进度延误低于5％，或者费用超支低于5％

风险可能性等级

参数等级值描述

风险很高5风险发生的几率为0.8 ～ 1.0

可能性比较高4风险发生的几率为0.6 ～ 0.8

中等3风险发生的几率为0.4 ～ 0.6

比较低2风险发生的几率为0.2 ～ 0.4

很低1风险发生的几率为0.0 ～ 0.2

风险系数等级

风险风险可能性

系数很高 5比较高 4中等3比较低 2很低 1风险很高5252015105

严重性较高420161284

中等31512963

比较低2108642

很低154321

本表灰色部分的风险系数为10 ～ 25 ，应当优先处理

风险检查表

商业风险

风险类型检查项

政治政府或者其它机构对本项目的开发有限制吗？

法律有不可预测的市场动荡吗？

市场有不利于我方的官司要打吗？

本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗？

竞争对手有不正当的竞争行为吗？

本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗？

客户

子承包商供应商是否在开很少有人真正需要却自以很好的品？

是否在开可能本的品？

客的需求是否含糊不清？

客是否反反复复地改需求？

客指定的需求和交付期限在客上可行？

客品的健壮性、可靠性、性能等量因素有非常分的要求？客的合作度友善？

与客的合同公正？双方互利？

客的信誉好？例如按客的需求开了品，但是客可能不。与子承包商、供商的合同公正？双方互利？

子承包商、供商的信誉好？

子承包商、供商有可能倒？

子承包商、供商能及交付量合格的品（或部件）？

子承包商、供商有能力做好售后服？

管理

型

目划目

上

行政部合作部

目的模、度估是否比正确？

人力源（开人、管理人）用？合格？

目所需的件、硬件能按到位？

目的用？

度安排是否于？有合理的冲？

度表中是否忘了一些重要的（必要的）任？

度安排是否考了关路径？

是否可能出某一工作延致其它一串的工作也被延？

任分配是否合理？（即把任分配合适的目成，充分其才能）是否了省，不采用（）成熟的件模，一切从零做起？

?

目成？是否存在矛盾？

是否大部分的目成工作真？

大部分的目成有工作情？

之中有“害群之” ？

技开伍中有工？

本目开程中是否会有核心人辞、？

是否能保“人流基本不会影响工作的性”？

目理是否忙于行政事而无暇及目的开工作？

本目是否得到上的重？

上是否随会抽本目的源用于其它“高先”的目？

上是否多地介入本目的事并且瞎指？

行政部门的办事效率是否比较底，以至于拖项目的后腿？

行政部门是否经常干一些无益于生产力的事情，以至于骚扰本项目？

机构是否能全面、公正地考核员工的工作业绩？

机构是否有较好的奖励和惩罚措施？

本项目的合作部门的态度积极吗？是否应付了事？或者做事与承诺的不一致？

技术风险

风险类型检查项

需求开发需求开发人员懂得如何获取用户需求吗？效率高吗？

需求管理需求开发人员懂得项目所涉及的具体业务吗？能否理解用户的需求？

需求文档能够正确地、完备地表达用户需求吗？

需求开发人员能否与客户对有争议的需求达成共识？

需求开发人员能否获得客户对需求文档的承诺？以保证客户不随便变更需求？

综合技术开发人员是否有开发相似产品的经验？

开发能力待开发的产品是否要与未曾证实的软硬件相连接？

包括设计对开发人员而言，本项目的技术难度高吗？

编程、测试等开发人员是否已经掌握了本项目的关键技术？

如果某项技术尚未实践过，开发人员能否在预定时间内掌握？

开发小组是否采用比较有效的分析、设计、编程、测试工具？

分析与设计工作是否过于简单、草率，从而让程序员边做边改？

开发小组采用统一的编程规范吗？

开发人员对测试工作重视吗？能保证测试的客观性吗？

项目有独立的测试人员吗？懂得如何进行高效率地测试吗？

是否对所有重要的工作成果进行了同行评审（正式评审或快速检查）？

开发人员懂得版本控制、变更控制吗？能够按照配置管理规范执行吗？

开发人员重视质量吗？是否会在进度延误时降低质量要求？

软件项目风险评估报告

本文主要针对软件开发涉及到的风险，包括在软件开发周期过程中可能出现的风险以及软件实施过程中外部环境的变化可能引起的风险等进行评估。在文中对所提到的风险都一一做了详细的分析，并提出了相应的风险回避措施。由于风险是在项目开始之后才开始对项目的开发起负面的影响，所以风险分析的不足，或是风险回避措施不得力，都很有可能造成软件开发的失败。风险分析是在事前的一种估计，凭借一定的技术手段和丰富的经验，基本能够对项目的风险做出比较准确的估计，经过慎重的考虑提出可行的风险回避措施，是避免损失的重要环节。 主要风险综述 任何软件的开发，其主要风险均来自于两个方面，一是软件管理，二是软件体系结构。软件产品的开发是工程技术与个人创作的有机结合。软件开发是人的集体智慧按照工程化的思想进行发挥的过程。软件管理是保证软件开发工程化的手段。软件体系结构的合理程度是取决于集体智慧发挥的程度和经验的运用。 软件管理将影响到软件的下列因素： 软件是否能够按工期的要求完成：软件的工期常常是制约软件质量的主要因素。很多情况下，软件开发商在工期的压力下，放弃文档的书写，组织，结果在工程的晚期，大量需要文档进行协调的工作时，致使软件进度越来越慢。软件的开发不同于其他的工程，在不同的工程阶段，需要的人员不同，需要配合的方面也不同，所有这些都需要行之有效的软件管理的保证。 软件需求的调研是否深入透彻：软件的需求是确保软件正确反映用户的对软件使用的重要的文档，探讨软件需求是软件开发的起始点，但软件的需求却会贯穿整个软件的开发过程，软件管理需要对软件需求的变化进行控制和管理，一方面保证软件需求的变化不至于造成软件工程的一改再改而无法按期完成；同时又要保证开发的软件能够为用户所接受。软件管理需要控制软件的每个阶段进行的成度，不能过细造成时间的浪费，也不能过粗，造成软件缺陷。 软件的实现技术手段是否能够同时满足性能要求：软件的构造需要对软件构造过程中的使用的各种技术进行评估。软件构造技术通常是这样：最成熟的技术，往往不能体现最好的软件性能；先进的技术，往往人员对其熟悉程度不够，对其中隐含的缺陷不够明了。软件管理在制定软件开发计划和定义里程碑时必须考虑这些因素，并做出合理的权衡决策。 软件质量体系是否能够被有效地保证：任何软件管理忽略软件质量监督环节都将对软件的生产构成巨大的风险。而制定卓有成效的软件质量监督体系，是任何软件开发组织必不可少的。软件质量保证体系是软件开发成为可控制过程的基础，也是开发商和用户进行交流的基础和依据。 软件体系结构影响到软件的如下质量因素： 软件的可伸缩性：是指软件在不进行修改的情况下适应不同的工作环境的能力。由于硬件的飞速发展和软件开发周期较长的矛盾，软件升级的需要显得非常迫切。如果软件的升级和移植非常困难，软件的生命期必定很短，使得化费巨大人力物力开发出的软件系统只能在低性能的硬件或网络上运行，甚至被废弃不用，造成巨大的浪费。 软件的可维护性：软件的维护也是必然的事情，为了保证软件的较长使用寿命，软件就必须适应不断的业务需求变化，根据业务需求的变化对软件进行修改。修改的成本和周期都直接和软件的体系结构相关。一个好的软件体系结构可以尽可能地将系统的变化放在系统的配置上，即软件代码无需修改，仅仅是在系统提供的配置文件中进行适当的修改，然后软件重新加载进入运行状态，就完成了系统部分功能和性能要求的变化。对于重大改动，需要打开源代码进行修改的，也仅仅是先继承原先的代码，然后用新的功能接替原先的调用接口，这样将把软件改动量减小到最低。 软件易用性：软件的易用性是影响软件是否被用户接受的关键之关键因素。在软件产品中，设计复杂，功能强大而完备，但因为操作繁复而被搁置者屡见不鲜。造成的主要原因在于缺乏软件开发中软件体系结构的宏观把握能力。另一方面，缺乏有效的手段进行软件需求的确定和对潜

风险对照检查表示例

风险对照检查表 提示：请使用者根据项目的实际情况进行对照、检查并评分。 商业风险 风险类型检查项评分（0～5） 市场法律政府或者其它机构对本项目的开发有限制吗？ 有不可预测的市场动荡吗？ 有不利于我方的官司要打吗？ 本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗？ 竞争对手有不正当的竞争行为吗？ 是否在开发很少有人真正需要却自以为很好的产品？ 是否在开发可能亏本的产品？ 客户客户的需求是否含糊不清？ 客户是否反反复复地改动需求？ 客户指定的需求和交付期限在客观上可行吗？ 客户对产品的健壮性、可靠性、性能等质量因素有非常过分的要求吗？ 客户的合作态度友善吗？ 与客户签的合同公正吗？双方互利吗？ 客户的信誉好吗？例如按客户的需求开发了产品，但是客户可能不购买。 子承包商供应商与子承包商、供应商签订的合同公正吗？双方互利吗？ 子承包商、供应商的信誉好吗？ 子承包商、供应商有可能倒闭吗？ 子承包商、供应商能及时交付质量合格的产品（或部件）吗？子承包商、供应商有能力做好售后服务吗？ 管理风险 风险类型检查项评分（0～5） 项目计划对项目的规模、难度估计是否比较正确？ 人力资源（开发人员、管理人员）够用吗？合格吗？ 项目所需的软件、硬件能按时到位吗？ 项目的经费够用吗？ 进度安排是否过于紧张？有合理的缓冲时间吗？ 进度表中是否遗忘了一些重要的（必要的）任务？ 进度安排是否考虑了关键路径？ 是否可能出现某一项工作延误导致其它一连串的工作也被延误？

任务分配是否合理？（即把任务分配给合适的项目成员，充分发挥其才能） 是否为了节省钱，不采用（购买）成熟的软件模块，一切从零做起？… 项目团队项目成员团结吗？是否存在矛盾？ 是否绝大部分的项目成员对工作认真负责？ 绝大部分的项目成员有工作热情吗？ 团队之中有“害群之马”吗？ 技术开发队伍中有临时工吗？ 本项目开发过程中是否会有核心人员辞职、调动？ 是否能保证“人员流动基本不会影响工作的连续性”？项目经理是否忙于行政事务而无暇顾及项目的开发工作？ 上级领导行政部门合作部门本项目是否得到上级领导的重视？ 上级领导是否随时会抽调本项目的资源用于其它“高优先级”的项目？上级领导是否过多地介入本项目的事务并且瞎指挥？ 行政部门的办事效率是否比较底，以至于拖项目的后腿？ 行政部门是否经常干一些无益于生产力的事情，以至于骚扰本项目？机构是否能全面、公正地考核员工的工作业绩？ 机构是否有较好的奖励和惩罚措施？ 本项目的合作部门的态度积极吗？是否应付了事？或者做事与承诺的不一致？ 技术风险 风险类型检查项评分（0～5） 需求开发需求管理需求开发人员懂得如何获取用户需求吗？效率高吗？ 需求开发人员懂得项目所涉及的具体业务吗？能否理解用户的需求？需求文档能够正确地、完备地表达用户需求吗？ 需求开发人员能否与客户对有争议的需求达成共识？ 需求开发人员能否获得客户对需求文档的承诺？以保证客户不随便变更需求？ 综合技术开发能力包括设计编程、测 试等开发人员是否有开发相似产品的经验？ 待开发的产品是否要与未曾证实的软硬件相连接？ 对开发人员而言，本项目的技术难度高吗？ 开发人员是否已经掌握了本项目的关键技术？ 如果某项技术尚未实践过，开发人员能否在预定时间内掌握？开发小组是否采用比较有效的分析、设计、编程、测试工具？分析与设计工作是否过于简单、草率，从而让程序员边做边改？开发小组采用统一的编程规范吗？ 开发人员对测试工作重视吗？能保证测试的客观性吗？

软件项目风险管理

软件项目风险管理 1 前言 一般来说，软件工程师总是非常乐观。当他们在计划软件项目时，经常认为每件事情都会像计划那样运行，或者，又会走向另外一个极端。软件开发的创造性本质意味着我们不能完全预测会发生的事情，因此制定一个详细计划的关键点很难确定。当有预想不到的事情引起项目脱离正常轨道时，以上两种观点都会导致软件项目的失败。 目前，风险管理被认为是IT软件项目中减少失败的一种重要手段。当不能很确定地预测将来事情的时候，可以采用结构化风险管理来发现计划中的缺陷，并且采取行动来减少潜在问题发生的可能性和影响。风险管理意味着危机还没有发生之前就对它进行处理。这就提高了项目成功的机会和减少了不可避免风险所产生的后果。 2 什么是风险 所谓“风险”，归纳起来主要有两种意见，主观说认为，风险是损失的不确定性；客观学认为，风险是给定情况下一定时期可能发生的各种结果间的差异。它的两个基本特征是不确定性和损失。IT行业中的软件项目开发是一项可能损失的活动，不管开发过程如何进行都有可能超出预算或时间延迟。项目开发的方式很少能保证开发工作一定成功，都要冒一定的风险，也就需要进行项目风险分析。在进行项目风险分析时，重要的是要量化不确定的程度和每个风险相当的损失程度，为实现这一点就必须要考虑以下问题： 要考虑未来，什么样的风险会导致软件项目失败？ 要考虑变化，在用户需求、开发技术、目标、机制及其它与项目有关的因素的改变将会对按时交付和系统成功产生什么影响？ 必须解决选择问题，应采用什么方法和工具，应配备多少人力，在质量上强调到什么程度才满足要求？ 要考虑风险类型，是属于项目风险、技术风险、商业风险、管理风险还是预算风险等？ 这些潜在的问题可能会对软件项目的计划、成本、技术、产品的质量及团队的士气都有负面的影响。风险管理就是在这些潜在的问题对项目造成破坏之前识别、处理和排除。 3 风险管理 项目风险管理实际上就是贯穿在项目开发过程中的一系列管理步骤，其中包括风险识别、风险估计、风险管理策略、风险解决和风险监控。它能让风险管理者主动“攻击”风险，进行有效的风险管理。 在项目管理中，建立风险管理策略和在项目的生命周期中不断控制风险是非常重要的，风险管理包括四个相关阶段： 风险识别识别风险的方法常用的有风险识别问询法（座谈法、专家法）、财务报表法、流程图法、现场观察法、相关部门配合法和环境分析法等。

APP项目风险评估

A P P项目风险评估 This model paper was revised by the Standardization Office on December 10, 2020

APP项目风险评估 本分析主要针对本APP开发涉及到的风险，以及营销推广，软件管理，包括在软件开发周期过程中可能出现的风险以及软件实施过程中外部环境的变化可能引起的风险等进行评估。在文中对所提到的风险都一一做的分析，并提出了相应的风险回避措施。 由于风险是在项目开始之后才开始对项目的开发起负面的影响，所以风险分析的不足，或是风险回避措施不得力，都很有可能造成软件开发及项目的失败。风险分析是在事前的一种估计，凭借一定的技术手段和丰富的经验，基本能够对项目的风险做出比较准确的估计，经过慎重的考虑提出可行的风险回避措施，是避免损失的重要环节。 项目环境分析 （1）生活节奏越来越快，越来越多的上班族没有时间做饭，但又不喜欢餐厅的口味或环境，同时又有很大部分的自由职业者及宝妈有足够的同时做饭，同时愿意分享 美食给其它人。 （2）繁忙的工作及社会工作压力，使人们没有过多的时间交友，但同时又对社交充满渴求。 （3）本项目是基于同社区分享美食集社交交友为一体的服务型软件。能同时解决都市人吃饭问题和交友问题。是时代的需求。 技术风险 软件的开发：其主要风险均来自于两个方面，一是软件管理，二是软件体系结构。软件产品的开发是工程技术与个人创作的有机结合。软件开发是人的集体智慧按照工程化的思想

进行发挥的过程。软件管理是保证软件开发工程化的手段。软件体系结构的合理程度是取决于集体智慧发挥的程度和经验的运用。 APP软件管理将影响到软件的下列因素： APP软件是否能够按工期的要求完成：软件的工期常常是制约软件质量的主要因素。很多情况下，软件开发商在工期的压力下，放弃文档的书写，组织，结果在工程的晚期，大量需要文档进行协调的工作时，致使软件进度越来越慢。软件的开发不同于其他的工程，在不同的工程阶段，需要的人员不同，需要配合的方面也不同，所有这些都需要行之有效的软件管理的保证。 APP软件需求的调研是否深入透彻：软件的需求是确保软件正确反映用户的对软件使用的重要的文档，探讨软件需求是软件开发的起始点，但软件的需求却会贯穿整个软件的开发过程，软件管理需要对软件需求的变化进行控制和管理，一方面保证软件需求的变化不至于造成软件工程的一改再改而无法按期完成；同时又要保证开发的软件能够为用户所接受。软件管理需要控制软件的每个阶段进行的成度，不能过细造成时间的浪费，也不能过粗，造成软件缺陷。 APP软件的实现技术手段是否能够同时满足性能要求：软件的构造需要对软件构造过程中的使用的各种技术进行评估。软件构造技术通常是这样：最成熟的技术，往往不能体现最好的软件性能；先进的技术，往往人员对其熟悉程度不够，对其中隐含的缺陷不够明了。软件管理在制定软件开发计划和定义里程碑时必须考虑这些因素，并做出合理的权衡决策。

XXX系统安全风险评估调查表完整

XX系统安全风险评估调查表 系统名称： 申请单位： 申请日期：

填写说明 1.申请表一律要求用计算机填写，内容应真实、具体、准确。 2.如填写内容较多，可另加附页或以附件形势提供。 3.申报资料份数为纸版和电子版各一份。

目录 填写说明................................................................................................ I I 目录............................................................................................................... I 一、申请单位信息 (2) 二、系统评估委托书 .....................................................错误！未定义书签。 三、信息系统基本情况调查表 (4) 四、信息系统的最新网络拓扑图 (6) 五、根据信息系统的网络结构图填写各类调查表格。 (7) 表3-1. 第三方服务单位基本情况 (9) 表3-2. 项目参与人员名单 (10) 表3-3. 信息系统承载业务（服务）情况调查 (11) 表3-4. 信息系统网络结构（环境）情况调查 (12) 表3-5. 外联线路及设备端口（网络边界）情况调查 (13) 表3-6. 网络设备情况调查 (14) 表3-7. 安全设备情况调查 (15) 表3-8. 服务器设备情况调查 (16) 表3-9. 终端设备情况调查 (17) 表3-10. 系统软件情况调查 (18) 表3-11. 应用系统软件情况调查 (19) 表3-12. 业务数据情况调查 (20) 表3-13. 数据备份情况调查 (21) 表3-14. 应用系统软件处理流程调查（多表） (22) 表3-15. 业务数据流程调查（多表） (23) 表3-16. 管理文档情况调查 (24) 六、信息系统安全管理情况 (25) 七、信息系统安全技术方案 (25)

工程项目检查表

中铁四局集团项目精细化管理手册（试行） （鲁编写部分） 第二章安全管理 第二章安全管理 第三条安全管理流程 1、识别、评价危险源，建立危险源清单和重大危险源清单（施工过程中，应在危险源现场，设置危险源告知牌）针对重大危险源，编制专项安全方案和应急救援预案（施工过程中，应对应急预案进行演练和完善）；针对一般危险源，编制安全保证措施（纳入施工组织设计中）对操作人员进行安全教育和岗前安全培训施工过程中，随着施工进展，配备安全设施并组织验收，如安全防护设施、施工用电设备、消防设施等，为作业人员发放安全防护用品对操作人员进行技术交底的同时进行安全技术交底按照安全质量管理组织设计，进行日常安全检查和定期安全检查，督促问题整改，验证整改效果定期召开安全专题会议，分析研究解决重要安全问题对安全工作进行总结，提出改进意见和下步工作思路，填写各项安全工作资料和报表。 第五条安全教育和培训 （一）职责 1、项目综合办公室是安全教育培训的主责部门，制定安全教育培训计划，并按计划组织培训和考核。 2、项目部综合办公室可采取多层次、多渠道和多种形式开展安全教育，通过举办讲座、黑板报、宣传栏、放映音像制品等方式宣传安全生产。 3、项目安质部制定安全教育培训制度，协助综合办公室，提出

全员安全教育培训计划，并提供安全教育培训的业务支持。 4、项目安质部负责组织全体员工学习贯彻国家、行业主管部门、属地政府和上级单位有关安全生产的文件精神。 5、项目工程技术部门负责安全技术交底具体实施。 6、项目物机部门负责做好物资、设备相关安全知识的培训教育。 7、项目部其他部门协助做好涉及本部门管理范围内的安全教育培训工作。 （二）流程： 1、项目部综合办公室根据项目特点，制定教育培训计划，项目“三类人员”、特种作业人员培训计划由项目部提报，由公司、局组织实施。 2、项目部综合办公室按计划组织相关部门编写整理培训教材、组织实施教育培训，并如实记录安全生产教育和培训情况。 3、安质部结合安全生产月活动、11.15安全警示教育等活动组织开展安全生产法律法规、安全知识、事故典型案例等培训教育活动，贯彻落实国家、地方、行业主管部门、股份公司、局、公司有关安全生产的文件规定和要求等。 4、工程技术部制定安全方案及技术交底书，项目总工组织召开项目部经理部相关人员进行安全技术交底会，使参与施工管理人员、作业人员，对方案及交底内容有进一步的了解，掌握各作业项目的安全技术保证措施、安全技术操作规程和注意事项等，被交底人员确认无误后，双方共同签字确认，并登记备案。 5、安质部通过日常检查和专项检查对其安全教育培训情况进行考核，查找存在问题，提出改进措施，实现安全培训教育工作持续改进。

软件项目管理之风险评估

软件项目管理之风险评估 很多时候不知道大家有没有发现，项目成为我们见面或茶余饭后的谈资，其中软件项目开发尤为多，但由于种种原因，这个项目并不能如期的完成。那么，如何在项目实施过程中进行有效地评估和预防这些风险呢，这就涉及到风险的评估。 项目管理教会我们如何在复杂多变的环境中做好一件事，风险评估是其中非常重要的一项。本文就软件项目管理中的风险评估方面做详细介绍。 风险评估 软件项目风险是指在整个项目周期中所涉及的成本预算、开发进度、技术难度、经济可行性、安全管理等各方面的问题，以及由这些问题而对项目所产生的影响。项目的风险与其可行性成反比，其可行性越高，风险越低。软件项目的可行性分为经济可行性、业务可行性、技术可行性、法律可行性等四个方面。而软件项目风险则分为产品规模风险、需要风险、相关性风险、管理风险、安全风险等六个方面： 1. 产品规模风险 项目的风险是与产品的规模成正比的，一般产品规模越大，问题就越突出。尤其是估算产品规模的方法，复用软件的多少，需求变更的多少等因素与产品风险息息相关： (1) 估算产品规模的方法 (2) 产品规模估算的信任度 (3) 产品规模与以前产品规模平均值的偏差 (4) 产品的用户数 (5) 复用软件的多少 (6) 产品需求变更的多少 2. 需求风险

很多项目在确定需求时都面临着一些不确定性。当在项目早期容忍了这些不确定性，并且在项目进展过程当中得不到解决，这些问题就会对项目的成功造成很大威胁。如果不控制与需求相关的风险因素，那么就很有可能产生错误的产品或者拙劣地建造预期的产品。每一种情况对产品来讲都可能致命的，这些的风险因素有: (1) 对产品缺少清晰的认识 (2) 对产品需求缺少认同 (3) 在做需求分析过程中客户参与不够 (4) 没有优先需求 (5) 由于不确定的需要导致新的市场 (6) 不断变化需求 (7) 缺少有效的需求变化管理过程 (8) 对需求的变化缺少相关分析等 3. 相关性风险 许多风险都是因为项目的外部环境或因素的相关性产生的。控制外部的相关性风险，能缓解策略应该包括可能性计划，以便从第二资源或协同工作资源中取得必要的组成部分，并觉察潜在的问题,与外部环境相关的因素有： (1) 客户供应条目或信息 (2) 交互成员或交互团体依赖性 (3) 内部或外部转包商的关系 (4) 经验丰富人员的可得性 (5) 项目的复用性 4. 技术风险 软件技术的飞速发展和经验丰富员工的缺乏，意味着项目团队可能会因为技巧的原因影响项目的成功。在早期，识别风险从而采取合适的预防措施是解决

软件项目风险评估方法的研究

北京工业大学 硕士学位论文 软件项目风险评估方法的研究 姓名：焦鹏 申请学位级别：硕士 专业：运筹学与控制论 指导教师：吕宏伯;张方 2003.5.1

摘要 本文从项目管理者角度出发，以项目风险管理理论为基础，结合软件开发项目的特点，对软件项目全生命周期的风险评估方法与应用进行了深入的研究。 论文以项目风险管理的工作程序为阐述的主线索，主要针对项目风险评估的过程，介绍了风险识别、风险估计、风险评价、风险管理技术的概念和常用方法与工具：综合了相关学科的知识，在风险评估过程的各个步骤中提出了新模型和新方法；结合具体案例介绍了风险评估方法的使用，并给出了风险评估方法在实际使用中的几种模式。 本文提出了以下新模型和新方法： （１）综合项目管理知识领域的ＴＣＱＲ风险评估指标体系模型。该模型是风险因素和风险驱动因子的两层次模型，并结合实际情况引入了反映管理能力 的风险放大系数，较好的反映了软件项目的特点。 （２）建立了一般性项目风险驱动因子的标准集，并总结出ＴＢＱ调查问卷。ＴＢＱ调查问卷使得对风险驱动因子的识别和客观评价项目组的管理能力具有 了可操作性，也为ＴｃＱＲ模型的在实际工作中得以应用提供了保证。 （３）结合风险综合评价函数改进了二级模糊综合评价方法，引入了评价项目总体风险水平的项目综合风险系数。 （４）利用成功度评价风险管理的效果，并简要介绍了如何把风险评估方法运用于软件开发项目实践中的几种模式。 上述各种方法简单易懂、适于操作，便于在实际工作中得到应用和推广。通过本文的探索，旨在为项目管理者对软件开发项目的潜在风险的分析、处理、决策提供一套标准化、系统化、定量化和切实可行的方法体系，为进一步研究软件开发项目的风险管理打下基础。 关键词：风险；风险驱动因子；风险放大系数；模糊评价；蒙特卡罗模拟

计算机系统风险评估表

HPLC 操作软件系统风险评估表 使用部门：QC 安装地点：QC仪器室 Code Category Question Possible points Remarks 序号类别问题关键点备注 1 计算机系统的GXP 1.1 计算机系统是否和 GLP、GSP、 是否 该项目如果选择否，不用属性GDP、GMP 相关？进行以下项目 2.1 GAMP 第一类 2.2 GAMP 第二类 选择第一类和第二类，不 2 计算机系统的分类需要进行4、5、6、7的 2.3 GAMP 第三类 问答 2.4 GAMP 第四类 3.1 独立的软件系统是 3 计算机系统的性质/ 3.2 集成于设备的 PLC 系统是否 选择是的，进入5的确4 计算机系统验证 4.1 是否需要进行计算机系统验证是否认，选择否的，直接进入 6 的选择。 5.1 IQ 测试是否包括以下内容 5.1.1 检查软件的硬件配置符合最 是否集成于设备的PLC系统 低配置要求不需要回答此项5.1.2 证明硬件的安装环境符合硬 是否/ 件的使用要求 5.1.3 检查安装的软件和软件说明 是否/ 书上的版本号一致 5.1.4 检查软件已经正确安装在指 是否集成于设备的PLC系统 定的路径不需要回答此项5 计算机系统验证 5.1.5 软件说明书、手册或其他相 是否/ 关资料齐全 5.2 OQ 测试是否包括以下内容 5.2.1 软件安全性验证 5.2.1.1 软件的密码保护，不同级别 是否/ 的人员拥有不同的账号和密码 5.2.1.2 软件的权限保护，是否对于 是否 不同的级别的人员，设置了不同的/ 权限 5.2.2 软件的备份与恢复

序号类别问题关键点备注 5.2.2.1 软件有硬件备份及硬件备 是否/ 份的存放地点 5.2.2.2 卸载软件后，使用备份，重 是否集成于设备的PLC系统 新安装软件不需要回答此项 5.2.2.3 软件产生的数据拷贝后，使 是否集成于设备的PLC系统 用软件能查看拷贝的数据不需要回答此项5.2.3 灾难恢复 5.2.3.1 是否进行了灾难恢复测试是否/ 5.2.4 软件的功能测试 5.2.4.1 是否进行了报警功能测试是否/ 5.2.4.2 是否进行了软件的功能测 是否PLC 系统，进行 PLC 的 试功能测试5.2.5 审计追踪 5.2.5.1 是否进行了审计追踪功能 是否/ 的测试 5.2.6 业务连续性 5.2. 6.1 是否有业务连续性计划是否/ 6 计算机系统文件 6.1 是否建立了计算机系统管理的 是否如果答案为否，下面的回 SOP？答可以不进行6.2 对应的 SOP 编号 6.3 软件产生的数据 电子记录如回答纸质记录，可不需要6.6和6.8，单纯电子 纸质记录记录，不需要回答6.9 电子和纸质共存 6.4 SOP 中是否包含权限管理的要 是否/ 求 6.5 SOP 中是否包含密码管理的要 是否/ 求 6.6 SOP 中是否包含了数据备份的 是否/ 要求 6.7 SOP 中，是否规定了软件备份 是否/ 的要求 6.8 SOP 中，是否规定了软件产生 是否/ 数据的管理要求

资料软件项目风险评估报告

软件项目风险评估报告本文主要针对软件开发涉及到的风险，包括在软件开发周期过程中可能出现的风险以及软件实施过程中外部环境的变化可能引起的风险等进行评估。在文中对所提到的风险都一一做了详细的分析，并提出了相应的风险回避措施。由于风险是在项目开始之后才开始对项目的开发起负面的影响，所以风险分析的不足，或是风险回避措施不得力，都很有可能造成软件开发的失败。风险分析是在事前的一种估计，凭借一定的技术手段和丰富的经验，基本能够对项目的风险做出比较准确的估计，经过慎重的考虑提出可行的风险回避措施，是避免损失的重要环节。 1主要风险综述 任何软件的开发，其主要风险均来自于两个方面，一是软件管理，二是软件体系结构。软件产品的开发是工程技术与个人创作的有机结合。软件开发是人的集体智慧按照工程化的思想进行发挥的过程。软件管理是保证软件开发工程化的手段。软件体系结构的合理程度是取决于集体智慧发挥的程度和经验的运用。 1.1软件管理将影响到软件的下列因素： 软件是否能够按工期的要求完成：软件的工期常常是制约软件质量的主要因素。很多情况下，软件开发商在工期的压力下，放弃文档的书写，组织，结果在工程的晚期，大量需要文档进行协调的工作时，致使软件进度越来越慢。软件的开发不同于其他的工程，在不同的工程阶段，需要的人员不同，需要

配合的方面也不同，所有这些都需要行之有效的软件管理的保证。 软件需求的调研是否深入透彻：软件的需求是确保软件正确反映用户的对软件使用的重要的文档，探讨软件需求是软件开发的起始点，但软件的需求却会贯穿整个软件的开发过程，软件管理需要对软件需求的变化进行控制和管理，一方面保证软件需求的变化不至于造成软件工程的一改再改而无法按期完成；同时又要保证开发的软件能够为用户所接受。软件管理需要控制软件的每个阶段进行的成度，不能过细造成时间的浪费，也不能过粗，造成软件缺陷。 软件的实现技术手段是否能够同时满足性能要求：软件的构造需要对软件构造过程中的使用的各种技术进行评估。软件构造技术通常是这样：最成熟的技术，往往不能体现最好的软件性能；先进的技术，往往人员对其熟悉程度不够，对其中隐含的缺陷不够明了。软件管理在制定软件开发计划和定义里程碑时必须考虑这些因素，并做出合理的权衡决策。 软件质量体系是否能够被有效地保证：任何软件管理忽略软件质量监督环节都将对软件的生产构成巨大的风险。而制定卓有成效的软件质量监督体系，是任何软件开发组织必不可少的。软件质量保证体系是软件开发成为可控制过程的基础，也是开发商和用户进行交流的基础和依据。 1.2软件体系结构影响到软件的如下质量因素： 软件的可伸缩性：是指软件在不进行修改的情况下适应不同的工作环境的能力。由于硬件的飞速发展和软件开发周期较长的矛盾，软件升级的需要显得非常迫切。如果软件的升级和移植非常困难，软件的生命期必定很短，使得

项目风险评估报告

项目风险评估报告 第一章项目概况 一、项目建设单位概况。 *****项目是由 ***** 投资的新建项目，项目地点位于 ***** 。二、项目概况本项目工程的建设规模为 *******, 属新建项目。 **装置包括： **** 区、 ** 主车间、 ** 罐区、 ** 灌装、 ** 灌装；锅炉房规模为 **** 蒸汽锅炉；生活辅助设施包括：综合楼、宿舍楼、 ****、围墙及大门；生产辅助设施包括： *** 区、辅材库、备件库（含 ***库）、化学品库、机修间、循环水站、一次水池及堆场（煤堆场、灰渣堆场、**** 场等）；厂区工程包括：厂区工艺及热力外管、厂 区供电、照明及避雷、厂区给排水及消防管网。 初步设计已经批准。 第二章评估对象及目标 本项目风险评估的对象为******* 项目可能出现的经济、管理、 安全、环境等各方面风险。通过风险评估，确定风险等级，并针对各 风险因素（事件）编制应急预案，将各类风险降低到可以接受的水平。 第三章风险评估程序和评估方法 1.风险评估程序 根据已经批准的本项目的初步设计、公司规章制度、相似工程的 风险评估文件等相关要求，结合项目所在地的实际情况，确定本项目风险评估程序为： ◢1◣

（1）对项目初始风险进行评价，分别确定各风险因素和安全风险发生的 概率和损失值。 （2）分析各风险因素的影响程度，确定主要风险因素对施工安全和施工 成本的影响。 （3）根据评价结果制定相应的管理方案或措施。 2、风险评估方法 以集团批准的初步设计为主线，综合运用风险层次分析法、图表 法、模糊综合评估法等方法。 3、风险管理领导小组及工作职责 根据本项目工程特点，结合公司管理经验，成立专门的风险管理 领导小级。 （1）领导小组组 长： *** 副组长： ***** 组成员如下： *********** 。 （2）职责分工 组长：负责风险评估与管理工作的领导工作。制定各个施工阶段 风险评估工作实施细则。 副组长：根据组长制定的实施细则开展管理工作，并向组长负责。落实风险评估、风险监督管理、风险措施落实等。

(完整版)信息系统集成项目风险评估及防控措施

信息系统集成项目风险评估及防控措施 1、参与涉密项目人员风险评估 1.1 可能存在的风险点 ?项目部组建时人员是否满足涉密人员要求； ?上岗前是否接受过保密知识培训及考核； ?是否与公司签订保密承诺书，保密协议，保密责任书及涉密人员考核评价表；?部门是否按照公司要求开展保密知识培训，加强部门涉密人员的保密意识；?涉密人员离岗时是否签订离岗保密承诺书，保密工作领导小组是否对其进行脱密期管理。 1.2 风险防控措施 ?应聘员工应满足公司对涉密人员的聘用标准； ?上岗必须学习岗位保密业务，且保密知识考核成绩合格； ?与公司签署保密协议、保密承诺书、保密责任书； ?员工所在部门领导确认涉密人员考核评级表内容，确认无误后签字。同时保密领导小组同意签字后．评价表交保密工作领导小组存档，做为该员工的涉密考核内容； ?保密办公室应在年初做好本年度保密知识培训计划及考核计划，组织涉密人员学习各项保密知识。 ?涉密人员在离开项目后，严格遵守公司保密制度，与公司签署离岗保密承诺书，并严格遵守公司对离岗人员的脱密期管理要求。 2、涉密载体风险评估 2.1 可能存在的风险点 纸质文件： ?涉密文件、资料是否有专人管理； ?涉密文件是否有收发记录； ?涉密文件复印、外借是否有登记，是否在记录中标明使用理由、复印数量及使用人签字； ?涉密文件借阅是否有登记记录，是否在记录中标明借阅理由、使用时间、归还时间及借阅人签字； ?涉密文件是否及时归档，档案目录是否及时更新。 电子文件： ?是否指派专人对涉密电子文件进行管理： ?制作涉密电子文件时，是否记录使用范围及制作数量： ?是否在非涉密计算机中传递涉密电子文件； ?在携带涉密电子文件外出时，是否有专人携带； ?涉密电子文件是否及时归档； ?报废的涉密电子文件如何处理。 2 .2 风险防控措施 纸质文件: ?所有保密文件、文档、材料由项目保密专员统一管理，统一登记并存入密码柜，定期进行清查，避免发生资料泄露或丢失。严禁其他人员随意翻看保密资料，如有其他保密人员要借阅使用，由保密专员进行登记，写明借阅时间及借阅理由，并保证不拿到涉密办公室以外的地方使用。

软件项目风险评估报告

软件项目风险评估报告 本文主要针对软件开发涉及到的风险，包括在软件开发周期过程中可能出现的风险以及软 件实施过程中外部环境的变化可能引起的风险等进行评估。在文中对所提到的风险都一一做了 详细的分析，并提出了相应的风险回避措施。由于风险是在项目开始之后才开始对项目的开发起负面的影响，所以风险分析的不足，或是风险回避措施不得力，都很有可能造成软件开发的 失败。风险分析是在事前的一种估计，凭借一定的技术手段和丰富的经验，基本能够对项目的 风险做出比较准确的估计，经过慎重的考虑提出可行的风险回避措施，是避免损失的重要环节。主要风险综述 任何软件的开发，其主要风险均来自于两个方面，一是软件管理，二是软件体系结构。软件 产品的开发是工程技术与个人创作的有机结合。软件开发是人的集体智慧按照工程化的思想进 行发挥的过程。软件管理是保证软件开发工程化的手段。软件体系结构的合理程度是取决于集 体智慧发挥的程度和经验的运用。 软件管理将影响到软件的下列因素： 软件是否能够按工期的要求完成：软件的工期常常是制约软件质量的主要因素。很多情况下，软件开发商在工期的压力下，放弃文档的书写，组织，结果在工程的晚期，大量需要文档 进行协调的工作时，致使软件进度越来越慢。软件的开发不同于其他的工程，在不同的工程阶段，需要的人员不同，需要配合的方面也不同，所有这些都需要行之有效的软件管理的保证。 软件需求的调研是否深入透彻：软件的需求是确保软件正确反映用户的对软件使用的重要的 文档，探讨软件需求是软件开发的起始点，但软件的需求却会贯穿整个软件的开发过程，软件 管理需要对软件需求的变化进行控制和管理，一方面保证软件需求的变化不至于造成软件工程 的一改再改而无法按期完成；同时又要保证开发的软件能够为用户所接受。软件管理需要控制 软件的每个阶段进行的成度，不能过细造成时间的浪费，也不能过粗，造成软件缺陷。 软件的实现技术手段是否能够同时满足性能要求：软件的构造需要对软件构造过程中的使 用的各种技术进行评估。软件构造技术通常是这样：最成熟的技术，往往不能体现最好的软件 性能；先进的技术，往往人员对其熟悉程度不够，对其中隐含的缺陷不够明了。软件管理在制 定软件开发计划和定义里程碑时必须考虑这些因素，并做出合理的权衡决策。 软件质量体系是否能够被有效地保证：任何软件管理忽略软件质量监督环节都将对软件的 生产构成巨大的风险。而制定卓有成效的软件质量监督体系，是任何软件开发组织必不可少的。软件质量保证体系是软件开发成为可控制过程的基础，也是开发商和用户进行交流的基础和依据。 软件体系结构影响到软件的如下质量因素： 软件的可伸缩性：是指软件在不进行修改的情况下适应不同的工作环境的能力。由于硬件 的飞速发展和软件开发周期较长的矛盾，软件升级的需要显得非常迫切。如果软件的升级和移 植非常困难，软件的生命期必定很短，使得化费巨大人力物力开发出的软件系统只能在低性能 的硬件或网络上运行，甚至被废弃不用，造成巨大的浪费。 软件的可维护性：软件的维护也是必然的事情，为了保证软件的较长使用寿命，软件就必

项目风险评估报告范文

项目风险评估报告 本文档的范围和目的 以及软件实施过程中外部环境的变化可能引起的风险等进行评估。在文中对所提到的风险都一一做了详细的分析，并提出了相应的风险回避措施。 足，或是风险回避措施不得力，都很有可能造成软件开发的失败。风险分析是在事前的一种估计，凭借一定的技术手段和丰富的经验，基本能够对项目的风险做出比较准确的估计，经过慎重的考虑提出可行的风险回避措施，是避免损失的重要环节。 主要风险综述 构。软件产品的开发是工程技术与个人创作的有机结合。软件开发是人的集体智慧按照工程化的思想进行发挥的过程。软件管理是保证软件开发工程化的手段。软件体系结构的合理程度是取决于集体智慧发挥的程度和经验的运用。 多情况下，软件开发商在工期的压力下，放弃文档的书写，组织，结果在工程的晚期，大量需要文档进行协调的工作时，致使软件进度越来越慢。软件的开发不同于其他的工程，在不同的工程阶段，需要的人员不同，需要配合的方面也不同，所有这些都需要行之有效的软件管理的保证。 的重要的文档，探讨软件需求是软件开发的起始点，但软件的需求却会贯穿整个软件的开发过程，软件管理需要对软件需求的变化进行控制和管理，一方面保证软件需求的变化不至于造成软件工程的一改再改而无法按期完成；同时又要保证开发的软件能够为用户所接受。软件管理需要控制软件的每个阶段进行的成度，不能过细造成时间的浪费，也不能过粗，造成软件缺陷。 中的使用的各种技术进行评估。软件构造技术通常是这样：最成熟的技术，往往不能体现最好的软件性能；先进的技术，往往人员对其熟悉程度不够，对其中隐含的缺陷不够明了。软件管理在制定软件开发计划和定义里程碑时必须考虑这些因素，并做出合理的权衡决策。 环节都将对

项目风险检查表.docx

膄风险严重性等级 螂参数羃等级节值莇描述 芆风险蚂很高聿5肅例如进度延误大于30 ％，或者费用超支大于30 ％ 肃严重性膃比较高肃4薇例如进度延误20% － 30 ％，或者费用超支20% － 30％ 肈中等芃 3膀例如进度延误低于20 ％，或者费用超支低于20 ％ 例如进度延误低于10 ％，或者费用超支低于10 ％艿比较低袇 2 很低1例如进度延误低于5％，或者费用超支低于5％ 风险可能性等级 参数等级值描述 风险很高5风险发生的几率为0.8 ～ 1.0 可能性比较高4风险发生的几率为0.6 ～ 0.8 中等3风险发生的几率为0.4 ～ 0.6 比较低2风险发生的几率为0.2 ～ 0.4 很低1风险发生的几率为0.0 ～ 0.2 风险系数等级 风险风险可能性 系数很高 5比较高 4中等3比较低 2很低 1风险很高5252015105 严重性较高420161284 中等31512963 比较低2108642 很低154321 本表灰色部分的风险系数为10 ～ 25 ，应当优先处理 风险检查表 商业风险 风险类型检查项 政治政府或者其它机构对本项目的开发有限制吗？ 法律有不可预测的市场动荡吗？ 市场有不利于我方的官司要打吗？ 本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗？ 竞争对手有不正当的竞争行为吗？ 本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗？

客户 子承包商供应商是否在开很少有人真正需要却自以很好的品？ 是否在开可能本的品？ 客的需求是否含糊不清？ 客是否反反复复地改需求？ 客指定的需求和交付期限在客上可行？ 客品的健壮性、可靠性、性能等量因素有非常分的要求？客的合作度友善？ 与客的合同公正？双方互利？ 客的信誉好？例如按客的需求开了品，但是客可能不。与子承包商、供商的合同公正？双方互利？ 子承包商、供商的信誉好？ 子承包商、供商有可能倒？ 子承包商、供商能及交付量合格的品（或部件）？ 子承包商、供商有能力做好售后服？ 管理 型 目划目 上 行政部合作部 目的模、度估是否比正确？ 人力源（开人、管理人）用？合格？ 目所需的件、硬件能按到位？ 目的用？ 度安排是否于？有合理的冲？ 度表中是否忘了一些重要的（必要的）任？ 度安排是否考了关路径？ 是否可能出某一工作延致其它一串的工作也被延？ 任分配是否合理？（即把任分配合适的目成，充分其才能）是否了省，不采用（）成熟的件模，一切从零做起？ ? 目成？是否存在矛盾？ 是否大部分的目成工作真？ 大部分的目成有工作情？ 之中有“害群之” ？ 技开伍中有工？ 本目开程中是否会有核心人辞、？ 是否能保“人流基本不会影响工作的性”？ 目理是否忙于行政事而无暇及目的开工作？ 本目是否得到上的重？ 上是否随会抽本目的源用于其它“高先”的目？ 上是否多地介入本目的事并且瞎指？

IT项目风险评估分析与管控

XXX项目风险评估分析与应对措施 XXX项目建设涉及项目实施规划与设计、数据采集、UI设计、软件开发与实施、硬件采购与安装、网络与数据中心工程、基建工程、弱电工程、工程施工、商务谈判与合同、资金管理、公共关系维护、供应商管理、项目管理等众多方面的专业性建设与综合性统筹管理。 项目建设存在整体跨度大、专业性强、复杂度高低不同、工作量大等特征。 一、缺乏共识的风险 1、与业主方的共识风险。 业主方对项目建设的难度、时间需求、具体解决方案等没有清晰认识，同时片面追求政绩、成果展示等项目驱动，从而对项目提出不现实或多变的要求。 2、项目组内部（包括企业方与供应商方）、企业内部的共识风险。 内部人员对项目定位、具体解决方案有多种理解与认识，而产生对项目建设走向、时间进度、成本等各方面造成至关重要影响。从建设的角度可以这么概括，在一个解决方案上达成共识比这个解决方案本身的先进性重要得多，但往往形成不了共识。 3、各方的项目驱动力的不同且存在变化，造成共识风险加大。 业主方注重政绩、特定的项目诉求及其它利益点；企业方注重项目正常完结、各方公共关系维护及项目款项收取；供应商注重既定需求的项目快速交付与项目款项收取，但各方项目驱动力是变化的。 应对：与各方就大的共识点达成意向，同时注意项目驱动力的不同并对各方不同策略响应；无法达成共识时，由决策人作决策。 二、组织和管理风险 1、项目组织架构是否存在？成员分工是否清晰明确？决策人是否明确？沟通机制？会议制度？ 2、仅由项目经理制下的相关人员进行的项目决策，会导致权限不够、计划进度缓慢、计划时间延长； 3、公司高层在参与度不够的情况下，审查决策的周期比预期的时间长； 4、各种因素影响下的预算削减，将打乱项目计划； 5、公司高层作出了打击项目组织积极性的决定； 6、项目缺乏必要的规范，导致工作失误与重复工作； 7、非技术的第三方的工作（预算批准、设备采购批准、法律方面的审查、安全保证等）时间比预期的延长。 应对：项目应为一把手工程，最高领导的支持力度及参与情况将是项目稳健的保证；健全的项目组织、沟通汇报机制、会议制度、项目进度管理等；

如何进行项目风险评估

如何进行项目风险评估 AMT的研究表明，在信息化实施过程中，风险不仅仅来源于企业，信息系统的实施方也是导致风险产生的一个重要来源。在实施的不同阶段，从开始到结束，实施方的消极态度会直接导致项目的失败。 "诚实的自我评估、确定目标并向着目标稳步前进，所有这些构成了一个连续的过程，而这也正是管理的趣味所在。" 管理者成功地解决难题之后，征服感油然而生。但在企业的管理工作中，可以抵消这种趣味的事情似乎和趣味一样多。 接触过信息化建设的人士都知道，一个信息系统的实施不是短时间内能够完成的，上一个比较完整的ERP系统，少则半年，多则一两年，甚至三四年。如此漫长的实施过程，已经足以把企业内人们对信息化最初的憧憬和热情消磨殆尽。中国有句俗话，叫"日久见人心"，所隐含的无非就是时间可以作为衡量事物真实性的最好的手段。同样的，放在信息系统实施里，一开始不成问题的事情，到了后来都会蜕变成问题，并且有可能随着时间的推移，糟糕程度也不断地增加。因此，如何有效地管理实施过程，降低企业的实施风险成为保障信息化建设成功的一个重要环节，这也就是我们在这里探讨的主题。 如何有效地降低实施过程的风险呢？首先需要了解在实施过程中我们可能碰到哪些风险。 按照一般意义，我们常常所说的风险分为两大类，一种是不可预知的，一种是可预知的。既然是不可预测的风险，有预防的想法，恐怕也是无从做起，只能是在风险到来的时候直接对问题做出反应。而这里我们主要针对的是那些能够预测的风险，在明晰它们的基础上，想办法去控制和降低它们。 信息化项目的项目特性，注定了实施过程中的风险有综合风险，也有阶段风险。

图1 信息化项目的风险包括项目的综合性风险和阶段性风险 （资料来源：AMT－企业资源管理研究中心） 所谓综合风险，是指贯穿整个实施过程，甚至贯穿整个信息化项目过程的几大类风险。根据我们的研究，归纳总结出这么几种：缺乏共识、项目驱动力风险、信息不对称/欺诈风险、财务风险、人力资源风险、业务中断风险。 接下来我们就缺乏共识和项目驱动力风险这两项来做个简单的介绍。 缺乏共识，是IT项目中最常见的风险，带来的后果各种各样。对于IT建设来说，项目组内部（包括企业方与实施方）、企业内部能就关键问题达到共识，显得至关重要。有一句话是这么概括的，在一个解决方案上达成共识比这个解决方案本身的先进性重要得多。为什么共识会在IT项目中扮演了如此重要的一个角色呢？业内人士聚在一起讨论信息化建设，常常会说信息化建设风险很大，然而最难以预测和掌握的是人的因素，技术的问题总是会有解决方案。而达成共识其实就是解决人的问题，减轻或者降低项目实施过程中可能出现的，由于人而引起的不必要的阻力。再来看看项目驱动力风险。项目驱动力其实包含了两层意思，一个是指项目启动的诱因，例如是否是由业务需求驱动，还是出于别的一些原因的考虑；另一个隐含的意思是企业高层对IT项目的推动作用。大家都知道信息化建设是"一把手工程"，领导的支持程度直接影响到项目的成败。 对于阶段性风险，顾名思义，就是在信息化建设各阶段（如选型阶段，项目启动，需求调研等）中出现的、带有浓厚的阶段色彩的风险。举例来说，在项目启动阶段，可能出现计划残缺，思维混沌的风险。对于任何一个项目来说，有明确的项目目标以及详细的项目计划是至关重要的。一个明确的项目目标，决定了整个项目的基调，一个详细的项目计划，使得后面的每项活动都易于控制和掌握。对于IT项目来说，更是如此，作为一个新兴的项目管理领域，IT项目的管理是不够成熟的，而IT的本身又是极难衡量的。在这样的情况下，在项目启动阶段就明确了IT项目的目标和计划显得犹为重要。 "项目不是在结束时失败，而是在开始时失败。"做过项目的人大概都会对这句话感触良深。在项目开始前，或者在项目的启动阶段，多做些工作并且把工作做踏实是非常必要的，也是提前杜绝一些可预测风险发生的一个有效手段。 在进入项目实施前，项目目标明晰和项目计划落实固然非常重要，然而仅仅这些措施是不够的。我们提倡，在项目启动阶段，企业应该对现状做一个评估，看看一旦启动信息化项目，各种风险发生的可能性有多大，对可能发生的困难要有预估，并提前做好防范措施。 如何在项目启动之前对项目的潜在风险进行量化评估 对于项目启动之前的风险评估一般来说可以从两个方面来考虑，一方面评估信息化建设成功的可能性，另一方面需要评价项目实施的难易程度。 影响项目成功可能性的风险因素包括（我们通常称之为A类指标）：企业战略对信息化的需求、决策层的态度、信息化项目的准备情况以及企业信息化建设的现