Fiona Charles
30 Jul

Delivering Difficult Messages

30 July 2011 by Fiona Charles

You're the test manager on a project where there are many unresolved critical bugs that could have major customer impacts. You have not yet been able to test key areas of the system, and the ship date is now only a week away. The official project status reports consistently declare the project to be "green" and the system on schedule to ship. You know that the system is in no fit state to release and that the bugs will not be fixed in time. In fact, "everyone" on the project knows this and is talking about it, but the project manager does not appear to be getting the message. Either that, or he/she is failing to report the true state of the system to management. You believe that your reports to the project manager have clearly described the issues.


You're not the gatekeeper. It's not up to you to decide whether or not to ship the product. But as the test manager, it is your job to provide accurate information about the true state of the system so that management can make an informed decision.

You feel obligated to speak out directly, but you know that your message about the true state of the system is not going to make anyone happy. Perhaps having to acknowledge it will cause a manager to lose ground with more senior managers. Perhaps it will jeopardize someone's bonus, or his or her next promotion.

It is in your interest -- and also in the interests of the organisation -- that you deliver the message well. You want your information to be truly heard. You want it to be received as valuable information so that it can be considered appropriately. You don't want to damage your credibility or hurt your future in this company. You don't want the message recipient to react with anger or disbelief.

Welcome to delivering difficult messages! This is only one of the many situations where you, as a person in a responsible role on a software project, may have to deliver a message that is difficult primarily because the recipient doesn't want to hear it. You can't control other people's reactions, but with careful planning and preparation you can craft your delivery of a difficult message to strengthen the likelihood of a constructive response.Begin by thinking about the principal considerations for successful delivery of a difficult message:

  • message recipient(s)
  • time and place
  • message content
  • message delivery

Message Recipient(s)

First, there's the message recipient - who should you talk to? Given the scenario described above, should you talk first to the project manager? If he or she dismisses your concerns, you need to think about where you go next. Think also about what you know of the intended message recipient and what might motivate his or her potential reactions to the information. Do you believe this to be a person of integrity, or are there vested interests you need to be wary of? Should the meeting be one-to-one, or include more people? Do you have any potential allies in this situation who could help, either by paving the way for your conversation or by joining it?

Time and Place

Having decided who you're going to talk to, when and where should you meet? It would be a bad idea to buttonhole a senior manager in the cafeteria queue and blurt out your urgent concerns, or spring your message on an unsuspecting vice president at a project party-though testers have surely done these things, or worse. You need to pick an appropriate moment and a quiet place for a manager to hear your message. Try to schedule the meeting accordingly.

Message Content

What is the content of your message? What are you going to say? How sure are you that your information is accurate? What supporting material do you have? Be scrupulously careful not to go beyond facts you can prove. If you must state an opinion, be clear that it is your opinion.

Message Delivery

Finally, how are you going to deliver the message? Your delivery method and style will depend on your message, but also on your assessment of the person(s) you are going to talk to. Are you going to sit down and talk or stand at a whiteboard and illustrate your points with pictures? What else might you do?

A busy executive may be prepared to give you full attention for five minutes or less. You'd better be able to deliver your message to this person succinctly and in summary-with the details in your back pocket in case you're asked. Another manager may be detail oriented, not content until every last fibre of every last thread has been exhaustively explored. You will need all the details to hand when you meet with him or her.

Regardless of a recipient's personal style, it's essential that you stick to a factual narrative that you can readily support. But what if, in spite of all your preparations, the manager becomes angry and hostile? Can you manage your own reactions and help your message be heard? Can you remain calm and factual in the face of a manager's fury? Sometimes, you might need to say, "I'll have to get back to you on that," and excuse yourself. But then you need to go back and finish what you started.

Come to EuroSTAR!

"Delivering Difficult Messages" is a big topic and I've only touched on some of the important points in this blog post. In my tutorial at EuroSTAR 2011, we will explore some likely project scenarios in depth experientially, using role plays to practice the interactions between message giver and recipient(s), and sharing tips and techniques from our own experiences and observations. We'll talk about common pitfalls and how to avoid them. We'll also discuss a model that can help our understanding of difficult interactions and help us prepare better when we have to deliver bad news.

Delivering unwelcome news is never fun, but we can have fun exploring and practicing how to do it. Come prepared to practice with real situations that have happened for real testers, including current scenarios brought by participants.


5 comment(s) for “Delivering Difficult Messages”

  1. Gravatar of Johan Åtting
    Johan Åtting Says:
    you have made some very good points about a difficult subject. I would like to add some thoughts around message content that I think is important when delivering difficult messages, like the one in the example, or presenting problems in general.

    I think it’s important to know why I’m delivering the message; e.g. is it just to keep my back clear so I later can say “I told you so…” (probably not), or is it that I need guidance in how to solve a problem, or are my intention to get a specific action (reaction), e.g. extra test and bug fix time? Also as a manager myself I like to know why I’m being presented with a problem.

    One schema that I have found very useful, both as a deliverer and as a recipient, is to structure the messages like this:
    - What’s the problem
    - What’s the background (in my view)
    - What are the possible solutions (that I can see)
    - What’s the preferred solution (if you ask me)

    This schema can be varied depending on the recipient(s), e.g. one could skip the “background” part but be prepared to explain it if asked for, one could also skip the “preferred solution” if one like the recipient(s) to decide, but again be prepared to explain what solution I think is the preferred one, and why. If I only present a problem it’s likely that the manager would like to know the background, and also what solution(s) I see to the problem. As a manager I like my staff to do some thinking themselves and not just present a problem but also their view on possible solutions.
    /Johan Åtting
  2. Gravatar of Fiona Charles
    Fiona Charles Says:

    Thanks for your thoughtful additions. It's certainly important to understand your own motives when you deliver a difficult message. Sometimes, though, it's just as I wrote: "You want [the message] to be received as valuable information so that it can be considered appropriately." As the person delivering the message, you may not have a particular solution in mind for a complex problem, though you may favour a particular approach to arriving at a solution.

    So, I like your schema for structuring messages, but I would add one caution. It can be helpful to ask one's staff to think before they speak about potential solutions to the problems they bring, but at the same time, it's not always fair for a manager to expect people to bring solutions when they bring problems. Not all problems are readily solvable, and the most difficult and intractable problems are most likely to be the ones that managers really need to hear about. I've seen unfortunate consequences from situations where people were too intimidated to tell their manager about a serious issue because they didn't have a solution.
  3. Gravatar of Henrik Bodén
    Henrik Bodén Says:
    Hi Fiona,
    some really good thoughts on how to deliver difficult messages.
    I think however that as much testing as possible should be done as early as possible in the development process thus preventing the situation of having to deliver a difficult message. The difficult messages usually belongs to the fact that test is late in the project and there is too little time to correct what’s wrong or not working in order to deliver on time. To often the projects are already too late when they enter the test phase and then to say we have a problem is not well seen. My experience is that Agile working methods together with continuous integration (automatic builds and deploys) really helps finding the problems early when there is still time to do corrections thus making the difficult messages less difficult.
    /Henrik Bodén
  4. Gravatar of Fiona Charles
    Fiona Charles Says:
    Hi Henrik,

    Thanks for your comment. Yes -- that's usually true for this particular difficult message. With earlier feedback loops, quality issues are usually exposed and dealt with far earlier. However, the example I gave in the blog post is only one example of the kinds of difficult messages that testers and other responsible people on a project may have to deliver.

    When I presented a version of this tutorial at CAST in 2010 (with the title "Speaking Truth to Power") the tester participants came up with quite a range of scenarios from their own (Agile and not-Agile) project experiences where they had been in the position of having to deliver unwelcome news. While I hope we continue to improve how we manage and conduct our projects, I don't see the necessity for occasionally having to deliver difficult messages going away in the foreseeable future.

    .../Fiona Charles
  5. Gravatar of testwithus
    testwithus Says:
    SWIFT Interview questions on

    For selenium solution visit

    For QTP interview questions

Leave comment: