IT项目管理中的风险(共9页).doc

《IT项目管理中的风险(共9页).doc》由会员分享，可在线阅读，更多相关《IT项目管理中的风险(共9页).doc（12页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、精选优质文档-倾情为你奉上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 进度已经拖延的项目在重新评估时过于优化和忽略项目历史

2、；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 非技术的第三方工作比预期延

3、长（预算批准、设备采购批准）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、交付产品不满意，要求重新设计和重做；4.3 最终用户不买进项目产品，无法提供后续支持；4.4 最终用户的意见没有被采纳，造成产品最终无法满足用户期望，而必须重做；5 客户：5.1 客户坚持新的需求；5.2 客户对规划、原型和规格的审核/决策周期比预期要长；5.3 客户没有或不能参加规划、原型、规格阶段的评审，导致需求不稳定和耗时的变更；5.4 客户坚持技术决策导致进度计划延长；5.5 客户对于开发进度管理过细，导致实际进度变慢；5.6 客户提供的组件无法和开发产品匹配，导致额外的设计和集成工作；5.7 客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户管理管理工作；5.8

5、客户要求的支持工具和环境不兼容，性能差或者功能不完善，导致生产率下降；5.9 客户不接受交付的软件，尽管已经满足了所有的规格；5.10 客户期望的开发速度是开发人员无法达到的；6 承包商：6.1 承包商没有按承诺交付组件；6.2 承包商递交的组件质量低下无法接收，必须花费时间改进质量；6.3 承包商没有买进项目开发所需要的公举，进而无法提供需要的性能水平；7 需求：7.1 需求已经成为项目的基准，但是变化还在继续；7.2 需求定义欠佳， 而进一步的定义会扩展项目范畴；7.3 添加额外的需求；7.4 产品定义含糊的部分比预期需要更多时间；8 产品：8.1 错误发生几率高的模块需要比预期更多的测试

6、，设计和实现工作；8.2 校正质量低下不可接受的产品，需要比预期更多的测试，设计和实现工作；8.3 在一个或多个新兴领域推广计算机技术使得计划进度的延长不可预期；8.4 由于软件功能的错误，需要重新设计和实现；8.5 开发额外不需要的功能，延长了计划进度；8.6 要满足产品规模和进度要求，需要比预期更多的事件，包括重新设计和实现工作；8.7 严格要求与现有系统兼容，需要进行比预期更多的事件进行测试，设计和实现工作；8.8 要求在不同操作系统下运行将花费比预期更长的时间；8.9 在不熟悉或没有经验的软件环境中运行产生没有预料的问题；8.10 在不熟悉或者没有经验的硬件环境中运行产生没有预料的问题

7、；8.11 开发一种对组织全新的模块将比预期花费更长的时间；8.12 依赖于正在开发中的技术将延长计划进度；9 外部环境：9.1 产品依赖于政府规章，而规章的改变是不可避免的；9.2 产品依赖于草拟中的技术标准，而最后的标准是不可预期的；10 人员：10.1 招聘人员所花费时间比预期长；10.2 做为先决条件的任务不能万丞，比如培训，其他项目的万丞，工作许可证；10.3 开发人员和管理层关系不佳导致决策缓慢，影响全局；10.4 项目组乘员没有全身心投入项目，进而无法达到需要的产品性能水平；10.5 缺乏激励机制，士气低下，降低了生产能力；10.6 缺乏必要的规范，增加了工作失误和重复工作；10

8、.7 某些人需要更多时间适应不熟悉的软件工具和环境；10.8 某些人需要更多时间适应不熟悉的硬件工具和环境；10.9 某些人需要更多时间适应不熟悉的编程语言；10.10 项目结束前，合同制人员离开团队；10.11 项目结束前，雇员辞职；10.12 项目后期加入新的开发人员，额外的培训和沟通降低现有成员的效率；10.13 项目组成员不能有效地一起工作；10.14 由于项目组成员的冲突，导致沟通不畅，设计欠佳，接口错误和额外的重复工作；10.15 有问题的成员没有调离项目组，损害了项目组其他成员的积极性；10.16 项目组的最佳人员没有加入项目组；10.17 项目组的最佳人员已经加入项目组，但是因

9、为政治或其他原因没有合理使用；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 一些必要

10、的功能无法是用现有的代码和库实现，开发人员必需使用新的库或者自行开发所需要的功能；11.7 代码和库质量低下，导致需要额外的测试，错误修正或重做；11.8 过高估计增强型工具对项目进度的节省量；11.9 分别开发的模块无法有效集成，需要重新设计或者重做；12 过程12.1 大量纸面工作导致进展比预期慢；12.2 进度跟踪不准确，导致无法预知项目是否已经落后计划进度；12.3 前期的质量保证行为不真实，导致后期的重复工作；12.4 质量跟踪不准确，导致无法得知影响进度的质量问题；在IT中时常会遇到风险，包括技术风险、管理风险等等对项目产生影响的不确定因素。项目风险的控制直接影响项目的成败，是贯穿

11、项目生命周期始终的一个重要组成部分。本文就IT的一个实际项目：数据移植来讨论风险控制的步骤。1.风险识别数据移植是把数据从一个系统批量地移植到另一个系统的过程，通常用在更换系统或系统升级的时候。在做数据移植之前，首先要进行风险识别，就是标识出整个数据移植的过程中可能出现的对项目产生影响的风险。风险识别有以下几种方法：头脑风暴。有关数据移植的项目成员、专家、客户等各方人员组成小组，一起讨论所有可能的风险；专家访谈。向数据移植领域的专家或有经验人员了解项目中会遇到哪些困难。历史资料。通过查阅数据移植项目的历史资料了解可能出现的问题。检查表。将可能出现的问题列出清单，可以对照检查潜在的风险。评估表。

12、根据历史经验进行总结，通过调查问卷方式判别项目的整体风险和风险类型。就数据移植而言，风险可以分成以下几类：技术风险。数据移植涉及到的字段匹配因数据源的数据质量问题或目标系统的接口变化而产生潜在风险。管理风险。数据移植的计划草率，项目进度和人员配置不合理组织风险。高层对项目不重视、数据移植资金不足或与其他项目有资源冲突。外部风险。数据移植涉及到的目标系统的的负责方发生变化。2.风险分析在进行风险识别并分类之后，必须就各项风险发生的概率和对项目的影响力做一些分析和评价。风险分析的方法非常多，一般采用统计学范畴内的概率、分布频率、 平均数众数等方法。风险造成的后果是风险发生的概率和产生的影响力的乘积

13、。如果风险发生的概率很高，但产生的影响并不严重，则最终的后果可能是中等。反 之，如果风险产生的影响极其恶劣，但发生的概率非常低，则最终的后果可能是低等级。风险分析比较实用的两种方法是：定性评估：将风险发生概率和影响力分成低、中、高、极高等几个等级，通过相互比较确定每个事件的等级。例如在数据移植项目中，数据质量问题发生的概率比较高，但影响可能只是局部的，则数据质量风险的等级是低级或中级。定量评估：将发生概率和影响力用01之间的一个数字描述，然后找出那些“概率子跋炝背嘶蟮氖录缭谑菀浦蚕钅恐校钅拷纫蠛芙簦?但关键的人员却还在别的项目中，这个事件的发生概率大概为0.5，却影响整个项目的成败，影响力为0

14、.8，则整个事件的定量评估值为0.5*0.8= 0.4.3.风险应对策略风险应对策略主要有以下四种。规避。通过变更项目计划消除风险或风险的触发条件，使目标免受影响。这是一种事前的风险应对策略。例如，在数据移植的过程中澄清不明确的需求、明确资源的需求量和时间、加强与各参与方的沟通，确保项目资金等。转移。不消除风险，而是将项目风险的结果连同应对的权力转移给第三方。这也是一种事前的应对策略，例如，将数据移植项目的成败交给监理方控制或与用户签定补偿性合同。弱化。将风险事件的概率或影响力降低到一个可以接受的程度。例如，在正式的数据移植之前在测试系统上多次演练，增加备份设计等。接受。不改变项目计划，而考虑

15、发生后如何应对。例如当数据移植出现问题时按事先制定好的应急计划或退却计划执行。4.风险监控风险监控的目的是：监视风险的状况，确定风险是已经发生、仍然存在还是已经消失；检查风险的对策是否有效，监控机制是否在运行；不断识别新的风险并制定对 策。无论项目进展的情况如何，都必须将风险管理的计划和行动结果整理汇总进行分析，形成风险管理报告。采取书面或口头、不定期的或阶段性的等多种方式，为 项目的实施、控制、管理、决策提供信息基础。风险总是和效益并存的。只有正确地识别风险、分析风险、应对风险，才能确保每一个项目的顺利实施和成功完成，才能给企业带来更多的效益。IT项目风险管理案例和应对之道 2011-3-2

16、8 来源：网络 IT项目管理从某个意义上来说，就是风险管理。从理论上讲风险管理可以分为三个部分：风险识别、风险分析和风险解决。 传统的风险管理系统只能帮我们较正规地统计和管理风险，这些系统本身是不能规避或解决任何风险的。在实际操作上，由于可能发生风险的种类很多，处理起来所耗费的人力物力也相当可观。在下列的案例中，我们建议的不是一套昂贵而且全面的风险管理系统，而是一套扼住最关键部位，高效且低成本，适合于千万中小企业的小型解决方案。 一个案例 在2009年某家在北京海淀区的嵌入式产品公司跟我们讨论项目管理时，该公司的王总监跟我们做了以下沟通。他们项目风险种类可以概略分为四类： （1） 需求风险 对

17、需求理解不够透彻或需求变更频繁； （2） 人员风险 人员生病或离职，一时无法找到替代者； （3） 技术风险 某个关键的技术问题无法快速攻克； （4） 管理风险 管理人员协调能力和执行力能力不足，计划偏差，流程更改和沟通不良等。 这些风险的发生导致的结果就是项目延期和成本大幅攀升。无法有效处理这些风险的两个最大问题在于： （1）对风险的反应迟钝 常常是太晚发现问题，以至于无法弥补或是弥补成本太大； （2） 对过程难以掌控 虽已有既定的流程，但由于人员变动、流程变动、系统出错等问题，很难照着走。 为了让我们更理解，王总监很生动的解释了以上两个问题。对风险反应迟钝的问题，他说，在做项目计划时为求实际

18、，总会多估个20%到40%的时间。如果项目需求清晰，或是团队做过类似项目，就用20%或多些；如果是新项目，或风险因素多便用30%到40%。所以，当某些风险（如，需求变更或人员变动）发生了，一般也未必马上就造成项目延期。可是，如果风险发生量继续增加，或是某一两个风险产生较严重的冲击，在某个时刻就会过了临界点。难的地方就是项目大人员多，就是连项目经理也是见树不见林。 对过程难以掌控的问题，王总监举了个例子。公司的研发制度里规定，为保证需求的准确性，一个需求的变更要经过（1）该项目经理，（2）一位资深程序员，和（3）该产品经理，等三个关键人审核后才可以进行更改。王总监说：需求变更的过程在逻辑上看似简

19、单，但在实际操作时却不断地发生问题。举例来说，内部沟通主要是以邮件通知的方式进行，需求变更的文档寄来寄去，版本很多，而且邮件总是遗失。另有一次更严重，产品经理因为休假，没能及时查邮件。在等了两天后，因怕误了工期，项目经理便越权要求程序员把代码写了。不巧，产品经理对这需求的更改有他强烈的意见。当他看到在没得到他的同意下就把代码写了，火冒三丈，直接在会议中就和项目经理吵了起来。 两个控制风险的原则 虽然风险总是发生，但就如同大多数的公司一样，该公司也不愿意花费太多的精力和时间在这风险管控上，所以在寻求一个低成本又高效的管控方法。王总监和我们在研讨后，使用工具DevSuite基于下列两个原则做了处理

20、。（为避免篇幅太大，以下我们仅把最精彩的点列出来。） （1） 提高项目的可视性 不论是哪一种风险，其最后冲击的基本上就是项目本身，延期是最常见的结果。如果是对可能发生的风险都一一进行管控，成本必然很高，而且还可能有疏漏。使用燃尽图（Burn Down Chart）可能是针对项目延期最有效的解决办法，因为它很大程度地提高了项目的可视性。在实际操作时，我们让团队成员每天对其参与的每一任务都键入下列两项数字：1）该任务花费时间，和2）该任务所剩时间。结果就会生了类似如下的燃尽图。 如图所示，起初这项目被估计是要3480小时完成。大致上来说，一般的研发团队因着人员请假、会议和其他突发事情，平均每人每天

21、只能有六小时花在实际项目工作上。现这项目有七个人参与，估算出来大约需要四个月完成。（也就是从2009年11月29日到2010年3月29日，图中红色直立线为起始线，蓝色直立线为终止线。）这图里共有三条曲线。红色号码?/span表示到现在为止在该项目的总花费时间，红色号码?表示估算的项目剩余时间，红色号码?是到目前为止所花的时间与剩余时间之和的曲线。到了2010年3月21日就得到了上面的这个图。到了这一天，我们发现原本估计的3480总小时数是低估了，更可能的是?所示的3740小时。 以纵轴的性质区分，燃尽图可以分为两大类，即纵轴可以是时间或是事件。以范围区分，燃尽图至少可以分为三类：项目级的、任务

22、级的和需求级的。透过燃尽图，我们可以看到项目进行的情况，项目需求是否按计划进入开发流程，工作是否有延时，或者工作安排的饱和度是否适合。如上图所示，我们可以轻易地看到，照着现在的进度，这项目最可能会延期6到7工作天。当高层看到这图时，就可以在资源上做调动，以避免延期产生的不良后果。 我们刻意使用了这个较理想的图做讲解，为的是让读者更容易理解。它不是个典型的图。在大多情况，使用燃尽图会是比较复杂的，因为它可能包含了需求搜集、编程、单元测试、集成测试和缺陷修复，并且还可能有迭代。所以估算时间会较困难。这个燃尽图的过程是比较稳定的，结果是比较理想的，其原因至少有二：（一）项目里单纯地只有编程、单元测试

23、和缺陷修复任务，全都由程序员搞定；它里头没有需求搜集、集成测试或其他任务。（二）这个项目复杂度低，约一半的编码任务是机械性的，所以估出来的时间较为准确。 （2） 固化工作流以管控过程 对于公司里既定的流程，我们在DevSuite里以图形化的工作流将其固化。下图就是以前面王总监提到的需求变更流程设计出来的。 这工作流指明了，在一个变更事件被创建后，它需要经过一个评审状态。在评审阶段里，有三个人（A，B和C）要全部同意，才能到达通过状态。有任何一人不同意，状态就转到拒绝。当一到达评审状态，系统马上促发邮件和手机通知，将信息寄给A，B和C。系统可以预先设定这三人有两天的时间评审该变更。假如两天过了，

24、状态仍为评审，那就是有人未及时处理该事件。这时候，系统会自动将事件升级，把状态转换为升级处理，系统马上促发邮件，将信息寄给研发部王总监。王总监可以斟酌情况，做最妥善的处理。 使用固化的工作流至少有四个优点：1）提高通知效率 ?邮件和手机自动通知提高效率，沟通出错的机会减少了；2）避免流程出错 ?DevSuite的工作流将流程完全自动化，每个人在收到邮件或短信通知时，照着工作流中既定的步骤操作就行了，省心又省力； 3）工作流变动时处理很容易 ?当流程或人员变动时，系统配置员可以轻易地花几分钟就做完调整，之后所有团队成员就照着流程走便行了；4）避免摩擦?人是有情绪的，固化的工作流使得操作完全对事不

25、对人，避免了人和人之间不必要的摩擦。 以上提到的软件项目风险实例几乎在每个项目中都出现，而且，它们造成的损失也是严重的。所幸，从实际操作中，我们发现处理它们的成本并不高：1）培训团队成员照工作流中既定的步骤操作，学会填写任务花费时间和任务所剩时间，并理解意图，所花时间不超过1小时，2）系统配置员要了解需求，设计工作流，并设置人员（如例子中的A、B、C和走流程的人）的权限等，所花费时间在1到3天之间，也算合理，3）以往当团队人员或评审流程有变动，管理人员要更改文档并向所有人宣布；现系统配置员只要花几分钟改系统配置，一切就就绪了。 小结 这并不是一个全方位的风险管控系统；相反的，它是个相当简化，只

26、对关键点作处理的系统。虽然只是做在关键点上，但效果却十分明显。就拿需求变更来说，需求变更一直都是项目中让人恨得牙痒痒的瘤。既然需求变更是不可避免，那我们所能做的就是，尽可能减少变更的次数，降低变更造成的冲击。以往大多数人审核需求变更时较为草率，导致同一个功能点变了又变。在一轮又一轮的返工后，程序员和测试人员会产生倦怠感，编码和测试的质量一再下降。使用了DevSuite后，所有的操作都在系统里留下记录，这统计在年终时可以作为考评的参考材料。自然而然地，审核人员就很严谨地审核每一个需求变更。而且，因为系统设置了每人只有两天的时间处理，审核人员处理需求变更时不仅是快，而且较仔细。单单就这个变化，就使得整个团队的气象焕然一新。专心-专注-专业