6 rules of talking to the management when your IT project is in danger

Crisis communication with management requires a specific language. Your CEO and stakeholders don’t want to listen about tech debt or refactoring – they don’t care about technical details. They talk money: they want to know how much the problems are going to cost, how soon you can manage the challenges, and what the risks are.

In this article, we’ll talk about… talking. We’ll take a look at how to communicate problems to management in a way that’s honest and true, but doesn’t put you in a bad light either. We’ll explain how you can get off the tiger’s back in a potentially harmless way. 😉 

Here’s a list of 6 things that will make it easier for you to communicate bad news.

Audit your project

1. Don’t hide problems, or they’ll blow in your face

The rule of thumb is: never, ever hide the problems or they will blow right in your face at the moment when you least expect it (it’s simply Murphy’s law, right?).

We’ve learned that absolute honesty is the way to go, and that’s how our product managers communicate with stakeholders. We’re not perfect as a software vendor, we make mistakes, and sometimes we just screw up. But whenever we do, be sure we’ll tell you about it – we’ll communicate the risks as soon as possible, discuss all the potential challenges, and propose a tangible solution to a problem.

Here’s an example of what you can hear from us: 

“We underestimated the complexity of the feature we’re implementing. Because of that, we won’t be able to launch it on Monday as we had agreed. We don’t want to release an untested and bug-prone solution. That’s why we’d like to put off the launch date to Friday. By that time, we’ll make sure everything is sewed up. Are you okay with that?”

• Also check: IT Project Delays: A Framework for Exec Talks

2. Speak Problem + Solution

Second, the order in which you communicate things is important, too. We’ll break it down into small bricks that will then be connected.

The simplest structure to think of is the problem + solution concept. In simple terms, you communicate the problem AND right away you’re explaining how you’re going to solve it.

Interestingly, look at how the problem is framed here: it’s a combination of a fact and it’s (negative) impact:

• Problem: server outage
• Impact: we are currently tracking 3 days behind

Then, of course, goes the solution.

Why is this important?

It removes emotion and defensiveness. You’re clearly stating the facts (and facts are neutral by nature), honestly informing about the potential consequences, and proactively proposing solutions.

Another example:

1. Fact: “I’ve noticed the data entry process currently requires manual input across three different sheets.”
2. Impact: “This increases the risk of error and takes about 5 hours a week that could be used for analysis.”
3. Solution: “I’ve looked into an automation tool that could reduce this to 30 minutes. Should I set up a trial?”

BTW, we created a similar solution:

Saving 2 hours daily: efficient AI & low-code accounting automation

Saving 2 hours daily: efficient AI & low-code accounting automation

We’ve helped our finance specialist get rid of daunting bookkeeping tasks and save her up to 2 hours every day with AI & low-code.

Learn More

3. Address their objections before they do

The conversation could stop here. Yet, there’s a big chance one of the stakeholders will say “but this solution is 30% more expensive upfront!”. Well, they will say that, that’s what you need to steal their thunder.

In psychology, “inoculation” means exposing a person to a weak argument against your position so they can build up resistance to it. In a management context, this means voicing the manager’s objection before they do.

Look:

You present a solution, and the manager immediately thinks, “But that will cost too much money.” If they have to point that out, you look short-sighted. So, what do you do? Call out the downside yourself. This builds credibility – the stakeholders believe they can trust you because you are well-prepared.

Now, let’s take a look at how to do it. There will be a bit of auto-promotion here (but just a bit. 😉

“I recommend we switch to Pragmatic Coders. I know this is 30% more expensive upfront, but they have huge experience in rescuing projects on fire, so the collaboration with them will be cheaper in the long run.”

It works because it shows you have already thought critically about the negatives, so they don’t have to “catch” you.

So, our bricks look like this now:

Fact + Impact + Solution + Objection + Justification

• Also check: How to manage stakeholders during project recovery

4. Loss aversion

Psychologically, humans are “loss averse.” We feel the pain of losing $100 twice as much as the joy of finding $100. You can use this to make your problem sound like a necessary intervention.

• The Risk: Presenting a problem feels like you are just adding work.
• The Fix: Frame the problem as protecting an asset or preventing a loss.
• How to do it:
  • Instead of: “We need to delay the launch because the code is messy.”
  • Try: “To avoid a 20% crash rate at launch (The Loss), we need to spend two extra days stabilizing the code.”
  • Why it works: You aren’t asking for a favor; you are saving them from a DISASTER.

5. Keep it simple

Cognitive fluency refers to how easy it is for our brains to process information. Research shows that people perceive statements that are easy to understand as being more truthful and the speaker as being more intelligent.

(If you’re curious, read more about Daniel M. Oppenheimer’s 2006 research. In short: he took graduate school admission essays and translations of Descartes and created a simple and a complex (e.g., switching use → utilize) version of them. The result was that study participants rated the authors of the “complex “ text as… less intelligent.).

It works because nervous employees tend to over-explain, ramble, give too much backstory, or use jargon to hide the issue. This increases the manager’s “cognitive load,” which, in turn, leads to frustration. On the other hand, concise communication signals confidence and control.

The fix is to be very concise. Strip away the adjectives. Cut our jargon. Just facts. Short and sweet:

6. Peak-end rule

And, finally, the peak-end rule. Humans judge an experience largely based on how they felt at its peak (the most intense point) and at its end, rather than the total sum of the experience.

This is a problem when the conversation ends on the problem or the apology, leaving a negative impression. That’s why you should make sure the interaction ends on a high note – usually a solution or an action plan (just as we discussed earlier). If you do so, the stakeholders will walk away remembering your proactive approach, not just the error.

Conclusion

Talking about challenges in your IT project to the management is not easy. Yet, I hope this set of tips will help you communicate them in a way that always shows you in a good light. 

Have you just realized your project is in deep trouble? Do you need clarity on whether the project is salvageable? We will help you diagnose the current performance without the need to escalate upward. Contact us for a product & technical audit.