在很多软件项目开发团队中，项目经理和部门经理负责项目管理和控制。为了控制软件开发的进度，效率和风险，经理们往往要求团队成员提交和更新各种各样的表格，例如日报、周报、代码量报告、缺陷报告等等，通过各种计划、报告、表格来管理团队。但是这种方法有很多固有的弊病。
首先，数据不准确。例如在日报中，一般要求提交任务完成百分比。这个数字很多时候是团队成员拍脑袋想出来的。任务完成90%后，剩下的10%需要更多的时间完成的情况在很多团队中也屡见不鲜。
其次，数据不及时。除了项目文件，经理们没有办法了解项目的具体运行状况，进度，只有通过日报或者周报。任务分配也不及时，团队内部工作量也不均衡。
再次，衡量标准不恰当。用代码量作为衡量Dev生产率的标准本来就是不恰当的。这使团队成员单纯追求代码量而不停的复制拷贝，不关心优秀系统架构所要求的代码简洁，架构清晰。
用缺陷作为衡量Dev工作效率的标准也是不恰当的。软件开发并不仅仅是编写代码，更重要的是沟通问题。绝大多数缺陷其实是由需求不明确或者是沟通的不充分和不准确导致的。用缺陷率作为标准会导致团员成员之间的矛盾，互相指责，推卸责任。
另外，信息不透明，不直观。报告往往不是团队成员直接可见的，需要登录到网站，或者访问Source Control或者共享文件夹的某个文件(往往是有权限控制的)。这些信息不会直接展示给大家，他们总是需要一路点击过去。
最后，过多的无效工作。团队成员要花费很多时间和精力在更新及维护报告上面，但这些工作并没有业务价值。
在处理复杂像软件开发这类复杂问题的时候，使用Command&Control方式效率十分低下。很多情况下即使是最有经验的经理，由于他不在现场，不掌握全部具体情况，也很难做出准确的判断，有效地指挥团队成员工作。
而第二种管理方式(Self-organizing)在解决复杂问题时就要有效得多。
在复杂的环境中，可以通过训练及培训使团队成员掌握工作的基本原则，把责任下放给第一线的工作人员，由他们根据不断变化的实际情况，不断地调整，完成团队任务。