精品文档
1. 功能无限蔓延；
2. 需求镀金或者开发人员镀金； 3. 质量不定； 4. 计划过于乐观； 5. 设计欠佳； 6. 银弹综合症； 7. 研发导向的开发； 8. 人员薄弱； 9. 签约商失败；
10. 研发人员和客户的摩擦；
1. 计划编制风险：
1.1 计划、资源和产品定义完全靠客户或者上层领导的口头命令，并且不完全一致； 1.2 计划是优化的，但是是不现实的； 1.3 计划忽略了必要的任务；
1.4 计划基于使用特定的小组成员，而那个小组成员基本上指望不上； 1.5 在限定时间内无法建立成已定规模的产品； 1.6 产品规模比估计的大；
1.7 进度已经拖延的项目在重新评估时过于优化和忽略项目历史； 1.8 过度的进度压力造成生产率下降；
1.9 目标日期提前，没有相应调整产品范围和可用资源； 1.10 一个任务的拖延导致相关任务的连锁反应；
1.11 涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多； 2 组织和管理：
2.1 项目缺乏一个有凝聚力的最高领导人； 2.2 由于前期乏力，项目长时间搁置；
2.3 解雇和削减开支导致项目小组能力下降；
2.4 仅由管理层或市场人员来进行技术决策，导致计划进度延长； 2.5 低效的项目组结构降低生产率；
2.6 管理层审查/决策的周期比预期时间长； 2.7 预算削减打乱项目计划；
2.8 管理层做出了打击项目积极性的决定；
2.9 非技术的第三方工作比预期延长（预算批准、设备采购批准……） 2.10 计划性太差，无法适应期望的开发速度；
2.11 项目计划由于压力而放弃，导致开发混乱，低效；
2.12 管理层强调英雄主义，而忽略客观确切的状态报告，降低发现和改正问题的能力； 3 开发环境：
3.1 设施没有及时到位； 3.2 设施到位，但是不配套； 3.3 设施拥挤，杂乱或者破损； 3.4 开发工具没有及时到位；
3.5 开发工具不如期望那样有效，开发人员需要时间创建工作环境或者切换新的工具； 3.6 开发工具的选择不是基于技术需求，不能提供计划所需要的性能； 精品文档
精品文档
3.7 新开发工具的学习比预期的长，内容多； 4 最终用户：
4.1 最终用户坚持新的需求；
4.2 最终用户对于最后交付产品不满意，要求重新设计和重做； 4.3 最终用户不买进项目产品，无法提供后续支持；
4.4 最终用户的意见没有被采纳，造成产品最终无法满足用户期望，而必须重做； 5 客户：
5.1 客户坚持新的需求；
5.2 客户对规划、原型和规格的审核/决策周期比预期要长；；
5.3 客户没有或不能参加规划、原型、规格阶段的评审，导致需求不稳定和耗时的变更； 5.4 客户坚持技术决策导致进度计划延长；
5.5 客户对于开发进度管理过细，导致实际进度变慢；
5.6 客户提供的组件无法和开发产品匹配，导致额外的设计和集成工作；
5.7 客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户管理管理工作；
5.8 客户要求的支持工具和环境不兼容，性能差或者功能不完善，导致生产率下降； 5.9 客户不接受交付的软件，尽管已经满足了所有的规格； 5.10 客户期望的开发速度是开发人员无法达到的； 6 承包商：
6.1 承包商没有按承诺交付组件；
6.2 承包商递交的组件质量低下无法接收，必须花费时间改进质量；
6.3 承包商没有买进项目开发所需要的公举，进而无法提供需要的性能水平； 7 需求：
7.1 需求已经成为项目的基准，但是变化还在继续； 7.2 需求定义欠佳， 而进一步的定义会扩展项目范畴； 7.3 添加额外的需求；
7.4 产品定义含糊的部分比预期需要更多时间； 8 产品：
8.1 错误发生几率高的模块需要比预期更多的测试，设计和实现工作；
8.2 校正质量低下不可接受的产品，需要比预期更多的测试，设计和实现工作； 8.3 在一个或多个新兴领域推广计算机技术使得计划进度的延长不可预期； 8.4 由于软件功能的错误，需要重新设计和实现； 8.5 开发额外不需要的功能，延长了计划进度；
8.6 要满足产品规模和进度要求，需要比预期更多的事件，包括重新设计和实现工作； 8.7 严格要求与现有系统兼容，需要进行比预期更多的事件进行测试，设计和实现工作； 8.8 要求在不同操作系统下运行将花费比预期更长的时间；
8.9 在不熟悉或没有经验的软件环境中运行产生没有预料的问题； 8.10 在不熟悉或者没有经验的硬件环境中运行产生没有预料的问题； 8.11 开发一种对组织全新的模块将比预期花费更长的时间； 8.12 依赖于正在开发中的技术将延长计划进度； 9 外部环境：
9.1 产品依赖于政府规章，而规章的改变是不可避免的；
9.2 产品依赖于草拟中的技术标准，而最后的标准是不可预期的； 10 人员： 精品文档
精品文档
10.1 招聘人员所花费时间比预期长；
10.2 做为先决条件的任务不能万丞，比如培训，其他项目的万丞，工作许可证； 10.3 开发人员和管理层关系不佳导致决策缓慢，影响全局；
10.4 项目组乘员没有全身心投入项目，进而无法达到需要的产品性能水平； 10.5 缺乏激励机制，士气低下，降低了生产能力； 10.6 缺乏必要的规范，增加了工作失误和重复工作； 10.7 某些人需要更多时间适应不熟悉的软件工具和环境； 10.8 某些人需要更多时间适应不熟悉的硬件工具和环境； 10.9 某些人需要更多时间适应不熟悉的编程语言； 10.10 项目结束前，合同制人员离开团队； 10.11 项目结束前，雇员辞职；
10.12 项目后期加入新的开发人员，额外的培训和沟通降低现有成员的效率； 10.13 项目组成员不能有效地一起工作；
10.14 由于项目组成员的冲突，导致沟通不畅，设计欠佳，接口错误和额外的重复工作； 10.15 有问题的成员没有调离项目组，损害了项目组其他成员的积极性； 10.16 项目组的最佳人员没有加入项目组；
10.17 项目组的最佳人员已经加入项目组，但是因为政治或其他原因没有合理使用； 10.18 关键人员只能兼职参与； 10.19 项目人员不足；
10.20 人员工作的进展比预期的慢； 10.21 任务的分配合人员技能不匹配；
10.22 项目管理人员的怠工导致计划和进度失控；
10.23 技术人员怠工导致工作遗漏或质量低下，工作需要重做； 11 设计和实现：
11.1 设计过于简单，无法确定主要事件，并导致重新设计和实现； 11.2 设计过于复杂，导致一些不必要工作，并影响效率； 11.3 设计质量低下，导致重复设计和实现；
11.4 采用不熟悉的方法，导致额外的培训时间，并重犯以前的错误； 11.5 产品采用低级语言来实现，导致生产率比预期低；
11.6 一些必要的功能无法是用现有的代码和库实现，开发人员必需使用新的库或者自行开发所需要的功能；
11.7 代码和库质量低下，导致需要额外的测试，错误修正或重做； 11.8 过高估计增强型工具对项目进度的节省量；
11.9 分别开发的模块无法有效集成，需要重新设计或者重做； 12 过程
12.1 大量纸面工作导致进展比预期慢；
12.2 进度跟踪不准确，导致无法预知项目是否已经落后计划进度； 12.3 前期的质量保证行为不真实，导致后期的重复工作； 12.4 质量跟踪不准确，导致无法得知影响进度的质量问题；
在IT项目管理中时常会遇到风险，包括技术风险、管理风险等等对项目产生影响的不确定因素。项目风险的控制直接影响项目的成败，是贯穿项目生命周期始终的一个重要组成部分。本文就IT的一个实际项目：数据移植来讨论风险控制的步骤。
精品文档
精品文档 1.风险识别
数据移植是把数据从一个系统批量地移植到另一个系统的过程，通常用在更换系统或系统升级的时候。在做数据移植之前，首先要进行风险识别，就是标识出整个数据移植的过程中可能出现的对项目产生影响的风险。风险识别有以下几种方法：
●头脑风暴。有关数据移植的项目成员、专家、客户等各方人员组成小组，一起讨论所有可能的风险；
●专家访谈。向数据移植领域的专家或有经验人员了解项目中会遇到哪些困难。 ●历史资料。通过查阅数据移植项目的历史资料了解可能出现的问题。 ●检查表。将可能出现的问题列出清单，可以对照检查潜在的风险。
●评估表。根据历史经验进行总结，通过调查问卷方式判别项目的整体风险和风险类型。 就数据移植而言，风险可以分成以下几类：
●技术风险。数据移植涉及到的字段匹配因数据源的数据质量问题或目标系统的接口变化而产生潜在风险。
●管理风险。数据移植的计划草率，项目进度和人员配置不合理
●组织风险。高层对项目不重视、数据移植资金不足或与其他项目有资源冲突。 ●外部风险。数据移植涉及到的目标系统的的负责方发生变化。 2.风险分析
在进行风险识别并分类之后，必须就各项风险发生的概率和对项目的影响力做一些分析和评价。风险分析的方法非常多，一般采用统计学范畴内的概率、分布频率、 平均数众数等方法。风险造成的后果是风险发生的概率和产生的影响力的乘积。如果风险发生的概率很高，但产生的影响并不严重，则最终的后果可能是中等。反 之，如果风险产生的影响极其恶劣，但发生的概率非常低，则最终的后果可能是低等级。风险分析比较实用的两种方法是： ●定性评估：将风险发生概率和影响力分成低、中、高、极高等几个等级，通过相互比较确定每个事件的等级。例如在数据移植项目中，数据质量问题发生的概率比较高，但影响可能只是局部的，则数据质量风险的等级是低级或中级。
●定量评估：将发生概率和影响力用0~1之间的一个数字描述，然后找出那些“概率子跋炝Α背嘶蟮氖录＠缭谑菀浦蚕钅恐校则整个事件的定量评估值为0.5*0.8= 0.4. 3.风险应对策略
风险应对策略主要有以下四种。
●规避。通过变更项目计划消除风险或风险的触发条件，使目标免受影响。这是一种事精品文档
钅拷纫蠛芙簦?但关键的人员
却还在别的项目中，这个事件的发生概率大概为0.5，却影响整个项目的成败，影响力为0.8，
精品文档
前的风险应对策略。例如，在数据移植的过程中澄清不明确的需求、明确资源的需求量和时间、加强与各参与方的沟通，确保项目资金等。
●转移。不消除风险，而是将项目风险的结果连同应对的权力转移给第三方。这也是一种事前的应对策略，例如，将数据移植项目的成败交给监理方控制或与用户签定补偿性合同。 ●弱化。将风险事件的概率或影响力降低到一个可以接受的程度。例如，在正式的数据移植之前在测试系统上多次演练，增加备份设计等。
●接受。不改变项目计划，而考虑发生后如何应对。例如当数据移植出现问题时按事先制定好的应急计划或退却计划执行。 4.风险监控
风险监控的目的是：监视风险的状况，确定风险是已经发生、仍然存在还是已经消失；检查风险的对策是否有效，监控机制是否在运行；不断识别新的风险并制定对 策。无论项目进展的情况如何，都必须将风险管理的计划和行动结果整理汇总进行分析，形成风险管理报告。采取书面或口头、不定期的或阶段性的等多种方式，为 项目的实施、控制、管理、决策提供信息基础。
风险总是和效益并存的。只有正确地识别风险、分析风险、应对风险，才能确保每一个项目的顺利实施和成功完成，才能给企业带来更多的效益。
IT项目风险管理案例和应对之道
2011-3-28 来源：网络
IT项目管理从某个意义上来说，就是风险管理。从理论上讲风险管理可以分为三个部分：风险识别、风险分析和风险解决。 传统的风险管理系统只能帮我们较正规地统计和管理风险，这些系统本身是不能规避或解决任何风险的。在实际操作上，由于可能发生风险的种类很多，处理起来所耗费的人力物力也相当可观。在下列的案例中，我们建议的不是一套昂贵而且全面的风险管理系统，而是一套扼住最关键部位，高效且低成本，适合于千万中小企业的小型解决方案。 一个案例
在2009年某家在北京海淀区的嵌入式产品公司跟我们讨论项目管理时，该公司的王总监跟我们做了以下沟通。他们项目风险种类可以概略分为四类：
（1） 需求风险 ——对需求理解不够透彻或需求变更频繁； （2） 人员风险 ——人员生病或离职，一时无法找到替代者；
精品文档
IT项目管理中的风险培训课件
