项目管理引入中国好多年了，除了国外的PMP、IPMP认证体系，现在更是将之引入高等学位教育。除了最先应用项目管理的建筑行业，现在各行各业都非常重视行业内的项目管理，这些足以可以看到项目管理的蓬勃发展。但是软件项目失败案例还是比比皆是的今天，如何将项目管理与新理论和技术层出不穷的软件产业双剑合璧？项目管理理论是欧美国家伴随着生产管理起步的，虽然方法论是通用的，但是如何在软件开发中产生更大效益，需要更多的业界项目经理以及高层思索和总结。

一个成功的建筑行业项目经理也会是一个合格的IT项目经理吗？项目管理有之一个名言：一个成功的建筑行业项目经理也会是一个合格的IT项目经理。在欧美国家是适用的，这样跨行业的例子也非常多。但据我了解在大陆这样的例子还非常鲜见。尤其软件开发行业，就更没这种先例了，为什么在欧美或者印度模式中，都是行得通，在中国不行呢？欧美或者印度模式的项目经理负责制定开发计划、协调、以及填写各种项目输出表格或模版就够了。在这种模式中项目经理不一定要求必须是技术专家，但更强调项目经理的工作经验，一般会要求项目经理有8年以上工作经验。而在中国，尤其是现在一个有三年工作经验的teamleader也会称项目经理，当然他也并不需要对成本、人员、采购等众多项目管理领域的关注，这样的team里也根本不会有技术经理或顾问专有角色的配备，项目经理要更多的关注技术因素，所以项目经理一般是与行业和产品同步成长起来的。如何做好质量、成本、沟通、时间、以及更资源参与的全面项目管理是我们的项目经理的课题。

范围管理是项目经理具备的首要能力。范围说明是未来项目决策的基线，也是衡量项目是否成功的标准。在我们软件开发项目中，需求规格就是我们项目的范围的体现。我的经验是项目经理应极端重视需求，成功的需求管理才能保证范围在基线内，需求调查、讨论、分析、归档、review、变更、回溯等一系列活动是我们需求管理的有效活动。

计划能力是项目经理的应具备的另一个技能，其中软件开发任务的估算是一个难点，即使有历史数据达到CMM4的软件企业也会有20%-50%的误差，我的一些做法用三层到四层的WBS模版从底向上进行时间资源的估计，会从自己经验和相似项目的历史数据中进行加权平均，时间资源的平衡，在WBS分解模版中采用自底向上估计，估计时我们采用了三人以上匿名delphi法，设定差值阈值为30%，如果与平均值的差值比小于此阈值，将不在重新估计，如果大于将进行重新估计，重新估计后如果还是超过设定阈值，估计人要写明为什么如此估计的原因。对于阈值内估计值我们采用历史经验数据进行修正即可作为我们WBS工作包的估计值。

合适的软件开发生命周期模式，对软件开发项目尤为关键。根据项目的需求、资源、风险、时间、质量等实际情况，选择合适的软件开发生命周期模式，对软件开发项目尤为关键。印度软件模式中更是提出了流程模式重于项目。在需求不确定、变化较频繁的项目我们可以选用迭代和原型法。在产品按版本递增开发的项目，由于每期需求比较稳定，宜选择瀑布变种的V模型进行测试提前的生命周期。开发模式的选择将影响项目计划，例如V字形，每个过程都有严格的输入输出，上一个过程的