在说方法之前，我先分享一个最近和跨部门合作过程中，碰到的一件为了不延期的奇葩事情。

这个骚操作真的刷新了我多年项目管理的认知，原来为了准时上线还可以这样......就很离谱。

还是说一下我总结的几个控制进度的方法吧。

这个看似很简单，每个项目都做的，但我发现大多有2个误区。

a 估算人员

有的项目估算周期的时候都是项目经理来估算。首先项目经理对一些细小的部分不可能很了解，所以他的估算和开发测试人员的估算肯定存在偏差，这也是为什么很多开发人员拿到周期后，大呼时间不够的原因。

另外就算项目经理对系统很熟悉，技术很精湛，那么做这个任务模块的开发人员和他是一个水平的吗？两个能力不在一个水平线的人估算出的时间肯定不一样。

所以从估算人员的角度来说，谁来做这个任务，就由谁来做事先的估算。

b 估算方法

很多时间估算都是拍脑袋，到真正做的时候发现有两个地方没想到：这个没想到和那个没想到。

做估算也是要讲究流程的。我要求开发和测试在估算的时候必须有清单，要在调查修正范围的基础上，最终给出一个比较合理的周期。

一说到这个，估计很多项目经理都要摇头了，需求变更真的是个老大难问题。

那么我说一下我对需求变更的应对（这里特别注明只是我的方法，每个项目经理或者每个项目有不同的解决方案，不用杠）。

只要是项目就有相关方，那么我就会把这些人都绑到我的项目上，我拿什么去震慑他们呢？

老板。

为什么以前有那么多相关方想添加或者改需求？因为他们一直认为这个项目负责人就是项目经理，他们出个嘴就可以了，他们只用管提需求，工期什么的他们根本不关心。

但我的工作就是给他们洗脑，有时候带有一点胁迫。

看似很简单的一个动作，但相关方就会掂量一下。如果我发邮件了，老板看到了就会想当初这个需求为什么没想到？项目都快结束了再提？

虽然有概率老板批准继续做，但提的多了，老板心里会舒服吗？所以很多以前他们张嘴就来的需求，现在都要掂量一下，这样需求变更自然就少了。

这个又是看似每个项目必做的一个任务。但我还是发现其中两个问题，项目经理在追踪项目进度的时候，只是简单地问一下做了百分之几了，有的时候开发就会按照自己的评估给出一个数字。

有时候数字是50%，但这个数字和项目经理的数字的意义可能并不一样，项目经理心中的50%和开发人员估算的50%可能有较大的偏差。

还有一个问题，哪怕到最后开发人员说完成了，但这个最后的输出真的是符合需求的吗？也不一定吧。

所以针对一些时间耗时比较久的任务，都需要设定一个里程碑，邀请相关方进行统一评估，即使出现问题也可以做及时的调整。

所以从项目角度来说，看到的一般都比听到的更真实一些。

上面其实只是一些避免项目延期的小技巧，每个项目情况都不一样，只能说供大家参考。




优培东方送你一张配置管理计划表：
项目名称：                        准备日期：                     
配置管理方法：

配置管理角色和责任：

附上与配置控制过程相关的所有表格。