IT项目风险管理案例和应对之道
69 浏览量
2021-02-03
15:15:07
上传
评论
收藏 148KB PDF 举报
IT项目风险管理案例和应对之道项目风险管理案例和应对之道
IT项目管理从某个意义上来说，就是风险管理。从理论上讲风险管理可以分为三个部分：风险识别、风险分析和风险解决。
传统的风险管理系统只能帮我们较正规地统计和管理风险，这些系统本身是不能规避或解决任何风险的。在实际操作上，由于
可能发生风险的种类很多，处理起来所耗费的人力物力也相当可观。在下列的案例中，我们建议的不是一套昂贵而且全面的风
险管理系统，而是一套扼住最关键部位，高效且低成本，适合于千万中小企业的小型解决方案。
一个案例一个案例
在在2009年某家在北京海淀区的嵌入式产品公司跟我们讨论项目管理时，该公司的王总监跟我们做了以下沟通。他们项目风险年某家在北京海淀区的嵌入式产品公司跟我们讨论项目管理时，该公司的王总监跟我们做了以下沟通。他们项目风险
种类可以概略分为四类：种类可以概略分为四类：
（1） 需求风险 ——对需求理解不够透彻或需求变更频繁；
（2） 人员风险 ——人员生病或离职，一时无法找到替代者；
（3） 技术风险 ——某个关键的技术问题无法快速攻克；
（4） 管理风险 ——管理人员协调能力和执行力能力不足，计划偏差，流程更改和沟通不良等。
这些风险的发生导致的结果就是项目延期和成本大幅攀升。无法有效处理这些风险的两个最大问题在于：这些风险的发生导致的结果就是项目延期和成本大幅攀升。无法有效处理这些风险的两个最大问题在于：
（1）对风险的反应迟钝 ——常常是太晚发现问题，以至于无法弥补或是弥补成本太大；
（2） 对过程难以掌控 ——虽已有既定的流程，但由于人员变动、流程变动、系统出错等问题，很难照着走。
为了让我们更理解，王总监很生动的解释了以上两个问题。对风险反应迟钝的问题，他说，在做项目计划时为求实际，总会
多估个20%到40%的时间。如果项目需求清晰，或是团队做过类似项目，就用20%或多些；如果是新项目，或风险因素多便用
30%到40%。所以，当某些风险（如，需求变更或人员变动）发生了，一般也未必马上就造成项目延期。可是，如果风险发生
量继续增加，或是某一两个风险产生较严重的冲击，在某个时刻就会过了临界点。难的地方就是项目大人员多，就是连项目经
理也是见树不见林。
对过程难以掌控的问题，王总监举了个例子。公司的研发制度里规定，为保证需求的准确性，一个需求的变更要经过（1）
该项目经理，（2）一位资深程序员，和（3）该产品经理，等三个关键人审核后才可以进行更改。王总监说：需求变更的过
程在逻辑上看似简单，但在实际操作时却不断地发生问题。举例来说，内部沟通主要是以邮件通知的方式进行，需求变更的文
档寄来寄去，版本很多，而且邮件总是遗失。另有一次更严重，产品经理因为休假，没能及时查邮件。在等了两天后，因怕误
了工期，项目经理便越权要求程序员把代码写了。不巧，产品经理对这需求的更改有他强烈的意见。当他看到在没得到他的同
意下就把代码写了，火冒三丈，直接在会议中就和项目经理吵了起来。
两个控制风险的原则两个控制风险的原则
虽然风险总是发生，但就如同大多数的公司一样，该公司也不愿意花费太多的精力和时间在这风险管控上，所以在寻求一个
低成本又高效的管控方法。王总监和我们在研讨后，使用工具DevSuite基于下列两个原则做了处理。（为避免篇幅太大，以
下我们仅把最精彩的点列出来。）
（（1）） 提高项目的可视性提高项目的可视性
不论是哪一种风险，其最后冲击的基本上就是项目本身，延期是最常见的结果。如果是对可能发生的风险都一一进行管控，
成本必然很高，而且还可能有疏漏。使用燃尽图（Burn Down Chart）可能是针对项目延期最有效的解决办法，因为它很大程
度地提高了项目的可视性。在实际操作时，我们让团队成员每天对其参与的每一任务都键入下列两项数字：1）该任务花费时
间，和2）该任务所剩时间。结果就会生了类似如下的燃尽图。
如图所示，起初这项目被估计是要3480小时完成。大致上来说，一般的研发团队因着人员请假、会议和其他突发事情，平均
每人每天只能有六小时花在实际项目工作上。现这项目有七个人参与，估算出来大约需要四个月完成。（也就是从2009年11
资源评论
