项目风险管理知识：风险评估报告

2008-07-01

引言

本文档的范围和目的

本文主要针对软件开发涉及到的风险，包括在软件开发周期过程中可能出现的风险以及软件实施过程中外部环境的变化可能引起的风险等进行评估。在文中对所提到的风险都一一做了详细的分析，并提出了相应的风险回避措施。

由于风险是在项目开始之后才开始对项目的开发起负面的影响，所以风险分析的不足，或是风险回避措施不得力，都很有可能造成软件开发的失败。风险分析是在事前的一种估计，凭借一定的技术手段和丰富的经验，基本能够对项目的风险做出比较准确的估计，经过慎重的考虑提出可行的风险回避措施，是避免损失的重要环节。

主要风险综述

任何软件的开发，其主要风险均来自于两个方面，一是软件管理，二是软件体系结构。软件产品的开发是工程技术与个人创作的有机结合。软件开发是人的集体智慧按照工程化的思想进行发挥的过程。软件管理是保证软件开发工程化的手段。软件体系结构的合理程度是取决于集体智慧发挥的程度和经验的运用。

软件管理将影响到软件的下列因素：

软件是否能够按工期的要求完成：软件的工期常常是制约软件质量的主要因素。很多情况下，软件开发商在工期的压力下，放弃文档的书写，组织，结果在工程的晚期，大量需要文档进行协调的工作时，致使软件进度越来越慢。软件的开发不同于其他的工程，在不同的工程阶段，需要的人员不同，需要配合的方面也不同，所有这些都需要行之有效的软件管理的保证。

软件需求的调研是否深入透彻：软件的需求是确保软件正确反映用户的对软件使用的重要的文档，探讨软件需求是软件开发的起始点，但软件的需求却会贯穿整个软件的开发过程，软件管理需要对软件需求的变化进行控制和管理，一方面保证软件需求的变化不至于造成软件工程的一改再改而无法按期完成；同时又要保证开发的软件能够为用户所接受。软件管理需要控制软件的每个阶段进行的成度，不能过细造成时间的浪费，也不能过粗，造成软件缺陷。

软件的实现技术手段是否能够同时满足性能要求：软件的构造需要对软件构造过程中的使用的各种技术进行评估。软件构造技术通常是这样：最成熟的技术，往往不能体现最好的软件性能；先进的技术，往往人员对其熟悉程度不够，对其中隐含的缺陷不够明了。软件管理在制定软件开发计划和定义里程碑时必须考虑这些因素，并做出合理的权衡决策。

软件质量体系是否能够被有效地保证：任何软件管理忽略软件质量监督环节都将对软件的生产构成巨大的风险。而制定卓有成效的软件质量监督体系，是任何软件开发组织必不可

少的。软件质量保证体系是软件开发成为可控制过程的基础，也是开发商和用户进行交流的基础和依据。

软件体系结构影响到软件的如下质量因素：

软件的可伸缩性：是指软件在不进行修改的情况下适应不同的工作环境的能力。由于硬件的飞速发展和软件开发周期较长的矛盾，软件升级的需要显得非常迫切。如果软件的升级和移植非常困难，软件的生命期必定很短，使得化费巨大人力物力开发出的软件系统只能在低性能的硬件或网络上运行，甚至被废弃不用，造成巨大的浪费。

软件的可维护性：软件的维护也是必然的事情，为了保证软件的较长使用寿命，软件就必须适应不断的业务需求变化，根据业务需求的变化对软件进行修改。修改的成本和周期都直接和软件的体系结构相关。一个好的软件体系结构可以尽可能地将系统的变化放在系统的配置上，即软件代码无需修改，仅仅是在系统提供的配置文件中进行适当的修改，然后软件重新加载进入运行状态，就完成了系统部分功能和性能要求的变化。对于重大改动，需要打开源代码进行修改的，也仅仅是先继承原先的代码，然后用新的功能接替原先的调用接口，这样将把软件改动量减小到最低。

软件易用性：软件的易用性是影响软件是否被用户接受的关键之关键因素。在软件产品中，设计复杂，功能强大而完备，但因为操作繁复而被搁置者屡见不鲜。造成的主要原因在于缺乏软件开发中软件体系结构的宏观把握能力。另一方面，缺乏有效的手段进行软件需求的确定和对潜在需求的挖掘。

项目管理的风险

软件项目管理的风险来自于软件项目自身的特点：

软件产品不可见：开发的进展以及软件的质量是否符合要求难于度量，从而使软件的管理难于把握。

软件的生产过程不存在绝对正确的过程形式：可以肯定的是不同的软件开发项目应当采用不同的或者说是有针对性的软件开发过程，而真正合适的软件开发过程是在软件项目的开发完成才能明了的。因此项目开发之初只能根据项目的特点和开发经验进行选择，并在开发过程中不断的调整。

大型软件项目往往是"一次性"的。以往的经验可以被借鉴的地方不多。回避和控制软件管理风险的唯一办法就是设立监督制度，项目开发中任何较大的决定都必须有主要技术环节甚至是由用户参与进行的。在该项目中项目监督由项目开发中的质量监督组来实施。

一般参与软件开发的人员（包括管理者和技术人员）和其责任进行分析如下：

参与者

项目经理1人

主要职责：进行全局把握，侧重于项目的商务方面，充当项目组同客户正式交流的接口环节。

项目负责人1人

主要职责：制定项目开发计划和开发策略，参与项目核心系统的分析设计，同时努力保证开发

计划的按时完成和开发策略的真正贯彻落实。

领域专家1或2人

主要职责：在软件分析阶段帮助分析人员界定系统实现边界和实现的功能，对特定检测点进行

算法审核，同时对测试策略和软件操作界面提出参考意见。

质量监督组1或2人

主要职责：编制软件质量控制计划，并负责落实；控制必要文档的生产，通过文档，监督项目

实施过程中软件的质量，并产生软件质量报告，提请项目经理和项目负责人审阅；对于项目中出现

的质量问题，主持召开质量复审会议。

系统分析员1或2人

主要职责：协同项目负责人进行软件系统的分析和设计工作，书写软件需求分析和系统设计相关文档。在软件实现阶段进行测试策略的编制和对性能测试的指导。

程序员2或3人

主要职责：协助分析人员进行详细设计，和软件系统的代码实现，并进行适当的白盒测试。

测试员2或3人

主要职责：已经实现的软件组件、构件或系统进行正确性验证测试，整合后的系统的性能测试等。书写测试报告和测试统计报告提请质量监督组复审。

技术支持2或3人

主要职责：协同系统分析人员听取用户需求，对需求分析进行参考性复审。协同测试人员进行测试，书写操作手册和在线帮助，在项目交付用户之后进行跟踪服务。

文档组1或2人

主要职责：对各部门产生的文档进行格式规范、版本编号和控制、存档文件的检索；协助质量监督组进行软件质量监督。 通过适当的人员配备和职责划分，能有效的降低软件开发在后期的失控的可能性，和软件对关键人员的依赖性。

软件技术风险

本系统拟订采用的两个重大的软件技术是面向对象的构件和基于微软的COM组件技术。组件和构件技术都是为了提高软件的可靠性和软件的可扩展性而采用的技术手段。从技术成熟度上说不存在风险，但为了实现良好的软件构架和稳定的组件，与传统开发方法比较，有相当的多的额外工作需要做，这会给项目工期带来较大的风险。

回避和控制这部分风险的办法是在项目进行的过程不断的对该阶段进行风险估计和指定有效的里程碑。同时采用"范例"方式提高开发人员的构件组件的分析识别能力，适时调整构件组件的数量和粒度。

软件过程风险

软件需求阶段的风险

软件的开发是以用户的需求开始，在大多数情况下，用户需求要靠软件开发方诱导才能保证需求的完整，再以书面的形式形成《用户需求》这一重要的文档。需求分析更多的是开发方确认需求的可行性和一致性的过程，在此阶段需要和用户进行广泛的交流和确认。需求和需求分析的任何疏漏造成的损失会在软件系统的后续阶段被一级一级地放大，因此本阶段的风险最大。

设计阶段的风险

设计的主要目的在于软件的功能正确的反映了需求。可见需求的不完整和对需求分析的不完整和错误，在设计阶段被成倍地放大。设计阶段的主要任务是完成系统体系结构的定义，使之能够完 成需求阶段的即定目标；另一方面也是检验需求的一致性和需求分析的完整性和正确性。

设计本身的风险主要来自于系统分析人员。分析人员在设计系统结构时过于定制，系统的可扩展性较弱，会给后期维护带来巨大的负担，和维护成本的激增。对用户来说系统的使用比例会有明显的折扣，甚至造成软件寿命过短。反之，软件结构的过于灵活和通用，必然引起软件实现的难度增加，系统的复杂度会上升，这又会在实现和测试阶段带来风险，系统的稳定性也会受到影响。从另一个角度上看，业务规则的变化，或说用户需求和将来软件运行环境的变化都是必然的情况，目前软件设计的所谓"通用性"是否就能很好的适应将来需求

和运行环境的的变化，是需要认真折衷的。这种折中也蕴涵着很大的风险。

设计阶段蕴涵的另一种风险来自于设计文档。文档的不健全不仅会造成实现阶段的困难，更会在后期的测试和维护造成灾难性的后果，例如根本无法对软件系统进行版本升级，甚至是发现的简单错误都无从更正。

实现阶段引入的风险

软件的实现从某种意义上讲是软件代码的生产。原代码本身也是文档的一部分，同时它又是将来运行于计算机系统之上的实体。源代码书写的规范性，可读性是该阶段的主要风险来源。规范的代码生产会把属于程序员自身个性风格的成分引入代码的比例降到最低限度，从而减小了系统整合的风险。

维护阶段的风险

软件维护包含两个主要的维护阶段，一个是软件生产完毕到软件试运行阶段的维护，这个阶段是一种实环境的测试性维护，其主要目的是发现在测试环境中不能或未发现的问题；另一个阶段是当软件的运行不再能适应用户业务需求或是用户的运行环境（包括硬件平台，软件环境等）时进行的软件维护，具体可能是软件的版本升级或软件移植等。

从软件工程的角度看，软件维护费用约占总费用的55%~70%，系统越大，该费用越高。对系统可维护性的轻视是大型软件系统的最大风险。在软件漫长的运营期内，业务规则肯定会不断发展， 科学的解决此问题的做法是不断对软件系统进行版本升级，在确保可维护性的前提下逐步扩展系统。

在软件系统运营期间，主要的风险源自于技术支持体系的无效运转。科学的方法是有一支客户支持队伍不断收集运行中发现的问题，并将解决问题的方法传授给软件系统的所有使用者。

项目风险表

风险评估表中所提到的风险是一般项目在开发过程中都客观存在的，表中所列出的风险系数是指在不对风险进行深入的分析和有效的规避的情况下，该风险项发生的概率。比如软件产品的设计目标是运行十年，体系结构不合理的风险是40%的含义是，如果不对系统进行深入的分析，未采用最合理的软件技术进行设计，则生产出一个不具备可扩展性的软件系统的概率是40%。由于客户公司是仍将不断发展的，在十年内，该软件系统都能满足公司运营要求的可能性极低。由此而可能产生的灾难性后果是公司在业务发展的时候，必须重新开发新系统。

向客户提供风险评估，是按照国际惯例进行的例行操作，一方面让客户对潜在的风险有更充分的了解，表明公司诚信 为本的态度，另一方面也用以鞭策和激励全体开发人员严格执行开发标准，共同监督项目开发过程，努力避免风险的发生。

第二篇：第 8 章 项目风险管理案例

第 8 章  项目风险管理案例

项目需要以有限的成本在有限的时间内达到项目目标，而风险会影响这一点。风险管理的目的就是最小化风险对项目目标的负面影响，抓住风险带来的机会，增加项目干系人的收益。作为项目管理人员，必须评估项目中的风险，制定风险应对策略，有针对性地分配资源、制定计划，保证项目顺利的进行。

8．1 案例一：风险分类

阅读以下关于信息系统项目管理过程中人群风险分类方面问题的叙述，回答问题1至问题3。

8.1.1 案例场景

某公司召开会议，商量是否实施ERP项目，三个部门主要负责人就此问题发表自己的看法。

甲：我们公司不应该实施这个项目。现在我们刚把办公自动化系统搞好，还没有适应，工作效率也没提高多少，再上 ERP 有些不适应，而且这个ERP项目花费太大。ERP在国内很多企业都搞失败了，成功的几率不会多大。如果我们也失败了，会给公司带来灾难性的后果。利用搞ERP的这些钱我们可以做一些短、平、快的项目，多招一些开发高手，提高公司的收益，而不是搞这些无端的风险投资。

乙：不应该一棒子打死ERP，ERP是一种新兴事务，ERP不是万能的，但是不上ERP又是万万不行的。企业规模到了一定程度，管理和决策就是一个重要的问题。ERP是知识经济时代的管理方案，是面向供应链和“流程制”的智能决策支持系统，其先进的管理思想可以帮助企业最大限度地利用已有资源，解决管理和决策问题。但是实施 ERP 风险很大，很多企业都失败了，主要原因在于项目实施的管理问题，没有及时识别项目中的风险并及时处理，项目监控机制不好，高层支持不够，老员工的适应性差等，最终导致“ERP天折”。我们公司以后想获得更大发展，应该实施ERP ，现在有些条件不够，整体上ERP不太可行，我们可以分步实施。我们可以借鉴其他企业实施 ERP 的经验，先进行小范围ERP试验、积累经验，等以后时机成熟了，我们就整体实施ERP 。

丙：ERP 应该上，而且要迅速上，不应该等。如果其他企业都上了ERP，那么我们公司再依靠ERP获得收益就没有什么希望了。ERP本身就是一把双刃剑，虽然有风险，但是收益也大，现在我们的目标是收益，对于风险要想法化解。项目实施中要注意借鉴其他企业的经验，摸着石头过河，形成自己的特色，提高自己公司的管理和决策水平，争取把公司做大做强。小的、可以自己解决的风险自己处理；难以处理的、不确定的风险进行外包，实施风险转移；如果管理有问题的话，可以从专业咨询公司招聘顾问来担当项目经理的职务。总之，尽一切可能实施 ERP，实现收益最大化。

【问题1】如图8-1所示，横轴表示项目投资的大小，纵轴表示项目成功的概率，A、B, C代表三种不同应对风险的人。请写出A,B,C的名字和特征，并且指出上述案例中甲、乙、丙分别属于哪一种对象(250字左右)。

【问题2】如果公司有以下三种职位，你认为甲、乙、丙分别适合做什么：项目经理、程序员、产品销售人员(请说清楚原因，不超过150字)。

【问题3】根据你自己的经验，阐述 ERP 实施中的主要风险和应对措施(600字左右)。

8.1.2 案例分析

【问题1】

本题考查考生对风险管理中不同投资者进行分类的能力。要想回答好该题，考生需要了解三种不同投资者(风险规避者、风险中立者和风险冒险者)对风险的承受能力和态度；能够从图中得出三种人的特征，然后进行分类；最后还要联系案例中的角色，对号入座。

求解此题时，也可以采用双管齐下的方针，先由图中简要归纳出 A,B,C 的特征，这些特征可能有些片面、不太完善。此时可以联系案例中甲、乙、丙的言谈，由于案例中言谈内容丰富，并且具有鲜明的性格特征，所以极易区分。从言谈中提取出的特征可以补充前面由图中归纳出的特征，使得特征更加全面、具体，同时也完成了对甲、乙、丙的归类。

A)风险规避者：这种人希望活动获得成功的概率随着投入的增加呈凸函数曲线规律增加，属于保守派。他们害怕风险，认为风险随时存在。在风险和收益对比方面，他们认为两者成反比关系，所以更注重前者。他们自始至终都不愿意接受较大的风险，希望利用少量投资就可以得到较高的成功概率，随着投资的增加，他们希望成功概率越来越大，最后达到百分之百。

B)风险中立者：这种人希望活动获得成功的概率随着投入的增加呈 S 曲线规律增加，属于中庸派。当投入少时，他们可以接受较大的风险，即使获得成功的概率不高也能接受；当投入逐渐增加时，他们就开始变得谨慎起来，希望获得成功的概率提高了，最后达到百分之百。

C)风险冒险者：这种人希望活动获得成功的概率随着投入的增加呈凹函数曲线规律增加，属于冒险派。他们认为风险和收益成正比，为此积极追求成功，正视风险，以尽可能获得最大收益为第一准则。为了这个目标，甘愿承受较大的风险。他们自始至终都愿意接受较大的风险，当投入少时，他们可以接受较大的风险；随着投入的增加，他们也会变得谨慎一些，希望成功概率有所增加，最后达到百分之百。

上述案例中，甲不愿意冒风险，坚决反对实施 ERP，属于风险规避者；乙可以承受小范围内的风险，实施局部 ERP，属于风险中立者；丙可以承受全部风险，坚决要求实施 ERP,属于风险冒险者。

【问题2】

本题考查考生综合运用人力资源分类和风险管理知识的能力。要想回答好该题，考生需要了解项目开发中不同角色应该具有的特征和能力。

人力资源管理中，“人尽其能”是获取利益最大化，降低风险的一个分配原则，只有这样才能充分地发挥每个项目干系人的能力，保证他们能够以足够的精力参与到项目中来。

甲属于风险规避者，做事小心谨慎，不愿意冒大风险，比较适合做程序员。因为程序员做事讲究规矩，不提倡个性化的随意发挥、出风头和冒风险。他们设计程序结构采用标准设计模式，定义数据结构采用标准包结构，代码遵守通用语法风格，算法采用通用的标准算法。他们编出的程序具有强标准性、开放性和稳定性。

乙属于风险中立者，做事深思熟虑、讲究章法，制定计划切实可行、可进可退，比较适合做项目经理。因为项目经理要求具有广博的知识和丰富的经历，能够合理处理质量、进度和费用的关系，处事灵活，能够预测变化并且能够适应变化。

丙属于风险冒险者，做事大胆，敢于冒风险，一切以效益为先，积极追求成功，具有强烈的成功欲望，比较适合做产品销售人员。因为产品销售人员要具有恒心和毅力，耐得住客户的冷眼和漠然，最终说服客户；要具备外向、冒险性格，这样有利于销售人员主动地与客户交流、敢于为争取机会而采取果断的行动。

【问题3】

本题考查考生在 ERP 实施中综合应用风险管理知识的能力。要想回答好该题，考生需要了解ERP 的相关基础知识和实施中的常见风险和应对方法。

ERP 实施中的主要风险和应对措施如下：

(l)项目范围的风险

ERP 项目采购管理通常有三种合同方式：固定价或总价合同、成本报销(加奖励)合同、单价合同。对于不确定性越大、风险越大的 ERP 项目，通常采用后面的合同方式，但这种方式对客户存在较大风险，客户一般倾向于固定价或总价合同方式，但这种方式对供应商又存在较大风险。在此前提下，若项目范围定义不清晰，可能导致双方对项目范围的认知产生分歧：供应商希望尽量缩小实施范围，以最小的成本结束项目；而客户希望将 ERP 系统的所有功能尽可能多地实施，以固定价格获得最大的效益。若双方的分歧较大，不能达成一致，则必然造成效率低下、相互扯皮。

因此，ERP 项目合同中，应对项目实施范围做尽可能清晰的界定。宁愿在项目实施前的范围界定工作上多花一些时间，也不要在项目实施过程中，面对 ERP 繁多的功能，产生争执或被迫让步，投入更大的精力，导致项目不能按时完成。

(2)项目进度的风险

目前 ERP 项目实施存在强调“快速”的倾向，但实际操作中提高 ERP 项目进度绝非易事，实现该目标不仅取决于公司能力，很大程度上也与客户对 ERP 期望值是否合理、对范围控制是否有效、对项目投入是否足够等方面有关。一味在项目进度计划时求快，甚至是刻意追求某个具有特殊意义的日期作为项目里程碑，将对项目的控制造成很大压力。事实上，很多项目的失败，都是因为制定超前的项目进度，而实际无法完成进而出现拖延，从而导致项目团队士气低落、效率低下。

因此，ERP 项目实施中的项目进度制定需要充分考虑各种潜在因素，适当留有余地和柔性；任务分解详细适中，便于操作和考核；在执行过程中，应强调项目按进度执行的重要性，在考虑任何问题时，都要将保持进度作为先决条件；同时，合理利用赶工及快速跟进等方法，充分利用资源，争取保质保量完成任务。

(3)项目人力资源的风险

人力资源是 ERP 项目实施过程中最为关键的资源。人力资源获取与建设中遇到的问题，例如：招募到的项目成员不适合当前项目的需要；团队成员很少或根本没有彼此合作的经验；团队气氛不积极、士气低落；团队的任务和职责分配不清楚等，均会导致项目失败。有效地发挥每一个参与项目人员的作用，保证他们能够以足够的精力参与到项目中来，是项目成功实施的基本保证。

因此，实施双方应对参与人员进行认真的评估，这种评估是双向的，既包括用户对咨询顾问的评估，也包括咨询公司对参与项目的用户方成员(在国内目前的环境下，主要是指关键用户)的评估。

同时，应保证项目人员对项目的投入程度。应将参与 ERP 项目人员的业绩评估与 ERP 项目实施的状况相关联，明确 ERP 项目是在该阶段项目相关人员最重要的本职工作；制定适当的奖惩措施；在企业中建立“一把手工程”的思想，层层“一把手”，即各级负责人针对 ERP 实施向下行使全权、对上担负全责，将一把手从个体概念延伸到有机结合的群体概念。

(4)对ERP认识不正确的风险

有的企业把ERP视为企业管理的灵丹妙药，认为既然ERP“功能强大”，只要上了ERP，企业的所有问题便迎刃而解，或者以为企业的所有流程都可以纳入到ERP 中来；还有的人简单地将ERP视为当前业务流程的电子化。

因此，要防范或减轻这种风险，需要对用户进行大量的培训：ERP 的由来、ERP 的功能、实施ERP的目的与期望等等，尽可能在用户产生“ERP不能满足我的需求和期望”这种想法之前，让用户知道“现阶段对ERP合理的需求期望是什么”。

8.1.3 参考答案

【问题1】

A 为风险规避者：属于保守派。他们自始至终都不愿意接受较大的风险，希望利用少量投资就可以得到较高的成功概率；随着投资的增加，他们希望成功概率越来越大，最后达到百分之百。

B 为风险中立者：属于中庸派。当投入少时，他们可以接受较大的风险；当投入逐渐增加时，他们就开始变得谨慎起来，希望获得成功的概率提高了，最后达到百分之百。

C 为风险冒险者：属于冒险派。他们自始至终都愿意接受较大的风险，当投入少时，他们可以接受较大的风险；随着投入的增加，他们也会变得谨慎一些，希望成功概率有所增加，最后达到百分之百。

上述案例中，甲、乙、丙分别对应 A, B, C.

【问题2】

甲属于风险规避者，做事小心谨慎，不愿意冒大风险，比较适合做程序员。

乙属于风险中立者，做事深思熟虑、讲究章法，制定计划切实可行、可进可退，比较适合做项目经理。

丙属于风险冒险者，做事大胆，敢于冒风险，一切以效益为先，积极追求成功，具有强烈的成功欲望，比较适合做产品销售人员。

【问题3】

ERP 实施中的主要风险和应对措施如下：

(1)项目范围的风险。对于不确定性越大、风险越大的ERP项目，通常采用单价合同。这种方式对客户存在较大风险，客户一般倾向于固定价或总价合同方式，但这种方式对供应商又存在较大风险。因此，双方往往在项目实施范围上发生争执。

因此，ERP项目合同中，应在项目实施前的范围界定工作上多花一些时间，对项目实施范围做尽可能清晰的界定。

(2)项目进度的风险。目前ERP项目实施存在强调“快速”的倾向，但实际操作中提高 ERP 项目进度绝非易事。一味在项目进度计划时求快，甚至是刻意追求某个具有特殊意义的日期作为项目里程碑，将对项目的控制造成很大压力，甚至导致失败。

因此，ERP 项目实施中的项目进度需要适当留有余地和柔性；任务分解详细适中，便于操作和考核；在执行过程中，应强调项目按进度执行的重要性；同时，合理利用赶工及快速跟进等方法，充分利用资源，争取保质保量完成任务。

(3)项目人力资源的风险。人力资源是ERP项目实施过程中最为关键的资源。人力资源获取与建设中遇到的问题，均会导致项目失败。

因此，实施双方应对参与人员进行认真的评估，这种评估是双向的。同时，应保证项目人员对项目的投入程度。

(4)对ERP认识不正确的风险。有的企业把ERP视为企业管理的灵丹妙药，可以解决一切问题；还有的人简单地将ERP 视为当前业务流程的电子化。

因此，需要对用户进行大量的培训，尽可能在用户产生“ERP不能满足我的需求和期望”这种想法之前，让用户知道“现阶段对ERP合理的需求期望是什么”。

8．2 案例二：蒙特卡罗分析

阅读以下关于信息系统项目管理过程中风险管理和蒙特卡罗分析方面问题的叙述，回答问题1至问题3。

8.2.1 案例场景

某公司实施 CRM 工程，实施过程中进行风险量化，其中的进度仿真采用蒙特卡罗分析，如图8-2 所示。

需求调研阶段，发现功能需求15个，非功能需求12个；需求复审阶段，有10个用户参与复审，所有复审者都有相同解释的需求数目是24个。

项目开发过程中，应用功能点法则，分解出的系统功能点有346开发过程中发现23个错误，提交后又发现3个错误。

测试过程中，采用植入故障法估算程序中原有故障总数，人为植入的故障数是10个，经过一段时间的测试后发现的播种故障数是4个，在测试中又发现原有的故障数是2个。

产品发布时，发布模块总数是46个，和以前相比，变动6个模块，新添加7个模块，删除6个模块。

【问题1】解释案例中分析图的含义，简述进度仿真中，为什么不用传统的数学分析技术(不超过250字)。

【问题2】请用 500 字之内阐述项目质量管理中蒙特卡罗模拟方法的一般步骤。

【问题3】根据案例中的数据，分别计算整体缺陷清除率、需求解释一致性、程序中原有的故障数和软件成熟度。

8.2.2 案例分析

【问题1】

本题考查考生在进度仿真中对蒙特卡罗仿真结果进行分析的能力。要想回答好该题，考生需要了解蒙特卡罗曲线的实际意义。

风险量化的目的是形成有关需要追逐的机遇和需要注意的威胁的清单，建立有关项目团队有意识地接受或忽略的那些风险源和风险事件，以及谁决定这么做的文档。进行风险量化的常用方法包括：期望的货币价值、统计综合、风险仿真、决策树等。其中风险仿真除了量化风险以外，还可以制定项目进度计划。

风险仿真使用系统的表示法或模型来分析系统的行为或性能。项目最常用的仿真形式，是使用项目网络作为项目模型的进度仿真。大多数进度仿真是基于某种形式的蒙特卡罗(Monte Carlo)分析，该方法是一种模拟方法，通过多次“执行”目标项目，从而给出计算结果的统计分布，可以用来量化风险、计算在不同活动假设下的多个项目的持续时间。根据蒙特卡罗分析所得的结果，可以评估在不利条件下进度计划的可行性；以及为了应付和减缓意外风险情况带来的影响，要准备的应急/应对计划；此外，该模拟结果还可以评估这些应急/应对计划的可行性。

该曲线利用蒙特卡罗分析描述项目的进度仿真，该S形曲线显示了针对特定日期，项目的累积概率。曲线的开始点表示项目开始的前100天为准备期，项目开始200天可以完成项目的50%,项目开始320天可以基本完成。该 S 曲线向左移动表示项目完成日期提前，但这样有更高的风险；向右移动表示项目完成日期拖延，这样风险会降低。

任何大型或复杂的项目都应该进行进度仿真，传统的数学分析技术，如关键路径法(CPM)和项目评审技术(PERT)一等，都以最小值为基准，并且不计算路径的交汇，这样会低估项目的工期。

【问题2】

本题考查考生在进度仿真中运用蒙特卡罗模拟方法进行分析的能力。要想回答好该题，考生需要熟悉蒙特卡罗模拟方法的原理和使用步骤。

蒙特卡罗模拟是一种随机模拟方法。蒙特卡罗方法得名于欧洲著名赌城-摩纳哥的蒙特卡罗。大概是因为赌博游戏与概率的内在联系，第二次世界大战时美国曼哈顿计划中把这种方法称为蒙特卡罗方法。在这之前，蒙特卡罗方法就已经存在。1777年，法国Buffon提出用投针实验的方法求圆周率π。这被认为是蒙特卡罗方法的起源。近年来，随着计算机运算速度的提高，蒙特卡罗模拟得到了广泛的运用。

蒙特卡罗模拟的基本思想是人为地造出一种概率模型，使它的某些参数恰好重合于所需计算的量。又可以通过实验，用统计方法求出这些参数的估值，把这些估值作为要求的量的近似值。

在项目管理中，常常用到的随机变量是与成本和进度有关的变量如价格、用时等。由于实际工作中可以获得的数据量有限，它们往往是以离散型变量的形式出现的。例如，对于某种成本只知道最低价格、最高价格和最可能价格；对于某项活动的用时往往只知道最少用时、最多用时和最可能用时三个数据。经验告诉我们，项目管理中的这些变量服从某些概率模型。现代统计数学则提供了把这些离散型的随机分布转换为预期的连续型分布的可能。可以利用计算机针对某种概率模型轻易进行数以千计、甚至数以万计的模拟随机抽样。项目管理中蒙特卡罗模拟方法的一般步骤是：

(1)对每一项活动，输入最小、最大和最可能估计数据，并为其选择一种合适的先验分布模型。

(2)计算机根据上述输入，利用给定的某种规则，快速实施充分大量的随机抽样。

(3)对随机抽样的数据进行必要的数学计算，求出结果。

(4)对求出的结果进行统计学处理，求出最小值、最大值以及数学期望值和单位标准偏差。

(5)根据求出的统计学处理数据，让计算机自动生成概率分布曲线和累积概率曲线(通常是基于正态分布的概率累积 S 曲线)。

(6)依据累积概率曲线进行项目风险分析。

【问题3】

本题考查考生在软件开发中定量分析软件质量的能力。要想回答好该题，考生需要熟悉软件开发常用定量分析指标和计算方法。

软件的整体缺陷清除率指的是软件产品开发过程中发现的缺陷数占软件产品所有缺陷数的比率。设 Dl 为在开发过程(提交之前)中发现的所有缺陷数，D2 为提交后发现的缺陷数，那么整体缺陷清除率就等于 Dl/(Dl+D2)。一般而言，CMM 等级越高，整体缺陷清除率也相应比较高。例如，美国的平均整体缺陷清除率目前只达到大约85%。而像AT&T, IBM,摩托罗拉和惠普这样一些大公司的顶级项目，通过实施CMM,其缺陷清除率可以超过99%。

对本题而言，D1=23，D2=3，则整体缺陷清除率为23/(23＋3)＝0.885=88.5％。

软件的需求解释一致性指的是所有复审者都有相同解释的需求数目和软件中所有需求数目(功能需求和非功能需求之和)的比率。设 Nui 为所有复审者都有相同解释的需求数目，Nf 为功能需求的数目，Nnf 为非功能需求数目，那么需求解释一致性就等于 Nui/ (Nf＋Nnf)。一般而言，如果软件需求的模糊性越低，那么需求解释一致性越接近1。

对本题而言，Nui=24，Nf=15，Nnf= 12则整体需求解释一致性为24/(15+12)=0.889= 88.9％。

捕获一再捕获抽样法利用测试前在程序中植入的故障数目来估算程序中原有的故障总数，该方法理论基础是统计分析中的等概率事件原理，应用该方法的前提是要求对播种故障和原有故障同等对待。设Ns是在测试前人为地向程序中植入的故障数(称播种故障)，ns是经过一段时间测试后发现的播种故障的数目，no是在测试中又发现的程序原有故障数，则程序中原有故障总数No的估算值为：No=(Ns/ns)no。对本题而言，Ns =10，ns = 4，no = 5则程序中原有的故障数No=(10/4)2 = 5

8.2.3 参考答案

【问题1】

该曲线利用蒙特卡罗分析描述项目的进度仿真，该S形曲线显示了针对特定日期，项目的累积概率。曲线的开始点表示项目开始的前100天为准备期，项目开始200天可以完成项目的50%,项目开始320天可以基本完成。该S曲线向左移动表示项目完成日期提前，但这样有更高的风险；向右移动表示项目完成日期拖延，这样风险会降低。

任何大型或复杂的项目都应该进行进度仿真，传统的数学分析技术，如关键路径法(CPM)和项目评审技术(PERT)等，都以最小值为基准，并且不计算路径的交汇，这样会低估项目的工期。

【问题2】

蒙特卡罗模拟是一种有效的随机模拟统计实验方法，其基本思想是人为地造出一种概率模型，使它的某些参数恰好就是所需计算的量。又可以通过实验，用统计方法求出这些参数的估值，把这些估值作为要求的量的近似值。

项目管理中，经常用到的随机变量大多是与成本和进度有关的变量，由于数据量有限，它们往往以离散性形式出现。有经验可知，这些变量服从某些概率模型，利用蒙特卡罗方法结合这些概率模型就可以把那些离散分布转换为连续分布。其一般步骤如下：

(1)对每一项活动，输入最小、最大和最可能估计数据，并为其选择一种合适的先验分布模型。

(2)计算机根据上述输入，利用给定的某种规则，快速实施充分大量的随机抽样。

(3)对随机抽样的数据进行必要的数学计算，求出结果。

(4)对求出的结果进行统计学处理，求出最小值、最大值以及数学期望值和单位标准偏差。-

(5)根据求出的统计学处理数据，让计算机自动生成概率分布曲线和累积概率曲线(通常是基于正态分布的概率累积S曲线)。

(6)依据累积概率曲线进行项目风险分析。

【问题3】

整体缺陷清除率：23÷(23+3)=23÷26=0.885=88:5%；

需求解释一致性：．24÷(15+12)=24÷27=0.889=88.9%；

程序中原有的故障数：(10÷4)×2=5;

软件成熟度：[46-(6+7+6)]÷46=27÷46=0.587=58.7%。

8.3 案例三：电子政务项目风险

阅读以下关于信息系统项目管理过程中风险管理方面问题的叙述，回答问题1至问题3。

8.3.1 案例场景

希赛信息技术有限公司(CSAI )具有良好的政府背景，主要承接政府电子政务工程，管理机制灵活，人员技术过硬。

近期承接某政府B的电子政务工程，政府B先支付部分款项，CSAI任命C作为项目主管。由于B初次实施电子政务，对其功能不是太清楚，提出的需求也不是太明确，C花费好长时间、用了很多方法进行需求分析，需求基本明确后开始开发。由于开发过程中用户需求经常变更，加重了项目组的工作量，原定4个月就完成的项目，搞了6个月才完工。

项目完成后进入试运行实施阶段，由于CSAI和政府B关系比较紧密，所以政府B一直没有支付剩余的全部款项；对于实施中某些需要政府牵头的事情，如服务器安装、培训等，政府B经常以领导近期忙、需要开会讨论等理由搪塞，结果造成整个实施进度的拖延；政府主要领导对这个系统的指指点点，随便一句话，就要进行需求变更，导致项目试运行一直无法结束；政府B没有项目周期的概念，对合同规定的验收等反馈不予回应，需要企业CSAI 的高层领导亲自协调。源于此，项目组成员十分不满，C也十分苦恼。

【问题1】如果C想快速结束这个项目，请用300字内讲述应该怎么处理。

【问题2】在现阶段电子政务开发和实施过程中，如何应付政府领导的长官意志和政府工作的拖沓作风，试用450字内回答。

【问题3】电子政务承办机构在电子政务信息化实施过程中，为了避免项目失败，同时也为了获得收益，需要解决政府机关对于电子政务理解的哪些误区，试用300字内回答。

8.3.2 案例分析

【问题1】

本题考查考生在电子政务开发中应对项目收尾过程中风险和冲突的能力。要想回答好该题，考生需要熟悉电子政务开发的特点和沟通技巧。

(1)项目结束基础是政府主管领导要有一定的信息化基础知识，消除对电子政务认识上的误区，真正理解电子政务的本质和作用，让他们认识到电子政务是他们以后工作中不可缺少的部分。这样才能发挥他们的主观积极性，结合实际情况，提出他们真正需要解决的问题；而不是依靠他们的长官意志，提出一些不切合卖际的、易变的需求。要实现这一点，需要项目经理安排人员定期到政府机关进行信息化普及培训。

(2)项目结束关键是项目经理和公司主管上级的沟通，使其产生迫切的结束需求，并准备好项目结束所需要的文档资料，如：项目章程、项目范围说明书、项目管理计划、合同文件等，让主管上级和政府机关电子政务主管领导交涉。

(3)项目结束的核心是政府主管领导按照合同和计划办事，积极参与项目结尾过程。项目移交试运行以后，要给政府主管领导培训项目管理相关知识，使他们意识到项目验收的重要性，意识到无限制地拖延下去会对政府机关的权威、形象和公司的收益造成不好的影响，利用他们的主观积极性克制拖沓的工作作风。

【问题2】

本题考查考生在电子政务开发应付政府领导的长官意志和政府工作的拖沓作风的能力。要想回答好该题，考生需要了解我国电子政务系统开发和应用的现状、特点、沟通技巧、合同管理方法、需求变更方法、验收管理方法等内容。

该案例是目前电子政务软件公司面对的一个典型问题。国内某些政府部门拖沓的工作作风和长官意志，使 IT 业内人士感到无所适从，这也是许多电子政务项目没能取得预期效果的重要原因之一。

但作为项目结果的接受者，客户的要求应该是放在第一位的，项目是为了客户而存在的，应付这种情况带来的风险正是一个成熟的项目团队需要具有的能力。

首先，所有从事电子政务软件开发的公司必须对中国电子政务建设有一个明确的认识。即电子政务建设是伴随中国政府机构和管理体制改革而进行的，改革才是目的，电子政务软件的开发和建设只是手段；对于不断快速变革的体制，项目需求不变是不可能的，而且客户的特殊身份决定了必须用不同方式来约束客户需求的变化。

其次，中国各级政府部门的信息化管理水平还是比较低的，网络化办公的意识还基本没有，在基层政府部门尤为突出一。在这样的客户面前，技术业务人员必须有耐心，帮助政府部门普及信息化教育，讲解语言尽量大众化，不要用太多的专业名词。只有提高政府人员的信息化意识，才能够消除政府机关和软件公司的沟通鸿沟，淡化政府领导的长官意志，转变政府工作的拖沓作风。

电子政务建设是“一把手”工程，只有得到政府主要领导的支持，电子政务建设才能顺利实施。因此对政府主管领导的培训及其重要，要尽一切可能、一切机会向他们灌输信息化思想，注意沟通，要让他们在思想上接受电子政务。在当代中国，政府工作特点是垂直式上行下效关系，而且这些年随着公务员制度的诞生，大批年轻人进入政府机关，他们伴随中国互联网发展而成长，思想活跃，易于接受新事物，是实施电子政务的主力军，只要上级领导决定实施电子政务，他们会义无反顾执行。

项目经理要注意和政府机关及时沟通，遇到问题要及时协商和解决。实在无法解决的问题要请示企业上级领导，通过公司高层领导和客户领导的密切沟通和交涉，大部分问题会友好解决，项目也会顺利验收。

电子政务系统开发的关键在于“制定阶段目标”。公司要先将电子政务系统的特性与客户在理念上进行沟通，双方达成共识：理想、完善的系统是不存在的。改革在深入，认识在提高，技术在发展，系统也会不断地调整下去，只有在应用中，系统才能得以完善，工作人员的认识和水平才有所提高，转而提出更切合实际的需求，而不是施展长官意识随意提出系统更改要求。

与客户达成共识后，用户提出需求变更时一般有两种应对方法：其一，接受变更，立即执行；其二，接受变更，后期项目统一执行。这样既保持了客户的良好关系，又避免了当期目标的拖延实施，造成项目延误。

项目实施中的关键环节要特别注意：合同的目标和工期，要明确阶段；需求调查和需求变更要有清楚的文档和会议纪要；阶段验收前，文档要齐全，阶段目标要保证实现，后期目标调整要有承诺。

阶段验收十分必要，要使政府部门认识验收重要性，制定合理的项目验收计划可以制衡政府拖沓作风，考虑现阶段实际情况，阶段验收计划要有柔性，一方面考虑政府对电子政务理解的滞后，不可操之过急，另一方面又要防止无限制的拖延。

【问题3】

本题考查考生把握当前电子政务建设现状和根源的能力。要想回答好该题，考生需要了解当前鱼待解决的政府机关电子政务认识上的误区。

在现阶段电子政务实施过程中，政府机关存在一些不切实际的想法和误区，给工程实施带来一定影响。为了保证电子政务顺利实施，必须改正想法、消除误区。

(1)形象工程问题。许多领导认为信息化只是形象工程，解决不了什么事。很多机构实施“信息化”的目的和意愿并不是利用信息化提升管理、实施根本的业务流程再造。有的纯粹是为了所谓“领导工程/面子工程”，迫于行政压力或者舆论压力而实施；有的是为了炒作，获取在社会舆论中的形象；还有的机构实施“信息化”的初衷只是为领导或者高层提供“信息简报”。这些都是对“信息化”的误解，必然不能从根本上提升管理水平。

(2)技术与决策的关系问题。信息系统是七分管理，三分技术，IT 人员只是对系统的技术支持，而各级管理人员、尤其是最高决策者是实施工作的领导与主要参与者。很多领导认为信息化改造工程是技术部门或者信息化部门的事情，或者就是简单地上一两套信息化软件。实际上，信息化改造涉及到管理和业务流程的方方面面，它不是简单的修修补补，而是要对政府机构的整体改造，是一个“脱胎换骨”的过程，这样才能根本上让电子政务工程产生效益。

(3)一步到位的问题。许多领导同志认为信息化是一步到位工程，这本身就是误区。信息系统只是政府管理工作的一种辅助性手段，信息化不是一步到位工程，更不是“交钥匙”工程，而是一种长期的、不断改善的系统工程。因此，要选择实力强、服务好的供应商，建立长期的合作关系，在信息化建设过程中根据自身条件整体规划、分步实施，因地制宜。

(4)信息上载和信息安全问题。在我国有些许多政府部门的观念中，上网的全部过程和目的似乎就是注册域名、建立网站、发布信息。不少政府网站建立后所发布的信息和消息一两年没有变化；许多政府承诺的服务在网站上一应俱全，但实际操作中还是老一套；许多政府部门以信息安全为借口，将本来可以共享的信息拒绝上网。这些问题都使电子政务的功能没有得到真正发挥。

8.3.3 参考答案

【问题1】

(1)项目结束基础是政府主管领导要真正理解电子政务的本质和作用，提出他们真正需要解决的问题，而不是依靠他们的长官意志，提出一些不切合实际的、易变的需求。因此，需要C安排人员定期到政府机关进行信息化普及培训。

(2)项目结束关键是 C 和公司主管上级的沟通，使其产生迫切的结束需求，并准备好项目结束所需要的文档资料，让主管上级和政府机关电子政务主管领导交涉。

(3)项目结束的核心是政府主管领导按照合同和计划办事，积极参与项目结尾过程。为此，C 要给政府主管领导培训项目管理相关知识，使他们意识到项目验收的重要性。

【问题2】

首先，公司必须明确认识：电子政务建设中政府体制改革是目的，软件开发和建设只是手段，体制变化，所以项目需求也要变化，而且客户的特殊身份决定了必须用不同方式来约束客户需求的变化。

其次，技术业务人员必须耐心帮助政府部门普及信息化教育。

电子政务建设是“一把手”工程，因此对政府主管领导的培训极其重要，要让他们在思想上接受电子政务。

项目经理要注意和政府机关及时沟通，遇到问题要及时协商和解决，实在无法解决的问题要请示企业上级领导。

电子政务系统开发的关键在于“制定阶段目标”。公司与客户要达成共识：理想、完善的系统是不存在的。只有在应用中，系统才能得以完善，工作人员的认识和水平才有所提高，转而提出更切合实际的需求，而不是施展长官意识 随意提出系统更改要求。

与客户达成共识后，用户提出需求变更时一般有两种应对方法：其一，接受变更，立即执行；其二，接受变更，后期项目统一执行。

项目实施中的关键环节要特别注意。

阶段验收十分必要，要使政府部门认识验收重要性，考虑现阶段实际情况，制定阶段验收计划要有柔性。

【问题3】

(1)形象工程问题。许多领导认为信息化只是形象工程，解决不了什么事。有的纯粹是为了所谓“领导工程/面子工程”，迫于行政压力或者舆论压力而实施；有的是为了炒作，获取在社会舆论中的形象；还有的机构实施“信息化”的初衷只是为领导或者高层提供“信息简报”。

(2)技术与决策的关系问题。很多领导认为信息化改造工程是技术部门或者信息化部门的事情，或者就是简单地上一两套信息化软件。

(3)一步到位的问题。许多领导同志认为信息化是一步到位工程，或者是“交钥匙”工程。

(4)信息上载和信息安全问题。不少政府网站建立后所发布的信息和消息一两年没有变化；许多政府承诺的服务在网站上一应俱全，但实际操作中还是老一套；许多政府部门以信息安全为借口，将本来可以共享的信息拒绝上网。

8．4 案例四：风险管理方案

阅读以下关于信息系统项目管理过程中风险管理方面问题的叙述，回答问题1至问题3。

8.4.1 案例场景

20##年，国内一家省级电信公司(H公司)打算上某项目，经过发布RFP (需求建议书)，以及谈判和评估，最终选定希赛信息技术有限公司(CSAI)为其提供 IP 电话设备。宏达公司作为 CSAI 的代理商，成为了该项目的系统集成商。李先生是该项目的项目经理。

该项目的施工周期是三个月。由CSAI负责提供主要设备，宏达公司负责全面的项目管理和系统集成工作，包括提供一些主机的附属设备和支持设备，并且负责项目的整个运作和管理。CSAI和宏达公司之间的关系是一次性付账。这就意味着 CSAI 不承担任何风险，而宏达公司虽然有很大的利润，但是也承担了全部的风险。

3个月后，整套系统安装完成。但自系统试运行之日起，不断有问题暴露出来。H公司要求宏达公司负责解决，可其中很多问题涉及 CSAI 的设备问题。因而，宏达公司要求 CSAI 予以配合。但由于开发周期的原因，CSAI无法马上达到新的技术指标并满足新的功能。于是，项目持续延期。为完成此项目，宏达公司只好不断将CSAI 的最新升级系统(软件升级)提供给H公司，甚至派人常驻在H公司(外地)。

又经过了3个月，H公司终于通过了最初验收。在宏达公司同意承担系统升级工作直到完全满足RFP 的基础上，H公司支付了10%的验收款。然而，20##年底，CSAI 由于内部原因暂时中断了在中国的业务，其产品的支持力度大幅下降，结果致使该项目的收尾工作至今无法完成。

【问题1】请用200字以内文字描述该项目存在的主要问题和原因。

【问题2】请用300字以内文字结合你本人的实际项目经验，描述如何解决案例中所述问题的办法。

【问题3】请用400字以内文字说明如果你是李经理，?你觉得应如何制定有效的项目风险管理方案吗？

8.4.2 案例分析

【问题1】

该项目最终失败的原因主要在于风险控制和风险处理机制。导致项目失败，尤其是项目预期的经济指标没有完成，这是非常遗憾的事情。项目失败或没有达到预期的经济指标的因素有很多，其中风险管理是一个极为重要的因素。

在很多 IT 项目中，由于竞争和其他原因造成了风险过度集中在某一个相对弱势的角色身上。在本案例中，宏达公司就处于这样的境地：一方面它需要依赖代理 CSAI 的产品生存，另一方面要它还必须要满足用户的具体需求。

我们知道，项目经理有识别和处理风险的责任。通常，项目经理在运作这样的项目时，要充分考虑到自己公司所处的地位，充分发挥自己的作用，平衡各方的利益。

【问题2】

事实上，项目管理知识体系中关于风险管理方面有非常详细的论述。不过，在实际工作中，如果完全照搬国外项目管理的风险识别和控制理论，是很难达到较好的效果。一般来说，对于国内公司的项目经理来说，除了理解项目管理知识体系中的理论外，还需要在实践中进行总结。

(1)签合同前的“须知”

一般情况下，如果项目经理在项目合同签订以前加入项目，可以充分利用项目采购管理一章的知识，了解自己公司在项目中的位置，对买方提出的 RFP 认真回答，规避潜在的风险，这是非常重要的。对于 RFP 中过高的要求不能完全满足时，应充分说明，并在以下几个方面有充分的准备和考虑：

①合同的类型。通常，在 IT 项目中，代理商与最终用户的合同类型是很难改变的固定价格合同，但对代理商和设备商之间的合同是有很多讲究的。代理商和国外供货商一般是通过信用证付款，但很多时候，为了拿到订单，供货商通常给予代理商一定的信用额度和付款方式的优惠。代理商应充分利用这一利害关系，在合同签订以前决不能轻易让步。

②项目实施方对项目的熟悉程度。通常情况下，做一个成熟项目的风险小，而做新项目的风险高。在本案例中，宏达公司是第一次进行类似的项目，并不完全了解其中的风险，更无可利用的历史数据。因此，在这种情况下，最好采用“让利于人，风险共担”的策略。具体做法是，将已经识别的具有风险的部分外包(风险转移)，或者单独与供货商签订补充合同。这样做可能损失了部分利益，但降低了风险，并且减少了很多额外投入。

③具有明确的规范 (Specification),包括设计规范 (Design),功能性规范 (Functional)、性能规范(Performance).明确的规范是识别风险和规避风险的前提条件。如果已经具有一定的历史数据，可以采用头脑风暴的方式对规范加以确认和识别，这项工作可与风险识别同时进行。

(2)风险的预警和量化

在项目的进行过程中，项目经理和项目的拥有人要将风险管理纳入日常工作的重要步骤。要明确成本与风险、成本与时间的关系。在制定完善的风险管理计划的基础上，从以下几个方面入手。

①建立管理风险预警机制。对于风险集中的一方，建立管理风险预警是风险管理计划的重要补充。这里的预警是指对有可能超出项目经理管理范围的风险事件的预警。预警机制可由低到高，并由定期的项目联席管理(多方)会议讨论处理。这样可以减少处理风险事件的响应时间；同时，使高层管理者能够及时介入，处理可能产生的风险。

②风险的量化。之所以单独将风险的量化加以论述，是因为很多情况下，项目经理的确已经对风险进行了识别，并采取了应对措施，但并未对此风险带来的影响进行量化(通常可以以货币或者时间损失加以估算)。量化过的风险是项目经理采用相应对策的前提。在本案例中，宏达公司了解 CSAI升级软件不能按时提供，这本身就需要量化。这个风险带来的就是 10%的验收款和 10%尾款的不能按时支付。如果一开始，宏达公司能够将付款和风险对应起来，就知道该风险是管理风险，并且是不能够接受的。

总之，风险集中的项目管理起来是极为复杂的。要尽量在第一时间把事情考虑好，不能指望风险小的一方替风险大的一方承担很多责任。尤其是目前进入中国市场的国外企业很多，情况复杂，IT 市场的变化有时很难预测，更应该注意风险带来的影响。

【问题3】

如何制定有效的项目风险管理方案？

在全面分析评估风险因素的基础上，制定有效的管理方案是风险管理工作的成败之关键，它直接决定管理的效率和效果。因此，翔实、全面、有效成为方案的基本要求，其内容应包括：风险管理方案的制定原则和框架、风险管理的措施、风险管理的工作程序等。

(1)风险管理方案的制定原则

①可行、适用、有效性原则

管理方案首先应针对已识别的风险源，制定具有可操作的管理措施，适用有效的管理措施能大大提高管理的效率和效果。

②经济、合理、先进性原则

管理方案涉及的多项工作和措施应力求管理成本的节约，管理信息流畅、方式简捷、手段先进才能显示出高超的风险管理水平。

③主动、及时、全过程原则

项目的全过程建设期分为前期准备阶段(可行性研究阶段、勘察设计阶段、招标投标阶段)、施工及保修阶段、生产运营期。对于风险管理，仍应遵循主动控制、事先控制的管理思想，根据不断发展变化的环境条件和不断出现的新情况、新问题，及时采取应对措施，调整管理方案，并将这一原则贯彻项目全过程，才能充分体现风险管理的特点和优势。

④综合、系统、全方位原则

风险管理是一项系统性、综合性极强的工作，不仅其产生的原因复杂，而且后果影响面广，所需处理措施综合性强。例如，项目的多目标特征(投资、进度、质量、安全、合同变更和索赔、生产成本、利税等目标)。因此，要全面彻底地降低乃至消除风险因素的影响，必须采取综合治理原则，动员各方力量，科学分配风险责任，建立风险利益的共同体和项目全方位风险管理体系，才能将风险管理的工作落到实处。

(2)风险管理方案计划书内容框架

计划书一般应包括：

①项目概况；

②风险识别(分类、风险源、预计发生时间点、发生地、涉及面等)；

③风险分析与评估(定性和定量的结论、后果预测、重要性排序等)；

④风险管理的工作组织(设立决策机构、管理流程设计、职责分工、工作标准拟订、建立协调机制等)；

⑤风险管理工作的检查评估。

风险管理的综合性措施：

①经济性措施：主要措施有合同方案设计(风险分配方案、合同结构设计、合同条款设计)；保险方案设计(引入保险机制、保险清单分析、保险合同谈判)；管理成本核算。

②技术性措施：技术性措施应体现可行、适用、有效性的原则，主要有预测技术措施(模型选择、误差分析、可靠性评估)；决策技术措施(模型比选、决策程序和决策准则制定、决策可靠性预评估和效果后评估)；技术可靠性分析(建设技术、生产工艺方案、维护保障技术)。

③组织管理性措施：主要是贯彻综合、系统、全方位原则和经济、合理、先进性原则，包括管理流程设计、确定组织结构、管理制度和标准制定、人员选配、岗位职责分工，落实风险管理的责任等。还应提倡推广使用风险管理信息系统等现代管理手段和方法。

8.4.3 参考答案

【问题1】

该项目最终失败的原因主要在于风险控制和风险处理机制。在很多 IT 项目中，由于竞争和其他原因造成了风险过度集中在某一个相对弱势的角色身上。在本案例中，宏达公司就处于这样的境地：一方面它需要依赖代理 CSAI 的产品生存，另一方面要它还必须要满足用户的具体需求。

【问题2】

一般情况下，如果项目经理在项目合同签订以前加入项目，可以充分利用项目采购管理一章的知识，了解自己公司在项目中的位置，对买方提出的 RFP 认真回答，规避潜在的风险，这是非常重要的。对于 RFP 中过高的要求不能完全满足时，应充分说明。在项目的进行过程中，项目经理和项目的拥有人要将风险管理纳入日常工作的重要步骤。要明确成本与风险、成本与时间的关系。制定完善的风险管理计划，建立管理风险预警机制。

【问题3】

在全面分析评估风险因素的基础上，制定有效的管理方案是风险管理工作的成败之关键，它直接决定管理的效率和效果。因此，翔实、全面、有效成为方案的基本要求，其内容应包括：风险管理方案的制定原则和框架、风险管理的措施、风险管理的工作程序等。

8.5 案例五：合作项目的风险

阅读以下关于信息系统项目管理过程中风险管理方面问题的叙述，回答问题1至问题3。

8.5.1 案例场景

希赛信息技术有限公司(CSAI)为某省某运营商建立一个商务业务平台，并采用合作分成的方式。也就是说所有的投资由CSAI方负担，商务业务平台投入商业应用之后运营商从所收取的收入中按照一定的比例跟CSAI作分成。

同一时间，平台有两个软件公司(CSAI)和C公司一起进行建设，设备以及技术均独立，也就是说同时有两个平台提供同一种服务，两个平台分别负责不同类型的用户。

但是整个项目进行了10个月，并经历了一个月试用期之后。准备正式投入商业应用的第一天，运营商在没有任何通知的情况下，将该商务业务平台上所有的用户都转到了CSAI 竞争对手C公司的平台上去了，也就是停止使用CSAI的商务业务平台。

整个项目CSAI投资超过两百万，包括软、硬件，以及各种集成、支持、差旅费用，等等。现在CSAI所有的设备被搁置但不能搬走，并没有被遗弃，运营商口头声称还会履行合同，按照原来的分成比例给CSAI分成。但是CSAI无法得知每个月的使用情况、用户多少，所以根本无法知道他们究竟应该拿到多少分成。所以，运营商的口头承诺根本如同鸡肋。在出事当天，项目经理王刚呆若木鸡。

【问题1】请用200字以内文字描述该项目存在的主要问题和原因。

【问题2】请用300字以内文字描述发生这样的事情，项目经理有没有责任？如果有责任，那么具体有哪些责任？

【问题3】请用400字以内文字结合你本人的实际项目经验，说明如果你是王经理，你觉得应如何避免这样的事情发生？

8.5.2 案例分析

【问题1】

类似本案例这种结局的项目很多，风险管理不再只是纸上谈兵，而应有具体的量化评估体系，具体的风险应对对策。由此可见国内企业在项目管理的实施上还没有深入。有很多是整体环境和管理层的问题，但项目经理也具有不可推卸的责任。

其一，国内企业对项目管理的实施很浅薄：一个普遍现象就是购买所谓专业的项目管理软件来做项目管理，以为这样就可以解决一切问题，就很专业很规范了。但企业本身的管理体系和软件的项目管理思想格格不入，至少没有融合，或者是根本没有深入，在这种背景下的项目管理充其量也就是定期搞个报表哄哄领导。所以一旦项目出现任何风险就会岌岌可危。

其二，项目管理体系不健全：由于企业管理层对项目管理知识的匾乏，导致公司没有一个比较健全的项目管理体系，正是因为缺乏项目生存环境，所以项目经理们在实施项目的时候四处碰壁，无可奈何。当然这并不是为项目经理推脱责任，这个道理就好像外企的职业经理人空降后全都天折了一样。别忘了项目经理的权利最重要，项目经理没有决策权，做什么都白做。

其三，项目管理的量化时代迟迟没有到来：这个案例的直接原因就是风险管理的缺乏，如果有一个好的风险预警体系，这种问题应该很早能预料到，能够增加一些防范措施。我们现在所谓的风险管理只是象征性地列个risk list，没有一个很好的量化和评估过程，基本只是个文档。所以这样的管理都是些面子过程。项目经理的职责是跟踪监控，那么没有具体的数据，所谓的监控只能沦为例行公事。

其实，导致这种状况的原因可能还有些更深层次的外部因素，比如国内企业目前基本是以市场为导向，而中国处于一种市场经济的发展阶段，市场化并不成熟，各种因素导致了企业为了市场而急于求成，本来就缺乏规范管理的企业就更谈不上项目管理了。

当然种种原因不足以说明我们的项目管理就不能进行了，在这个案例中，项目经理负有不可推卸的责任，你的风险列表里是否已经识别到了这种合同风险或市场风险呢？如果有，那么你是否采取过什么沟通手段和措施。也许你没有根本解决这个问题权利，但你有努力挽救这种结局的责任和义务。

【问题2】

软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题，以及这些问题对软件项目的影响。软件项目风险会影响项目计划的实现，如果项目风险变成现实，就有可能影响项目的进度，增加项目的成本，甚至使软件项目不能实现。如果对项目进行风险管理，就可以最大限度地减少风险的发生。但是，目前国内的软件企业不太关心软件项目的风险管理，结果造成软件项目经常性的延期、超过预算，甚至失败。成功的项目管理一般都对项目风险进行了良好的管理。因此任何一个系统开发项目都应将风险管理作为软件项目管理的重要内容。

在项目风险管理中，存在多种风险管理方法与工具，软件项目管理只有找出最适合自己的方法与工具并应用到风险管理中，才能尽量减少软件项目风险，促进项目的成功。

项目风险管理是指为了达到项目的目标，识别、分配、应对项目生命周期内风险的科学与艺术。

项目风险管理的目标是使潜在机会或回报最大化，使潜在风险最小化。风险管理涉及的主要过程包括：风险识别，风险量化，风险应对计划制定和风险监控，如图 8-3 所示。风险识别在项目的开始时就要进行，并在项目执行中不断进行。就是说，在项目的整个生命周期内，风险识别是一个连续的过程。

(1)风险识别：风险识别包括确定风险的来源，风险产生的条件，描述其风险特征和确定哪些风险事件有可能影响本项目。风险识别不是一次就可以完成的事，应当在项目的自始至终定期进行。

(2)风险量化：涉及对风险及风险的相互作用的评估，是衡量风险概率和风险对项目目标影响程度的过程。风险量化的基本内容是确定哪些事件需要制定应对措施。

(3)风险应对计划制定：针对风险量化的结果，．为降低项目风险的负面效应制定风险应对策略和技术手段的过程，风险应对计划依据风险管理计划、风险排序、风险认知等依据，得出风险应对计划、剩余风险、次要风险以及为其他过程提供的依据。

(4)风险监控：涉及整个项目管理过程中的风险进行应对。该过程的输出包括应对风险的纠正措施，以及风险管理计划的更新。每个步骤所使用的工具和方法详见表 8- 1。

【问题3】

软件项目的风险无非体现在以下四个方面：需求、技术、成本和进度。IT 项目开发中常见的风险有如下几类：

1．需求风险

(l)需求已经成为项目基准，但需求还在继续变化。

(2)需求定义欠佳，而进一步的定义会扩展项目范畴。

(3)添加额外的需求。

t4)产品定义含混的部分比预期需要更多的时间。

(5)在做需求中客户参与不够。

(6)缺少有效的需求变化管理过程。

2．计划编制风险

(1)计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致。

(2)计划是优化的，是“最佳状态”，但计划不现实，只能算是“期望状态”。

(3)计划基于使用特定的小组成员，而那个特定的小组成员其实指望不上。

(4)产品规模(代码行数、功能点、与前一产品规模的百分比)比估计的要大。

(5)完成目标日期提前，但没有相应地调整产品范围或可用资源。

(6)涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。

3.组织和管理风险

(1)仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长。

(2)低效的项目组结构降低生产率。

(3)管理层审查决策的周期比预期的时间长。

(4)预算削减，打乱项目计划。

(5)管理层做出了打击项目组织积极性的决定。

(6)缺乏必要的规范，导致工作失误与重复工作。

(7)非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。

4.人员风险

(l)作为先决条件的任务(如培训及其他项目)不能按时完成。

(2)开发人员和管理层之间关系不佳，导致决策缓慢，影响全局。

(3)缺乏激励措施，士气低下，降低了生产能力。

(4)某些人员需要更多的时间适应还不熟悉的软件工具和环境。

(5)项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低。

(6)由于项目组成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作。

(7)不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性。

(8)没有找到项目急需的具有特定技能的人。

5．开发环境风险

(1)设施未及时到位。

(2)设施虽到位，但不配套，如没有电话、网线、办公用品等。

(3)设施拥挤、杂乱或者破损。

(4)开发工具未及时到位。

(5)开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具。

(6)新的开发工具的学习期比预期的长，内容繁多。

6.客户风险

(1)客户对于最后交付的产品不满意，要求重新设计和重做。

(2)客户的意见未被采纳，造成产品最终无法满足用户要求，因而必须重做。

(3)客户对规划、原型和规格的审核决策周期比预期的要长。

(4)客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更。

(5)客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长。

(6)客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作。

7．产品风险

(1)矫正质量低下的不可接受的产品，需要比预期更多的测试、设计和实现工作。

(2)开发额外的不需要的功能(镀金)，延长了计划进度。

(3)严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作。

(4)要求与其他系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作。

(5)在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题。

(6)开发一种全新的模块将比预期花费更长的时间。

(7)依赖正在开发中的技术将延长计划进度。

8.设计和实现风险

(1)设计质量低下，导致重复设计。

(2)一些必要的功能无法使用现有的代码库实现，开发人员必须使用新的库或者自行开发新的功能。

(3)代码和库质量低下，导致需要进行额外的测试，修正错误或重新制作。

(4)过高估计了增强型工具对计划进度的节省量。

(5)分别开发的模块无法有效集成，需要重新设计或制作。

9．过程风险

(1)大量的纸面工作导致进程比预期的慢。

(2)前期的质量保证行为不真实，导致后期的重复工作。

(3)太不正规(缺乏遵循软件开发策略和标准的意识)，导致沟通不足，质量欠佳，甚至需重新开发。

(4)过于正规(教条地坚持软件开发策略和标准)，导致过多耗时于无用的工作。

(5)向管理层撰写进程报告占用开发人员的时间比预期的多。

(6)风险管理粗心，导致未能发现重大的项目风险。

软件项目管理从某种意义上讲，就是风险管理。我们尽量去定义明确不变的需求，以便进行计划并高效管理，但商业环境总是快速变化的，甚至是无序的变化。所以，软件企业在进行项目管理的过程中，必须采用适合自己的风险管理方法进行风险管理，以确保软件项目在规定的预算和期限内完成项目。

8.5.3 参考答案

【问题1】

首先，CSAI由于被项目“合作分成”的利益所迷惑，所以对项目的可行性分析和风险分析做得很不够，才会出现全额承担项目费用的情况，将自己的成本控制得非常高，所以项目经理、行政主管都有错。

其次，虽然 CSAI 自身承担高额的成本，但对于合同条款的管理没有严格约束，这是导致运营商出现平台停用后没有足够法律条款约束其的后果。所以律师、项目经理需要反省。

最后，公司需要对项目的技术进一步审核，修正存在的问题，以免运营商提出种种没有达标的借口，并整理相关的在合同签订时、项目实施中、事后运营商出具的相关的文档为日后可能出现的官司准备。所以整个项目团队都要积极参与。

【问题2】

(1)从本案的商业模式来看，CSAI 与运营方实际上首先都是投资方，运营方投入的是品牌和渠道，CSAI 投入的是技术和资金，而从本案来看，CSAI 好像将自己定位为一个项目执行方，那么一开始已经注定成功的可能性不大，出现这样的问题也在情理之中。

(2)这个商业模式本身没有问题，有问题的是项目经理在出现了一个潜在的竞争者却“浑然不觉”，毕竟在利益和商业道德之间至少在目前多数人会选择利益，抛弃道德，这个是项目经理在做项目可行性计划时的失误，至少，可行性计划中对这方面的风险分析是有缺陷的。

(3)项目经理不缺乏项目管理的经验，而缺乏必要的商业运作经验，本项目的失败项目经理要承担部分责任，毕竟在项目执行过程中一定会有很多“蛛丝马迹”表明运营商将会有违约的可能，这时候项目经理应该及时向自己的组织通报项目存在的风险，便于公司的高层及时与运营商沟通并约束对方履行合同，当然，本项目失败的根本原因在 CSAI 公司的高层，至少他们应该承担项目失败成本 85％的责任。

(4)项目经理应提高自己的法律意识和商业意识。

【问题3】

首先，项目的风险管理应该在项目实施之前就应该做好，准备好风险出现时的应急措施。任何项目可能都存在风险性，如何圆满处理和化解风险才是项目经理在管理项目时应该考虑的。

其次，项目经理如果在与运营商谈此项目之时，就参与进入的话，项目经理是有推卸不了的责任，因为项目经理应该知道项目各方的权责利问题，尽可能把项目风险把握在自己可控之中，并且有一定的法律依据。

再次，“合作分成”这样的搭建平台的方式本身就具有很大的风险性，但是现在工作中这种合作方式又普遍存在的，这样就要求项目经理应该具有很强的自我法律保护意识，在签署项目合作协议时，应该规范合作各方的权责利，规避项目风险！