同样地，针对设计和测试工作采用什么样的形式化和严格程度才是合适的呢？与项目管理有关的时间汇报、进展汇报、状态会议及其他常见活动又如何呢——尤其针对那些仅持续一周或两周的项目？这些问题总是相互关联的，但是一些传统上被接受的答案却需要至少每隔几年重新审视一下，因为成本-收益参数正在随着商业环境、技术和软件开发人员的变化而不断变化。
轻方法还重新审视了历史上有关投入资源在需求分析的假定，以及投入资源在过程改进的假定。1981年Barry Boehm在他的经典著作“软件工程经济学”（Software Engineering Economics）中指出了一项惊人发现，即如果我们在项目的系统分析阶段引入一个缺陷的话，那么在项目的分析阶段发现这个缺陷会比允许这个错误直至进入设计阶段才被发现节省约10倍资源。但是Boehm在此做了一个在新千年的头十年中未必依然正确的基本假定：仅当该缺陷在生命周期某阶段发生时可通过某种方式加以鉴别，那么这种数量级增长关系图才是相关的。在今天的环境中，这个前提假定在许多商业条件下都是不成立的。比如，当Bill Gates阐明对于浏览器IE的需求时，可能他会说“就象Netscape Navigator那样，但要更好”，可能Netscape的Marc Andreesen也会这样想：“我希望使Navigator就象Mosaic一样，但要更好。”但是当Tim Berners-Lee在构建WWW的初始版本和浏览器的第一个草样时又该如何考虑呢？让他写出详细需求的意义何在呢？
