Every time we put a label on a concept, and idea, or a system with the best of intentions to describe it and that system or idea becomes popular, that label (and by extension the system itself) gets corrupted into a mockery of itself.
Without fail.
Every. 馃憦 Single. 馃憦 Time.
I wrote this originally a few years ago for teams whose members were new to each other; these suggestions acted as a guide to understanding my perspectives. I know that everyone has different points of view on how to run a project. By making myself the locus of attention, the idea was that the team could debate with me about the details and we could come to a consensus that worked for everyone.
Preamble aside, let's read on!
I鈥檝e written this document because, over the past few years, I have encountered one too many situations with developers not living up to their own expectations.
As a developer myself with a couple of decades of experience under my belt, I鈥檝e seen a lot of examples of how code can go wrong and how painful it can be to fix them when the PM comes along with a new feature request or important bug fix. As a project manager I鈥檝e had to deal with the consequences of those poor coding decisions, spending an inordinate amount of time and social and political capital trying to smooth things over when a client gets upset because we went over time and budget.
"Over-communication" is not a thing because things change and there is always a reason to communicate.
What people often get bogged down in is what to communicate and when, for fear of inducing communication fatigue (assuming they have an honest intent to actually communicate).
The key word is communicating.
Remember, if someone tells you that the chances of something happening are "next to nil" or "almost impossible" or even "highly unlikely," then the chances are still non-zero.
Next to nil isn't zero.
This axiom is clue that something is at risk and you should pay attention to it. It's not statistics that we should worry about it. It's our assumptions.