招标投标-IT项目招投标的二维分析法131 精品.doc

《招标投标-IT项目招投标的二维分析法131 精品.doc》由会员分享，可在线阅读，更多相关《招标投标-IT项目招投标的二维分析法131 精品.doc（13页珍藏版）》请在第一文库网上搜索。

1、IT项目招投标的二维分析法IT项目特点汀项目以其实施的低成功率越来越引起大家的关注：到底是什么原因引起汀项目的失败?原因有很多，但其中一个重要的原因就是汀项目本身的特点所引起的，那就是汀项目需求往往不够清晰、项目实施过程的隐蔽性、项目可交付物的抽象性。正是IT项目的这些特征，使得汀项目从前期论证到中期实施都体现出“摸着石头过河”的特点。很多汀项目在实施的过程中都会体现出需求频繁变更、工期紧张、质量低劣等特点，造成的后果是实施IT项目的团队成员加班加点、疲于奔命；服务提供方的老板救火频频；而最要命的是客户方不满意程度一直在上升。一个项目下来，简直是几败俱伤，没有任何一方对项目的结果感到满意。究其

2、原因，很大程度上就是项目前期的论证工作不充分。简单地讲，就是做了不该做的项目。项目还没有真正启动时，就注定要成为一个失败的项目，后续阶段即使投入再多，也乏回天之力。“百人现象” 中国目前的IT行业是所谓的“买方市场”，IT企业往往为了几十万元的订单都打得头破血流，更不用说百万元、千万元的大单了，其中的“杀手锏”就是价格战。假如企业不能在项目前期进行充分论证，就盲目参加招投标，过分乐观地沉醉于“又签下一笔大单”的盲目喜悦中，最后的结果就相当危险了，其中就有一个发人深省的“百人现象”。笔者有机会接触了国内IT行业的许多公司，对许多尚处于快速成长期的IT公司来讲，规模达到百人左右、年营业额达到千万元

3、数量级是公司管理层孜孜以求的目标。殊不知，这正是一个危险地带。对于规模较小的汀企业来讲，比如三四十人的规模，拿到一个千万元的大单几乎是天上掉馅饼的事情。而如果到了百人规模左右，则获得这样订单的机会就会有，不幸的是，这种项目在很多情况下却演变为“催命项目”!因为项目成本过高，公司入不敷出，只能艰难度日，许多公司正是被这些“催命项目”逼上了绝路。怎样才能尽可能避免这种情况?那就是量力而行，做自己能做的事情。但正如前面所讨论的汀项目的特点，汀项目很多时候(尤其是前期)都是看不见、摸不着的，怎样能够在项目前期就清晰地得出做与不做一个项目的理由呢?笔者试图通过介绍业界的一种量化论证方法，以期抛砖引玉，共

4、同探讨降低IT项目风险的方法。 是否去投标 对于很多汀项目来说，做或不做有时看起来很难判断，尤其是角色和职责可能都会对最后形成的结果产生影响。单纯从销售的角度看，可能会觉得做项目多多益善，通常销售的提成与项目的签约额成正比；而财务可能比较关注项目盈利的状况如何；技术可能会关心有没有实现不了的技术障碍或者是不是技术含量过低等。下面所示的某IT公司的两维分析法是投标前可行性分析方法的一种。通过这种两维分析，可以相对量化、直观地去判断要不要去参加一个项目的招投标。 1风险和机会总评价 如下页图所示，两维分析法分别从做项目所面临的风险和机会两个角度去分析是否去参加一个项目的招投标活动。 风险和机会的分

5、布值均设定为0到100，所以整个平面被分为四个区域：分别是第1区(低风险低回报)、第(高风险低回报)、第区(高风险高回报)和第区(低风险高回报)。从理论上讲，大家都倾向于选择位于第区的项目(低风险高回报)。但是在市场竞争的前提下，这种情况不太可能出现，倒是更多地会集中于其他几个区域。如图所示，凶代表对一个潜在项目评价后它的具体位置，从图上可以看到它位于第111区(高风险高回报)。此时应该认定去参加此项目的招投标吗?通常的情况是组织要根据自己的历史经验去判断。例如图中所示的曲线将整个区域划分为两部分，曲线上半部分意味着组织可以参加招投标；而曲线下半部分则意味着最好放弃。通过这样直观的方式，就可以

6、将相对模糊的判断变得清晰起来。 注：曲线的绘制要根据组织自身的项目信息积累和分析给出。 2风险分类评价接下来，再分析如何根据风险和机会分析计算项目具体的数值(也即因的具体位置)。首先来分析风险的计算过程(风险值决定了因的横坐标值)。此处将项目面临的风险分为十个大的类别，分别是：客户承诺；需求定义；工期设置；复杂程度；项目工期；相关经验；标书响应；技术能力；文化冲突；项目经理。 针对给出的10个风险类别，再依次评价每个风险对于项目的影响程度、风险评级，然后计算每个风险对应的数值，再经过两次加权，最后计算在百分值的风险规模下项目对应的风险数值。具体过程如下： 单一风险分值：影响程度x风险评级。 计

7、算所有风险分值之和Z。 风险加权得分：Z x 100(影D向程度之牙口x 4)。 说明：公式中影响程度之和乘以4是因为风险区分为4个级别(1、2、3、4)，4是风险的最高级别，如果每项风险都为4，二次加权后的风险值即为最高值100。类似地，后续机会的算法也采用相同的方式，不再赘述。 即得到风险二次加权得分为 6944。 具体数值如表1所示。而每项风险都需要考虑两项指标：影响程度和风险评级。影响程度通常是根据每个项目的特点而进行相对权重的调整，一般情况下为2到5之间；例如在表1的例子中，“客户承诺”、“需求定义”相对重要，所以影响程度设为5；而“标书响应”相对次要，所以设为2。对于风险评级，则要

8、根据具体的项目参照组织标准进行设定，本文给出的例子中风险评级都采用四级评价法。因为篇幅关系，重点讨论IT项目常见的三项风险的风险评级内容，其他几项不做重点介绍。 (1)客户承诺。 客户承诺对于项目的成功有着至关重要的影响，通常是通过客户对于资源的承诺、关键人员的参与、充足的预算等方面体现出来。具体分为四种情况，而每种情况即对应相应的风险评级： 客户对于项目有充足的预算并有关键的人员参与。 此种情形的客户往往有比较雄厚的财力，例如金融、电信等行业的客户。对这类型的客户来说，资金通常并不是大问题。另外，如果项目足够重要，客户方的高层会充分参与。 客户对于项目有充足的预算但缺乏关键的、有影响力的人员

9、参与。 客户虽然对于项目的预算充足，但项目的重要性不够(从客户的角度)或者客户方本身的组织结构决定了客户不具备对项目有足够影响力的人员参与。 客户方指定了相关的人员配合或参与项目的工作，但客户对此项目的预算不足或没有预算。 客户对于欲启动的项目既无相关的人员配合，也无相应的预算。 一个IT项目是否能够成功，很大程度上取决于客户对项目的态度。这也就是为什么在实施IT项目时很多都要争取“一把手”项目，因为只有在这种情况下预算和人员才会相对充分。而如果客户方是第三种或第四种情况，那作为开发商或服务提供商就非常被动了，对于后两种情形不定期得警惕相关的情形：有些客户往往用所谓的“后续相目”作为幌子，希望

10、能够得到服务提供商提供的服务：有的则以“示范项目”，说明后续项目的回报是如何如何地可观。 如表1中所示的风险级别为3，就说明客户的预算不充分，典型的情况就是政府行业的项目。他们往往会讲，今年的预算已经做完了，明年考虑你们吧，你们也得体谅我们啊!遇到这种情况也得三思而后行，谨防演变为“催命项目”!许多客户实际上扮演着“IT公司杀手”的角色，尽管他们的本意并非如此。 (2)需求定义。 需求定义的方式往往是引起IT项目各种问题的总根源。客户的需求是否明确、客户的需求是否能够和日常的工作相结合，以及项目需求能否真正和客户的业务保持一致，都会对项目有着最直接的影响。典型的表现方式就是客户的需求变更。因为

11、在国内IT行业大多数项目（尤其是软件内容为主的项目）都是固定总价合同，所以一旦出现需求变更，对项目目标的实现往往都会产生负面的冲击。对于需求定义也区分为四种方式： 由开发商或服务提供商为客户提供需求。 此种情形虽然是开发商最希望出现的情形，但实际项目中却是凤毛麟角。个中原因是客户极少愿意完全听从别人的指导，让开发商告诉他们自己的业务应该如何去做。 开发商指导客户完善客户需求。 虽然很难达到第一种情形，但现在越来越多的开发商和服务提供商试图努力做到“比客户更了解自己的业务”。例如对于电信等飞速发展的行业而言，客户在很多情形下自己不能够完全把握未来的业务需求。此时如果开发商兼有提供服务和业务咨询的

12、能力，当然会得到客户认可了。所以现在看到很多汀公司都在委托猎头公司为自己招聘有经验的行业专家，行业专家也越来越成为IT公司打单时手中的王牌。 客户自己提出业务需求，但开发商没有充分参与。 此种情形对于相对成熟的业务来讲比较典型，例如税务、医疗、金融等行业。因为业务相对成熟且比较稳定，客户通常对自己的需求把握比较充分，因而能够提出完整的需求，但对于开发商或服务提供商来说，通常意味着一个熟悉和学习客户需求的过程。 客户没有成文的需求。 当然第四种情形最为可怕。对于没有成文需求的客户，他们往往不能完全将自己的业务需求描述清楚。或者本来他们的业务需求就不完事，甚至出现相互矛盾或相互冲突的情形。现实中看

13、到的这种类型的客户还有一个特点就是对开发商的期望过高，他们往往会有这样的潜台词：“我是说不清自己的需求，但是你们得能提出来呀，你们提出来我来评价，你们提出来我确认需求。”遇到这种类型的客户一定得有足够的心理准备：因为他们同时还有另外一个派生的特点，他们的业务不断地在调整!有可能的话，争取签署期限较短的合同吧。 评价客户可能的需求定义方式非常重要。一方面，我们看到客户对于开发商是非常挑剔的，而另一方面开发商或服务提供商对于客户则往往是“逆来顺受”，以客户为上帝嘛!客户是上帝当然没错，可是对于和什么样的客户打交道，一定得做到事先心里有数，否则项目签单后悔莫及!至少应该在合同签署时对于客户的各种行为

14、尝试加以相应的约束和引导。 (3)工期设置。 IT项目的工期和汀项目的需求一样，也充满了不确定性。通常工期的设置应首先考虑到客户业务的需要，再结合实际项目实施的进度，最后得到一个合理的进度。但汀项目的特殊之处在于很难确切地告诉客户工期到底是多少，因为开发商自己心里也没底。这就是麻烦所在了。如果我们到农贸市场去买西红柿，能经常听到下面的对话：“来五斤西红柿!”“一斤两块钱，正好十元。”“我买五斤呢，一块五一斤给我吧！”“得，您是今儿第一个买主，一块八一斤！”“好，那您得给足分量喽!”“您一百个放心吧!”做项目和买菜的相似之处在于都有买卖的双方。但IT开发商或服务提供商的苦恼是不能确切知道做项目的

15、成本到底是多少，例如工期也可以看做是一种成本。即便是这种情况，作为开发方也应该争取主动，尽可能地在确定项目工期方面占据主导地位。在两维分析法中对项目工期的设置也区分为四个风险级别。 由开发商或服务提供商设置项目的工期。 取决于开发商和客户的相对地位，如果客户对于开发商和服务提供商完全信任，则有可能出现这样的情形。 客户和开发商共同设定项目的工期。 这种情形在实际项目中比较多一些。双方讨论或者是讨价还价后确定一个都能接受的工期。许多开发商在给客户提供工期时往往流于简略，最常见的方式就是“根据我们做(了这么多)项目的经验，我们建议工期应该是八个月”。其实这种做法没有足够的说服力，最好引入对客户相对透明的工期计算方法，这样客户的认可程度要好一些。 工期由客户设定，但如果项目延期的话，不至于招致项目的延期罚款。此种情形也比较多。客户逐渐也接受了这样的事实，“IT项目的延期一点都不奇怪”。 工期由客户设定，如果项目延期，则会引起项目的延期罚款(客户说到做到)。 此种情形很少，但如果有类似的情况发生，那是很大的麻烦!项目赚不赚钱还不一定呢，先被罚掉了不少钱。