交付类项目管理杂谈

鉴于公司性质，这段时间做了很多运行商的项目。与其他企业内部管理系统类似，这种项目的突出特点就是需求变更比较严重。

需求变更是什么

从项目管理理论来说，需求变更也就意味着项目范围的变更。在实际项目中，以范围蔓延的情况居多。在项目阶段性汇报或交付过程中，客户总习惯提出一些修改意见。有些出自于官僚主义，也就是爱摆谱，比较这里颜色换一下，那个图标改一改之类；有些是项目成果与预期有差别，毕竟客户也非IT行业出身，在项目成果展现在他们面前之前，很难对自己的期望能有详尽的描述，加上沟通过程中的信息的丢失和误解，这种现象看起来也再说难免；当然还有其他情况，这里不做累述。但对于项目组来说，呵！呵！兄弟们又得加班啦！

面对这种情况，如何来破。我们先从项目管理技术角度来说。

从项目管理三角形入手



项目管理三角形有很多画法。我一般情况下习惯用上图的画法。需求变更又称范围蔓延或范围调整。当范围发生变化时，工作任务会增加，随之带来的可能是进度的延后，或者要投入更多的人力来处理这些意外。也就是范围增加引起了进度的滞后和成本的增加。我们换个角度来思考这个问题。当客户提出需求变更时，只要客户同意将原定的交付日期延后，同时愿意支付更多的费用，公司也有更多的人力资源的投入，对于项目来说就是安全的。从中也揭示出对于单个项目管理时的管控准则：对于“范围”、“进度”、“成本”是息息相关的三要素，在保证“质量”不收影响的情况下，三者保持同步协调，就能从一定程度上保证项目的成功。

从干系人入手

但现实的骨感往往是另项目经理头疼的地方。客户提出需求变更以后，以各种理由不愿支付更多的费用（当然也不能全怪他们，有时也是收项目预算的限制），或者说公司人力资源紧张，无法投入更多的人员。更何况加人也不一定能解决问题（这点《人月神话》中有较详细的论述）。

面对这种情况，也不意味着一切便没了办法。不识庐山真面目，只缘身在此山中。跳出项目本身，从其他方面想办法：

1. 将变更纳入下一期开发

一般交付类项目都不只一期，对于较大的变动可以引导客户讲变更部分放入下一期开发。

2. 与干系人沟通，获取发布底线

一般客户对于项目的交付预期往往与写在合同上的预期会有差异。经过多个项目的洗礼，客户对承包商的进度往往也心中有数。通过沟通获知他们心中实际的交付日期，往往可以减轻项目压力。

随着项目经验的增多也慢慢意识到干系人管理的重要性。其实很多项目，只要能做好对干系人的管理，项目实施起来会比较轻松。