在开发活动中，项目计划是项目启动后的头一件重大事件，但也是经常被忽略的一件事。
项目计划好比是一份项目的交通图，指导项目准确的达到目标，即使它没有被形成规范文档，它至少会在项目经理的脑子里，只不过比较粗糙和模糊罢了。
为什么每个项目都需要一份项目计划，并且要形成规范的文档呢？这是因为：
第一、通过制定计划，使得小组和有关管理人员，对项目有关事项，如资源配备、风险化解、人员安排、时间进度、内外接口等形成共识，形成事先约定，避免事后争吵不清；
第二、通过计划，可以使得一些支持性工作以及并行工作及时得到安排，避免因计划不周造成各子流程之间的相互牵掣。比如测试工具的研发，人员的培训都是需要及早计划和安排的。
第二、可以使项目实施人员明确自己的职责，便于自我管理和自我激励；
第三、计划可以有效的支持管理，作为项目经理、业务经理、qa经理、测试经理们对开发工作跟踪和检查的依据；
第四、做好事先计划，就可以使注意力专心于解决问题，而不用再去想下一步做什么？
第五、计划是项目总结的输入之一，项目总结其实就是把实际运行情况与项目计划不断比较以提炼经验教训的过程。通过计划和总结，项目过程中的经验和教训别很好的记录和升华，成为“组织财富”。
制定项目计划的过程被称为项目策划。在项目策划时，要尽量让员工估计自己的工期，使团队成员积极参与到项目中来，而且由于技术发展如此迅速，往往只有具体模块开发人员对那部分工作最了解；但是项目经理也不是完全消极的，他应该积累项目管理数据，推动开发过程能力成熟度的提高，以便可以协同开发人员进行越来越准确的项目估计。计划常以文本文档和图形文档结合的形式出现，文本主要记录项目的约束和限制、风险、资源、接口约定等方面的内容，对于进度和资源分解、职责分解、目标分解最好通过项目管理软件工具（如普遍应用的microsoft project）来进行规划和管理，不要分散在文档的若干个地方，那样非常不利于同步修改。项目计划需要设计成“可检查”的文件，这要求任务的划分要细到具体产品，如果存在有形产品的输出，要罗列出来。比如测试这一任务，不要简单分解为测试准备、测试执行，而是分解为测试环境搭建、测试方案编制、测试执行、测试报告编制为好。
使用microsoft project编制的文件可以称为计划进度表，可以用来规划项目时间进度，辅助项目跟踪。计划进度表的制定步骤是：工作分解和定义（wbs）、任务排序、活动历史估算、编制。
估算是计划活动的基础之一，有工作规模估算、工作量估算、成本估算等。估算要求有历史数据，要求在项目过程中通过不断的维护项目数据库积累历史数据。这些数据既可以分析和总结本项目，又可作为后续项目的历史数据。
在计划实施过程中需要注意的一点是，不能把计划“固定化”。“计划赶不上变化”，但“要跟上变化”。实际运作中，要对计划进行周期性维护。开发计划会受到很多影响，比如相关计划（质量保证计划、采购计划、测试计划、验收计划等）的影响，实际进度变动的影响、资源变动的影响、项目目标变动的影响、还有随着需求的逐渐明确引起的项目计划细化，如果在这些变化发生后，没有及时维护开发计划，开发计划于实际的偏离会越来越大，最后变得没有价值，人们就会不再阅读它。所以实际工作中要有具体的责任人和一套指导书来对计划实施指导和维护。计划变更时，要保留旧的版本，在总结阶段需要阅读旧版本的信息以对项目过程的变更历史作评价。总之：变化的计划才有生命力！
实际工作执行项目计划常常遇到各种困难。有的组织文化中有种观念认为计划是一种约束，反正大家努力往前赶就对了，没必要自己捆住手脚；另外一种情况是大家没有按照计划工作的习惯，计划虽然做好了，做的时候还是我行我素，管理人员也没有维护计划的习惯，项目开始没多久，计划就被完全撂了一边；还有一种情况是资源不能保障，比如，设备不能到位，人员也频繁被抽调从事计划外活动，每天改计划都来不及，只好放弃计划，这种情况常见于一些规模较小的还在“求生存阶段”的公司。
事实上，不仅是在项目计划这一问题上，在其它引入制度化的场合都遇到了类似的困惑。据说，美国家庭常会对做家庭清扫这样的事情列出一张“责任矩阵表”，按表的内容顺序进行扫除活动，完成一项作一个记号，这其实就是一种简单的项目管理，他们在如此自然的运用，对于中国人是不可想象的。但是制度化是商业社会的基石，迟早要渗透到社会生活的每一个缝隙。具体到项目管理中的计划活动，除了尽量把计划做的更具可行性以外，努力在组织内传播和培育制度化的组织文化将是项目经理们的一项长期责任，除此，别无选择。