书中关于项目计划的论述，揭露了三个令人沮丧的事实：
- 在项目正式开展之前就进行的时间表预估，无论如何谨慎，无论事前如何频繁地修改，一旦项目开始，你会发现都是存在很大问题的。
- 随着项目的开展并不断接近预计完成时间，你会发现对于各个里程碑预计完成的时间估计越来越激进，即便是原来预计非常宽裕，需要三个星期才能完成的事项，最终完成可能只安排了3天，至于质量么……上帝知道。
- 对于时间原本就预估过紧的事项，在项目进展初始几乎没有人会真正认识到这一点，直到项目距离截止日期只有2-3星期的时候，才会有人如“恍然大悟”一般地发现：这件事情TM（这里你可以看成Trademark的缩写）怎么才给我留了这么一点点时间？
上述三个事实几乎会导致同一个结果——几乎所有的时间预计偏差都很难在项目正式开始之前被发现，当发现的时候，所剩下的选项只有要么牺牲质量，要么拖延进度。
《人月神话》中揭露的另一个事实是，当一线经理发现自己的队伍出现了计划偏离时，他肯定不会马上赶到老板那里去汇报这个令人沮丧的消息。一线经理的利益和老板的利益是内在冲突的。一线经理担心如果汇报了问题，老板会采取行动,这些行动会取代经理的作用，降低自己的威信，搞乱了其他计划。所以，只要项目经理认为自己可以独立解决问题，他就不会告诉老板。所有的事情都被隐藏在地毯之下。
地毯最终会被揭开，但没人知道会以什么样的方式被揭开。如果是一个拥有良好沟通文化的企业，应该是在定期的沟通会或者其他正式沟通渠道被揭开，如果是一些“一般”的，拥有“历史成色”的公司，这层地毯很有可能是“被迫”掀开的，掀开它的，可能是投诉、可能是市场、可能是互联网上内外部人士爆出的“大瓜”，当然也有可能是项目经理的“敌对势力”。
进程管理只是项目管理中的一个方面，还有比进程管理失控更加可怕的，那便是未能准确地获取客户的需求，导致项目运行方向犹如救经引足，南辕北辙。
收集客户需求看似简单，然而实际情况千变万化不一而足，某些用户仅仅偶尔使用程序，有些用户必须依赖程序，还有一些用户必须根据环境和目的的变动对程序进行修改。他们对于程序和项目的需求互不相同甚至彼此冲突，是否需要同等对待？
每个用户都需要一段对程序进行描述的文字。可是大多数文档只提供了很少的总结性内容，就像是描绘了树木，形容了树叶，但却没有一幅森林的图案。如何才能将零珠碎玉完整准确拼合，获取项目用户真正的意图，而不是管中窥豹，坐井观天。这就需要使用到有效的需求文档，囿于篇幅，这里不做详细展开，不过一个合格的需求文档，至少需要包括目的、环境、范围、实现功能和使用的算法、输入－输出格式、操作指令、选项、运行时间、精度和校验，最后需要包含验证的方式和程序。
需求明确后，方能明确实现的方式，建立整个项目的实现方式和流程，拥有验证方式和程序，才能够知道项目是否走在预期的轨道上，而这一切的基础，都是建立在拥有详实明确的需求文档之上，否则将有大量的时间浪费在和用户反复确认需求，从而延缓整个项目的进程。
