项目计划的生命周期
所有的计划都有其生命周期。一般来说，计划存在制定期（撰写完成计划）、执行期（执行计划，产生问题）、修订期（分析问题，修订计划，进行审核）三个阶段，如此往复，不断轮回。
根据项目管理者的经验和项目执行状况，这个生命周期的长短也各不相同，可能是一、两个星期，也可能是一、两个月，或者只是一、两天。
所以，所有的计划，尤其是大的计划，都是要在即将结束的时候才有可能出现一个完全可以执行到结尾的状态，否则，变化始终是计划的唯一特性。
那么，一个项目计划到底应该包括哪些内容呢？
1. 计划的内容
项目计划一般来说应该包括如下内容：
(1)人员安排
项目组中有多少人，每一个人有什么特点、专长和职责分配的内容。
(2)任务安排
大体上各个阶段的任务由哪些人来参与完成，需要什么样的资源配置。
(3)资源分配
每个阶段可以从公司或者投资方获得哪些可用资源，这些资源的数量和持续时间等特性都需要描述清楚。比如，公司会在什么时候发奖金作为激励，奖金的数量和获得的前提条件是什么？再比如，什么时候可能需要安排加班突击进度，那么是否要给大家安排食宿并解决一些生活上的问题。另外，公司可以提供什么样的计算机配置，以及其他设备资源配置以便大家使用，这些资源的持续时间是多久，是否会因为其他项目组的使用而发生冲突等等。
关于这三个方面的内容到底如何使用，如何表述，就属于计划制定的范畴。
2. 计划制定
一个完整的项目计划在制定之初只能绘制出大的阶段划分情况，因为有可能不同的阶段，人员、资源都会发生变化，任务也可能因为用户方的变更或者前期分析不到位而产生变化，所以绝对不要奢望已开始制定的项目计划就细化到天，只要能粗略的根据进度和要求做一下大体合理的划分就可以。
计划每次制定如下节示例即可，剩下的时间就是根据项目的进展情况不断地丰富和细化，将它丰满起来，完善起来。
除了甘特图以外，还需要有一份文档说明。文档内容可以很简单，只需要包括上面计划内容的三个方面即可。
3. 计划审核与修改
计划的审核过程可以这样执行（以一个产品计划为例）：
从上图可以看到第二代产品开发的计划是比较细致的（因为第一代产品已经开发完成），执行到具体的阶段才会细化出来，到第三代和第四代产品就没有细化，只是一个大的阶段展示。
甘特图如下所示：
4. 计划执行
计划的执行就不必多言，按照计划的内容，把任务分配给具体的执行人即可。
执行过程中对于小的任务只需要考虑结束前的审核即可，较大的任务一定要考虑分阶段进行审核，至少是与任务承担者进行沟通，确定任务执行过程个中的有效性，及时发现项目风险，并尽早进行处理。
这里可以列举笔者在中国电信集团商务处的审核方式作例子：
在那里，一个已经熟练的工作人员——业务主办或者更高级别的人员，平均每个时刻手头都有四到五个项目在进行中，领导会根据每个人的特点和专业方向把具体项目分配到每个人头上，每周五都要向处长进行面对面的工作汇报，处长会把你叫到他的桌子前询问这一周你手中项目的进展情况，周三有可能随机由副处长询问一些进展情况，其它时间都是自己做自己的事情，没有人管你，除非发生大的有争议的事情，比如厂商投诉到处长这里，处长才会根据情况进行判断，并当面询问。事实上有些情况领导直接就会回复：这件事情由某某项目经理负责，你们找他就可以，不用找我。
该案例涉及到一个项目进展过程中的审核和放权问题。如果管理者管理过死，事事过问，那么开发者就不可能放手来施展自己的能力解决问题。但是，承担者是否有足够的能力来解决这个任务的全部问题，就要看管理者如何管理和衡量，如何判断和审核。
5. 计划变更
计划的变更一定要有一个具体的变更流程，并且每一次变更都要经过评审和修订。修订的时候应该在修订说明中写明是因为什么原因产生的变更，并经了哪些人参加的评审确定下来；评审修订后，每一个参加评审的人必须对修订结果进行确认，将来一旦发生问题，这些人也应该为这次评审的失误（假设这个问题是因为这次评审的结果造成的）而承担相应的责任。如果没有发生任何问题，评审的结果使得项目更好地进展下去，那么项目收益也应该考虑到参与评审的人员，具体模式请参考《用绩效模型对IT技术人员进行有效管理》。
6. 计划终结
当一个项目进行到最后，我们应该完成如下的工作内容：
(1)对项目中发生的变更、风险、评审和修订等信息进行统计，同时对这些数据根据解决情况和发生原因等进行归类总结，以便于后续项目在同样的阶段进行参考以避免发生一些可以避免的同类问题的再次出现。
(2)对项目计划进行最终的修订，补充项目的完成时间和最终评审情况。
(3)对项目进行全过程中所有参与人员的绩效进行审核和计算，获得每一个贡献者的绩效贡献数值，以便于在项目将来获得收益时候采取有效的分配方式，避免因为分配不公平出现公司赚钱员工反而大量辞职团队反而消失的现象。
