一个IT项目失败回顾

dudq

本人作为项目经理，曾经为一个央企实施OA，本来三个月的项目，最后七个月才完成。经过两个月的试运行后，项目被放弃。
  {9 F2 ^* s1 J! u" w$ q这个项目让我真正明白了项目的风险管理是怎么回事，于是本人的项目管理工程硕士论文就以IT项目的风险管理为研究对象，系统地研究IT项目的风险管理。
7 }8 D. R2 k7 j0 b现在对此项目进行回顾。
学过项目管理的人都知道，项目风险对项目结果的影响函数是Boehm公式，即RE=P(UO)*L(UO)，其中，P(UO)是风险发生的概率，L(UO)是风险发生时对项目造成的后果。在IT项目中，有一些典型的高发生概率、高影响的风险，如技术风险、关键员工离职风险等；而有的风险虽然经常发生，但却对项目的影响却不大，如项目中的某一项任务延期。现在承包方和客户对延期都有了一种免疫力，对一般的延期大家都不太放在心上，也不知道这是一件好事，还是一种约定俗成的看法，但这也体现了客户方的一种无奈。
5 D0 C+ ^& l1 F. ?4 F. k1 _) S另外一种风险就是发生的概率很小，但一旦发生就会对项目造成非常大的影响，而且，这种影响在项目的初始阶段并不明显，当这种风险逐渐转变成问题，要想再改正就在付出极为高昂的代价，对承包方和客户都带来极为不利的影响。这个风险就是产品选型风险。
可能大家觉得不可理解，现在OA已经是大路边上的产品了，从万元以下，到50万元、60万元的产品都有，产品线极为丰富，为什么还会有产品选型这种风险呢？其实很好理解，一句话：关系。
: X0 N- i7 h' M& L. ]% u- d如果承包方和某一软件公司的关系很好，在进行产品采购时，当然要优先考虑这个公司的产品。如果客户方没有此方面的经验，也没有请相关专家和顾问，再加上没有严格走招标程序，认真进行产品选型，项目能否成功，那真的要看运气了。
随着项目的进展，产品选型带来的问题（现在已经转化成问题了）一点一点的出现了。大家知道，央企都带有一定的政府职能，他们下发的文件叫“红头文件”，这样，OA就必须有“套红”功能；此外，必须有电子印章，这样，OA就必须和第三方的电子印章系统有良好的接口；还有，发文要有发文号，文号又有大类和小类的区别，而文号只跟大类走。一连串的需求，已经让合作方招架不住了，但偏偏合作方内部又出问题。
合作方的总部在上海，我们公司是和他们的北京分公司接触的。不知道怎么回事，上海总部对北京分公司不太满意，要在北京成立一个办事处。这样，有段时间，对北京分公司的项目一率不再支持，直接就把我们（承包方）给凉在了那儿。在这个时候，我们要想再换产品，已经来不及了，因为，随着项目的进行，变更的代价是几何级上升的。那段时间真正是进退两难。

造成这个结果另外一个原因就是承包方领导层不注重一线员工的意见。在进行产品选型时，如果和一线的项目经理多做沟通，这种情况基本上就可以避免。因为一线项目经理对客户需求是非常了解的，知道他们需要什么样的产品，对技术也相当了解，如果由他们对产品进行考查，这种风险是不会出现的。
这里仅仅提到了对项目影响最大的两个风险，也是直接造成项目失败的主要原因。其实，IT项目的风险非常多，项目开始的风险管理规划对项目的实施是必不可少的，也是很有帮助的。
9 `4 ]1 P+ \6 x9 Y现在对IT项目的实施，大家也开始提到项目风险的管理了。但很多也仅仅是说说而已，主要是说给客户听的，想给客户留下一个印象：即我们的公司的管理制度是规范的，看，我们的项目管理计划做得是非常完整的，我们可以很好地控制项目的风险和进度。但在实际上，如果不注意一下项目风险的管理，项目在进行过程中肯定要发生问题的，这是不可避免的。当然，一般造成的影响主要就是延期，这个延期掩盖了太多的问题，这也是承包方的不幸，因为他们没有认真地查找问题，解决问题，错过了一次又一次的改正机会，问题积累到一定程度，一定会爆发的。
在做项目的时候，时不时有个想法：既然公司做项目，就应该成立一个项目管理办公室，积累经验，更要注重教训，不断地积累，不断地改正，无论对公司，还是对个人，才会有进步。

! V) m# y9 _! b+ U. D6 o[ 本帖最后由 dudq 于 2010-3-14 19:34 编辑 ]

鹤中天

支持一下

damonwill

通过惨痛的教训积累了经验