The Simple Rule of Project Status Updates

During one of my recent project retrospectives I discovered how the quality of project status updates relates to the health of a project. Specifically, the idea is that a project's health — and thus its value to the organization — is directly proportional to how easy it is to get and understand status updates about that project.

A project's health — and thus its value to the organization — is directly proportional to how easy it is to get and understand status updates about that project.

It's important to note that I said nothing of the content of the status updates: only about how hard it is to get and understand feedback.

For example, I'd rather hear my project lead say "Our experiment failed and we're moving on to something else," rather than "Well, it's complicated. See, the database migrations needed a dependency deployed, and…".

A few corollaries arise from this observation:

  • When I'm given bad news in a clear way I can kill the project and avoid the sunk cost fallacy. This reduces our direct cost and opportunity cost.

  • The quality of the status updates is also a function of:

    • The project leader's communication skills (you always want superb communicators running your most valuable projects)
    • The culture and quantity of psychological safety to which your team has access (lack of psychological safety staunches early access to bad feedback)

This simple rule is now something I keep in mind when assessing the project updates from my colleagues. I'm curious to see if anyone else sees something similar. Please reach out and let me know.