IT项目特点
汀项目以其实施的低成功率越来越引起大家的关注：到底是什么原因引起汀项目的失败?原因有很多，但其中一个重要的原因就是汀项目本身的特点所引起的，那就是汀项目需求往往不够清晰、项目实施过程的隐蔽性、项目可交付物的抽象性。正是IT项目的这些特征，使得汀项目从前期论证到中期实施都体现出“摸着石头过河”的特点。很多汀项目在实施的过程中都会体现出需求频繁变更、工期紧张、质量低劣等特点，造成的后果是实施IT项目的团队成员加班加点、疲于奔命；服务提供方的老板救火频频；而最要命的是客户方不满意程度一直在上升……。一个项目下来，简直是几败俱伤，没有任何一方对项目的结果感到满意。究其原因，很大程度上就是项目前期的论证工作不充分。简单地讲，就是做了不该做的项目。项目还没有真正启动时，就注定要成为一个失败的项目，后续阶段即使投入再多，也乏回天之力。
“百人现象” 中国目前的IT行业是所谓的“买方市场”，IT企业往往为了几十万元的订单都打得头破血流，更不用说百万元、千万元的大单了，其中的“杀手锏”就是价格战。假如企业不能在项目前期进行充分论证，就盲目参加招投标，过分乐观地沉醉于“又签下一笔大单”的盲目喜悦中，最后的结果就相当危险了，其中就有一个发人深省的“百人现象”。笔者有机会接触了国内IT行业的许多公司，对许多尚处于快速成长期的IT公司来讲，规模达到百人左右、年营业额达到千万元数量级是公司管理层孜孜以求的目标。殊不知，这正是一个危险地带。对于规模较小的汀企业来讲，比如三四十人的规模，拿到一个千万元的大单几乎是天上掉馅饼的事情。而如果到了百人规模左右，则获得这样订单的机会就会有，不幸的是，这种项目在很多情况下却演变为“催命项目”!因为项目成本过高，公司入不敷出，只能艰难度日，许多公司正是被这些“催命项目”逼上了绝路。
怎样才能尽可能避免这种情况?那就是量力而行，做自己能做的事情。但正如前面所讨论的汀项目的特点，汀项目很多时候(尤其是前期)都是看不见、摸不着的，怎样能够在项目前期就清晰地得出做与不做一个项目的理由呢?笔者试图通过介绍业界的一种量化论证方法，以期抛砖引玉，共同探讨降低IT项目风险的方法。
是否去投标
对于很多汀项目来说，做或不做有时看起来很难判断，尤其是角色和职责可能都会对最后形成的结果产生影响。单纯从销售的角度看，可能会觉得做项目多多益善，通常销售的提成与项目的签约额成正比；而财务可能比较关注项目盈利的状况如何；技术可能会关心有没有实现不了的技术障碍或者是不是技术含量过低等。下面所示的某IT公司的两维分析法是投标前可行性分析方法的一种。通过这种两维分析，可以相对量化、直观地去判断要不要去参加一个项目的招投标。
1．风险和机会总评价
如下页图所示，两维分析法分别从做项目所面临的风险和机会两个角度去分析是否去参加一个项目的招投标活动。
风险和机会的分布值均设定为0到100，所以整个平面被分为四个区域：分别是第1区(低风险低回报)、第Ⅱ(高风险低回报)、第Ⅲ区(高风险高回报)和第Ⅳ区(低风险高回报)。从理论上讲，大家都倾向于选择位于第Ⅳ区的项目(低风险高回报)。但是在市场竞争的前提下，这种情况不太可能出现，倒是更多地会集中于其他几个区域。如图所示，凶代表对一个潜在项目评价后它的具体位置，从图上可以看到它位于第111区(高风险高回报)。此时应该认定去参加此项目的招投标吗?通常的情况是组织要根据自己的历史经验去判断。例如图中所示的曲线将整个区域划分为两部分，曲线上半部分意味着组织可以参加招投标；而曲线下半部分则意味着最好放弃。通过这样直观的方式，就可以将相对模糊的判断变得清晰起来。
注：曲线的绘制要根据组织自身的项目信息积累和分析给出。
2．风险分类评价
接下来，再分析如何根据风险和机会分析计算项目具体的数值(也即因的具体位置)。首先来分析风险的计算过程(风险值决定了因的横坐标值)。此处将项目面临的风险分为十个大的类别，分别是：①客户承诺；②需求定义；③工期设置；④复杂程度；⑤项目工期；⑥相关经验；⑦标书响应；⑧技术能力；⑨文化冲突；⑩项目经理。
针对给出的10个风险类别，再依次评价每个风险对于项目的影响程度、风险评级，然后计算每个风险对应的数值，再经过两次加权，最后计算在百分值的风险规模下项目对应的风险数值。具体过程如下：
①单一风险分值：影响程度x
风险评级。
②计算所有风险分值之和Z。
③风险加权得分：Z x 100／(影D向程度之牙口x 4)。
说明：公式③中影响程度之和乘以4是因为风险区分为4个级别(1、2、3、4)，4是风险的最高级别，如果每项风险都为4，二次加权后的风险值即为最高值100。类似地，后续机会的算法也采用相同的方式，不再赘述。
即得到风险二次加权得分为 69．44。
具体数值如表1所示。
而每项风险都需要考虑两项指标：影响程度和风险评级。影响程度通常是根据每个项目的特点而进行相对权重的调整，一般情况下为2到5之间；例如在表1的例子中，“客户承诺”、“需求定义”相对重要，所以影响程度设为5；而“标书响应”相对次要，所以设为2。
对于风险评级，则要根据具体的项目参照组织标准进行设定，本文给出的例子中风险评级都采用四级评价法。因为篇幅关系，重点讨论IT项目常见的三项风险的风险评级内容，其他几项不做重点介绍。
(1)客户承诺。
客户承诺对于项目的成功有着至关重要的影响，通常是通过客户对于资源的承诺、关键人员的参与、充足的预算等方面体现出来。具体分为四种情况，而每种情况即对应相应的风险评级：
①客户对于项目有充足的预算并有关键的人员参与。
此种情形的客户往往有比较雄厚的财力，例如金融、电信等行业的客户。对这类型的客户来说，资金通常并不是大问题。另外，如果项目足够重要，客户方的高层会充分参与。
②客户对于项目有充足的预算但缺乏关键的、有影响力的人员参与。
客户虽然对于项目的预算充足，但项目的重要性不够(从客户的角度)或者客户方本身的组织结构决定了客户不具备对项目有足够影响力的人员参与。
③客户方指定了相关的人员配合或参与项目的工作，但客户对此项目的预算不足或没有预算。
④客户对于欲启动的项目既无相关的人员配合，也无相应的预算。
一个IT项目是否能够成功，很大程度上取决于客户对项目的态度。这也就是为什么在实施IT项目时很多都要争取“一把手”项目，因为只有在这种情况下预算和人员才会相对充分。而如果客户方是第三种或第四种情况，那作为开发商或服务提供商就非常被动了，对于后两种情形不定期得警惕相关的情形：有些客户往往用所谓的“后续相目”作为幌子，希望能够得到服务提供商提供的服务：有的则以“示范项目”，说明后续项目的回报是如何如何地可观。
如表1中所示的风险级别为3，就说明客户的预算不充分，典型的情况就是政府行业的项目。他们往往会讲，今年的预算已经做完了，明年考虑你们吧，你们也得体谅我们啊!遇到这种情况也得三思而后行，谨防演变为“催命项目”!许多客户实际上扮演着“IT公司杀手”的角色，尽管他们的本意并非如此。
(2)需求定义。
需求定义的方式往往是引起IT项目各种问题的总根源。客户的需求是否明确、客户的需求是否能够和日常的工作相结合，以及项目需求能否真正和客户的业务保持一致，都会对项目有着最直接的影响。典型的表现方式就是客户的需求变更。因为在国内IT行业大多数项目（尤其是软件内容为主的项目）都是固定总价合同，所以一旦出现需求变更，对项目目标的实现往往都会产生负面的冲击。对于需求定义也区分为四种方式：
①由开发商或服务提供商为客户提供需求。[本文共有 2 页，当前是第 1 页] <<上一页 下一页>>
您的位置：
