从时间、功能和质量、费用三个角度考察项目风险，并有针对性的进行控制。

    项目失败将造成浪费—— 稀缺的资源被投放到了无法获得任何价值的项目上，项目人员其实是可以从事其他的能带来价值的工作的。不仅如此，项目失败还会带来两个更深层次的影响。

    第一个影响称为“利益损失”风险。IT项目是有其价值的，项目会带来产品和服务，会给我们带来商业上的利益。

    第二种称之为“间接损失”风险。参与这个项目的人可能会因为项目失败而受到伤害，包括个人、团队，甚至是整个机构。最糟的情况是，由于一个重大挫败或者一连串的失败而在信心上带来重大的危机—我们还有能力交付什么吗？被迫接受的结局是— 是谁造成了这种后果？事实的背后所隐藏的似乎总是注定要失败—因此也就永远无法信任整个团队的每一个成员。当然，从个人角度上说，总是希望避免这种状况出现，机构更是如此。但整个项目之舟似乎就要放弃了。

    从下面的三个角度来考察部分失败的案例是有用的：时间、功能和质量、费用。

    这三个角度是项目经理需要常常关心的，有时被描述成三角形的三个顶点。如果在项目里还有什么重要的话，理智的项目经理也许会把它作为第四边。

    不能承受的时间之重

    “截止期”这个术语在项目里常常会被用到。它指的是计划交付日期，通常与此相关是部署日期或者投产日期。现实世界里似乎总存在这种或者那种固定的日期，还有一些需要快速响应的日子—比如解决2000年问题不能推迟；这似乎是业务部门为影响项目而设定的独断而富有挑战的目标；但它也是细化工作计划、评估和确定进度的基础。

    如果项目出现了延迟，会发生什么事情？通常情况下，如果有一套实时控制机制的话，那么项目延迟首先会对项目参与者自身造成影响，次之会造成项目资源和费用分配上的紧缺，最后可能导致对功能和质量要求的降低。对那些“必须做”的项目—如果确实必须做而且必须按时完成的项目—则必须承担后续的因为赶工而在质量保证及部署上引起的操作风险。否则，项目肯定会延迟。而项目延迟所付出的代价则是项目延长占用资源的直接费用外加可能造成的间接利益损失，包括延迟期内产生的和各种其他的“间接损失”所产生的费用。这些“间接损失”通常都是无形的。如果还造成了关联的项目的延迟的话，那么其影响就更广泛了。

    功能和质量不佳带来利益损失

    项目推迟可能很难掩盖，而功能及质量问题则很容易隐藏。一旦出现了产出物质量较差或者不完整的情况，尤其是出现在需要第一次交付的场合，那么要想在以后的过程里不折不扣地完成非交付内容将是很困难的。有些IT交付团队为应付这种情况采用跟踪负责制—你必须不带抱怨地拿走交给你的东西—一旦你发现了问题，别人还可以对自己提交的东西做出解释—到了那个时候你就必须解释你为什么认为这是一个缺陷，而且还要解释为什么要高优先级地解决这个问题。对交付团队来说，每一个成员都要分担无可避免的返工所造成的推迟交付的压力。在见到出口的曙光之前，还能对一些尚未交运的遗漏做出抱怨应该感到很幸运了—因为至少我们还能确认还能赶上下一班船—但我们真的能确信这趟被推迟的旅程还有返工的价值吗？

    通常，功能和质量不佳会造成一些利益损失。比如，我们宁愿在项目初期就对任务做出重大的削减，把任务的责任交还给用户，也不要等到最后只能完成任务的十分之三。但是，有时产品的一个缺陷可能会直接或者间接地影响业务，造成的损失远大于项目费用和潜在的商业利益。比如，核电控制系统，其目标首先是自动化的保障过程，其次是适当减低劳动力成本。然而，只要交付的全部自动过程特性中出现了一个失效，那么其造成的后果可能会远远超出节约人工成本所获得的全部好处。

    让费用回复正常

    “投入更多的资源给项目”形成的累计费用可以简单地看成部分项目失败的表象。已经投给某个项目的资源超出计划多少？这只是项目失败的直接成本。也许在项目的总费用里，初期投入不值一提，在投入上也不会那么均衡—如果一开始就能了解所有的问题，那么也许我们会走另外一条完全不同的路。

    然而，对于某些IT项目而言，因为开销过大而引起的无法弥补的费用缺口还是能找到一种得到认同的解释办法。即使这揭示了项目后期费用还要不停地追加，但通常的情况下还是无法杜绝有一件事情的一而再、再而三地发生，那就是对单项项目的预测投资评估。投资委员会将对照新的费用重新计算(不变的)利润流—每次都希望这次的结果同余下的开销能更接近些，期望原先计划之外追加的部分能够满足超出的费用需求。

    如果出现了多个项目都超支的情况，超支的坏消息出来又迟了，而且还是在已经追加的基础上超出，那么最终投资人就可能会重新审视所有的投资项目。CFO也会试着找出系统性地滥用投资管理流程的情况。以后新IT项目费用估计就会或多或少要受到一些影响了。当一个满怀期望的项目经理把一份投资委员会所要求的投资估算交出去的时候，其实在投入的数字被核实以前，它一定是被明显夸大的—当然可能参照上还带点偶然性。这其实同典型的IT项目的“加倍原估计”的“拇指”规则不谋而合。

    当然，对这种不良的反应—那些热衷于承担有意义的IT项目但却每每遭受打击的人—应该把铅笔削尖些，大大削减最初的估算，同时期望投资委员会的流程更充实一些，使项目费用估算回复到正常的投资水平。最终，把这一流程锁定为立即批准项目的行为模式，如果还出现意外，那么剩下的就只会是时间和人这两个因素了。

    项目交付时的系统性失败

    有些关于IT项目失败的统计数据是非常惊人的。似乎绝大部分的IT项目都以失败而告终。在那些总是系统性地出现重要IT项目交付失败的机构里面，这样的失败会给业务带来哪些影响呢？

    作为最大的一笔IT预算，行星计划遭到了系统性地挫败。也因此受到了美国总审计局(US General Accounting Office)的关注：

    今天我们听取的是有关政府信息技术(IT)管理议题的报告……这是一个重要的议题，因为根据总统最近批准的预算，联邦政府每年在信息技术方面花费数十亿美元—— 据报2003财政年度花费了570亿美元。但是这些资金并没有很好地管理。例如，监察报告显示在2005财年大约需要600亿美元的信息技术投资，200亿美元—— 投在621个主要项目上—— 列在现在的关注名单中。这份清单所包括的那些重大项目，在效能度量、回报价值管理和/或信息技术安全等方面都需要加以改进。(GAO，2004a)

    在这些庞大而复杂的组合中，总会有一些“常见失败”(参见海岸警卫队的例子)，也会面对一些“旗舰”的“挑战”：

    总统管理议程(President’s Management Agenda)的五个优先议题之一是发展电子政府—— 使用互联网应用技术使获得和交付政府信息的服务得到提升。管理与预算办公室(Office of Management and Budget，OMB)已经资助了25个电子政府活动。这些活动是因为项目对国民价值的提高、对提升效率以及18到24个月投产的可能性这几项因素来选择决定的。到2002年5月，这些活动共91项目标已确立。应分委员会的要求，GAO评估认为这91项目标是我们面临的挑战。(GAO，2004a)

    在这份于2004年3月出版的报告里—从2002年5月开始至少有2年的目标确认期—描述了下面的流程：

    总之，在25项OMB资助的电子政府项目中最初的91个目标已获得进展。目前，33个已经全部完满完成；38项已经部分地完成；17项次重要的流程也已取得进展。另外，由于有3项目标被认为不切实际或者不恰当而被终止……

    其中的2个项目—Grants.gov和国内税收服务(IRS Free File)—初始目标已经达到，附加5项的主要工作也已完成。其他的18个项目，大部分都已完成部分任务，还有一些被认为不再需要……

    OMB认可的关键因素包括这个项目能不能在18到24个月内部署，仍未达标的数目或者仅仅部分达标的项目数量表明，同OMB的预期相比，这些项目要取得进展还面临着很大的挑战。(GAO，2004f)

    总之，IT项目失败所造成的巨大损失在公司层面表现出来只会是时间问题，最终牺牲的是股东价值。

    为交付项目而管理机构

    要想系统地控制项目风险，就要保持项目开发行进在一条正确的道路上。除了采用“战术上”的补救措施之外，更有必要采用能力强大、成熟的开发技术。

    最重要的能力也许是尽可能早地发现项目出现的问题，进而做出艰难决定的能力—取消项目或坚持做下去。如果得不到业务上的完全支持，并且提不出继续投入的理由，那么这个项目就应该终止。如果这个项目需要坚持下去，那么你就需要找到坚持下去的方式，需要使用一些特别的措施使项目回到正常的轨道上。取消一个项目，需要一个可能有些残忍的程序性角色，因为会有一些不愉快的经历。通常这个角色是由CFO来担当。终止低效的项目的好处是可以把省出来的资源投入到余下的项目中，实际上提高了这些项目交付的确定性。

    开发过程中的“项目文化”大概是另一项最重要的能力了。这就是，机构里的核心专家或专家们所提交的变更应该是可以信任的，或者说应该可以预言他们“会做不错的工作”。很多机构并不是非常在意为项目人才提供一条好的职业道路。更奇怪的是，项目角色总是会引来负面的眼光。你能做到最好的只是能交付(仅仅靠他手上握着的笔就决定了你的生死)或者不能交付，然后被炒鱿鱼，或者被带上“不适合实际工作”这个带着污点的标签。事实上，很多人在项目里面即会发挥长处，也会表现出短处，尽管他们付出努力后，所获得的成效仅有很小部分会因为项目的成功而为机构做出了实际的贡献。重要的是能把好的人才吸引进来，让他们加入到更有价值(可能也很困难)的项目中来。同时，激励他们提升自身的工作效率，并能在后续的项目产出中体现出他们每一个人的努力，能对他们个人的绩效做出客观的评估。

    第三项重要的基础能力是围绕着一个项目机构学习的制度体系。屡屡的项目失败所造成的体验是很痛苦的，对那些利益相关者也是一种打击— “我老感觉似曾相识”—能留下的是一些严重的，而且将持续多年的痛苦回忆。在我们经历的失败中，是不是存在一种明显的模式？我们所犯的错误，哪些是很常见的？导致我们失败的根本原因是什么？我们成功的标志又是什么？我们怎样比别人做得更好？在问这些问题之前，关键是要搞清楚自己是否有意愿或者能力去做成什么事情。我们必须及时发现问题，同时也要弄清潜在的负面影响—这些可能还不够—紧接下来，应该在你所管理的团队中收集所有的这样或那样的观点，尽最大可能从不同的视角出发，去分析和处置风险(Keil等，2000)。

    尽管在很多机构里，这种情况非常常见。但是后实施评价(PIR)过程存在的主要理由仍然是为了搞清责任，同时也为了满足官僚政治的需要。如果能通过构建和维护机构内的项目管理知识库，并且能使我们在其他的项目中采用正确的方法，那么这种后实施评价才是最有价值的。

    管理项目—航行风险

    讨论了机构和能力问题，我们现在把目光移到单一的项目上。如果我们把IT项目比作航行在大海上正在航向目的地的一条船的话，那么作为管理者，他的视角同普通船员的视角是有些不同的。很多的文献都为项目管理者列出了如何掌控项目的各式各样的指引。现在，让我们站在 “司令官”的位置，开始指挥整个舰队。

    管理信息技术项目风险不单单是使项目启动起来，还要使项目以正确的方式运作。

    ◆ 设计好项目的组织架构—也就是有一条好的船。一个适用的项目架构将为全体项目人员提供良好的环境和清晰的命令发布体系。邀请一些专家在项目组中充任合适的角色— 比如，安全问题顾问，数据迁移专家等—这些都需要细心挑选，特别指定。尤其是在只要求这些专家参与整个项目过程的一个或两个阶段的情况下。

    ◆ 挑选并雇佣项目成员—也就是需要好的船员。项目开始之前，项目团队的每一个角色都必须明确下来，并为每个角色找到最合适的人。要用既明确无误又容易理解和接受的方式告诉每一个成员，他(她)担当什么角色，这个角色的涵义是什么。非常重要角色同其他项目组成员之间的关系在团队内部必须作出正式的说明。为了保证他们之间的良好沟通，要防止出现任何模糊之处。

    ◆ 制定规划—要想顺利抵达目的地，船队需要高质量的地图来指引，至少最初的航程要在地图上标注出来。就像我们在前面讨论过的，如果你根本不知道你要去哪儿，那么你也就根本不可能到达那儿。对末段航程，也要求做出详尽的计划，这种要求是不切实际的。但对第一阶段的航程却十分必要。这可以使兵强马壮的一支队伍能集中精力做好急需完成的工作。

    航程指引也是很重要的：

    ◆ 沟通的规范化—海上航行中的舰队通讯，到达港航行日志的备份。打算对项目中每一项日常活动都进行直接的监督并不可行。正是由于这种约束，项目组内部就更需要以规范形式进行管理信息的沟通，因为这可使各个管理层能直接、有效地了解项目情况。

    ◆ 那种“板报”形式的信息沟通是最通用的方式。重大的项目必须以标准化的形式，定期作出报告(比如每月)。而最难忍受的还是类似于在自我评估和自行报告体制下，提交的那种所谓“自说自话 ”式的报告，但这种做法却很常见。

    ◆ 对照计划对项目进程进行跟踪—检查会使项目一直在正确的航向上航行。应该规范地核查项目的三方面，包括费用、功能性和时间。即使是对那些实施过程已经高度自动化的项目，那些具备强有力执行人的项目，我们也需要进行规范地核查。通常核查是由项目团队自己来进行的—所以对项目的微观活动也进行繁琐的核查既无必要性，也不会有什么价值。一旦项目组计划展开行动(哪怕只是为了应付)，那么在组内部就必须马上启动明确而有效的沟通机制。

    对准目标：

    ◆ 接收交付—项目结束，也就意味着你将卸下包袱，意味着你将得到你想得到的，抛弃那些你无法应付的。当一个项目到达了终点，那么质量保证(QA)体系就开始活跃起来，用户验收的里程碑也就很接近了。其中的关键是要认识到功能不全或者功能缺陷都将会对项目的实施过程造成阻碍，原因是它们会造成系统不能正常发挥作用。很多项目到了这一步都会陷入一味地寻找完成的妙方而不是去找解决方案的误区。在完成了一个版本的交付和部署之后，大多数的方案都会出现一些细微的调整。通常在“后实施过程”，项目团队会把新的需求变更保留下来，暂时按兵不动。这其实是一个良机，可以用最小的费用增加换来项目尽快结束。

    决策与超时、功能及费用的控制

    谈到信息技术项目风险立即就会涉及项目层面的一些术语：时间、功能性和费用。

    对项目目标的初始估计是非常重要的。在大多数的机构里面，不是每一个人都对项目持有同样的观点，因此在对项目的定义上应该取得管理层的共识—包括寻找那些难以捉摸的支持者。对信息技术项目而言，业务案例就像一个典型的手工制品，要集中一批人，提出有关时间、功能性和费用方面的要求。而初始估计又常常会很不精确，因为你可能估算太长的时间、太多的功能和太大的开销—因此做些交易就不可避免了。做成交易进而为本项目制定出风险视图是项目管理者的责任。他还要审视整个项目计划，保证项目不能有什么缺失，也不能留下什么漏洞让项目组成员有滥用的机会。Lyytinen为我们建立了预料中失败的观念：项目的美丽只会出现在项目管理者的眼中。

    随着项目启动，一些机构会选择把项目的时间、功能性和费用这三个维度限制在预定的范围内，并把项目全权交给项目管理人员去管理。除非发生什么意外，否则不会出现任何变化。

    其余人的任务则是勒紧缰绳，要求哪怕最小的变更都要报告。而为防止出现意外而准备的余量—— 更多的时间、更多的资金—则要求在规范的变更评估的基础上才予以考虑。当然也应该考虑到项目团队成员的能动性、他们的努力和回避风险的能力：项目团队过高地估计风险因素可能会让他们在计划里预留很大的或有开支。这实际上是使项目成功的概念复杂化了—代理人(执行者)可能认为“项目是成功”的，而项目出资人的看法却完全不同。

    通常，从多个层面来管理信息技术风险还是有必要的。信息技术风险会威胁项目的一个或多个目标，这一点应该被所有的项目参与者所认识。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。