要達到「定期確認工作是否順利進行」這個管理目的，有些人會讓部屬做詳盡的統計數據、精美投影片來向自己報告。然而，製作這類型「報告」得花時間：它們並不是晚個10分鐘下班，順手就可以做完的事。如果一天工時8小時，做報告花1小時，那當天部屬就只剩7小時花在做「真正的」工作上。

然而，這類報告做得再好，它們都只是節省了主管花在「分析工作可否如期完成」，以及「掌控部屬的產出速度」的時間，而這類報告在「對外產出」的貢獻度其實是零，也就是做白工。所以，若要最大化團隊的對外產出，就得盡可能地幫助有對外產出的部屬節省「回報進度」的時間，讓進度報告的格式越簡單越好。

若團隊原先就有線上進度管理工具(例如: Jira, Trello, GitLab Issue Boards, Azure DevOps Boards, ...)，則不妨省去這類報告，直接用管理工具。只要確保我們能夠從工具上獲取足夠的原始資訊來從事「分析工作可否如期完成」，以及「掌控部屬的產出速度」兩項管理目的就夠了。這樣不但能省下部屬跟你說話(報告)的時間，而且只要你有空，隨時能進系統就能立刻得到你要的資訊。不必配合部屬有空的時間才去問進度，這實在是非常方便。因此，即使我們還得額外花些時間來整理，倘若從「最大化對外產出」的目的來看，我認為這些時間花的還是挺划算的。

此外，「進度報告的格式越簡單越好」也有助於部屬提高工作回報的頻率。如果做的夠好，部屬甚至願意做到「每天回報」。在時程很趕很急的專案上，若能每天都知道最新的工作進度，對於降低延期風險是非常有幫助的。

另外，還有個地方也可能會需要做進度報告，就是「系統維運狀況」。沒人敢保證自己做出的系統上線後，絕對不會有問題或不會被客訴。所以系統出的問題也是需要管理跟定期監控狀況，例如:故障行為，觸發情境，發生頻率，次數，目前解決進度，是否已找到基本原因...等等。而這類的報告也跟前述進度報告的管理精神類似：只要有線上管理系統(例如: BugZero, Bugzilla, Mantis, ...)，就盡可能地導入採用，讓部屬們多花點時間去前線解決問題吧!