I am all for a very open and honest project manager--project client relationship. Withholding any information is something I always frown upon. It can ruin a project, it can ruin a working relationship - and it can certainly ruin your career depending on the situation.
However, I do think there are certain things that you should never let your project client hear you say. That's different than withholding information. One is lying or at least deceit by omission. The other is just managing your words wisely in order to maintain a good relationship, not incite undo or unneeded stress or panic and to keep productive forward progress happening.
I’ve narrowed my list to six key phrases that I try to never utter to my project clients. They serve no good purpose, they can thwart positive outcomes like increase project revenue through change orders, and they can cause your project customer to become defensive…possibly even dissatisfied with the performance of the project team.
Let’s examine these 6...
“That can't be done.” Really?? Are you seriously going to tell a client who wants something that it simply can’t be done? You may have to tell them that, but not without some investigation. Some feasibility study. If it’s something they really want and possibly something the solution really needs, then you need to honor that request or need and look at least look into it…even if you’re pretty certain that it, indeed, cannot be done. But never say that directly to a request. Thank them for their input, tell them that sounds like a good idea, and that you or someone on your team will look into it and report back on the next status call. If it’s not possible, then you may be able to at least offer a meaningful alternative and still turn it into a change order and some additional revenue for your organization. Keep it positive.
“That's out of scope.” The last thing your project customer wants to hear you say a lot during a project is the “S” word. If you are constantly stating that things are out of scope, you’re going to upset your customer. The best response, again, is to state that you’ll look into whatever they are requesting. It may be out of scope, but it’s worth a thorough check of the requirements, possibly further discussion with the customer about the request to ensure that you are correctly understanding it, and then a team discussion on how big the request actually is. If it’s really small, maybe you can do it for free (avoid too many of those, though). But if it is bigger…and if it is out of scope…then by all means go back to the customer and tell them it’s beyond the current requirements and try to give them at least a rough estimate of what the change order may be. Let them decide if they want to proceed.
“You are wrong.” Never just flat out tell the project client that they are wrong. They may be as wrong as wrong can be, but use some good judgment in how you tell that to the customer. Discuss the possibility of a miscommunication or take partial blame yourself. You want the relationship to remain good – that’s how change orders get approved quickly, that’s how customers come back for more projects from you or your organization, and that’s how your reputation as a good customer-facing and reliable project manager gets established.
“You didn't pay for that.” Just like screaming, “That’s out of scope!”, it’s fairly rude to respond directly to a customer’s request with a phrase like, “You didn’t pay for that”. It may be true, but investigate it first. I had a client that thought they had, indeed, paid for some “free” training when they purchased our expensive software license for the solution that my team and I were configuring and installing. However, upon further discussion, it became clear that the expensive license they purchased did not include the training they badly needed in order to fully understand how the software worked so that we could navigate our way through the muddy waters of business process review and requirements definition. No, they needed to spend a lot more on their license to get that training included. My business analyst and I worked with our executive team to draw up an onsite training change order that saved the day and made them happy while giving us a nice revenue boost for the project. But we didn’t coldly respond with “You didn’t pay for that”. Again, stay positive and investigate before telling the customer that they are going to have to come up with more funds to get what they are asking for.
“That will cost too much.” It may be an expensive request – and the customer may even know that it will be an expensive request – but it’s offensive to make a statement like that. It’s almost like stating that you think the customer will be unable to afford the price of the work. Besides, a response like that from the project manager may cause the customer to withdraw the request – and that may have been a nice addition to the project bottom line and a nice feather in your project management cap. If the customer identifies a project need and makes a request, tell them you’ll discuss it with the team and come back with an estimate to complete the work…most likely in the form of a change order that they can then review and accept so that you can begin to work on their request.
“You don’t want that.” Just as bad as telling them that it’s too expensive is telling them that they really don’t want what they are asking for. Indeed, it may not be in their best interest, but it’s wrong to tell the customer that what they are asking for is not what they want. I am the first person to tell everyone that you should never just give the customer exactly what they are asking for if you know it’s not what they really want or need. But you arrive at a point of telling the customer that their request may be different than their real need after some detailed research and a more formal presentation or discussion. The worst thing you can do is easily dismiss their perceived need without some documented research and feedback to present to the project client.
Summary
That’s six of my statements that I try to avoid when having discussions with my project customers. There are more, I’m sure, but these are six common ones that could come up if I hadn’t gotten into the habit of counting to ten first. What makes up your list? What phrases have you found that set your customer off or what phrases do you avoid as you try to be positive when responding to the requests and needs of your project client?
However, I do think there are certain things that you should never let your project client hear you say. That's different than withholding information. One is lying or at least deceit by omission. The other is just managing your words wisely in order to maintain a good relationship, not incite undo or unneeded stress or panic and to keep productive forward progress happening.
I’ve narrowed my list to six key phrases that I try to never utter to my project clients. They serve no good purpose, they can thwart positive outcomes like increase project revenue through change orders, and they can cause your project customer to become defensive…possibly even dissatisfied with the performance of the project team.
Let’s examine these 6...
“That can't be done.” Really?? Are you seriously going to tell a client who wants something that it simply can’t be done? You may have to tell them that, but not without some investigation. Some feasibility study. If it’s something they really want and possibly something the solution really needs, then you need to honor that request or need and look at least look into it…even if you’re pretty certain that it, indeed, cannot be done. But never say that directly to a request. Thank them for their input, tell them that sounds like a good idea, and that you or someone on your team will look into it and report back on the next status call. If it’s not possible, then you may be able to at least offer a meaningful alternative and still turn it into a change order and some additional revenue for your organization. Keep it positive.
“That's out of scope.” The last thing your project customer wants to hear you say a lot during a project is the “S” word. If you are constantly stating that things are out of scope, you’re going to upset your customer. The best response, again, is to state that you’ll look into whatever they are requesting. It may be out of scope, but it’s worth a thorough check of the requirements, possibly further discussion with the customer about the request to ensure that you are correctly understanding it, and then a team discussion on how big the request actually is. If it’s really small, maybe you can do it for free (avoid too many of those, though). But if it is bigger…and if it is out of scope…then by all means go back to the customer and tell them it’s beyond the current requirements and try to give them at least a rough estimate of what the change order may be. Let them decide if they want to proceed.
“You are wrong.” Never just flat out tell the project client that they are wrong. They may be as wrong as wrong can be, but use some good judgment in how you tell that to the customer. Discuss the possibility of a miscommunication or take partial blame yourself. You want the relationship to remain good – that’s how change orders get approved quickly, that’s how customers come back for more projects from you or your organization, and that’s how your reputation as a good customer-facing and reliable project manager gets established.
“You didn't pay for that.” Just like screaming, “That’s out of scope!”, it’s fairly rude to respond directly to a customer’s request with a phrase like, “You didn’t pay for that”. It may be true, but investigate it first. I had a client that thought they had, indeed, paid for some “free” training when they purchased our expensive software license for the solution that my team and I were configuring and installing. However, upon further discussion, it became clear that the expensive license they purchased did not include the training they badly needed in order to fully understand how the software worked so that we could navigate our way through the muddy waters of business process review and requirements definition. No, they needed to spend a lot more on their license to get that training included. My business analyst and I worked with our executive team to draw up an onsite training change order that saved the day and made them happy while giving us a nice revenue boost for the project. But we didn’t coldly respond with “You didn’t pay for that”. Again, stay positive and investigate before telling the customer that they are going to have to come up with more funds to get what they are asking for.
“That will cost too much.” It may be an expensive request – and the customer may even know that it will be an expensive request – but it’s offensive to make a statement like that. It’s almost like stating that you think the customer will be unable to afford the price of the work. Besides, a response like that from the project manager may cause the customer to withdraw the request – and that may have been a nice addition to the project bottom line and a nice feather in your project management cap. If the customer identifies a project need and makes a request, tell them you’ll discuss it with the team and come back with an estimate to complete the work…most likely in the form of a change order that they can then review and accept so that you can begin to work on their request.
“You don’t want that.” Just as bad as telling them that it’s too expensive is telling them that they really don’t want what they are asking for. Indeed, it may not be in their best interest, but it’s wrong to tell the customer that what they are asking for is not what they want. I am the first person to tell everyone that you should never just give the customer exactly what they are asking for if you know it’s not what they really want or need. But you arrive at a point of telling the customer that their request may be different than their real need after some detailed research and a more formal presentation or discussion. The worst thing you can do is easily dismiss their perceived need without some documented research and feedback to present to the project client.
Summary
That’s six of my statements that I try to avoid when having discussions with my project customers. There are more, I’m sure, but these are six common ones that could come up if I hadn’t gotten into the habit of counting to ten first. What makes up your list? What phrases have you found that set your customer off or what phrases do you avoid as you try to be positive when responding to the requests and needs of your project client?
RSS Feed
