过去，IT风险管理常被忽略或仅仅作为一个单纯的技术问题，但是，现在它已经成为组织治理的问题，是一个涉及到政府部门、监管机构、外部审计、技术服务提供商、董事会与管理层及所有利益相关者的问题。SOX法案更是通过内部控制有效性声明和严厉惩罚将法律与IT风险问题绑定。鉴于此，谨向上述人士推荐此书，相信本书的出版对于推动IT风险管理领域的发展有着非常积极的意义。
4.2 风险的机构、流程及项目视角
要更好地交付IT项目，要注意下面三个层次的问题：
● 要交付项目的机构内部可能发生的情况。
● 多个并行的项目就像“空中的球”一样，管理团队必须持续应对。
● 那些独立的项目，每个都会处在自己独特的阶段。
4.2.1 为交付项目而管理机构
要想系统地控制项目风险，就要保持项目开发行进在一条正确的道路上。除了采用“战术上”的补救措施之外，更有必要采用能力强大、成熟的开发技术。
最重要的能力也许是尽可能早地发现项目出现的问题，进而做出艰难决定的能力——取消项目或坚持做下去。如果得不到业务上的完全支持，并且提不出继续投入的理由，那么这个项目就应该终止。如果这个项目需要坚持下去，那么你就需要找到坚持下去的方式，需要使用一些特别的措施使项目回到正常的轨道上。取消一个项目，需要一个可能有些残忍的程序性角色，因为会有一些不愉快的经历。通常这个角色是由CFO来担当。终止低效的项目的好处是可以把省出来的资源投入到余下的项目中，实际上提高了这些项目交付的确定性。
开发过程中的“项目文化”大概是另一项最重要的能力了。这就是，机构里的核心专家或专家们所提交的变更应该是可以信任的，或者说应该可以预言他们“会做不错的工作”。很多机构并不是非常在意为项目人才提供一条好的职业道路。更奇怪的是，项目角色总是会引来负面的眼光。你能做到最好的只是能交付(仅仅靠他手上握着的笔就决定了你的生死)或者不能交付，然后被炒鱿鱼，或者被带上“不适合实际工作”这个带着污点的标签。事实上，很多人在项目里面即会发挥长处，也会表现出短处，尽管他们付出努力后，所获得的成效仅有很小部分会因为项目的成功而为机构做出了实际的贡献。重要的是能把好的人才吸引进来，让他们加入到更有价值(可能也很困难)的项目中来。同时，激励他们提升自身的工作效率，并能在后续的项目产出中体现出他们每一个人的努力，能对他们个人的绩效做出客观的评估。
第三项重要的基础能力是围绕着一个项目机构学习的制度体系。屡屡的项目失败所造成的体验是很痛苦的，对那些利益相关者也是一种打击—— “我老感觉似曾相识”——能留下的是一些严重的，而且将持续多年的痛苦回忆。在我们经历的失败中，是不是存在一种明显的模式？我们所犯的错误，哪些是很常见的？导致我们失败的根本原因是什么？我们成功的标志又是什么？我们怎样比别人做得更好？在问这些问题之前，关键是要搞清楚自己是否有意愿或者能力去做成什么事情。我们必须及时发现问题，同时也要弄清潜在的负面影响—— 这些可能还不够—— 紧接下来，应该在你所管理的团队中收集所有的这样或那样的观点，尽最大可能从不同的视角出发，去分析和处置风险(Keil等，2000)。
尽管在很多机构里，这种情况非常常见。但是后实施评价(PIR)过程存在的主要理由仍然是为了搞清责任，同时也为了满足官僚政治的需要。如果能通过构建和维护机构内的项目管理知识库，并且能使我们在其他的项目中采用正确的方法，那么这种后实施评价才是最有价值的。
4.2.2 管理流程—— 多个并发IT项目的风险
人所共知，如果条件允许，进行一组“小而漂亮的”项目比实施一个“大而丑陋”的项目要容易得多。
在进一步讨论这个议题之前，我们要明白，从经验上看，对IT项目进行的风险因素评估中，小型项目在大多数因素上的得分都是比较低的(即项目风险比较小—— 译注)。即便如此，由于流程管理上的原因，小型项目还是会带来其他类型的风险：
● 需要保持众多项目统一与连贯—— 每个项目都会以自己的方式渡过自己的生存周期，因此有必要搞清楚项目之间互相依赖的地方。
● 在设计原则上，必须保持众多项目的一致性——
坚持始终的一致视角很容易被我们忽视，因此在很多局部性的解决方案上就会出现很多不相容的地方。尤其是在系统接口，整体的用户界面以及非功能性方面(比如，能不能采用相同的方式来组合系统的构件？)。
● 管理成本高企—— 需要进行协调的事情越来越多，这可能会大大分散团队成员对任务自身注意力，从而浪费大量的时间和资源。
● 严格管理稀缺的共享资源—— 如果多个项目都同时要求得到那些数量极少的技术专家的服务，那么为了获得这些紧缺资源，就不得不排队。因此，需要根据每个项目的优先级来决定哪个项目能获得优先权。
4.2.3 管理项目—— 航行风险
讨论了机构和能力问题，我们现在把目光移到单一的项目上。如果我们把IT项目比作航行在大海上正在航向目的地的一条船的话，那么作为管理者，他的视角同普通船员的视角是有些不同的。很多的文献都为项目管理者列出了如何掌控项目的各式各样的指引。现在，让我们站在“司令官”的位置，开始指挥整个舰队。
管理信息技术项目风险不单单是使项目启动起来，还要使项目以正确的方式运作。
● 设计好项目的组织架构—— 也就是有一条好的船。一个适用的项目架构将为全体项目人员提供良好的环境和清晰的命令发布体系。邀请一些专家在项目组中充任合适的角色—— 比如，安全问题顾问，数据迁移专家等—— 这些都需要细心挑选，特别指定。尤其是在只要求这些专家参与整个项目过程的一个或两个阶段的情况下。
● 挑选并雇佣项目成员—— 也就是需要好的船员。项目开始之前，项目团队的每一个角色都必须明确下来，并为每个角色找到最合适的人。要用既明确无误又容易理解和接受的方式告诉每一个成员，他(她)担当什么角色，这个角色的涵义是什么。非常重要角色同其他项目组成员之间的关系在团队内部必须作出正式的说明。为了保证他们之间的良好沟通，要防止出现任何模糊之处。
● 制定规划—— 要想顺利抵达目的地，船队需要高质量的地图来指引，至少最初的航程要在地图上标注出来。就像我们在前面讨论过的，如果你根本不知道你要去哪儿，那么你也就根本不可能到达那儿。对末段航程，也要求做出详尽的计划，这种要求是不切实际的。但对第一阶段的航程却十分必要。这可以使兵强马壮的一支队伍能集中精力做好急需完成的工作。
航程指引也是很重要的：
● 沟通的规范化—— 海上航行中的舰队通讯，到达港航行日志的备份。打算对项目中每一项日常活动都进行直接的监督并不可行。正是由于这种约束，项目组内部就更需要以规范形式进行管理信息的沟通，因为这可使各个管理层能直接、有效地了解项目情况。在项目持续的过程里，规范的沟通确实非常重要。但是，我们还要明确，沟通并不是单向的，如果有新的信息出现，那么就应该让全体船员及时了解。
● 那种“板报”形式的信息沟通是最通用的方式。重大的项目必须以标准化的形式，定期作出报告(比如每月)。而最难忍受的还是类似于在自我评估和自行报告体制下，提交的那种所谓“自说自话”式的报告，但这种做法却很常见。
● 对照计划对项目进程进行跟踪—— 检查会使项目一直在正确的航向上航行。应该规范地核查项目的三方面，包括费用、功能性和时间。即使是对那些实施过程已经高度自动化的项目，那些具备强有力执行人的项目，我们也需要进行规范地核查。通常核查是由项目团队自己来进行的—— 所以对项目的微观活动也进行繁琐的核查既无必要性，也不会有什么价值。一旦项目组计划展开行动(哪怕只是为了应付)，那么在组内部就必须马上启动明确而有效的沟通机制。
对准目标：
● 接收交付—— 项目结束，也就意味着你将卸下包袱，意味着你将得到你想得到的，抛弃那些你无法应付的。当一个项目到达了终点，那么质量保证(QA)体系就开始活跃起来，用户验收的里程碑也就很接近了。其中的关键是要认识到功能不全或者功能缺陷都将会对项目的实施过程造成阻碍，原因是它们会造成系统不能正常发挥作用。很多项目到了这一步都会陷入一味地寻找完成的妙方而不是去找解决方案的误区。在完成了一个版本的交付和部署之后，大多数的方案都会出现一些细微的调整。通常在“后实施过程”，项目团队会把新的需求变更保留下来，暂时按兵不动。这其实是一个良机，可以用最小的费用增加换来项目尽快结束。
4.2.4 决策与超时、功能及费用的控制
谈到信息技术项目风险立即就会涉及项目层面的一些术语：时间、功能性和费用。
对项目目标的初始估计是非常重要的。在大多数的机构里面，不是每一个人都对项目持有同样的观点，因此在对项目的定义上应该取得管理层的共识—— 包括寻找那些难以捉摸的支持者。对信息技术项目而言，业务案例就像一个典型的手工制品，要集中一批人，提出有关时间、功能性和费用方面的要求。而初始估计又常常会很不精确，因为你可能估算太长的时间、太多的功能和太大的开销—— 因此做些交易就不可避免了。做成交易进而为本项目制定出风险视图是项目管理者的责任。他还要审视整个项目计划，保证项目不能有什么缺失，也不能留下什么漏洞让项目组成员有滥用的机会。Lyytinen(1998)为我们建立了预料中失败的观念：项目的美丽只会出现在项目管理者的眼中。
随着项目启动，一些机构会选择把项目的时间、功能性和费用这三个维度限制在预定的范围内，并把项目全权交给项目管理人员去管理。除非发生什么意外，否则不会出现任何变化。
其余人的任务则是勒紧缰绳，要求哪怕最小的变更都要报告。而为防止出现意外而准备的余量—— 更多的时间、更多的资金—— 则要求在规范的变更评估的基础上才予以考虑。当然也应该考虑到项目团队成员的能动性、他们的努力和回避风险的能力(Phelps，1996)：项目团队过高地估计风险因素可能会让他们在计划里预留很大的或有开支。这实际上是使项目成功的概念复杂化了—— 代理人(执行者)可能认为“项目是成功”的，而项目出资人的看法却完全不同。
通常，从多个层面来管理信息技术风险还是有必要的。信息技术风险会威胁项目的一个或多个目标(Powell和Klein，1996)，这一点应该被所有的项目参与者所认识。在项目推进的过程中，那些现实的却又无解的问题将会逐步显现出来。实际上，有必要在项目团队内部建立完备的信息技术风险注册目录。尤其是在管理报告中，应该列出可能为项目带来高风险的“缺陷清单”。
对于那些仰赖项目团队上报的内容来评价项目状态与风险的人，正像英国政府机构IT项目提示中要求的那样，应当意识到项目层面风险管理的缺陷：狭窄的视野，无优先级的风险列表，无法了解哪些风险会转移给伙伴和供应商，可以依赖合约或者其惩罚性条款来减轻风险，不能对风险管理行为有效性进行监控(McCartney，2000)，等等。
京ICP备06004481号 Copyright 2002 - 2006 ITGov.org.cn, All Rights Reserved