爱华网1. IT项目特点
IT项目以其实施的低成功率越来越引起大家的关注：到底是什么原因引起IT项目的大面积的失败？原因有很多，但其中一个重要的原因就是IT项目本身的特点所引起的，那就是IT项目需求往往不够清晰、项目实施过程的隐蔽性、项目可交付物的抽象性。正是IT项目的这个特征，使得IT项目从前期论证到中期实施都体现出“摸着石头过河”的特点。很多IT项目在实施的过程中都会体现出需求频繁变更、工期紧张、质量低劣等特点，造成的后果是实施IT项目的团队成员加班加点、疲于奔命；服务提供方的老板救火频频；而最要命的是客户方不满意程度一直在上升…….一个项目下来，简直是几败俱伤，没有任何一方对项目的结果感到满意。究其原因，很大程度上就是项目前期的论证工作不充分。简单讲，就是做了不该做的项目。项目还没有真正启动时就注定要成为一个失败的项目，后续阶段即使投入再多，也乏回天之力。2. “百人现象” aihuau.com中国目前的IT行业是所谓的“买方市场”，IT企业往往为了几十万元的订单都打得头破血流，更不用百万元、千万元的大单了，其中的“杀手锏”就是价格战。假如企业不能在项目前期进行充分论证，就盲目参加招投标，过分乐观地沉醉于“又签下一笔大单”的盲目喜悦中，最后的结果就相当危险了，其中就有一个发人深省的“百人现象”。笔者有机会接触了国内IT行业的许多公司，对许多尚处于快速成长期的IT公司来讲，规模达到百人左右、年营业达到千万元数量级是公司管理层孜孜以求的目标。殊不知，这正是一个危险地带。对于规模较小的IT企业来讲，比如三四十人的规模，拿到一个千万元的大单几乎是天上掉馅饼的事情。而如果到了百人规模左右，则获得这样订单的机会还是有，不幸的是，这种项目在很多情况下却演变为“催命项目”！因为项目成本过高，公司入不敷出，只能艰难度日，许多公司正是被这些“催命项目”逼上了绝路。怎么样尽可能避免这种情况？那就是量力而行，做自己能做的事情。但正如前所讨论过IT项目的特点，IT项目很多时候（尤其是前期）都是看不见、摸不着，怎么样能够在项目前期就能够清晰地呈现出做与不做一个项目的理由呢？笔者试图通过介绍业界的一种量化论证方法，以期抛砖引玉，共同探讨降低IT项目风险的方法。3. 是否去投标对于很多IT项目来说，做或不做有时看起来很难判断，尤其是角色和职责可能都会对最后形成的结果产生影响。单纯从销售的角度可能会觉得做项目多多益善，通常销售的提成与项目的签约额成正比；而财务可能比较关注项目盈利的状况如何；技术可能会关心有没有实现不了的技术障碍或者是不是技术含量过低等等。下面所示的某IT公司的两维分析法是投标前可行性分析方法的一种。通过这种两维分析可以相对量化、直观地去判断要不要去参加一个项目的招投标。3.1 风险和机会总评价如图一所示，两维分析法分别从做项目所面临的风险和机会两个角度去分析是否去参加一个项目的招投标活动。风险和机会的分布值均设定为0到100，所以整个平面被分为四个区域：分别是第I区（低风险低回报）、第II区（高风险低回报）、第III区（高风险高回报）和第IV区（低风险高回报）。从理论上讲，大家都倾向于选择位于第IV区的项目（低风险高回报）。但是在市场竞争的前提下这种情况不太可能出现，倒是更多的会集中于其他几个区域。如图一所示，黄颜色方框代表对一个潜在项目评价后它的具体位置，从图上可以看到它位于第III区（高风险高回报）。此时应该认定去参加此项目的招投标吗？通常的情况是组织要根据自己的历史经验去判断。例如图一中所示的红色曲线 将整个区域划分为两部分，曲线上半部分意味着组织可以参加招投标；而曲线下半部分则意味着最好放弃。通过这样直观的方式就可以将相对模糊的判断变得清晰起来。3.2 风险分类评价接下来，再分析如何根据风险和机会分析计算项目具体的数值（也即黄颜色方框的具体位置）。首先来分析风险的计算过程（风险值决定了黄颜色方框的横坐标值）。此处将项目面临的风险分为十个大的类别，分别是：
一 客户承诺二 需求定义三 工期设置四 复杂程度五 项目工期六 相关经验七 标书响应八 技术能力九 文化冲突
十 项目经理针对给出的10个风险类别，再依次评价每个风险对于项目的影响程度、风险评级，然后计算每个风险对应的数值，再经过两次加权，最后计算在百分值的风险规模下项目对应的风险数值。具体过程如下：（1）单一风险分值=影响程度*风险评级（2）计算所有风险分值之和Z（3）风险加权得分=Z*100/(影响程度之和*4) 说明：公式（3）中影响程度之和乘以4是因为风险区分为4个级别（1、2、3、4），4是风险的最高级别，如果每项风险都为4，二次加权后的风险值即为最高值100。类似的，后续机会的算法也采用相同的方式，不再赘述。即得到风险二次加权得分为69.44具体数值如表一所示：而每项风险都需要考虑两项指标，影响程度和风险评级。影响程度通常是根据每个项目的特点而进行相对权重的调整，一般情况下为2到5之间；例如在表一的例子中“客户承诺”、“需求定义”相对重要，所以影响程度设为5；而“标书响应”相对次要所以设为2。对于风险评级则要根据具体的项目参照组织标准进行设定，本文给出的例子中风险评级都采用四级评价法。因为篇幅关系，重点讨论IT项目常见的三项风险的风险评级内容，其它几项不做重点介绍。3.2.1 客户承诺客户承诺对于项目的成功有着至关重要的影响，通常是通过客户对于资源的承诺、关键人员的参与、充足的预算等方面体现出来。具体分为四种情况，而每种情况即对应相应的风险评级：1. 客户对于项目有充足的预算并有关键的人员参与l 此种情形的客户往往有比较雄厚的财力，例如金融、电信等行业的客户。对这类型的客户来说，资金通常并不是大问题。另外，如果项目足够重要，客户方的高层会充分参与2. 客户对于项目有充足的预算但缺乏关键的、有影响力的人员参与l 客户虽然对于项目的预算充足，但项目的重要性不够（从客户的角度）或者客户方本身的组织结构决定了客户不具备对项目有足够影响力的人员参与3. 客户方指定了相关的人员配合或参与项目的工作，但客户对此项目的预算不足或没有预算4. 客户对于欲启动的项目既无相关的人员配合，有无相应的预算一个IT项目是否能够成功很大程度取决于客户对项目的态度。这也就是为什么在实施IT项目时很多都要争取“一把手”项目，因为只有在这种情况下预算和人员才会相对充分。而如果客户方是第三种或第四种情况，那作为开发商或服务提供商就非常被动了。对于后两种情形还得警惕相关的情形：有些客户往往用所谓的“后续项目”作为幌子，希望能够得到服务提供商提供的服务；有的则以“示范项目”，说明后续项目的回报是如何如何地可观。如表一中所示的风险级别为3，就说明客户的预算不充分，典型的情况就是政府行业的项目。他们往往会讲，今年的预算已经做完了，明年考虑你们吧，你们也得体谅我们啊！遇到这种情况也得三思而后行，谨防演变为“催命项目”！许多客户实际上扮演着“IT公司杀手”，尽管他们的本意并非如此。3.2.2 需求定义需求定义的方式往往是引起IT项目各种问题的总根源。客户的需求是否明确、客户的需求是否能够和日常的工作相结合、以及项目需求能否真正和客户的业务保持一致，都会对项目有着最直接的影响。典型的表现方式就是客户的需求变更。因为在国内IT行业大多数项目（尤其是软件内容为主的项目）都是固定总价合同，所以一旦出现需求变更，对项目目标的实现往往都会产生负面的冲击。对于需求定义也区分为四种方式：1. 由开发商或服务提供商为客户提供需求l 此种情形虽然是开发商最希望出现的情形，但实际项目中却是凤毛麟角。个中原因是客户极少愿意完全听从别人的指导，让开发商告诉他们自己的业务应该如何去做2. 开发商指导客户完善客户需求l 虽然很难达到第一种情形，但现在越来越多的开发商和服务提供商试图努力做到“比客户更了解自己的业务”。例如对于电信等飞速发展的行业而言，客户在很多情形下自己不能够完全把握未来的业务需求。此时如果开发商兼有提供服务和业务咨询的能力，当然会得到客户认可了。所以现在看到很多IT公司都在委托猎头公司为自己招聘有经验的行业专家，行业专家也越来越成为IT公司打单时手中的王牌3. 客户自己提出业务需求，但开发商没有充分参与l 此种情形对于相对成熟的业务来讲比较典型，例如税务、医疗、金融等行业。因为业务相对成熟且比较稳定的原因，客户通常对自己的需求把握比较充分，因而能够提出完整的需求，但对于开发商或服务提供商来说，通常意味着一个熟悉和学习客户需求的过程4. 客户没有成文的需求l 当然第四种情形最为可怕。对于没有成文需求的客户，他们往往不能完全将自己的业务需求描述清楚。或者本来他们的业务需求就不完整，甚至出现相互矛盾或相互冲突的情形。现实中看到的这种类型的客户还有一个特点就是对开发商的期望过高，他们往往会有这样的潜台词：“我是说不清自己的需求，但是你们得能提出来呀，你们提出来我来评价呀，你们提出来我确认需求”。遇到这种类型的客户一定得有足够的心理准备：因为他们同时还有另外一个派生的特点，他们的业务不断地在调整！有可能的话，争取签署期限较短的合同吧。评价客户可能的需求定义方式非常重要。一方面，我们看到客户对于开发商是非常挑剔的，而另一方面开发商或服务提供商对于客户则往往是“逆来顺受”，以客户为上帝嘛！客户是上帝当然没错，可是对于和什么样的客户打交道，一定得做到事先心里有数，否则项目签单后悔之不及！至少应该在合同签署时对于客户的各种行为尝试加以相应的约束和引导。3.2.3 工期设置IT项目的工期和IT项目的需求一样，也是充满了不确定性。通常工期的设置应首先考虑到客户业务的需要，再结合实际项目实施的进度，最后得到一个合理的进度。但IT项目的特殊之处在于很难确切地告诉客户工期到底是多少，因为开发商自己的心里也没底。这就是麻烦所在了。如果我们到农贸市场去买西红柿，能经常听到下面的对话：“来五斤西红柿！”“一斤两块钱，正好十元！”
“我买五斤呢，一块五一斤给我吧”
“得，您是今儿个第一个买主，一块八一斤”“好，那您得给足分量喽”“您一百个放心吧”做项目和买菜相似之处在于都有买卖的双方。但IT开发商或服务提供商的苦恼是不能确切知道做项目的成本到底是多少，例如工期也可以看作是一种成本 。即便是这种情况，作为开发方也应该争取主动，尽可能在确定项目工期方面占据主导地位 。在两维分析法中对项目工期的设置也区分为四个风险级别。1. 由开发商或服务提供商设置项目的工期l 取决于开发商和客户的相对地位，如果客户对于开发商和服务提供商完全信任，则有可能出现这样的情形2. 客户和开发商共同设定项目的工期l 这种情形在实际项目中比较多一些。双方讨论或者是讨价还价后确定一个都能接受的工期。许多开发商在给客户提供工期时往往流于简略，最常见的方式就是“根据我们做（了这么多）项目的经验，我们建议工期应该是八个月”。其实这种做法没有足够的说服力，最好引入对客户相对透明的工期计算方法，这样客户的认可程度要好一些3. 工期由客户设定，但如果项目延期的话，不至于招致项目的延期罚款l 此种情形也比较多。客户逐渐也接受了这样的事实，“IT项目的延期一点都不奇怪”4. 工期由客户设定，如果项目延期，则会引起项目的延期罚款（客户说到做到！）l 此种情形很少，但如果这有类似的情况，那是很大的麻烦！项目赚不赚钱还不一定呢，先被罚掉了不少钱所以工期的设置方式对于项目未来的成败也至关重要。与其他行业比较，世界范围内的IT项目都在大幅度的延期。所以对于项目工期的设定一定要争取主动，不能单纯地为了迎合客户，种下苦果，给项目设置不可能完成的目标。3.3 机会分类评价介绍了风险分类评价，这部分对机会的分类进行介绍。机会的计算过程与风险类似（机会值决定了黄颜色方框的纵坐标值）。此处将项目面临的机会也分为十个大的类别，分别是：一 战略方向二 产品销售三 项目收入四 利润目标五 客户潜力六 竞争对手七 销售成本八 售前资源九 合作伙伴十 综合评价对于机会的评价和算法与风险的评价和算法比较相似，参见表二。4 结论通过第三部分对于招投标二维分析法的介绍，IT公司可以对照自己的实际情况进行相应的修改。因为此处所介绍的招投标二维分析法具有特定的应用环境，如果国内的企业直接搬用这样的方法，可能不完全适用。但是可以借鉴它的思路，例如评价从机会和风险两个方面进行，然后每个方面又设定10项指标。对于指标设定可以根据组织的情况进行调整，例如五种、七种等等。毕竟它是一种将定性判断转变为定量判断的方式，不用特别苛求它的精确程度。而对于每一项指标的级别设定又应该和组织的实际情况结合。例如它将项目的收入额度划分为100万美元以下、100万到300万美元、300万到1000万美元、1000万美元以上。如果直接套用可能不适用。组织可以根据自己完成项目的情况，采取“中间大、两头小”的方式，有可能超过500万人民币就已经是上限了。许多IT公司感到招投标量化评价的困难在于没有历史数据作为比对的基准，一方面应该尽可能早地积累数据；另一方面，其实可以借助于评价已经完成的项目获取历史数据，这样效果可能还要更好些（因为已经知道了项目的真实结果）。
