项目经理作为项目的最核心人员，完成项目计划是最本质最重要的工作，是否能完成，是否有能力完成，编写的计划是否真正能指导项目的实施，对项目的成功非常重要。PMBOK中一共49项管理过程，其中计划相关有24项，足以说明计划的重要性和难度，编制计划涉及两方面，一是写什么，二是怎么写?
大部分项目经理关注最后一条，按照公司的要求，参考一些专业的知识，将各个子计划完成，拼接后形成项目的整体计划。
在计划编制前，首先要清晰公司给项目的目标是什么，目标不同，项目运转的方式和管理都会有所区别。比如目标是提升团队的业务能力和技术能力，与获取最高利润的目标是有区别的。一个仅仅是数据迁移的项目，提升项目的业务能力和技术能力的目标就非常的勉强，如果真定义了这样的目标，达成的可能性很小，项目经理应该和上级管理者沟通目标的合理性，而大部分项目经理对于计划书中的目标都是不关注的，直接使用模版或参考他项目的目标随意的定义，目标都不清晰，计划的意义基本失去了一半。
项目适合的体制是什么样，大部分项目经理也是相对不清晰的，公司或上级管理者提供什么样的人员，就使用什么样的人员开展工作，结果项目经理技术、业务、管理都全权负责和全情参与，在项目支撑不了时，临时增加人员帮助项目解决问题，项目团队很幸苦，结果效果不是很好。项目经理应该在计划时明确一些必须的核心角色及配置能力(同时清楚资源的退出时点，不是将所有的优质资源预留到项目结束是最优的)。另外，项目团队外的体制要明确，每个角色帮助/管控项目什么要清晰，可以帮助项目实施过程中的业务等方面的推进，客户的有效参与对项目有积极的意义。
工作分解大部分项目经理只分解了工程(WBS做的非常的漂亮)，对于管理工作基本不分解，认为管理工作项目经理承担即可，其他成员将所有的精力投入研发。但实际上，在研发过程中，多少成员被临时指派完成非研发工作，直接打乱研发节奏。
我看到的大部分项目的问题和风险项都非常类似，比如项目存在质量风险，我试图向项目经理沟通，什么叫质量风险，回答基本一致，“项目业务不熟悉、人员能力不足，所有项目存在质量风险”;解决措施也基本一致，“培训+制定标准”。质量风险太泛，是不是应该进一步分解，是代码的风险还是需求、设计文档的风险，如果是代码，那么影响代码的是业务还是代码本身，如果是代码本身是客户的要求“别致”还是团队成员不熟悉开发语言或者是没有代码标准，一级一级的分解，到了团队能理解和认可并可制定解决方案的程度，风险才是有价值的。
对于每个项目，组织能提供的资源一定是有限的(上级管理者还希望成本投入越少越好)，客户也希望越早上线越好，所有人都希望上线后没有BUG/质量问题，在这种情况下，项目是否能成功直接体现项目经理的价值。如果项目经理没有在项目研发启动前认真思考这三者之间的关系，如何平衡，对于项目的实施将造成重大影响。比如项目的前期应该投入一些能力较强的人/较好的资源，和客户约定什么样的问题在上线后是可以接受的，合理的上线方式(统一上线、分步上线)，利用什么样的研发模式更适合项目，这些内容和客户和上级达成一致，并记录到计划中。我看到的计划书基本没有这些内容，基本都是千篇一律的记录方式。
项目经理的第一能力应该是编制项目计划的能力，但大部分项目经理认为计划不重要，通常采用的方式，从质量或QA处索取一份项目计划书(或
使用自己原来的项目计划)，将项目名称修改、基本的业务介绍修改、工期修改、在做一份WBS及进度计划基本就完成，时间长短主要于进度计划的时间，一般2小时就完成一份计划。可想这份计划的价值，能为项目实施提供多少的指导。
计划是监控的依据，计划不落地，监控也是空中楼阁。能力提升从计划开始。作为项目经理，明确即将承担的责任，需要利用所有的资源、信息帮助梳理项目，将相关内容融入计划之中，至少确保项目团队认可和理解项目计划，从而理解项目，明确自己下一步的工作。