Comunicating failed deadlines

The problem:

I think that no one wants to be the bearer of bad news. Especially if the bad news means a big impact. Moreover when you know the recipient of bad news is not going to react well. I believe it is our human nature to fear this feeling, the feeling of offending people.

That is why it is always difficult in our professional environment to be the ones having to bring to our customers the bad news that we won't be able to deliver on time, as agreed and expected. There is a mix of shame and fear and desolation that is hard to quantify. That is why most product managers try to find any other solution than having to relay the news, having to negotiate deadline extensions, having to explain why this happened, taking ownership of the mistake, and mostly, taking the blame.

The "bullshit" solution:

Today we have a promotion "two for one" in the aisle of "bullshit solutions". This is due to the fact that most managers fall in one of the following categories: either they try to find the scapegoat or they push the teams to work more or cut corners in order to try and make the deadlines. There are times when both bullshit solutions apply. Let's imagine the scenario where you are still months before the deadline. It is an important release. Everyone is aware of it. Top management, all the C-level personalities stress the importance of this release. The customers are impatiently waiting for the new set of functionalities. They are making their own preparations and arranging for the availability of testers in order to validate the functionalities on their side also. They are waiting for the changes to be pushed to the staging environment, they are creating release strategies for early adopters and then the gradual release to the entire end-user pool. What else to say... It's one of those make it or break it moments.

During this time and having in mind the pressure of the deadline, the product manager goes to one of the teams and finds out that during the last iteration they found that the scope changed. They uncovered some use cases that were not seen until now. and it's bad. It means a delay. They don't even know how to quantify the delay because they haven't finished the analysis of the issue yet. You, as a product manager are flabbergasted. You yourself feel the rush of blood circling through your head and you start making scenarios in your head on where they will find your body and in how many pieces when everyone finds out about this. You decide to keep the lid on it for now until you find out how much of a delay this is. Moreover since this delay is on the main functionality to be released.

The next day you attend the review of another team and you see that they haven't even started work on a story that was on the critical path for another functionality. You know already that this also means a delay for this second functionality even if the team hasn't identified it yet. Again you decide for yourself to keep it hush hush until you manage to identify if there is any corrective action.

With the two issues at hand you start making a ton of math inside your precious little excels. There are still 5 months till the release. There must be some way to get it back on track. You analyze all the options: what if we work on weekends, what if i get people from other teams, what if i hire some outsourcing team that you worked with in the past to pitch in. All solutions seem to not work. You decide however to push the teams to give more. To do the overtime, to put in the weekend work. Given the importance of the release, everyone must pitch in and contribute to get back on track. You estimate that in 2 months, the gap should be covered. Let's wait for 2 more months and reevaluate.

And two months pass very quickly. The team with the story not started manages to reprioritize and they get it done. They are back on track. But the main functionality is still at risk. The team estimated a delay of 3 months due to the extra scope and use cases discovered. At this point you cannot keep it under the rug and you tell it to your organization. Of course the disappointment is huge and everyone panics while trying to get from you the pans to get back on track. You tell everyone that in the past 2 months the team managed to recover some of the lost time so there is an improvement compared to where we were 2 months ago, but the release is still on Amber in the RAG status. The internal stakeholders seem to be a little more optimistic about the news but they are in the same place you were 2 months ago and decide to wait for 2 more months before presenting it to the customer. You silently agree although you know deep down that you are still in deep shit.

And again two more months pass by. The team is still delayed. They have given everything they had and managed to recover one more month of the three month delay that was originally estimated. You present this progress to the internal stakeholders and show yourself optimistic that with an extra effort you still have a chance to release on time. Everyone is happy with the result and they pat you on the back. With this good news you can present the issue to the customer. You set a meeting, you get you own management as a backup and you present the risk to the customer. But you sugar-coat it in such a way that it is only seen as a minor setback, a possible risk. Given that this risk is raised just a month before release, the customer is skeptical. They try to get as much info as possible from you. But you have your own management behind you and every time you try to give them any relevant information, they intervene in reassuring the customer hat everything will be ok. Let's not worry over minor things.

And one more month passed by in the blink of an eye. And it's now 2-3 days before the release. You are on the home run. You see the finish line. You can smell the burned rubber. And then the shit really hits the fan. The same team that pushed for the past five months finally broke. Three out of the 5 team members are out sick. They could not keep with the overtime and stress for such a long time. The remaining two members have no chance of finishing and delivering in time. They are the most junior members and they do not have the knowledge to finish, nor the knowledge to prepare the release. And all the blood in your body comes rushing to your head once more. You yourself feel sick.

Now you only have 2 days to react. First thing you go to your management, to your internal stakeholders. You present the facts. You put the blame on the team members that are missing. The stakeholders agree with you but there is still the problem of the release. You need to go to the customer. In front of the customer you again try to find the scapegoat in the same guys that poured out their soul in the past 5 months. The team was not able to finish. You also state that last month you raised the risk. Well, the risk just happened. At the suggestion of management you also mention passing by that the entire schedule might have been on track if the customer would have replied faster to the emails where you tried to clarify the requirements and the use cases. This doesn't go unnoticed by the customer but instead of taking part of the blame they start becoming defensive and the tone changes in the meeting. Everyone is doing the math in their heads on how much money will cost all of us every day of delay. Trust in you as a manager is at an all time lor and since the customer is becoming more and more frustrated about this delay, your management intervenes once more and tries to calm down the customer by pulling one last ace out of their sleeve. They present to the customer another product owner, one with a lot more experience and seniority than you, and announce that he will be taking over the role and will do whatever necessary to ensure the delay is as small as possible. The meeting ends with the promise of a new plan in the next couple of days and a material retribution according to the contract. The customer is still unhappy because the financial retribution will not cover all the costs he incurred in preparing the release.

The "no bullshit solution":

Let me start with one important statement: "All of the following steps go much smoother if there is already in place a trust relation between you and the customer." Now, given that, follow the next steps:

1. The first and most important step is to OWN IT! Take the problem. Make it your own. Turn it on all sides. Get your hands dirty. Ask all the questions. Find everything there is to be found in your problem. If you know all the aspects it will be much easier to find solutions.
2. Create transparency from day one. Once you find there is a delay in the plan, shout it out. The sooner you present it to everyone, the sooner you can work together in finding the right action plan to address the problem. Make it visible both internally to your stakeholder as well as your customers. Nobody will be happy about the delay but it is important to state out you are on top of it. You are doing everything you can in order to fix it and also make public this set of actions you intend to take. Even if the full extent of the problem is known yet, it is still worth presenting it. State that your first action is to get around the issue and see how big it is. Next step is to analyze the impact. Create a communication plan with a frequency you are comfortable with and also agree with all the interested parties. Stick to that communication plan. Whether it is a status update mail or a status update meeting, set the frequency and stick to it. Even if you don't have updates, write the news letter and say you don't have updates. In cases where there is a known problem, no news usually means bad news and it freaks people out.
3. Find the right stakeholders to support you. They need to back you up in front of everyone else and they need to also provide guidance in case you need someone to spare some ideas with. Those people will later become your pillars for building your solution with.
4. You are the product manager, and do not forget that the team also has a product owner. Trust him with motivating the team amd relaying the message and avoid doing micromanagement yourself. Don't push the teams past their breaking point. I know it's easier to push your team  than pushing the customer but a NO is a NO when it comes from the team.
5. Put on your negotiating pants and start exploring scenarios with the customer. Try to find the flexibility point in their expectations. More often than not, you will be able to get some leniency from them also. You might find out that not all functionalities are as important as the others. You might even get something descoped from the release in order to focus the teams on the features that matter the most for the client. Find the flexibility in their timelines. Prepare them for the possible delay in order for them to also be prepared. Tha means they might need to shift test windows, they might need to hold off on press releases, they might need to push some other functionality of their product in front of the one in delay.
6. Back up every decision you take with cold hard facts. Every decision taken with the customer needs to be written. Every KPI you measure internally needs to be documented and dated for future reference. Every gentlemen agreement needs to be noted in some meeting minutes that will be disseminated only to the appropriate stakeholders.
7. Show to everyone you are on top of your game and you are always in control of your action plan. This cultivates trust and reduces the "what if" questions that are coming from uncertainty.
8. Follow up on your communication plan and always provide the most recent developments on the problem. Usually things become worse before they get better. If you foresee such a case, prepare everyone for this possibility. Try to forecast some numbers that will support your statements based on previous projects or similar situations.

In closing I would like to restate that communication is paramount in these kinds of situations but just as every journey starts with that first step, so does your solution to your problem start with the step of transparency.