过去，IT风险管理常被忽略或仅仅作为一个单纯的技术问题，但是，现在它已经成为组织治理的问题，是一个涉及到政府部门、监管机构、外部审计、技术服务提供商、董事会与管理层及所有利益相关者的问题。SOX法案更是通过内部控制有效性声明和严厉惩罚将法律与IT风险问题绑定。鉴于此，谨向上述人士推荐此书，相信本书的出版对于推动IT风险管理领域的发展有着非常积极的意义。
4.3 理解IT项目的风险因素
当我们根据信息技术风险的起因，逐项考察项目内容时，还是应该区分风险起因的轻重缓急。在一些研究文献里记录了项目风险因素的各种显著特征。在可以写满几大张纸的众多项目风险因素中，我们列出比较突出的几种：
● 项目规模—— 大型的项目本身就是一项风险因素—— 衡量一套交付解决方案有多大规模其实有很多种标准(通常，是从功能性上来衡量)，也可以看需要占用多少资源来完成项目任务。
● 机构的影响—— 通常，从用户的观点和业务流程视角上看，机构规模的大小也是一项风险因素。例如，一边是整个机构的所有用户使用的，并且需要重构机构核心业务流程的应用项目；另一边应用项目则只是由局部用户使用，仅仅涉及单一的非核心的业务流程。显然，前者比后者包含了更多的风险因素。
● 从与其他项目的依赖关系上度量项目复杂性—— 高依存度是一项风险因素。使用技术的数量和类型——
采用太多的技术也是风险因素；客户化成分越高，风险因素越高。
● 团队的技术与能力，能力的缺乏是一项风险因素，包括团队的经验和历史记录。
● 应用的技术类型—— 在项目里采用新的、未经验证的技术将会给项目成效估计带来困难，也会使项目在设计上难以采用“跟踪和纠错”方法。
在很多种情况下，上述的几种主要风险因素或者这几种风险因素综合在一起决定了一个IT项目如何变成“大而丑陋”家伙。IT项目的风险因素还决定了项目的难度。项目初期，制定的一些过于简单化的规定甚至就根本不适合IT项目设计—— 这些规定还可能会使项目团队在处置IT项目的高风险因素时无法取得高分。
对很多公司而言，即使冒着很大风险，即使项目具有太多的项目风险因素，有些项目还是必须进行下去的，这才是真正的难题所在。在这种情况下，一个或者多个“大而丑陋”的项目并不是数量大得多、“小而美丽”的项目所能替代的。这个问题其实同我们早前已经粗略讨论过的多个并行IT项目管理问题有些关联。
但是，同上面的情况有所不同，在某些情况下一个公司如果不得不面对一个具有高风险的IT项目，它们也许还可以做一些选择。但是获得这些选择同时其实也就意味着要做出妥协，还要做些交易。如果你的目光本来就很低，那么你就绝不会击中更高的目标。
● 项目规模能缩减吗？如果选择是，那么将少交付一些功能。
● 能设法降低对机构的影响吗？如果选择是，那么能从这个项目上获益的用户就会少些。
● 是不是有更好的人可以加入到团队中来，从而提高团队的能力呢？如果选择是，那么就会带来较高的费用开销，而且新加入的人要放下其他的工作。当然，还可以花更多的钱，请机构外的专家。
● 项目的复杂性能降低吗？如果选择是，不仅仅要避免使用最佳的技术架构(即，采用更少的技术并且从单一的来源获得)，还要减少客户化，降低潜在的差异性，限制对其他项目的依赖，创建新的技术库，等等。
了解项目的风险因素是很重要的，因为这将有助于系统性区分不同项目的特征，保证管理措施能及时传达到机构的每个层级。
● Barki等(2001)使用了“风险敞口”的概念—— 来表示风险因素的集合。它可能是由对项目的产出造成影响的一些特殊要素构成的(包括那些加总的风险因素)—— 使用不同“风险管理方案”来评估项目的效能。在“风险管理方案”中设计了三个关键的度量维度，规范计划、内部整合和用户参与。他们发现项目的效能受到项目风险敞口与项目风险管理方案之间适应性的影响。特别是在高风险项目中，必须满足项目高级别内部整合的预算要求以及高级别的规范规划的要求。质量作为项目效能的一项关键指标，比较成功的高风险项目应该具有更高的用户参与度[9]。
4.3.1 重大风险因素的管理
现在的关键问题变成了对于不同类型的项目，尤其是那些带有高风险因素的项目，我们如何采用不同的方法去管理它，减小风险发生的可能性，降低风险所可能造成的影响。我们如何用好风险管理武器库中的项目风险因素分析这个工具？
1. 控制规模
在软件开发项目的规模和失败几率之间存在着很大的关联性，这个观点已经得到了广泛认同(Verhoef，2002)。
尽管项目规模通常可以用产出物来衡量—— 比如功能点或者代码行数—— 但我们仍然觉得，项目规模这项风险因素的起因可能还是基于我们对项目存在着这样一种认知(尽管可能只是暂时性的)，那就是项目只不过是一种机构组织形式而已。因此，项目也需要面对着机构所面临着的几乎所有的难题，不论是小型公司也好还是大型公司也好。
大型公司常常被人描述成笨拙的实体。一旦开始行动，也许动力尚可维持，但确实很难快速调头，并且常常偏离既定的轨迹却又难以快速起停。与此相反，小型的公司则被认为是灵巧和敏捷的，能够转身，容易起停，而且只需要付出较小的成本。
大型机构组织的长处主要在于控制—— 通过明晰的分层结构，使命令链得到更有效的强制实施；通过各种各样的规范，可以获得效率。经过大型机构的核心系统IT项目的实施过程，如果说能给我们带来最有意义的一点启示的话，那么一定莫过于它将告诉我们大型的项目潜在的降级的行为必须得到有效的管理。
高级管理人员的时间也是一个稀缺资源，时间应该用于能发挥其最大价值的地方。而负责掌控那几个“大而丑陋”项目的信息技术项目委员会成员的角色就是发挥这种资源重要作用的地方之一。
在对大型项目进行管理时，必须采用分而治之的策略。项目经理之下的组织形态通常应以工作性质和/或方案构件为基础。比如，在整个项目的生存周期内，可能需要一名首席业务分析师去领导，负责确认业务需求并担负起维持需求一致性的责任。
简单地说，同规模相关的风险主要表现在项目的规模可能超出了实际需要。因此，设法让项目规模变得更小一些还是比较现实的。但这也在提醒我们，需要比较强的控制能力来管理那些超出预期的需求变化。
总之：
● 对大型项目而言，效率和控制是最重要的，灵活性次之。
● 大型项目往往都是管理关注的焦点。
● 分而治之策略，为项目经理之下的团队负责人以强有力支持是控制大型项目的重要手段之一。
● 需要强调，围绕着项目计划，应该针对管理上的差异进行有效的财务控制。
2. 以正确的方式影响机构
信息技术的发展和应用是一步步成长起来的。这可以形象地比喻为“爬－走—跑”的过程。现在，让我们从“爬”开始。
在业务部门对信息技术能做什么只有很有限的认知的情况下，研究和开发(R&D)也许是构思一个项目的最好方式之一。用于研发的资金也会多于“种子资金”。通过研发，可在比较小的范围里“引导”用户发现信息技术能给业务带来的根本性的变化，进而认识到这种变化的可能性和合理性。应该利用着迷于信息技术潜力的团队的创新能量，来逐步提升项目的价值，但这个过程要求项目管理者具备在“概念和可行性”阶段鼓励和培养探求新思想的特殊技巧。利用原型技术，对快速修正采取较宽松的控制措施，可以在较大范围内随意使用代码库可能是这一阶段比较恰当的开发方法。
现在我们来“走”。一旦业务人员知道信息技术能交付什么样的解决方案，那么他们就能准确地定义需求了(也需要得到业务分析技能方面的适当帮助)。这时，交付模型就相对显得比较重要了。如果项目最终还要进行跨公司部署，那么项目的规范就不能根据某个用户组或者兴趣组织的喜好去制定了。解决方案必须能满足整个企业的需要。可能遇到的问题必须尽早面对并及时加以解决—— 把多方的意见巧妙地结合起来。如果想把一个未成型的方案愿景转化为信息技术风景里的现实，最重要的还是在这个方案里要考虑到所有非功能的需求。这些非功能的需求需要经得起较长的时间和较大的空间的考验，并且保证在维护、保障和升级过程获得理想的成本—效益。交付团队还应该包括一大批的IT基础设施与操作方面的专家。在项目完成后，由他们拟定出来的解决方案应该是适合“移交”的。为了在解决方案部署前，及时了解可能出现的变更，让引导和训练每一个目标用户组的目标更容易达到，在项目管理中引入“变更管理”功能是比较恰当的。
如果打算在整个机构以多种模式广泛地部署一个打包的解决方案，那么“最小化变更”应该作为一个基础目标。这样的计划需要管理层之间紧密配合，需要具备深具信心的管理理念。诸如“你应该按照XXX标准”或者“我知道这不是你现在和过去做事的方式”之类的话，对说的人和听的人都是很难堪的。
质量保证体系也需要全体利益相关者的共同参与，而且不应该被任何议程所主导。缺陷分类系统也有可能被滥用，系统“认受性”阈值可能会建立在虚假的基础上。发出类似“我不喜欢这种系统的交付方式”指责的人同按照合理合法的方式提出：“以现在的模式，实施了这个方案后我们的业务会发生很大的变化”的人之间根本就不会有共同的目标。但是对某些人来说，把面粉从麦壳里分离出来也许并不难，尤其当用户是这个领域的真正专家，交付团队早就面临着早期流程失败的时候，比如，出现了类似于“我们绝不会签署这份规范”的争论。
现在我们可以“跑”了。如果项目目标是把某些变更交付到一个已经建好的系统环境中，那么我们建议采用另外的一种交付模式。现存的系统将对可行解决方案的选择会带来很大的约束。我们只能指望新的业务需求能够“框”在现存系统的“原理”、“架构”和“框图”里。如果真能这样，那么任何变更都不会对系统规范的细节构成影响—— 接下来要做的只需要让新需求能够认可现存系统的特性。如果能发出“让系统像以前那样的工作”这样的指令，那么这句话自身就是业务和信息技术专家之间最佳效果的沟通了，也很容易就如何满足现存系统的要求达成共识。然而，很多“非功能”性的系统需求都是内建的—— 或者说，即使这些功能并不存在，系统也是可以接受的。这种内建的非功能性的存在实际上意味着它们不可能得到任何实质上的改进—— 负责基础设施和操作的专家们早已知道这套解决方案是如何运行起来的，因此，他们只需要花很少的精力参与项目过程，就能让系统正常工作。这时，只要在“标准”的测试计划里，拟定一套回归测试库就可以让我们得到快速而高效的质量保证，这要比从头开始开发新QA方法要好得多。
接下来，我们就可以沿着已经建立起来的渠道把变更部署到业务环境中。围绕着系统新版本的功能以及因为这些新功能所带来的业务流程上的变更，着手制定并实施面向用户的瀑布型教育和训练计划，把已有那些明星客户、专家以及“用户组”作为第一批的培训对象，这是一条很合乎逻辑的途径。
到了这个“跑”的阶段，比较重要的事情是要维持审慎的、最低水平的控制以避免出现交付链上的“单点”失效风险。一家大型的零售商，他们很长时间以来一直处在“跑”的阶段，在听到本书作者之一对有关系统环境的标准问题做出解答以后，仍然感到非常吃惊。为什么呢？通常，两个经验丰富的高级程序员肯定有着自己本地的开发环境——
基于这样不同的环境进行着软件开发、跟踪和单元测试工作。开发结束，系统会直接被迁移到新的、已经完全不同的软件生产环境中。在这个时候，迁移的软件完全没有建立起测试环境，也无法把这些新软件完全孤立起来，做到完全的可控。再加上在这个时刻，程序员还可以无任何约束、无监控地访问产品库。种种因素加在一起，表现出了重大的、可能失控的风险：
即：
● 如果新技术是未知的，那么它对公司可能造成的影响也是未知的，那么采用新技术的过程可能就需要领航，采用R&D模式。每一个R&D项目都应该经历旨在把对机构造成的影响降到最低程度的领航过程，参照“种子资金”的管理方式来进行管理。除此之外，要求团队具有强烈团队意识，把业务专家和信息技术专家结合在一起，造就团队的创造性管理风格。
● 有生命力的、流行技术的采用和开发将对企业构成深刻而长远的影响。这个过程要求很深的用户介入，形成具有广泛代表性的利益相关者管理团队，组建具备“全面而独到”技能的信息技术解决方案交付团队，要求这支队伍具备优秀的管理能力，完善的沟通技能和良好的谈判技巧。必要的业务流程视角也可以拿来，作为对抗信息技术系统核心论的筹码。
● 在现有系统环境下进行的变更。在期待一种明快的管理控制的同时，这个过程非常仰赖于领域专家对变更做出正确定义。在质控和测试过程中，采用带有强迫性质的管理控制措施—— 至少要优于实施，这大概会成为问题的焦点。在用户看来，通过已有的渠道来部署新的功能是件顺理成章的事。
将变更引入现有的系统环境所带来的巨大挑战后面还会讨论。
3. 管理项目复杂性
也许我们提供用来治疗项目复杂性的第一味，也是最有效的药方只能是：除非万不得已，不要引入项目复杂性！然而，避免不必要的复杂性也是一场非常大的挑战。究其原因，还是因为信息技术人员具备的实践经验，经历的越复杂，企图采用的解决方案和项目结构就会越复杂。因此，就需要我们能采用比较独特的方案与架构设计技能，在从概念设计图开始，一直到生产环境部署终了这一系列的过程里，尽量采用最简单的解决方案。
第二味药方是：如果复杂性确实无法回避，那么发挥智慧来管理它(RAE，2004)。很多项目在最初的时候总是会指向几个并行的其他计划，多多少少都会表现出某些依赖性(或者独立性)。解决这个问题的办法通常是在项目团队里指定一个或者几个负责衔接、综合或者协调的角色，让他们来管理计划间依赖性。通常，这个职位上的人员都是比较低级的，没什么经验，也大多缺乏内涵。有些时候，对这个角色的职责定义也是模糊不清的—— 最大期望也就是能出席一些会议了—— 因此，为这个角色制定的目标和产出也很含混。
发挥智慧去管理项目复杂性，首先是项目经理的责任。必须规范化地管理同所有其他项目之间的重要依赖关系。是不是真的做到了严格管理，就看项目是否成功交付，还要看是否能成功交付在险产出。在一些成功项目的内部管理上，确实做到了将“分而治之”的策略运用得恰到好处，团队内的“矩阵”式管理体系同团队之间的合作经验相辅相成。如果项目经理不能站在这样的高度来看待、处置相关问题，那么项目的复杂性就不可能得到恰当的管理。
总之：
● 对项目复杂性问题，应该秉持一个正确的理念。如何管理项目复杂性给我们带来了一个很大的挑战。
● 把项目复杂性保持在必需的程度上。项目经理应该积极、动态地管理项目复杂性，尤其是复杂性同其他项目高度相关的场合，以及来自于项目团队内部各部门之间的复杂性。
4.3.2 理解项目的“困难程度”
采用项目风险因素的方法来度量项目风险是否恰当？从单一风险因素的定性特征来看，这种做法也许并不适合。但是，项目风险因素方法在有些方面还是很有用的：比如综合这些因素，将信息技术项目风险度量分为高、中或低几个级别，再用这几个级别来表示项目的成功开发的“困难程度”，帮助高级经理们做出相关报告等等。
Barki等(2001)往前更进了一步。他采用更直观的方法把 “项目风险敞口”定义为全局的不确定性(归一化处理后，使用了23个主要风险因素变量的平均值)乘以每种因素潜在损失的重要程度(包括这些变量的11项的均值)。
取Barki清单定义中的每一项潜在损失的均值是否会导致错误的结论，我们表示怀疑。但是，很多机构宁愿采用最大的潜在损失项而不是取它们的均值，分别在敞口和影响这两个维度上极其小心进行均值变换，最终导出均值。
京ICP备06004481号 Copyright 2002 - 2006 ITGov.org.cn, All Rights Reserved