书中借巴比伦塔项目的例子，讨论失败的原因是缺乏交流和组织，从而进度灾难、功能的不合理和系统缺陷纷纷出现，追其根本原因是团队成员之间的每个人的理解存在偏差，存在个人推测、群体猜忌等，因而团队之间应尽可能的相互讨论，无论是以正式的简要技术陈述的项目会议，共享的正式项目工作手册，还是非正式的小组讨论都可以让大家相互理解。同时人与人之间的交流和荣和也是相当花时间的，为了节约时间成本，组织结构要做好人力划分和限定职责范围的确定。在人力的划分上，也要注意权力和工作的划分，不允许双领导者的存在。
软件开发人员必须设立规模目标，控制规模，考虑减少规模的方法，在规模预算时，明确所占内存空间、程序对磁盘访问次数、指明每个模块的功能。在整个实现的过程需确保连贯的系统的完整性。编程需要技术的积累，每个项目需要自己的标准组件库。数据的表现形式时编程的根本，所以战略上的突破常常来自于对数据或表的重新表达。在对项目开发和管理时，要做好文档的撰写，例如目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配等。对每个关键文档的维护提供状态监督和预警机制，同时每个文档本身就可以作为检查列表或者数据库。开发策略上的一些正常变化无可避免，但是项目开发者应事先为一切推测可能发生的情况做好准备，但由于产品易于掌握的特性和不可见性,导致它的构造人员面临着永恒的需求变更，带来的困难是，程序员不愿为设计书写文档，为变更组件团队比为变更进行设计更加困难。程序维护包括修复设计缺陷、新增功能，或者是使用环境或者配置变换引起的调整，其维护成本随用户的增多，所发现的错误也越来越多。在“未雨绸缪”时，先尝试一块块地丢弃和重新设计系统，而不是一次性地完成替换。在构建框架系统时，采用增量开发模型更佳，逐渐精化，这样地设计策略可以使得模块的作用最大化。指定一套策略分配资源以及配置好专业工具是项目经理顺利开发出项目的重要保障。配置好自己需要的目标机器，尽量提高速度以及最大限度的内存，以及保证机器上的标准软件及时更新和实时可用。体系结构工作不但使产品更加易于使用，而且使开发更容易进行且bug更不容易产生。在编写任何代码之前，规格说明必须提交给外部测试小组，以详细得检查说明得完整性和明确性，开发人员无法自己完成这项工作。必须有人对变更和版本控制和文档化，团队成员应使用开发库的各种拷贝工作。