编者按：本文作者Serena（又名ccjjgg79310）在一家制造企业集团总部就职，负责IT项目管理，接触过较多的失败项目。在此，她愿与大家分享个人的实战经验，与志同道合者一起成长。亲爱的读者，也欢迎您来稿来电，联系本文编辑（MSN：bunnybunny505#hotmail.com  TEL：021-33680077*265），一吐胸中块垒。

IT项目管理实战经验谈① 失败！甲方屡次选错乙方终致项目暴毙

　　【IT168 专稿】甲方选对乙方供货商只是第一步，要实现双赢还有许多细节需要注意。接着说项目计划。

　　每个项目在需求确定的情况下，都会有一个大致合理的工期。因为进度与成本的关系并非单调变化，一般呈U形，所以这个合理的工期（成本最低、效益最大）是存在的，只是甲方多半不知道罢了。

　　对甲方来说，要知道非常简单，要求供应商提供解决方案的时候就提交计划。通常说来，差别不会不靠谱（万一真的不靠谱，就在讲标的时候问，看看他们能说出什么道理来），所以取个居中的时间，差不多就是这个最合理的工期。

　　没事的时候，最好不要强压供应商一定要什么时间完成，强压会导致供应商加人。事实上不是人加一倍，进度就快一倍；常常是人加一倍，进度只能少1/4，沟通成本、整合成本却在成倍增加。所以甲方的同志，要相信乙方对时间的估算。

需求分析锁定利益干系人

　　项目前期的需求分析，就是招标之前写初步需求，也是一个非常重要的环节。前文项目失败是因为供应商选择的问题，所以先写那篇，这里补上需求调研环节。

　　企业的实施类项目常见的生命周期包含以下步骤：开始，立项，需求调研，合同，系统实施（含二次开发、供应商测试、用户测试），试运行，结束。具体做法大致是：一个项目、一个合同、几个模块同时开始需求调研，同时开发、测试，同时试运行，然后项目整体结束。

　　项目的需求分析，就叫RFP吧，免得和供应商需求搞混了。在企业做项目，一定要知道自己的Stake Holder（利益干系人）是谁，尤其是部门长级别的Stake Holder。

　　一方面要知道他对这个项目的定位，也就是范围、深度，另一方面要知道他们的兴趣点是什么。没人会指望你做个系统就所有事情OK了，只要你解决了他头疼的2～3个问题，他就会开心了，IT部门的绩效就出现了。

　　不是说不关心下面人想什么，而是说要优先关心那2成的东西。事实上我的感觉是比如做10个模块，通常只有2个是部门长感兴趣的，也是让他决定要不要说你项目有用、做得好的2个决定性的模块，或者2成的功能是他感兴趣的。

　　项目实施过程中，客户提出来的问题8成都是些不好用之类的小问题，真的有问题的就2成，看起来2/8原则基本上是处处成立的。

实施不分阶段则先闲后忙

　　如果大老板们和下面的人提出的东西，彼此之间有一定的独立性，建议把项目分成几个阶段（RFP里面就要告诉供应商要分阶段），不是传统说法上那种“需求——实施——测试……”这种阶段，也不是一期二期那种，而是一个合同、项目之内的事情分成几个阶段。

　　比如，打算做8个模块，就先做大老板关心的1～2个模块+报表模块，其他的再慢慢做。建议周期在3个月以上的项目都可以考虑一下分阶段。这个当然不是每个项目都成立的，有的时候很不幸几个模块彼此关联性非常大，必须一起做，就没辙了。

　　分阶段实施的时候，第一阶段需求完成了，供应商开发的时候，就开始做第二阶段的需求。一来时间可以向前挪动一些；二来，用户和咨询顾问不会出现开发阶段无所事事的空当期；三来，用户使用模块的周期比较长，有更多的机会在前期就暴露出开发中的问题。

　　正常情况下，企业不分阶段实施项目的做法可以用下图示意：

　　示意图说明：时间仅做一个较长的跨度假设；假设详细需求调研是在合同签订前完成；合同签订与系统实施是串行关系，不能同时进行；假设系统实施的3个月中，2个月处于二次开发、单元测试、集成测试等供应商为主的工作，最后1个月处于用户测试以及反复修改的过程。

　　系统实施步骤长达3个月，期间包括各模块的并行开发、测试、用户测试等等，通常会出现：3个月中，前面2个月是处于用户和供应商没有交流的开发真空期，供应商和实施期的最后1个月内用户密集测试，工作量很大。

分阶段赢得时间却暗藏灾难

　　如果我们换一个做法，在系统实施阶段，按照模块的二次开发工作量的大小、需求的重要紧急程度等因素来划分阶段，把领导重视的、二次开发工作量小的模块放在前面实施，领导次要重视的、二次开发工作量大的模块放在后面阶段实施，可能会收到更好的效果。

　　因为领导重视程度与二次开发工作量大小两个维度没有必然相关，既可能领导重视、二次开发工作量大，也可能领导重视、二次开发工作量小，因此具体划分阶段时，必须根据企业的实际情况权衡。

　　现在假设一个项目有5个模块，把模块1、2这种领导最关注的并且几乎没有二次开发工作量的模块实施作为第一阶段，把模块3、4这种操作层关注、做少量二次开发就可以应用的模块实施作为第二阶段，把操作层很关注、但因与现有业务模式完全不同而需大量二次开发的模块实施作为第三阶段。如下图所示：

　　从图示中可以看出，每个阶段的末期都会有用户测试，这样整个实施过程中，用户始终是参与在项目当中的。一个阶段开发完成后，用户即可开始测试，用户最长的松弛时间是10月20～11月12日，22天，比起不分阶段60天的松弛时间，少了近2/3的记忆衰退期。

　　如果用户测试的过程中，供应商有足够的人力进行下一阶段的开发，那么时间示意图还可以成为这样：

　　从图示中可以看出，赢得了松动时间10天。

　　所有的方法都有正面和负面的效果，分阶段实施也不例外。它最大的问题就在于系统重复构架。因为客户试用后提出的需求是分阶段被描述的，后期提出的需求对前期的构架很可能有比较大的影响，这就存在一个反复构架、反复衡量影响已有模块的风险。

　　规避这种风险，要求供应商在合同之前的，就能对企业的业务深入理解，考虑到可能发生的变更，并有高水平的构架工程师一起设计出有足够柔性的框架，避免后期需求变更对框架的影响。一旦构架不够柔性或者需求变更大且多，分阶段实施的弊端就会给项目带来灾难性的影响。

　　因此，选择是否分阶段实施，需要事先有足够详细的规划和风险评估，请读者慎重选择。

实施分阶段和不分阶段之优劣比较