For a software development project, when is the best time to communicate to stakeholders bad news like having insufficient budget or schedule? From the behaviors I have observed of some managers and leads, their answer would seem to be "never" - upon learning bad news they hope things will turn out in the end and never voluntarily communicate such news to avoid looking bad themselves. Unfortunately, denial and blind hope are not valid management practices and do not make the issues go away. In fact, I feel that this often makes the situation worse. Instead I believe that the best practice to follow is to communicate bad news early.
Early communication has many benefits:
- It demonstrates transparency with stakeholders, which helps build trust. As Stephen M.R. Covey writes in the book The SPEED of Trust: The One Thing That Changes Everything, trust helps break down barriers that slow down business. In contrast, imagine stakeholders eventually finding out the bad news, and then learning that you knew for a while but kept it a secret. This can instantaneously destroy trust.
- The earlier people learn of an issue, the more time is available to deal with it. This is especially true for project management issues like insufficient budget or schedule. The options for dealing with this become extremely limited if you only find out when the budget is completely gone or the milestone date comes and passes unmet. Finding out early provides many more strategies for dealing with this.
- Awareness precedes action. Management attention and organizational resources can only be focused on resolving the issue only after it has been communicated.
- When you initiate the communication, you have an easier time controlling the message that goes out, which in turn usually leads to better outcomes. Letting bad news 'escape' on its own usually ends up being much less pleasant.
One potential drawback of communicating bad news early is that management attention can end up consuming your time, for example by having to explain over and over again what the issue is, why it happened, and what options there are for dealing with it. Even without a culture of shooting the messenger, this can demotivate people from raising bad news in the future.
I had the opportunity to communicate bad news early on a recent enterprise development project. The project was funded based on an initial high-level estimate of high-level requirements. After these requirements were decomposed into a prioritized backlog of stories and the first iteration was developed, I calculated the effort required to implement the minimum viable product based on the team's velocity. Unfortunately the numbers weren't good: a budget shortfall was predicted. So I promptly communicated this news to the product owner, project sponsors, and my management along with an action plan for addressing the issue. I did suffer the drawback I mentioned above: many of the managers were surprised at the bad news, and everyone wanted to meet with me to discuss the issue. Apart from that, the outcome was positive: scope was reduced from the minimum viable product (it turned out to be not-quite-minimum originally), the team was kept lean, and additional funding was pursued, leading to the budget going back to green. Some of these actions would have been much less effective if pursued later in development.
The practice of communicating bad news early applies to every level of the organization. Individual developers communicating obstacles or impediments to their team at the daily Scrum is an example at the grassroots level. The communication can also go multiple directions in the hierarchy. A Scrummaster or manager will typically communicate up the hierarchy concerning obstacles external to their team, while managers at every level should be communicating a realistic picture to their teams. Corporate culture should explicitly endorse and encourage the communication of bad news, as otherwise the tendency is to end up with a reality-distortion field, especially for senior management, as news is tweaked to be more positive (sometimes unconsciously each time it passes along).
One caveat regarding this practice: the "early" aspect of communicating bad news does not mean as early as possible: it means communicating at the earliest responsible moment (an adoption of the lean principle of deciding at the latest responsible moment.). You do not want to appear to be crying wolf. Sometimes it is beneficial or necessary to initiate actions to address the bad news prior to communicating. For example, communication of security holes regarding software products is done privately and typically only publicly communicated after the fix has been distributed in order to minimize the risk of attackers exploiting the hole.
So I encourage you to reflect on any bad news you might be hiding and seize the courage to communicate it to the appropriate parties.
If you find this article helpful, please make a donation.