4.5  识别、报告和管理项目风险

Drummond从Taurus项目为我们带来了一个警示：

风险的认受性—— 尽管存在很多的争论—— 就是指通过决策者之间的权力平衡而最终得到的某种产物。进一步地说，风险分析和管理的技术事实上总是同难于控制某些泛起的幻想相伴。
                                                                                                      (Drummond，1996)

现在我们以一个管理者的角色来审视信息技术项目，希望我们能承担得起积极管理项目风险的责任。要想发现项目的风险(定义为某种事情发生的可能性，其后果是可能使项目无法达到预定的目标)—— 可以通过三种途径：

●      审计/健康检查。

●      自评估。

●      项目门槛。

对一个重大的、高优先级的项目而言，要保证项目风险能被及时发现并准确无误地报告出来就必须确立上述的全部三项机制。对相对不太重要的项目来说采用全部的三种方法倒也未必那么必要。

审计和健康检查评估要求具有独立性的、能保持客观性的团队参照着既定的项目目标做出客观的评估。这种方法的好处在于在项目团队还不知道的情况下就能发现风险。这种方法的困难性在于它要求审计人员具备项目必备的知识，能够对项目做出精确、有价值的判断，还需要具备项目团队成员所不具备的影响力。

自评估主要是由项目组织团队内部知识丰富的资深人士执行，通过进行某种形式的调查和提问最终刻画出清晰的项目风险状况—— 期望采取的行动—— 至少在较高的管理层面上是这样。

项目门槛或者检查点方法要求项目做出更多的信息披露和讨论，就最常发生的行为，在广泛的领域，在可能参与项目专家同项目经理之间做到最大程度的分享。

4.5.1  委员会的监管

通过一个正式的委员会来监管信息技术项目是一个得到公认的比较好的方法。但还有一个认知也是很重要，即对项目负责的委员会要想发挥出最大的作用，必须满足下面几项条件：

●      业务表现出来的远比想象里的更符合实际—— 一旦项目不能按计划交付，这是每一个关心项目产出的人可能要承担的个人风险。

●      讨论实际的问题，而不是仅仅提交简单的表格来应付方向性的讨论。

●      看待项目需要具备另类的视野，而不是仅仅依赖项目经理每天提交的整洁的项目进度报告。

●      项目经理承担项目交付的责任，这一点必须得到支持，不要越过或者妨碍项目经理的工作。

4.5.2  另类的管理反应

当坏消息到来的时候，广泛存在着三类不同管理反应，分别对应着项目的三种状态：

●      垂死的—— 项目已经错过了恢复点，存活下去的可能性很低。

●      活着的—— 项目进展良好，但外部并没有改进项目的条件。

●      带伤的—— 项目备受压力，陷入麻烦似乎不能自己康复，现在是干涉的时候了。

通常，垂死的项目可以任其死亡，也可以让它加速走下去。这类项目越早停止交付越好。

而活着的项目则会继续下去，直到有个结果。

现在主要的管理焦点是在带伤的项目上。可以采取的行动包括：注资，更多的资源、范围变更、项目角色的重定义、项目组织结构的重定义、扩大供应商或服务供应商的交付内容，等等。

有关为什么濒于失控的IT项目还被允许继续下去(Mahaney和Lederer，1999，Keil等2000)的进一步研究已经有些结果。后来也有一些研究认为必须放弃这些项目(Addison和Vallabh ，2002)。毫无理性地认为“提高赌注”—— 基于“坏钱后面是好钱”这种认知—— 人所共知(Drummond，1996)。一旦你的管理团队也是这么想的，那么你就有必要在换人之前先打破这种循环。

4.5.3  在项目的每一步，要看什么结合更多“经典”瀑布交付模型的内容，接下来我们将讨论几个维度的“检查清单”问题，它们可以用来检查项目各阶段的门槛和检查点。

我们讨论的步骤是一般情形下的，并没有考虑某些机构的特殊情况：

●      观念和可行性。

●      需求与架构。

●      建造。

●      测试、认可与实施。

●      后实施。

我们首先要讨论每一步的基本原理，接着考虑管理团队的现实目标。可能对风险议程有所贡献的一些特殊项目和对风险识别有帮助的有关议题列在本书的附录中。

1. 理念和可行性

好主意有时可能反而得不到很好的宣传。在项目的构思阶段，很多好主意可能都不能表达出来。造成这种现象原因是，项目的成果往往不足以让我们做出给项目投入更多资金或者投入更多资源这样的决策。

相反，有时我们会发现资金是付出了，但在项目启动时并没有明了关键问题所在。

如果我们秉持坚定的理念，通过可靠的可行性评估，将会为项目拟定明确而准确的定义。在作出项目是“继续走下去”还是“现在停下来”的判断的时候，明确的项目定义将为此创造良好的客观基础。

在这个阶段，我们期望能找到：

●      正确的理念，明清晰的业务原理。
       ●      通过对方案和项目交付选项进行有重点的并且有效的评估，来确认项目的可行性。

●      明确商业价值，阐明在既定的投资标准下，能达到的项目回报。

●      适当考虑项目对机构所造成的广泛影响，利益相关人的参与程度以及给业务流程带来的变化。

●      组建一支高效而且行动迅速的项目团队，依照公认标准去工作。

2. 需求与架构

在这一步，很多业务计划都将变成IT项目。项目团队把精力集中在规范、分析和技术方面。必须沟通的信息也在逐步增多，但沟通应该尽可能用IT术语而不是业务术语来进行，尽管可能要冒着失去业务支持的风险。

详尽的需求定义常常会“膨胀”，超出预定的项目范围。反过来，原定的有关业务优先级和目标也可能会遭到遗弃，不理想的方案反而可能得到青睐。

选择供应商可能变成一个冗长而耗费巨大的过程—— 政府机构由于其采购及合规性要求，这种情况可能更严重。
如果一个项目起步阶段就不那么严谨，那么到了这一步可能因为项目费用失控而要大喊大叫。管理层也会感到时间过得飞快，出现未曾预想到的风险和难题，进而大大阻碍了项目进程。

这一步，我们期望看到：

●      持续不断地为业务部门提供最新的项目资料，最终会因为业务部门获得了比较全面的信息而获益。

●      一套得到业务部门认可、符合认受标准的优化技术方案，得到了供应商按时交付的承诺。

●      在订立的商业合约中，把方案交付伙伴获得商业回报的权利、责任同项目重大里程碑—— 而不仅仅是技术交付物—— 连接起来。

●      通过对技术方案和供应商交付方法的细化和限定，进一步强化业务案例基础。

●      构建一套支持未来项目运营、同业务密切整合并支持机构变革的基础体系，因为信息技术解决方案的导入过程必定会带来机构变革。

●      把业务、IT、供应商管理以及交付团队结合在一起，使整个项目达到公认的最佳效能标准，并在应对应急事务、风险等方面达到最高的水准。

3. 建造

无论是直接采购一个产品还是自己通过项目开发一套应用，建造阶段都应该是服务供应商责任占主导。项目活动可能会因为技术因素和细节而陷入“停顿”。

原始的业务目标可能会发生更多的偏移。供应者不仅要把注意力集中在交付预定的工作上面，还要时不时回头看看整个项目的目标。

中途的里程碑常常无法达到或者只能“技术性通过”。可疑的可能返工增多了，但却一直要到测试阶段才能暴露出来。机构上上下下禁不住开始担心供应商在预定的预算计划之内按时交付预定功能的能力。

机构为了使自身的变革尽快到位，会并行地展开一些业务活动。但这些业务活动同IT工作流之间却常常会失去一致性和协调性。

在这个阶段，我们希望看到：

●      在项目建造过程中，持续得到的业务支持以及业务部门的积极参与，并保持同业务部门的联系和沟通。

●      在项目所有维度、全体的功能范围和非功能需求上，确认方案都是适用的。

●      形成一套以获得共识的、详尽的测试计划。一旦测试开始执行，将会保证方案满足已达共识的认受条件。

●      按照承诺，服务供应商和销售商实施交付。

●      项目费用的严格管理。

●      项目团队的保持高效率。 

4. 测试、认可与实施

“不愿意看到的事”总是迟迟才发现。在验收性测试中，这却是常常发生的事，因为一直到这个时刻，完整的方案才被集成在一起，实际的业务场景到了这个时候才第一次被放到方案里去执行。

在测试里发现的堆积如山的问题中，其实很难把真正的缺陷找出来。当背负着这些包袱开始新的返工周期时，对抗的心态又会出现：方案供应商总是“带罪羔羊”。然而，只有在详尽的测试案例执行完成以后，功能修改的巨大任务负担才会完整地呈现出来。

认受标准上的含糊不清所引发的争吵一直持续不断。大家共同认定的功能界面也莫名其妙地发生了变化，常常问题还很难解决—— 在这样的困境下，无论是供应商还是客户都要承担巨大的成本。

在这一步，我们期望见到：

●      业务代表的积极参与可以使测试活动更为严谨，目标也更为明确，有助于早日完成实施准备。

●      在满足所有的功能和非功能需求方面，证明方案是适用的。

●      以重大的里程碑和认受标准为依据，为了实现对销售商和服务供应商产出的严格管理，必须按照合约、及时把供应商从所承担的责任中解放出来。

●      商业应用应该严格按照时间计划，在预定的费用范围内实施交付—— 不将费用难题遗留到后实施阶段来处理。

●      机构已经做好同系统实施有关的变更准备。

●      克服机构内部的障碍，实现有效的协同工作，使项目尽快达到目标。

5. 后实施

随着系统投产，项目组可以松口气了。在叹息声中，项目也该结束了。

尽管对利润计划的具体细节还会继续关注下去，但在通常的情况下，这个时候常常就此解散项目团队，所剩不多的资源和注意力则会被用来榨取项目计划的利润。

实施独立的项目评估将有助于项目团队实现以下目标：

●      业务所有者将会关注业务变更实施后所能获得的利益回报。

●      对方案效能的度量和监控将有助于满足确认的服务级别要求，服务供应商和供应商的法律义务也切实得到履行。

●      满意的进程推进，在操作、支持及维护活动上进入了“正常业务”的状态。

●      关闭项目账户，结束簿记。

●      找出已经过时的培训内容，用新版的指引、原理、方式和方法去更新它们。

本书的附件列出了在健康检查清单里面用到的所有的术语参考。健康检查将有助于管理委员会或管制部门向这些目标推进。另外，同风险相关的，同时也是利益相关者非常关心一些议题，比如项目的范围、方法及每次检讨计划都会被确定下来。