非常道-中小软件公司项目管理（3.3 项目外部关键成功因素） 最近忙一些私事，要离开自己亲手创建的团队了，心中多少有一些怅惘。软件开发这个行业总是这样分分合合，朋友在眼前来来往往，缘来则聚，缘尽则散。亲爱的兄弟姐妹们，希望以后还有机会再在一起奋
非常道-中小软件公司项目管理（3.3 项目外部关键成功因素）
最近忙一些私事，要离开自己亲手创建的团队了，心中多少有一些怅惘。软件开发这个行业总是这样分分合合，朋友在眼前来来往往，缘来则聚，缘尽则散。亲爱的兄弟姐妹们，希望以后还有机会再在一起奋斗。
接上节讲述的项目的内部成功因素，主要是：
一、识别团队能力
1、关键技术掌握度
2、团队成员综合能力（经验、能力、体力、专注度）
3、团队成员期望值
4、公司重视及期望值
二、获得资源
下面我们讲讲项目成功的外部因素，通常这些因素是最难以厘清的，也是考验一个项目经理真实功底的地方。
三、项目外部关键成功因素
项目要想成功，只靠内部因素是不够的，其实很多时候，内部的问题相对外部来说，也好解决的多，毕竟大家利益基本上是一致的，除开龌龊的政治斗争外，内部团队没人愿意项目失败。当然越大的公司内斗越利害，好比腾讯的财付通要在QQ空间投放软广告也要看QQ空间部门脸色还得付钱一样，这个没办法避免，只能尽量在公司的企业文化和政治制度下去尽量平衡和避免。因为我讲的主要是中小企业，所以这些厚黑的部分我们暂时忽略，大家自己将来慢慢领悟吧，讲多了也体会不到。
项目的外部关键成功因素重点就在两个字，关键。好了，我这不是废话，好比打仗一样，行军、选将、粮草、情报、天气、士气、地理都重要，但都考虑了，就算是越级计算机也算不过来。为什么这么多因素，还有人可以运筹帷幄打胜仗，我想没人说是运气，这其中的奥妙就在于，抓住了主要矛盾，一场战争，我可以一直输，但关键的一仗赢了，我就赢了，看看项羽和刘邦就明白了，小邦子开始那个输得惨，最后垓下一战一开始还被项羽打得找不着北，却转瞬就反包围了项羽，这其中，小邦子论武功、战场意识、用兵能力均比不上项羽，为什么他能赢，就因为他找准了关键因素，单打不行，要人多齐心一起灭了项羽，刘邦稳定了诸候，用利益调动了韩信、彭越、英布、刘贾这些人来一起群殴项羽，先除掉项羽这个最大的威胁，再来发展。这时战场上什么因素都不用去考虑，5个人打1个，小邦子这边又都是精英，大家都知道项羽厉害，不能让他翻身，全力以赴，终于让一代英雄项羽饮恨乌江。
说了这个故事，大家应该明白，关键成功因素是指在某个时间段内，某一因素对项目的成功起着决定性的正作用或反作用，只有运用各种手段，保证这一因素的形成或避免这一因素的形成，才能保证项目的最终成功。
关键因素是很微妙的，但一定是在某一时间段内恒定不变的，如果关键因素在项目交付前发生了变化，那就不是关键因素，而是我们所说的次要因素。下面我们分析一个案例：
某企业（甲方）委托某软件公司（乙方）开发一个生产管理系统，客户方要求根据工厂的生产管理特点进行钢材的工序及材料管理，甲方对接的小组长为信息中心主任，使用者为生产车间及仓库的统计员。甲方以前在生产管理中暴露的问题为：用Excel统计，数据规范性差，数据录入偏差大导致真实度低，并且难以统计分析。因此甲方希望在四个月内开发一套适合甲方生产特点的MIS系统，主要进行工序管理及原材料的出入库管理。
项目呢不大，总共不到三十万，乙方组织一个项目经理和两个开发人员外加一个测试人员进入项目，这里面成本预算从立项到实施加上一年的免费运维期，项目经理小强（打不死累不跨的项目经理们的统称）于是根据经验估算至少需要3个月的时间，加上一个月的缓冲期应该足够了（注意这里开始有问题），成本控制在6个月交付是最保守的，公司同意后，于是，立项、需求分析就开始了，需求分析的时候发现有个很严重的问题，甲方信息中心主任是foxbase开发出身，又要求软件用B/S架构，很多C/S的操作习惯又想带到B/S中，搞得小强一筹莫展，后来项目总监要小强先按B/S画个原型给甲方信息中心主任看看，结果甲方来了句看不懂，小强几乎要崩溃了，于是项目在拖拖沓沓的需求分析中勉强结束，甲方也勉强认可了。（问题很明显，同学们思考一下）。后面我就不说了，美国服务器，经过漫长的五个月，项目失败了，甲方信息中心主任极度不满意功能实现和操作方式，就更别提推广在全厂使用了。小强差点要吐血了。公司也终止了这个项目并总结了失败原因，不过总结的只是皮毛，诸如需求不明确，架构选择错误之类的。下面我来说一说：
这个项目的外部关键成功因素是什么，注意这个因素只有一个，请同学们思考一下：
（漫长的1分钟......）
诸位，答案肯定很多，我讲讲我的分析思路
1、 四个月完成不了，五个月、六个月交付项目是否可以算成功呢？
当然算成功，因此进度不超过四个月不算是关键成功因素，何况项目在五个月时就已经交付使用了。
2、 需求分析不明确
怎么说呢，原型也画了，功能描述和数据表设计甲方也认可了，勉强认可了原型和需求分析，也算是评审通过了。又有几个项目是需求完全无误差通过的呢，所以，需求吻合度也不算是关键成功因素
3、 架构错误
说实话，这个比较迷惑人，确实按甲方使用习惯是采用C/S比较好，但甲方又一定要求采用B/S架构，而且这个架构下的原型及操作方式都和甲方讲清楚了，甲方开始的时候也表示可以按这种方式去做，单纯的换架构到C/S方式也不一定能让用户像以前使用Excel那样方便
上述3个原因只是项目失败的原因，其实这个项目的关键成功因素只有一句话：
在保证用户操作使用习惯的前提下，实现简单的工艺流程及出入库管理。
看见没有，香港空间，技术人员和甲方认为B/S先进，却没想甲方一直是用Excel进行管理的，而且甲方的初衷就是开发一套适合甲方的生产管理系统，“适合”两个字被多少小强忽略了，因为太泛泛，但这种忽略换来的恶果就是项目的失败。软件，始终是要给人用的，当人的使用习惯不能被改变时，我们就只能按客户的习惯去实现，这是市场规律，要不然大家就都是乔布斯了。
小强的问题在于：
1、分析项目进行估算时，过于乐观，没有进行和组员一起头脑风暴，在没有和客户建立有效沟通的前提下，单纯的凭个人经验预估，导致后面死得很惨