项目风险的计划和来源分析

　　摘要：请注意，风险分解结构如何提供一个简单的、单页图表，以帮助确保项目团队充分考虑与 IT项目相关联的各类风险。除了依据项目或产品的特性识别风险外，同样需要根据项目管理知识领域，例如范围、时间、成本和质量来识别潜在的风险。

　　11，2 风险管理计划

　　 风险管理计划是决定如何处理和计划项目风险管理活动的过程。这一过程的主要成果是风险管理计划。风险管理计划(riskmanagementplan)记录了项目全过程中的风险管理的流程。项目团队通常应在项目生命周期的早期举行几次计划会议，帮助开发编制风险管理计划。项目团队应审查项目文档、以及公司的风险管理政策、风险种类、以往项目的经验教训报告，创建风险管理计划的模板。审查不同干系人的风险承受力同样非常重要。例如，如果项目发起人是风险厌恶型的，就需要采用不同于针对风险喜好型发起人的方法来管理风险。

　　 风险管理计划概括了风险管理在具体项目中将如何执行。像其他的专业知识领域计划一样，它是项目管理计划的子集。表11-2列出了在风险管理计划中应该着重强调的一般主题。明确角色和责任，准备预算和风险相关工作的进度评估，识别风险类别等都是非常重要的事情。同时，描述风险管理如何具体操作，包括创建风险管理文档，评估风险概率和影响也都是非常重要的事情。风险管理计划的详细程度依据项目需要的不同而差异较大。

　　很多项目除了编制了风险管理计划以外，还有应急计划、退路计划和应急储备金。应急计划(contingencyplans)是指如果所识别的风险事件发生，项目团队将采取的预先规定的措施。例如，如果项目团队知道，一个新的软件包发布后，却可能不能及时地应用到项目中，那么他们就可能执行应急计划，使用现有的旧版软件。退路计划(fallbackplans)是对项目目标的完成具有很大影响的风险编制的计划。如果降低风险的措施无效，将实施这个计划。例如，一个刚毕业的大学生对于自己毕业后住在哪里应该有一套主要计划和几套应急计划，但是，如果这些计划都无法实现，退路计划可能就是要在家里住一段时间。有时候应急计划和退路计划的名词可能交叉使用。应急储备金(contingencyreserves)或应急补贴(contingencyallowances)是指由项目发起人或组织所提供的储备，用于将项目成本或进度超期的风险降低到可接受的程度。例如，如果由于员工对一些新技术的使用缺乏经验，而项目团队又没有意识到，较终导致项目偏离正常轨迹，那么项目发起人可以从应急储备金中拨出一部分资金，雇用外部顾问，为项目成员使用新技术提供培训和咨询。

　　 在真正理解并应用其他的项目风险管理过程于IT项目之前，有必要先认识并理解风险的一般来源。

　　11．3 1T项目风险的一般来源

　　 多项研究表明，IT项目有着一些共同的风险来源。例如，StandishGroup对1995年的“混沌”进行了后续研究，他们把该项研究叫做“未完成的航行”。这项研究将60位IT的专业人员召集在一起，详细说明如何评价项目成功的可能性。表11—3列出了StandishGroup的成功潜力打分表，并给出了判断项目是否成功标准的因素，其权重表明这些因素的相对重要性。如果一个潜在项目没有达到较低分数，那该组织可能决定不继续开展项目工作，或者在投入较多的时间和资金之前，采取一定的行动减少风险。”

　　 StandishGroup针对上述成功标准，提供了具体的问题，用以帮助确定给项目分配的分数。例如，与用户参与相关的5个问题包括：

　　 ●我有合适的用户吗？

　　 ●我尽早并且经常让用户参与吗?

　　 ●我与用户建立了良好的关系吗?

　　 ●我方便了用户的参与吗？

　　 ●我发现了用户需要什么吗?

　　 对应于每个成功标准因素的问题数量决定了问题的肯定回答的得分数。例如，在用户参与这项中共有5个问题，每次肯定地回答一个问题，就加3．8(19／5)分；19代表标准因素的权重，5代表问题的数量。因此，你就可以给用户参与的每项标准因素分配一个值，这个值是通过给每个肯定的回答加3．8分得到的。

　　 很多组织开发自己的风险调查问卷，这些问卷所描述的更广范围的风险类型包括：

　　 ●市场风险：如果IT项目是生产新的产品或服务，那么它对组织有用吗?产品或服务能销售出去吗?用户会接受并采用这一产品或服务吗?还有没有其他人能更快、更好地生产该产品或服务，而使这一项目既浪费时间，又浪费金钱？

　　 ●财务风险：组织有能力承担这一项目吗?干系人在财务预测时有多少信心?项目会满足NPV、ROI和回报估计吗?如果不能满足，组织还有能力继续进行该项目吗?该项目是利用组织的财务资源的较好途径吗？

　　 ●技术风险：该项目在技术上可行吗?将采用成熟、领先或者过时的技术?什么时候决定采用何种技术?硬件、软件和网络功能适合吗?是否需要及时获取相应的技术来满足项目目标?在有用的产品生产出来之前，该技术会过时吗?如果需要，你可以将技术风险划分为硬件、软件和网络技术。

　　 ●人力风险：组织可以找到具备相应技能的合适人选成功地完成项目吗?成员有合适的管理和技术能力吗?他们有足够的经验吗?高层管理是否支持该项目?是否存在一个项目倡导者?组织熟悉项目的发起人和客户吗?和发起人、客户的关系好吗？

　　 ●结构／过程风险：新项目所引发的用户群和业务过程的变化程度如何?项目需要满足多少不同的用户群?新项目系统需要和其他多少系统交互?组织有成功完成项目的合理安排吗?

错在哪里？

　　KPMG是一家大型咨询公司，在1995年发表了一份调查研究报告，显示55％的失控项目(mnaway‘projects)——有严重的成本超支和进度超期的项卧，根本没有进行过风险管理；38％的项目只做了部分工作(其中半数在项目开展后，没有使用风险识别的结果)；7％不知道是否做过风险管理。”这份调查显示了开展风险管理工作对于提高项目成功的可能性、防止项目失控具有非常重要的意义。

　　 风险管理也成为很多组织供应链中的薄弱环节。全球性事件如恐怖袭击、发展经济中的政治不稳定，以及2004年的金属价格暴涨等都提醒了管理者要重视并对供应链项目中的风险进行评估和管理。具有讽刺意义的是，许多被供应经理们识别出来的新风险是成本削减计划的结果，而这在今天是被广泛采用的。新供应链管理策略的鼓吹者们在向管理层兜售新供应策略上花费了太多的时间和精力，而在识别和评估所有的风险和应对它们的潜在对策方面投入甚少。

　　 根据Standish Group的成功标准，审阅一个项目计划书、风险问卷或者其他类似的工具是了解IT项目风险一般来源的很好方法。同样，审阅WBS也是非常有效的，以此来查看是否存在WBS分类中的特定风险。例如，如果WBS申的一项包含了准备一篇新闻稿，而项目团队中没有人做过，若无法进行专业化的处理就是一个负面的风险。

　　 风险分解结构是一个很有用的工具，可以用来帮助项目经理较好地考虑各类潜在风险。和WBS的结构相似，风险分解结构(riskbreakdown structure)是针对项目潜在风险的分级架构。图11-3显示了一个可以应用到很多IT项目中的风险分解结构示例。较顶层分类是商业、技术、组织和项目管理。竞争对手、供应商管理和现金流归属于商业风险。技术风险下面有硬件、软件和网络。请注意，风险分解结构如何提供一个简单的、单页图表，以帮助确保项目团队充分考虑与IT项目相关联的各类风险。例如，在开篇案例中Cliff和他的经理们已经考虑了项目管理中各类风险而获得了很大的益处，包括项目评估、沟通和资源等方面。他们已经讨论了这些以及其他类型的与投标项目相关的风险，制订了优化正面风险和较小化负面风险的合适策略。除了依据项目或产品的特性识别风险外，同样需要根据项目管理知识领域，例如范围、时间、成本和质量来识别潜在的风险。注意图11—3中风险分解结构的一个主要分类是项目管理。表11-4列举了存在于各知识领域的、潜在的负面风险条件。

　　了解风险的一般来源有助于开展项目风险管理的下一步工作——风险识别。