对于风险评级，则要根据具体的项目参照组织标准进行设定，本文给出的例子中风险评级都采用四级评价法。因为篇幅关系，重点讨论IT项目常见的三项风险的风险评级内容，其他几项不做重点介绍。

    (1)客户承诺。
    客户承诺对于项目的成功有着至关重要的影响，通常是通过客户对于资源的承诺、关键人员的参与、充足的预算等方面体现出来。具体分为四种情况，而每种情况即对应相应的风险评级：
    ①客户对于项目有充足的预算并有关键的人员参与。
    此种情形的客户往往有比较雄厚的财力，例如金融、电信等行业的客户。对这类型的客户来说，资金通常并不是大问题。另外，如果项目足够重要，客户方的高层会充分参与。
    ②客户对于项目有充足的预算但缺乏关键的、有影响力的人员参与。
    客户虽然对于项目的预算充足，但项目的重要性不够(从客户的角度)或者客户方本身的组织结构决定了客户不具备对项目有足够影响力的人员参与。
    ③客户方指定了相关的人员配合或参与项目的工作，但客户对此项目的预算不足或没有预算。
    ④客户对于欲启动的项目既无相关的人员配合，也无相应的预算。

       一个IT项目是否能够成功，很大程度上取决于客户对项目的态度。这也就是为什么在实施IT项目时很多都要争取“一把手”项目，因为只有在这种情况下预算和人员才会相对充分。而如果客户方是第三种或第四种情况，那作为开发商或服务提供商就非常被动了，对于后两种情形不定期得警惕相关的情形：有些客户往往用所谓的“后续相目”作为幌子，希望能够得到服务提供商提供的服务：有的则以“示范项目”，说明后续项目的回报是如何如何地可观。

    如表1中所示的风险级别为3，就说明客户的预算不充分，典型的情况就是政府行业的项目。他们往往会讲，今年的预算已经做完了，明年考虑你们吧，你们也得体谅我们啊!遇到这种情况也得三思而后行，谨防演变为“催命项目”!许多客户实际上扮演着“IT公司杀手”的角色，尽管他们的本意并非如此。

    (2)需求定义。
    需求定义的方式往往是引起IT项目各种问题的总根源。客户的需求是否明确、客户的需求是否能够和日常的工作相结合，以及项目需求能否真正和客户的业务保持一致，都会对项目有着最直接的影响。典型的表现方式就是客户的需求变更。因为在国内IT行业大多数项目（尤其是软件内容为主的项目）都是固定总价合同，所以一旦出现需求变更，对项目目标的实现往往都会产生负面的冲击。对于需求定义也区分为四种方式：

    ①由开发商或服务提供商为客户提供需求。
    此种情形虽然是开发商最希望出现的情形，但实际项目中却是凤毛麟角。个中原因是客户极少愿意完全听从别人的指导，让开发商告诉他们自己的业务应该如何去做。

    ②开发商指导客户完善客户需求。
    虽然很难达到第一种情形，但现在越来越多的开发商和服务提供商试图努力做到“比客户更了解自己的业务”。例如对于电信等飞速发展的行业而言，客户在很多情形下自己不能够完全把握未来的业务需求。此时如果开发商兼有提供服务和业务咨询的能力，当然会得到客户认可了。所以现在看到很多汀公司都在委托猎头公司为自己招聘有经验的行业专家，行业专家也越来越成为IT公司打单时手中的王牌。

    ③客户自己提出业务需求，但开发商没有充分参与。
    此种情形对于相对成熟的业务来讲比较典型，例如税务、医疗、金融等行业。因为业务相对成熟且比较稳定，客户通常对自己的需求把握比较充分，因而能够提出完整的需求，但对于开发商或服务提供商来说，通常意味着一个熟悉和学习客户需求的过程。

    ④客户没有成文的需求。
    当然第四种情形最为可怕。对于没有成文需求的客户，他们往往不能完全将自己的业务需求描述清楚。或者本来他们的业务需求就不完事，甚至出现相互矛盾或相互冲突的情形。现实中看到的这种类型的客户还有一个特点就是对开发商的期望过高，他们往往会有这样的潜台词：“我是说不清自己的需求，但是你们得能提出来呀，你们提出来我来评价，你们提出来我确认需求。”遇到这种类型的客户一定得有足够的心理准备：因为他们同时还有另外一个派生的特点，他们的业务不断地在调整!有可能的话，争取签署期限较短的合同吧。

    评价客户可能的需求定义方式非常重要。一方面，我们看到客户对于开发商是非常挑剔的，而另一方面开发商或服务提供商对于客户则往往是“逆来顺受”，以客户为上帝嘛!客户是上帝当然没错，可是对于和什么样的客户打交道，一定得做到事先心里有数，否则项目签单后悔莫及!至少应该在合同签署时对于客户的各种行为尝试加以相应的约束和引导。

    (3)工期设置。
    IT项目的工期和汀项目的需求一样，也充满了不确定性。通常工期的设置应首先考虑到客户业务的需要，再结合实际项目实施的进度，最后得到一个合理的进度。但汀项目的特殊之处在于很难确切地告诉客户工期到底是多少，因为开发商自己心里也没底。这就是麻烦所在了。
如果我们到农贸市场去买西红柿，能经常听到下面的对话：

    “来五斤西红柿!”
    “一斤两块钱，正好十元。”
    “我买五斤呢，一块五一斤给我吧！”
     “得，您是今儿第一个买主，一块八一斤！”
    “好，那您得给足分量喽!”
     “您一百个放心吧!”

    做项目和买菜的相似之处在于都有买卖的双方。但IT开发商或服务提供商的苦恼是不能确切知道做项目的成本到底是多少，例如工期也可以看做是一种成本。即便是这种情况，作为开发方也应该争取主动，尽可能地在确定项目工期方面占据主导地位。在两维分析法中对项目工期的设置也区分为四个风险级别。

    ①由开发商或服务提供商设置项目的工期。
    取决于开发商和客户的相对地位，如果客户对于开发商和服务提供商完全信任，则有可能出现这样的情形。

    ②客户和开发商共同设定项目的工期。
    这种情形在实际项目中比较多一些。双方讨论或者是讨价还价后确定一个都能接受的工期。许多开发商在给客户提供工期时往往流于简略，最常见的方式就是“根据我们做(了这么多)项目的经验，我们建议工期应该是八个月”。其实这种做法没有足够的说服力，最好引入对客户相对透明的工期计算方法，这样客户的认可程度要好一些。

    ③工期由客户设定，但如果项目延期的话，不至于招致项目的延期罚款。此种情形也比较多。客户逐渐也接受了这样的事实，“IT项目的延期一点都不奇怪”。
    ④工期由客户设定，如果项目延期，则会引起项目的延期罚款(客户说到做到)。
    此种情形很少，但如果有类似的情况发生，那是很大的麻烦!项目赚不赚钱还不一定呢，先被罚掉了不少钱。

    所以工期的设置方式对于项目未来的成败也至关重要。与其他行业比较，世界范围内的汀项目都在大幅度地延期。所以对于项目工期的设定一定要争取主动，不能单纯地为了迎合客户，种下苦果，给项目设置不可能完成的目标。

      3．机会分类评价
    介绍了风险分类评价，这部分对机会的分类进行介绍。机会的计算过程与风险类似(机会值决定了因的纵坐标值)。此处将项目面临的机会也分为十个大的类别，分别是：①战略方向；②产品销售；③项目收入；④利润目标；⑤客户潜力；⑥竞争对手；⑦销售成本；⑧售前资源；⑨合作伙伴；⑩综合评价。对于机会的评价和算法与风险的评价和算法比较相似，参见表2。

        结论

    通过上文对于招投标二维分析法的介绍，IT公司可以对照自己的实际情况进行相应的修改。因为此处所介绍的招投标二维分析法具有特定的应用环境，如果国内的企业直接搬用这样的方法，可能不完全适用。但是可以借鉴它的思路，例如评价从机会和风险两个方面进行，然后每个方面又设定10项指标。对于指标设定可以根据组织的情况进行调整，例如五种、七种等。毕竟它是一种将定性判断转变为定量判断的方式，不用特别苛求它的精确程度。而对于每一项指标的级别设定又应该和组织的实际情况结合。例如它将项目的收入额度划分为100万美元以下、100万到300万美元、300万到1000万美元、1000万美元以上。如果直接套用可能不适用。组织可以根据自己完成项目的情况，采取“中间大、两头小”的方式，有可能超过500万元人民币就已经是上限了。

    许多汀公司感到招投标量化评价的困难在于没有历史数据作为比对的基准，一方面应该尽可能早地积累数据；另一方面，其实可以借助于评价已经完成的项目获取历史数据，这样效果可能还要更好些(因为已经知道了项目的真实结果)。