对于工作量和工作时间的估算，对于所有的设计者来说都是一个难题。因此我们也在思考一个问题，对于产品的设计，第一次可能因为经验不足出现各类问题和各种错误，第二次会不会比第一次好一些。毕竟我们默认一个人在某个领域的深耕会获得大量的经验，从而有助于他将工作做好。然而《人月神话》的结论却兜头给我们浇了一盆冷水。作者认为第二个系统恰恰是最危险的一个系统。因为在开发第一个系统过程当中，存在很多设计者初衷认为必须的或者说能够增光添彩的摄像，由于时间人力等等的限制，都没有能够实现。而人的执念往往会要求他在第2个系统当中来弥补第1个系统当中的遗憾。可惜的是时过境迁，新系统的应用和目的相较旧的系统本就不同，执着于旧系统当中未实现或者未尽实现的功能，对新系统来说未必是件好事，甚至可能引发灾难。作者还列举了“OS/360”以及“Windows NT”的例子来详细说明了这种执念会造成怎样可怕的后果。其实类似的案例又何尝只在编程界存在呢？近些年有一句非常流行的话，叫做“原生家庭的创伤，终其一生都在治愈”。而在项目管理当中，有些人便是“这一次的遗憾，一定要在下一次就得到弥补”，对于此前项目中的一些缺憾，在新的项目中，无论是否实质性有效都必须强行实施，从而造成项目管理的悲剧。而对于这一执念的“解药”，作者认为应该是对于所有功能和摄像“赋权”，即在项目的初始阶段，就确认各项功能实现所耗费的资源、人力和时间，一旦确定，不会由于某些微不足道的变故而轻易变更。从而可以避免在无关紧要的功能上浪费资源。
但凡在稍具规模的公司工作过的人都有这样的“痛苦回忆”——明明在项目的开始阶段一切都计划的好好的，各部门也都信誓旦旦地要做出一番成就，为什么到后期就如同建造 “巴别塔”一般，初心尽失、不思进取、彼此积怨，即便不至于拆墙挖脚、自毁长城，也是算计无数，各自为政。诸事所涉，就要说到一个老生常谈的问题——组织内部“沟通”。
关于“沟通”这一话题，其深度广度如同浩瀚之海，各类分析文章犹如恒河之沙，这里也不再拾人牙慧老生常谈。请从两个维度来谈一谈《人月神话》中有关沟通同的陈述以及实现的手段——一是项目理念的贯彻、二是项目进展的交流。
所谓项目理念，包括项目的整体思路、设计架构、执行策略等。在《人月神话》中，将这些理念纵向贯彻，从项目组的顶层一直落实到底层，是通过“手册”这一工具来实现。手册、或者书面规格说明，是一个非常必要的工具，它是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。而要使手册做到对于理念的准确传达，则需要使用“形式化”（概念精确、描述完整、区分显著）而非“记叙性”的语言对其进行描述。手册的存在，明确了整个项目的最终呈现状态，确保整个团队在统一的目标下前进。否则就如同“天鹅拉车”一般，整个项目中各部分互相掣肘，导致项目难以存进。
而对于项目的“横向”管理（项目-时间），书中提供了另外一个工具——“会议”。书中将“会议”分成两个级别：周例会和年度大会——这实际上是一种非常有效的分层沟通方式。周例会的目的是各部分的提问和建议，最终由首席结构师拍板定夺。要实现周例会的高效，有几点必须加以贯彻执行，一是所有的建议和观点都必须形成书面意见，在会前就让所有与会者知晓，避免在会上“临时加戏”，争论不休。二是讨论必须充分平等，所有参与者都有权充分发表自身看法，以免因为言犹未竟，影响今后会议决议的实施。三是一旦会议达成一致（无论是讨论一致还是首席结构师决定），都必须在会后按照这一决定执行，不得再生事端。如此的周会制度，项目组的主要成员每周聚首一次，可以保证信息的充分沟通，避免重新培训所耗费的时间。还保证相关意见都被及时提出并讨论，同时在第一时间之内达成一致意见并加以贯彻执行。清晰地授予首席结构师决策的权力，也从根本上避免了妥协和拖延。而当周例会无法解决的问题堆积或者这些问题需要更广泛的内外部人员参与时，年度大会也便应运而生。年度大会往往历时数天甚至一至两周，参与的人员除了项目组成员以外，还有更多相关的内外部人士。所有在大会上需要讨论的问题都会在会前装订成册，而每天都会有人汇总当天讨论出的成果，并体现在次日更新的手册当中。如此集中高效汇聚和讨论就是为了彻底解决在项目当中那些难啃的“硬骨头”以及超广泛的跨部门协作而设。