首先，數據不準確。例如在日報中，一般要求提交任務(wù)完成百分比。這個(gè)數字很多時(shí)候是團隊成員拍腦袋想出來(lái)的。任務(wù)完成90%后，剩下的10%需要更多的時(shí)間完成的情況在很多團隊中也屢見(jiàn)不鮮。 　　
其次，數據不及時(shí)。除了項目文件，經(jīng)理們沒(méi)有辦法了解項目的具體運行狀況，進(jìn)度，只有通過(guò)日報或者周報。任務(wù)分配也不及時(shí)，團隊內部工作量也不均衡。 　　
再次，衡量標準不恰當。用代碼量作為衡量Dev生產(chǎn)率的標準本來(lái)就是不恰當的。這使團隊成員單純追求代碼量而不停的復制拷貝，不關(guān)心優(yōu)異系統架構所要求的代碼簡(jiǎn)潔，架構清晰。 　　
用缺陷作為衡量Dev工作效率的標準也是不恰當的。軟件開(kāi)發(fā)并不僅僅是編寫(xiě)代碼，更重要的是溝通問(wèn)題。絕大多數缺陷其實(shí)是由需求不明確或者是溝通的不充分和不準確導致的。用缺陷率作為標準會(huì )導致團員成員之間的矛盾，互相指責，推卸責任。 　　
另外，信息不透明，不直觀(guān)。報告往往不是團隊成員直接可見(jiàn)的，需要登錄到網(wǎng)站，或者訪(fǎng)問(wèn)Source Control或者共享文件夾的某個(gè)文件(往往是有權限控制的)。這些信息不會(huì )直接展示給大家，他們總是需要一路點(diǎn)擊過(guò)去。 　　
結尾，過(guò)多的無(wú)效工作。團隊成員要花費很多時(shí)間和精力在更新及維護報告上面，但這些工作并沒(méi)有業(yè)務(wù)價(jià)值。 　　
在處理復雜像軟件開(kāi)發(fā)這類(lèi)復雜問(wèn)題的時(shí)候，使用Command&Control方式效率十分低下。很多情況下即使是更有經(jīng)驗的經(jīng)理，由于他不在現場(chǎng)，不掌握全部具體情況，也很難做出準確的判斷，有效地指揮團隊成員工作。 　　
而第二種管理方式(Self-organizing)在解決復雜問(wèn)題時(shí)就要有效得多。 　　
在復雜的環(huán)境中，可以通過(guò)訓練及培訓使團隊成員掌握工作的基本原則，把責任下放給第一線(xiàn)的工作人員，由他們根據不斷變化的實(shí)際情況，不斷地調整，完成團隊任務(wù)。