谈到项目计划，不得不从计划编制的依据说起。以我自己的理解来看，项目计划诞生的简要流程应该是：

根据RFQ/RFP编制整体的项目规划，在项目规划中对于项目做出明确的定义。项目的定义包括：目标、范围描述、进度要求、项目阶段定义、关键任务及里程碑等。
参照项目规划中的进度要求，对项目的整体目标及关键任务进行工作分解，生成WBS。
依据WBS编制项目整体计划，在计划中加入人力资源、工具、设备等信息。当然，还需要定义项目日历，资源费率等相关数据。
从整体计划中派生滚动计划，滚动计划可以根据经验和实际要求定义为W/W+n的周计划。W相对固定，W+n根据W的执行情况适当调整。
接下来就是计划的执行了，如果一切顺利，你会实施一个成功的项目。

可是，事实是这样吗？！有缘看到这些文字的朋友们，你们是在Enjoy这样的一个过程吗？不幸的是我看到的很多项目并不如此。。。。

不知下面的场景大家是不是有所经历，

Sales为了拿下单子，不切实际的答应客户的“无理”要求，包括范围、交付期等。负责实施的PM在接收项目后，发现目标根本不能在期限内达成，甚至无法达成。PM以及项目团队中的其他成员开始埋怨Sales没有事先与他们进行充分的沟通。虽然在项目前期，PM或其他负责项目交付的人员，可能有机会与客户进行沟通，但如大家所知，他们和客户的意见在大多数情况下不是能够达到完全一致的。差异总会存在，或多或少。当客户坚持的情况下，决策的天平会倾向哪边呢？最后，PM被迫接受错误的决定，去实现客户的“梦”。一旦项目开工，项目经理只有强忍着心中的酸痛，做着自己都不相信的项目计划，去迎接更猛烈的暴风雨。。。

在这种情况下，项目经理如果不能通过有效沟通说服客户和老板，切合实际的编制项目计划并付诸实施，项目前景堪忧。。。

Tip:把问题说出来，并设法解决。早期的时候，你可能会很痛苦，可是如果把问题捂到后期，项目会死，你也会死，而且你死的比项目更难看。

写完上面的片段，发散地想到项目计划编制中项目经理自身的问题。一个简单的例子，很多项目经理都会用MS Project来编制项目计划，却不肯花时间多学一些项目管理的方法论和软件使用的知识。把Project当Excel来用，只简单的编制任务列表和进度计划，不定义里程碑，不定义前置任务，不创建基准计划。真不知道他们如何利用工具对项目做到有效的跟踪和控制。下面是一个令人发指的Grant图，供大家参考。。

最后，把自己对于计划编制的一些理解分享给朋友们，希望有所帮助。

以目标为导向，认真进行工作分解；
计划是为了实施服务的，不要为了计划做计划；
充分沟通，编制切实可行的计划；
注意对于计划的跟踪和调整，创建基准是必要的。
注意积累经验，计划的编制离不了经验

此主题相关图片如下：

感谢楼主的分享。

一个良好的计划的编制确实离不开经验的积累，而且计划是需要不断检查和调整的，需要在计划执行的过程汇总各方面的情况，及时沟通并不断做出调整。

------------------------------------

对于老钟提到的几点计划建议，强烈举手同意。我的老板以前总认为做计划根本就不算工作，上午开完会，就让我中午把计划做一下，下午讨论。很多和我一起的PM们都屈服了，交的计划还不如上面的贴图呢。我经过痛苦的搏斗，现在终于不用做这种无聊的事情了，至少能够按照稍微更客观一点的原则编制可用性更强的计划了。但是，至于目标和sales承诺之间的冲突，唉……