摘要：从技术角度探讨在IT项目实施中如何识别技术风险，并论述技术风险规避的几点体会。

        如何在IT项目实施中有效地管理风险、控制风险，已经成为了项目实施成功的必要条件。在项目风险的诸多因素中，技术风险往往容易被忽视，但因技术风险导致的项目延期、项目成本失控、甚至项目失败却也不在少数。因此，本文就怎样识别技术风险，并采取有效的风险规避措施防止项目失控，谈谈个人的几点体会。

        项目风险的管理不仅贯穿于整个项目过程，而且在项目事件发生之前风险的分析就已经开始。我们可以根据风险控制与项目事件发生的时间将风险管理划分为三个部分：事前控制——风险管理规划，事中控制——风险管理方法，事后控制——风险管理报告。在这里风险管理规划是最重要的一个环节。技术架构好坏、软件提供方的技术能力以及项目实施方的实施经验等因素形成了信息化项目的技术风险。为了规避项目的技术风险，企业的项目经理，一方面要选择开发能力较强的软件提供方和经验丰富、服务优良的项目实施方；另一方面还要把握项目的技术架构与企业其它信息化项目技术架构之间的一致性；此外，引入第三方的专业咨询、监理和项目评估也是企业规避技术风险的有效手段。

        在实际IT项目中，项目的技术风险主要表现为以下情况。了解这些有助于项目经理在项目初期就识别出这些风险，并采取措施避免或者减少它们的发生：

        . 需求变更的风险应对

        在项目实施过程中，虽然需求已经基本明确，但此后仍然有变更发生，对项目造成影响，因此可以采取下述几个方法来处理：

        1) 前期的需求讨论要详细、充分。需求文档中需求的范围要明确、功能描述要清楚。

        2) 需求文档中要有demo。对于web项目，图片比文字更能说明问题。

        3) 找出项目中需求的决策者(通常会是产品经理、相关职能主管、客服)，所有的需求要经过他们的认可。

        4) 客户在项目过程中的全程参与有助于降低此类风险。需求讨论、需求确认、User确认、测试阶段的客户验收等环节，都要要求客户参与。

        5) 发生需求变更时，严格按照需求变更流程执行。

        . 技术架构的选型

        三分软件，七分实施，十二分数据。虽然这几乎已经是业界的一个共识。技术层面的东西仍然是信息化项目选型中一个难以跨越的鸿沟。如果在软件选型过程中，忽略了技术架构的内容，那么很难保证整个信息化项目能够取得圆满的成功。在IT项目中，系统的架构选择是否合理，对项目的成败是至关重要的。如果先期没有选择合适的系统架构，可能在项目实施初期还不会凸显矛盾，但随着项目实施的逐步深入，技术架构对系统的制约因素愈发难以消除，最终可能导致某些功能采取架构以外的技术实现，或勉强应对过去。

        1) 技术的成熟性

        在进行软件选型的时候第一个要考虑的技术架构层面的问题就是这个技术架构是否成熟。即时信息化管理软件是在原来的技术架构上升级而来的，而不能够忽视这个问题。最妥善的做法就是新版本软件出来之后不要马上采用。而是等一段时间，等到其出来补丁之后再使用。不然的话，项目成为了软件公司试验用的老鼠，为此技术架构的成熟性是项目选型中必须要考虑的问题之一。

        2) 技术架构的兼容性

        现在信息化管理软件的技术架构有很多。如有客户机/服务器模式的；也有浏览器/服务器模式的。其开发平台也有很多。如有传统的C语言平台的，也有最近比较时髦的JAVA与.NET平台的。不同的开发不同、不同的部署模式其兼容性是不同的。在软件选型的时候，需要考虑到技术架构的移值性问题，

        3) 资源的兼容性

        除了要考虑信息化管理软件跟操作系统平台的兼容性问题之外，还需要考虑与现有的其他管理软件的兼容性问题。简单的说，就是要看看预计要使用的架构软件，是否提供了足够多的接口，可以与新的信息化管理软件进行集成。在项目选型的时候也需要考虑技术架构跟现有企业资源的兼容性问题。为了减少信化项目的实施与维护成本，最好能够选择那些能够跟现有资源充分兼容的技术架构，最大限度的发挥现有资源的价值。这不仅可以让各个信息化系统通过一定集成手段整合为一个统一管理平台；而且由于充分利用了现有的资源，可以大大降低信息化项目的成本。

        . 技术难点

        在系统实施过程中，往往会碰到一些具体的技术难点，有些技术难点的解决与否会制约着项目的发展进程甚至左右着项目的成败。因此作为项目经理必须对项目中的技术难点有充分的认识，并预先做出判断。确定了技术难点后，必须在开发全队正式投入全部精力之前，先集中资源对这些技术难点进行技术讨论和先期开发，待技术难点问题得到彻底地解决或已经在技术上有明确的结论后，再制定与之相关的进度计划，否则即使制定了开发计划，在制约该计划的技术难点未有有效结论之前进度计划是没有意义的。由于技术难点的解决时间不是以工作量的大小来衡量的。不能以投入多少个人月这样的估算方式来衡量技术难点的工作量，必须依靠技术骨干的技术能力来解决。

        . 系统需求的确认时间

        我们在做系统时，经常是在商务人员把技术合同转交后在见到项目的需求内容此时需求已经在合同中确定而无法更改。这样，导致在项目实施过程中有些功能因技术或其它方面的原因而无法满足，只能更改目标范围或商务解决。为了防止这样的情况发生，项目经理最好在商务谈判中就开始介入系统，并与商务或前期技术支持人员共同讨论需求的合理性和可行性，避免把不合理的需求内容写入到技术合同中，在项目前期即开始风险的规避。

        软件项目风险评估主要采取以下方法：

        (1)建立软件项目风险清单。风险清单是关键的风险预测管理工具，风险清单中应列出在任何时候碰到的风险名称、类别、概率及该风险所产生的影响;

        (2)对软件项目风险进行评估。风险评估的具体做法是：根据风险的不确定性和损失两个基本特征，为每个风险计算风险值。风险http值=可能性×影响值，两者的乘积越大表明该风险越高，越值得重视；

        (3)软件项目风险划分。在进行了风险的量化分析后,需要对已经确定需要进行管理的风险进行优先级的划分。在风险划分中必须强调的是由于每个项目的资源都是有限的，所以风险管理必须把精力集中在最重要的风险子集上，并且在项目进行中条件和优先级发生改变的情况下，组成此子集的风险种类也要随之改变。

        风险归类应作为风险计划的一部分。风险计划是整个风险管理的总纲，负责为每个风险管理过程提供信息。风险归类应该作为风险计划的输入而不应该是风险识别的输入，因为风险计划提供的信息可贯穿整个风险管理系统。根据“二八”定理，20%的主要风险影响了项目80%的成功率，风险识别的重要任务是识别出主要的风险源而不是全部(风险分析员最惧怕在识别阶段漏列了主要的风险源)，风险归类的目的是为了在识别阶段能把大量精力用于识别主要的风险，使风险管理事半功倍。风险归类成为风险计划的一部分，不仅有助于后续风险识别，也有利于风险分析、开发有效风险处置策略及实施风险监控。

        软件项目风险分析活动都是为了建立一个具有良好效果的处理风险的策略。风险管理策略一般包含3个内容:(1)风险规避;(2)风险监控;(3)构建风险管理模型。

        风险规避就是通过变更项目计划，从而消除或形成风险的条件，或者保护项目目标免受风险的影响。虽然项目队伍永远不可能消除所有的风险,但某些特定的风险还是可以规避的。在项目早期出现的某些风险事件可以通过澄清需求、获取信息、加强沟通、听取专家意见的方式加以应对。减少项目范围以规避高风险的工作；增加项目资源或时间；采用一种熟悉的而不是创新的方法。

        项目失败根本原因可归结于对项目风险掌控不利，即未能有效运作项目风险管理系统。管理者未能成功实施项目风险管理的原因很多，大致有风险管理意识淡薄、缺失对风险管理过程模型的理性把握、风险管理技术实施难三点。其中属风险意识淡薄是关键原因，因为万事惟有意念先行才是问题解决的根本。

        作为IT项目的项目经理，必须对项目中的各种风险进行风险分http析，制订风险管理计划，还应特别关注项目中的技术风险，并按照风险管理计划对项目进行风险识别与处置。项目管理这门科学不是照本宣科地做就能做好，必须在应用实践中不断体会，并及时总结，才能真正达到项目管理的目的。