A prodigious client of mine once gave me this advice. “I want bad news fast and good news very slowly”. It’s good advice. Most consultants fret about giving their client bad news, they delay or worse yet they never communicate it, leaving it for the client to discover the truth on their own. Both of those situations are potentially catastrophic for a consultant/client relationship.

• “Why didn’t you tell me?”
• “And you’ve known about this since when?”

These are two questions a high value-add consultant should never hear from their client.

“Guys, I have good news and bad news. The good news is that each of you will get triple rations today and a 2 hour break. The bad news is the captain wants to go water-skiing before lunch”

The Bad News

Some common themes that consultants may have seen on projects are:

• The initial estimate was wrong and the schedule has been impacted
• The expected productivity hasn’t occurred and you are behind schedule
• A critical component was left out of the specification in error
• A key resource has left the project
• Etc.

The first thing I would say is that you have a responsibility to your client at the beginning of the engagement to talk about change. Change happens. Agree in advance that changes may occur, what you will do if it occurs and how your client wants it communicated to them. Talk about having some contingency hours set aside up front to deal with change. Even if it was 1 hour as contingency, the principal has been set that change was expected or at least possible.

The second point is to immediately communicate it to your client. It may not be in its final form but at least you have provided an early-warning to them that it’s coming. It will always be worse if you wait.

“Hi Bill, I just need to let you know that Chris has indicated that he is leaving the project. I will provide you with the date that this will occur and a recommended remedial action plan by Friday close of business. At this time I do expect this to have impact on his work area but I will have a complete impact analysis and recommendation on Friday.”

By doing so your client is now thinking at least 3 things:

• You are on top of the issue
• You are being forthright
• You have provided them the maximum amount of time to start thinking about impact and contingencies

So what if you have to give your client or your client’s resources feedback?

People need both positive and negative feedback. They need to know not only what they are doing in an ineffective way, but also what they do that is effective, so that they correct the one and continue the other.

Why do many people find it difficult to give feedback to someone else?

• They are afraid that, if they give feedback, the person will get upset
• They are afraid that the feedback will be misunderstood.
• They do not know how to give feedback effectively.
• They are not sure that it is proper for them to give feedback to a client.

How do people commonly react to negative feedback?

• Choosing not to hear what is being said.
• Doubting the other person’s motives
• Denying the validity of the feedback data
• Rationalizing to explain why he or she behaved that way
• Attacking the person giving the feedback

So it is the worst of all possible situations. You don’t want to give the feedback and the client or client resource doesn’t want to hear it. However, that doesn’t let you off the hook. If the issue is impairing your ability to execute the engagement properly or providing deliverables that are below expectations, then you must deal with it.

So here are some tips for giving feedback.

• Be objective: “When we reviewed the QA stats, your bug ratio was about 12%, 6% higher than other team members”
• Be specific: “It appears to be in caused by using custom code instead of leveraging our standard libraries for items such as exception handling”
• Be clear: “At this time, we need to work together to get your code quality in-line with the rest of the team’s performance and we will do that by having Greta work with you for a couple of days and show you some pointers”
• Be constructive: “If you do this, I am certain the code quality will come up and you can be right in there with our key developers”
• Be sensitive: “Don’t worry about this, I just want to help you improve. There is only benefit for your professional development by being exposed to the best practices with the library usage.“
• Be alone with them. Never give feedback publically.

Remember, feedback is given to help other people develop/change, not to make them wrong or feel inadequate.

The most effective feedback is when the receiver has asked for it – rather than being imposed by the giver.

Therefore, it is best to ask “Is it okay if I give you some good feedback that could help you ?”

99.9% of people will answer yes.

I  will also provide the same caution as I did in my blog Mastering the Art of Influence

** Warning: The above technique if ever applied during a relationship such as partner, spouse, sig. other etc. is at your own peril and is recommended for consultant/client interactions only.