同樣地，針對設計和測試工作采用什么樣的形式化和嚴格程度才是合適的呢？與項目管理有關的時間匯報、進展匯報、狀態會議及其他常見活動又如何呢——尤其針對那些僅持續一周或兩周的項目？這些問題總是相互關聯的，但是一些傳統上被接受的答案卻需要至少每隔幾年重新審視一下，因為成本-收益參數正在隨著商業環境、技術和軟件開發人員的變化而不斷變化。
輕方法還重新審視了歷史上有關投入資源在需求分析的假定，以及投入資源在過程改進的假定。1981年Barry Boehm在他的經典著作“軟件工程經濟學”（Software Engineering Economics）中指出了一項驚人發現，即如果我們在項目的系統分析階段引入一個缺陷的話，那么在項目的分析階段發現這個缺陷會比允許這個錯誤直至進入設計階段才被發現節省約10倍資源。但是Boehm在此做了一個在新千年的頭十年中未必依然正確的基本假定：僅當該缺陷在生命周期某階段發生時可通過某種方式加以鑒別，那么這種數量級增長關系圖才是相關的。在今天的環境中，這個前提假定在許多商業條件下都是不成立的。比如，當Bill Gates闡明對于瀏覽器IE的需求時，可能他會說“就象Netscape Navigator那樣，但要更好”，可能Netscape的Marc Andreesen也會這樣想：“我希望使Navigator就象Mosaic一樣，但要更好�！钡钱擳im Berners-Lee在構建WWW的初始版本和瀏覽器的第一個草樣時又該如何考慮呢？讓他寫出詳細需求的意義何在呢？
