在《人月神话》中，作者对于这种尚未思虑周全就盲目上马或者只顾及自我团队表现而不考虑项目整体效益的行为嗤之以鼻“在系统设计中，概念完整性应该是最重要的考虑因素。也就是说为了反映一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统，哪怕它们其实包含着许多很好的设计。”也就是说在作者看来，任何一个项目都不应该被看作独立的个体，而应该考虑对于整个大环境的兼容性和整合性。你之所以开发新的系统，并不是为了证明你有多卓越，而是为了整个大环境的需求考虑。
正如在上一篇当中所提到的，要考虑到新系统、新项目相对于此前整体环境和进展的兼容性和整合性，这必然不能采用人多嘴杂式的民主表决，概念的完整性要求项目的整体的架构和思路必须由一个专家或者非常少数互有默契的人员来设计和提出。一旦设计实现人员有了模糊设想，对技术有了相对清晰的构思以及拥有了定义良好的成本和目标时，工作就可以开始了。当然工作的开始并不意味着设计人员的职责已经完成，他还需要尽快地确认良好定义的时间和空间目标、设计指责模块的边界、结构以及所有的工具，此外还需要耗费时间和结构师、副手等等进行沟通。随后通过副手、结构师、编辑等人员的共同努力，将这一思路和架构传达到每一个具体的执行人员来执行实现。诚然在实现的过程当中，执行人员的及时反馈是非常重要的，它有助于设计人员及时根据反馈对于设计思路进行必要的调整，但这并不意味着设计人员可以在一开始并没有思路的情况下瞎马临池，而将实现产品功能的重担全部压在执行人员身上，还美其名曰根据现实状况“随机应变”。
在开发第一个系统过程当中，存在很多设计者初衷认为必须的或者说能够增光添彩的摄像，由于时间人力等等的限制，都没有能够实现。而人的执念往往会要求他在第2个系统当中来弥补第1个系统当中的遗憾。可惜的是时过境迁，新系统的应用和目的相较旧的系统本就不同，执着于旧系统当中未实现或者未尽实现的功能，对新系统来说未必是件好事，甚至可能引发灾难。作者还列举了“OS/360”以及“Windows NT”的例子来详细说明了这种执念会造成怎样可怕的后果。其实类似的案例又何尝只在编程界存在呢？近些年有一句非常流行的话，叫做“原生家庭的创伤，终其一生都在治愈”。而在项目管理当中，有些人便是“这一次的遗憾，一定要在下一次就得到弥补”，对于此前项目中的一些缺憾，在新的项目中，无论是否实质性有效都必须强行实施，从而造成项目管理的悲剧。而对于这一执念的“解药”，作者认为应该是对于所有功能和摄像“赋权”，即在项目的初始阶段，就确认各项功能实现所耗费的资源、人力和时间，一旦确定，不会由于某些微不足道的变故而轻易变更。从而可以避免在无关紧要的功能上浪费资源。
所谓项目理念，包括项目的整体思路、设计架构、执行策略等。在《人月神话》中，将这些理念纵向贯彻，从项目组的顶层一直落实到底层，是通过“手册”这一工具来实现。手册、或者书面规格说明，是一个非常必要的工具，它是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。而要使手册做到对于理念的准确传达，则需要使用“形式化”（概念精确、描述完整、区分显著）而非“记叙性”的语言对其进行描述。手册的存在，明确了整个项目的最终呈现状态，确保整个团队在统一的目标下前进。否则就如同“天鹅拉车”一般，整个项目中各部分互相掣肘，导致项目难以存进。
