项目计划的生成并不复杂。确定项目的工作范围，制定工作分解结构，估计产品元素的规模，分配资源，安排进度——一个简单的项目计划就出来了。
这个计划完全符合GJB 5000A/CMMI项目策划“建立项目估计值”和“制定预算和进度表”的要求，可是，这样的计划在现实中经常会被拆得七零八落，千疮百孔。下面的场景是否似曾相识：
●场景1：由于某外包部件交付质量不过关，产品集成无法进行，外卖试验时间不得不推迟。
●场景2：某软件的测试所需的硬件设备不能及时提供，软件验证不充分，系统联试过程中问题不断，出厂/出所时间不得不推迟。
为什么一个看起来符合标准要求的计划实际表现却如此不堪？是产品WBS分解不准确？是产品规模估计偏差太大？还是资源投入不够？都不是。
上述这些因素都不会给项目计划的执行带来太大的困扰。由这些因素引发的问题即使发生了，也都能及时修正，对项目计划的影响很小。真正有重大影响的因素是承诺，包括外部承诺和内部承诺。这些承诺不能履行所造成的影响往往不是一天两天的事儿。特别是多个承诺不履行，累加起来的效果更是惊人。
这里所说的承诺，是指那些直接或间接影响软件开发进程环节的直接责任人承诺在预期的计划节点提交满足质量要求的产品或参加必要的活动。承诺可分为内部承诺和外部承诺。其中内部承诺包括下列内容但不仅限于此：
●需求承诺。需求分析人员承诺提供一个准确、完备的软件需求给设计人员。
●设计承诺。设计人员承诺提供一个稳健的体系架构，覆盖所有需求，满足6大设计原则的设计说明给编码人员。
●编码承诺。编码人员承诺提供一个满足设计要求，符合编码规范，内在质量高的源代码给测试人员。
●测试承诺。测试人员承诺提供符合测试规范的测试活动，经过测试的软件产品无遗留重大缺陷，软件外部质量高。
●QA承诺。QA人员承诺按照相关标准和规范，独立确认软件产品和过程对标准/规范的符合性。
●配管承诺。配置管理人员承诺严格按照配置管理规程管控软件产品，软件版本受控。
●项目投入承诺。项目团队成员承诺按照本项目计划的进度安排，投入足够的时间和精力，保证本项目任务的完成。
外部承诺包括下列内容但不仅限于此：
用户方承诺。需求方承诺提供明确、完备的需求，确认开发人员对需求的理解与自己一致。
系统方承诺。系统方承诺按计划参加需求确认、验收以及闭项评审，并履行相应的职责。
组织外承诺。当系统存在分承制方，要与分承制方就提供接口协议、接口匹配等做出承诺协议。
硬件承诺。硬件设计师承诺按计划提供功能完好的硬件进行软硬件调试、联试和集成。
第三方测评承诺。第三方测评机构承诺按计划完成第三方测评活动。
如何确保这些承诺能够得到切实的履行呢？
首先要按照软件开发流程梳理出影响开发进程的承诺事项，并及时与各承诺人进行沟通和协商。协商的时机包括：
●制定进度计划过程中。制定进度计划时，不能仅考虑项目的工作范围，通过产品WBS分解和规模估计，结合本部门的资源做出计划，一定要与各承诺方进行沟通，与其对进度达成一致。
●承诺日期到达前。当进度计划进行到需要承诺方履行承诺的日期前至少1周时，就应与承诺方沟通，了解其履行承诺是否存在障碍，能否帮助其解决，以及考虑是否需要调整进度计划。
●承诺未能达成后。如果承诺方因为某种原因未能达成承诺，要及时与其协商，看是否需要重新进行承诺事项，或者采取某种替代的方式。
其次，就是要把所有的内部承诺、外部承诺文档化。文档化的内容包括承诺人、承诺完成日期、承诺事项（提供产品或参加活动）、承诺达成的前提条件、承诺履行遇到问题的反馈机制等。这些文档化的承诺应当纳入配置管理。
最后，终极大招就是由组织的高层领导对承诺进行评审。高层领导的重视会使承诺的完成率大大提升。
补充说明一下，前面所说的——完全符合GJB 5000A/CMMI项目策划“建立项目估计值”和“制定预算和进度表”的要求的计划，在实际表现中很差——并不是标准要求的问题，而是只完成了标准的前2个专用目标，没有切实做好第3个专用目标：获得对计划的承诺。
（本资讯于2016-08-19首次发布）
