Business stakeholders don’t like to be told that an IT deliverable is delayed. But we live in a world where delays happen. If you work in IT, and if you want to have less frustrated business stakeholders, then you need to know how to talk about delays.
If you’d like to learn an easy way to be better at talking about delays, check out the six-step process in the second half of this article.
What are delays?
Delays happen when we promise a date, or we are given a date to complete our work. Then something happens that means we cannot meet the delivery date.
Delays can be small: ‘I’ll be a couple of hours later than planned.’
They can also be big: ‘This project won’t finish until next year.’
Delays happen when we make mistakes. They also happen for reasons outside our control. If a production issue needs your focus, it can delay other planned development work. If a system you need is unavailable it takes longer to complete the work. And delays can happen when another team delivers late and it impacts your delivery.
Whenever there is a delay it is critical that you let the other stakeholders know.
Why should IT teams talk about delays?
Late delivery almost always impacts other people. If a change in date/time impacts another person or team you must let them know. Not only that, but you should let them know early.
If you give people notice about a delay, they then have time to take action, change plans, inform their stakeholders about the change. All this helps minimize the impact of a delay. Not only that, but it is polite to let people know.
General rule: The earlier you let someone know about a delay the better.
Finding the right time to tell someone about a delay is a tricky subject. You don’t want to tell them too soon because you might have time to get things back on track. You also don’t want to tell them too late. Never tell someone about a delay at the expected delivery time. Saying, ‘Sorry it isn’t done yet’ is a terrible way to communicate. Think about how you feel when people tell you they will be late at the moment you expect to receive something. It doesn’t feel good. It’s rude. Don’t do it.
Sooner is better
Many people wait until they are certain there is a delay and they have already tried to prevent it before telling the business. The problem is that certainty almost always comes when it is too late to do anything about the delay. It also means the business person has less time to react to the delay.
Instead of waiting until you are 100% certain there is a delay you should start talking about the risk or chance of a delay earlier. That gives the business a heads up about a potential problem. It shows you are taking steps to resolve the issue. And, you never know, it might even help remove the problem because the business person might say the delay doesn’t matter. How nice would it be to have the pressure taken away like that?
Also, if you don’t tell someone about a delay because you are worried about them being annoyed, you are creating a worse situation for yourself. In addition to handling the delay, the other person now has even less time to do anything about it.
If you are unsure when to tell someone about a delay, think about how you would feel if someone waited to tell you about it.
Sooner is almost always better.
Why the business needs to hear about delays sooner rather than later
The primary role of IT is to serve the business and the customer. Any delay to an IT deliverable is almost certainly going to impact a business or customer outcome.
Often there is other work tied to the completion of an IT deliverable. Product launches have marketing spend and other activities with fixed dates. The later the business finds out about a delay, the harder it is for them to reduce the impact.
A test team in a large telecom company once informed their stakeholders that testing would complete a month later than planned. That would delay a product launch by a month but the test team thought it would be worth it. After all, it is important to be certain a product works well for the launch.
What the test team didn’t know was that the company had committed to spending over $50 million on TV and billboard advertising. The dates of the adverts couldn’t easily change. If the delay was communicated on the expected day of delivery the advertising spend would have been wasted. That’s an expensive mistake. Luckily, the test team communicated the delay early enough that the company could find ways to complete the testing on time.
Even if the work is a pure IT deliverable, (e.g. refactoring code) there can still be business impacts. For example, a delay in finishing your IT project might mean a delay in starting another deliverable that is business-related.
It’s just good manners
Beyond the business impacts of delayed delivery, it is simply good manners to let people know when you are going to be late. Think about any time you have waited for a delivery to arrive at home. If the delivery company says it will arrive between 8am and 10am, but it doesn’t arrive until 2pm, that small delay can have a significant impact on your day. You have other things planned, places to be, things to do. The same is true for business stakeholders waiting for an IT deliverable.
How to talk about delays
It doesn’t matter if you communicate verbally or in writing, the principles of how to talk about delays are the same.
Tell the stakeholder sooner rather than later
As described above, when it comes to informing people about delays, earlier is better. There is never one right answer for when to tell someone about a delay. But there is one definite time to avoid: Don’t wait until the delivery date to tell someone about a delay.
It is also not great to wait until you are 100% certain there is a delay. Ideally, you should be telling people about the risk of a delay before that risk becomes an issue. Risks are not definite objects. The probability of a risk becoming a reality changes day by day. The impact of a risk also changes over the course of time.
So, when is it the right time to talk about risk? If your work has a defined and well functioning risk management process you should use that.
If like most of us, there isn’t an active risk management discussion, you need to pick a time to share the risk of a delay. My advice is to tell someone when you think you need to take action to stop the risk from becoming a reality. This simple guideline works no matter what the scale of impact or timeline for the risk or delay. If you think you, or someone else, should be doing something to avoid the risk then it is the right time to talk about the risk of delay.
Clearly identify the deliverable that will be late
Be specific about what is delayed. Don’t start a conversation without first making it clear what the topic is and exactly what is going to be late. You don’t want the audience to think an entire project is delayed if it is only the release notes or something small.
You can read how to make the topic clear at the start of a conversation or email in my article How to start a conversation at work the right way.
Note: being specific doesn’t mean be detailed. Name the project, task, or deliverable that is delayed. This isn’t the time to go into the depths of the technical issue or the various reasons for the delay.
Say how late it will be (one hour, three days, a year)
Tell them how long the delay is — again, it is important to be specific. If you don’t know the length of the delay you should give a ballpark figure.
You might be worried about committing to a new delivery timeline when you don’t know all the variables. In this case, give a reason why you don’t know the variables, give a timeline for when you will know, and state the main action(s) you are taking to find out the timeline.
Example: ‘I’m not sure how long the delay is. We are waiting for another team to provide us with their new delivery date. I have a call with their team leader this afternoon to find out more.’
If you use this type of messaging, your business stakeholder will see that you are being transparent. They also see you trying to get better information about the delay.
Show empathy and understanding
Show that you understand the importance and the impact of the delay on the business stakeholder.
Even if the delay isn’t your fault, you are still the messenger. Delivering bad news is not fun, or easy. But it is an opportunity to build a relationship with your business partner. Showing that you are aware of the impact on them and that you can appreciate the frustration, both go a long way towards demonstrating empathy. That is a key component of any relationship — even one with a business stakeholder.
If you aren’t sure what to say, try something like: ‘I know this isn’t what you want to hear, I’m sorry it isn’t great news. I know you have (other work/deliverables/outcomes) that rely on this fix.’
Propose solutions to remove or reduce the delay
When telling someone about a problem it is always a good idea to have ideas about solutions. When talking about a delay you can propose ideas to reduce or prevent the delay. If the delay is inevitable, think about ways to reduce the impact of the delay.
People are far more accepting of delays when they see you are trying to stop them from happening.
Ask if they have any questions
Make the conversation two-way and give the business stakeholder an opportunity to find out more.
Business and IT should work together as a partnership, and the key to good partnerships is communication. If you deliver bad news and walk away you are not in a partnership, you are just a messenger.
Sometimes you can ask if they have any ideas for how to speed up the delivery. This is a topic that doesn’t have a script. Sometimes the business stakeholders will have ideas, perhaps changing priorities for other work to free up resources to complete this first task. Or they might reduce the scope of the deliverable for an initial release and accept the second update in a later release that includes the final features. There are many possibilities.
Conclusion
Delays happen. We should all work hard to avoid them. We should also know how to talk about delays.
If something happens in your work that causes a delay, don’t wait, use the steps described above to talk about it. You might just avoid a $50m mistake!
