，所以每条说明都必须重复所有的基本要素，所以所有文字都要相互一致。这往往使手册读起来枯燥乏味，但是精确比生动更加重要。
3.2周例会
周例会由所有的结构师，加上硬件和软件实现人员代表和市场计划人员参与，由首席系统结构师主持。会议中，任何人可以提出问题和修改意见，但是建议书通常是以书面形式，在会议之前分发。新问题通常会被讨论一些时间。重点是创新，而不仅仅是结论。
该小组试图发现解决问题的新方法，然后少数解决方案会被传递给一个和几个结构师，详细地记录到书面的变更建议说明书中。接着会对详细的变更建议做出决策。这会经历几个反复过程，实现人员和用户会仔细地进行考虑，正面和负面的意见都会被很好地描述。如果达成了共识，非常好;如果没有，则由首席结构师来决定。这需要花费时间，最终所发布的结论是正式和果断的。这种会议的卓有成效是由于：
1）每周交流一次。因此，大家对项目相关的内容比较了解，不需要额外培训。
2）上述小组十分睿智和敏锐，深刻理解所面对的问题，每个人都要承担义务。
3）当问题出现时，在界线的内部和外部同时寻求解决方案。
4）正式的书面建议强制了决策的制订，避免了会议草稿纪要方式的不一致。
5）清晰地授予首席结构师决策的权力，避免了妥协和拖延。
3.3电话日志(交流日志，BBS等记录)
随着实现的推进，无论规格说明已经多么精确，还是会出现无数结构理解和解释方面的问题。显然有很多问题需要文字澄清和解释，还有一些仅仅是因为理解不当。讨论和解决，在BBS上做出记录。问题的答案(对问题的认识或者想法记录下来)必须是可以告知每个人的权威性结论。
3.4质量会议
项目经理最好的朋友就是他每天要面对的敌人——独立的产品测试机构/小组。该小组根据规格说明检查机器和程序，充当麻烦的代言人，查明每一个可能的缺陷和相互矛盾的地方。每个开发机构都需要这样一个独立的技术监督部门，来保证其公正性。
4.为变化组织架构
每个人被分派的工作必须是多样的、富有拓展性的工作，从技术角度而言，整个团队可以灵活地安排。当系统发生变化时，管理结构也需要进行调整。项目目标、进展、管理问题必须在人员整体中得到共享。管理人员和技术人才的能力给予培养，使管理人员和技术人才具有互换性。管理人员需要参与技术课程，高级技术人才需要进行管理培训。