Mixing
How to handle communication with client who cannot convey requirements well?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
3
down vote
favorite
I recently changed manager. The old manager is now one of many people requesting my help. However, he's still trying to take away projects for himself.
The problem is, he is more ambitious than experienced, and he is not able to be specific in his requirements, e.g. "I want an excel file showing the comparison between two different softwares". There is no information about what details he wants. Other colleagues are much clearer, and results are notably better.
My question is: how can I professionally handle communication with a client who requires technical support with no basic understanding of what he's saying?
communication consulting
edited Oct 1 '15 at 10:56
Joe Strazzere
223k104653921
asked Oct 1 '15 at 10:30
Monoandale
2,72041846
suggest improvements |Â
up vote
3
down vote
favorite
I recently changed manager. The old manager is now one of many people requesting my help. However, he's still trying to take away projects for himself.
The problem is, he is more ambitious than experienced, and he is not able to be specific in his requirements, e.g. "I want an excel file showing the comparison between two different softwares". There is no information about what details he wants. Other colleagues are much clearer, and results are notably better.
My question is: how can I professionally handle communication with a client who requires technical support with no basic understanding of what he's saying?
communication consulting
edited Oct 1 '15 at 10:56
Joe Strazzere
223k104653921
asked Oct 1 '15 at 10:30
Monoandale
2,72041846
10
I don't think "mentally challenged" is a good description here, that makes it sounds like he's handicapped, which does not seem to be the case.
– Erik
Oct 1 '15 at 10:32
He does have difficulty writing in correct English and he is not able to grasp basic concepts of his field of expertise... but I will edit the question. Oh. Thanks for editing!
– Monoandale
Oct 1 '15 at 10:57
5
There is nothing unprofessional about asking a client to be more specific in the request, with the goal of providing the correct answer/product in the first go.
– JoSSte
Oct 1 '15 at 11:00
2
One thing to note - you're saying he can't provide requirements well, then talk about his unclear specifications. You may find that you get better results by forgetting specifications if he's inexperienced, and instead focus on finding out what he actually wants to achieve. You will get far more kudos for really drilling down into what the stakeholder wants the end result to be and then producing that, rather than trying to force them to produce specs and then blindly following them. Ask questions lots of questions, and don't leave until you understand the problem.
– Jon Story
Oct 2 '15 at 14:02
suggest improvements |Â
up vote
3
down vote
favorite
up vote
3
down vote
favorite
I recently changed manager. The old manager is now one of many people requesting my help. However, he's still trying to take away projects for himself.
The problem is, he is more ambitious than experienced, and he is not able to be specific in his requirements, e.g. "I want an excel file showing the comparison between two different softwares". There is no information about what details he wants. Other colleagues are much clearer, and results are notably better.
My question is: how can I professionally handle communication with a client who requires technical support with no basic understanding of what he's saying?
communication consulting
edited Oct 1 '15 at 10:56
Joe Strazzere
223k104653921
asked Oct 1 '15 at 10:30
Monoandale
2,72041846
I recently changed manager. The old manager is now one of many people requesting my help. However, he's still trying to take away projects for himself.
The problem is, he is more ambitious than experienced, and he is not able to be specific in his requirements, e.g. "I want an excel file showing the comparison between two different softwares". There is no information about what details he wants. Other colleagues are much clearer, and results are notably better.
My question is: how can I professionally handle communication with a client who requires technical support with no basic understanding of what he's saying?
communication consulting
edited Oct 1 '15 at 10:56
Joe Strazzere
223k104653921
asked Oct 1 '15 at 10:30
Monoandale
2,72041846
edited Oct 1 '15 at 10:56
Joe Strazzere
223k104653921
edited Oct 1 '15 at 10:56
Joe Strazzere
223k104653921
edited Oct 1 '15 at 10:56
Joe Strazzere
223k104653921
223k104653921
asked Oct 1 '15 at 10:30
Monoandale
2,72041846
asked Oct 1 '15 at 10:30
Monoandale
2,72041846
asked Oct 1 '15 at 10:30
Monoandale
2,72041846
2,72041846
10
I don't think "mentally challenged" is a good description here, that makes it sounds like he's handicapped, which does not seem to be the case.
– Erik
Oct 1 '15 at 10:32
He does have difficulty writing in correct English and he is not able to grasp basic concepts of his field of expertise... but I will edit the question. Oh. Thanks for editing!
– Monoandale
Oct 1 '15 at 10:57
5
There is nothing unprofessional about asking a client to be more specific in the request, with the goal of providing the correct answer/product in the first go.
– JoSSte
Oct 1 '15 at 11:00
2
One thing to note - you're saying he can't provide requirements well, then talk about his unclear specifications. You may find that you get better results by forgetting specifications if he's inexperienced, and instead focus on finding out what he actually wants to achieve. You will get far more kudos for really drilling down into what the stakeholder wants the end result to be and then producing that, rather than trying to force them to produce specs and then blindly following them. Ask questions lots of questions, and don't leave until you understand the problem.
– Jon Story
Oct 2 '15 at 14:02
suggest improvements |Â
10
I don't think "mentally challenged" is a good description here, that makes it sounds like he's handicapped, which does not seem to be the case.
– Erik
Oct 1 '15 at 10:32
He does have difficulty writing in correct English and he is not able to grasp basic concepts of his field of expertise... but I will edit the question. Oh. Thanks for editing!
– Monoandale
Oct 1 '15 at 10:57
5
There is nothing unprofessional about asking a client to be more specific in the request, with the goal of providing the correct answer/product in the first go.
– JoSSte
Oct 1 '15 at 11:00
2
One thing to note - you're saying he can't provide requirements well, then talk about his unclear specifications. You may find that you get better results by forgetting specifications if he's inexperienced, and instead focus on finding out what he actually wants to achieve. You will get far more kudos for really drilling down into what the stakeholder wants the end result to be and then producing that, rather than trying to force them to produce specs and then blindly following them. Ask questions lots of questions, and don't leave until you understand the problem.
– Jon Story
Oct 2 '15 at 14:02
10
10
I don't think "mentally challenged" is a good description here, that makes it sounds like he's handicapped, which does not seem to be the case.
– Erik
Oct 1 '15 at 10:32
I don't think "mentally challenged" is a good description here, that makes it sounds like he's handicapped, which does not seem to be the case.
– Erik
Oct 1 '15 at 10:32
He does have difficulty writing in correct English and he is not able to grasp basic concepts of his field of expertise... but I will edit the question. Oh. Thanks for editing!
– Monoandale
Oct 1 '15 at 10:57
He does have difficulty writing in correct English and he is not able to grasp basic concepts of his field of expertise... but I will edit the question. Oh. Thanks for editing!
– Monoandale
Oct 1 '15 at 10:57
5
5
There is nothing unprofessional about asking a client to be more specific in the request, with the goal of providing the correct answer/product in the first go.
– JoSSte
Oct 1 '15 at 11:00
There is nothing unprofessional about asking a client to be more specific in the request, with the goal of providing the correct answer/product in the first go.
– JoSSte
Oct 1 '15 at 11:00
2
2
One thing to note - you're saying he can't provide requirements well, then talk about his unclear specifications. You may find that you get better results by forgetting specifications if he's inexperienced, and instead focus on finding out what he actually wants to achieve. You will get far more kudos for really drilling down into what the stakeholder wants the end result to be and then producing that, rather than trying to force them to produce specs and then blindly following them. Ask questions lots of questions, and don't leave until you understand the problem.
– Jon Story
Oct 2 '15 at 14:02
One thing to note - you're saying he can't provide requirements well, then talk about his unclear specifications. You may find that you get better results by forgetting specifications if he's inexperienced, and instead focus on finding out what he actually wants to achieve. You will get far more kudos for really drilling down into what the stakeholder wants the end result to be and then producing that, rather than trying to force them to produce specs and then blindly following them. Ask questions lots of questions, and don't leave until you understand the problem.
– Jon Story
Oct 2 '15 at 14:02
suggest improvements |Â
4 Answers
4
active
oldest
votes
up vote
14
down vote
accepted
You ask questions. You don't start the work until you understand what the work is, and you find that out by asking questions. If you are given the assignment in person, don't end the meeting until you have asked enough questions. If you are given the assignment in email, reply with your questions or with an email asking for a phone call or meeting to ask questions.
Yes, it's frustrating to have to interview requirements out of people. We have a saying in my company: some clients really need consultants. If they knew precisely what they wanted we would just be typing, right?
So, in your case "I want an excel file showing the comparison between two different softwares" you might ask
- have you chosen the two software packages or is my first step to research and find what packages to consider?
- is this spreadsheet going to be one column for each software package, and then rows with the price, features, and so on? [I would expect a yes here, but it doesn't hurt to ask.]
- have you made a list already of the features you care about, or should I research what the features are?
- when do you need this by?
- if I can't find out some of the information, should I give you the partial spreadsheet, or let you know it will be late?
As time goes by, you may need to ask less questions because you may realize that your boss wants you to figure out how to do these things. Or you may ask less questions because your boss realizes that it's important to give you more detailed instructions. But in the short term, the only fix for incomplete requirements is to ask short, crisp questions (not "I don't understand, can you give me more details" or "I need more requirements than that") until you have the requirements you need.
answered Oct 1 '15 at 12:44
Kate Gregory
104k40230332
2
Totally agree, I have found that one of the biggest differences between senior devs and junior ones is that we don't just accept what was given us as the requirement. We ask detailed questions, send it back if is is incomplete, etc. I can't tell how many times I have seen something fail in QA and the dev say well I just assumed it meant... instead of having asked a clarifying question.
– HLGEM
Oct 1 '15 at 21:14
1
Sometimes I also offer alternative scenarios, Did you want this or this and get him to choose. In the case of the spreadsheet that is undefined, I might offer a set of fields I think might be on it and ask him if anything is missing or did he want to get rd of some of the suggested fields. Understanding your business domain helps tremendously in this.
– HLGEM
Oct 1 '15 at 21:17
5
Please allow me to introduce a note of grace. Many people are Writers and go into programming because they are comfortable with written communication. This manager could well be a Listener, and the only way to get the requirements may be through a conversation. I have worked with several people who literally didn't know what they wanted until I asked them and the words came out of their mouths. You need to work with the clients you have, not the clients you wish you had. Treat Listeners as Listeners.
– Thomas Cox
Oct 1 '15 at 21:19
suggest improvements |Â
up vote
2
down vote
I would propose an explanation along the path of: "a well defined requirement will give you a more precise result".
You could use an analogy if he does not understand. For instance: "If you experience that your car doesn't stop when you hit the brake, and just say to the mechanic "my car doesn't work" - he may just top off the oil, or start looking at the motor/starter, and never get to the brakes.
If you expect a specific result you have to be able to define your requirements. The hard part is to ask the requester to be more specific, especially when it is a manager doing the asking.
Also: you have to remember that the higher you go in the management hierarchy, the more of a bird's eye perspective they tend to have, especially if their background is purely managerial, and no hands-on experience. The connection between a detailed report and a quick overview pie chart or other isn't always obvious to them.
edited Oct 1 '15 at 11:40
Joe Strazzere
223k104653921
answered Oct 1 '15 at 10:46
JoSSte
1293
2
As a boss, I would find that patronizing. Perhaps I expect you to go figure that stuff out. Lecturing me that I need to give you missing information will work out poorly in that case. Further, asking vague people to "be more specific" rarely works because they don't know how to. You have to ask questions that help them do what you want, not just prod them to do what you want.
– Kate Gregory
Oct 1 '15 at 14:27
1
Depending on the person and setting, i would take a different approach, for example, I don't mind appearing stupid, if it gets me the information needed, without escalating the situation. In my specific situation, I have a very informal dialogue with my managers, and clients, and that gives the liberty to be straightforward. I also have no qualms about turning down assignments based on lacking requirement specifications. It's a business risk, and my job description directly states that I have to identify and resolve them.
– JoSSte
Oct 1 '15 at 14:31
suggest improvements |Â
up vote
2
down vote
Your question is regarding a client who does not communicate well, therefore time is spent unnecessarily clarifying and tweaking things.
I don't see whats wrong here, surely the hours spent solving the clients problems are billable? Just bill them for it, and in your bill itemise things like that which could have been avoided.
Either they have so much money they don't care (which is fine)
Or they'll have a hard look at the info they're giving you to save some $$ next time.
In any case usually they wouldn't be giving you work direct, it should go through your manager first. So any issues you have should be taken up with your own manager.
answered Oct 1 '15 at 19:51
Kilisi
94.7k50216377
1
It's not clear from the question whether the Old Manager still works for the same organization or not. Some organizations and teams will refer to co-workers they do work for as internal clients. So it's not necessarily the case that the Old Manager is an external client they can bill.
– BSMP
Oct 1 '15 at 20:21
1
good point, but even internal jobs are usually billed internally aren't they? Everywhere I have worked people need to account for their time usually on some sort of job tracking. Makes no difference if it's time gathering info, or time spent more productively. The manager then looks at the job tracking and analyses it from there, not the worker...
– Kilisi
Oct 1 '15 at 20:35
2
but even internal jobs are usually billed internally aren't they? - Yes, though where I've worked it's referred to as non-billable time and you're supposed to make sure at least X% of your time is spent on billable work. I think your edit addresses this though. The OP should go to their manager if doing tasks for Old Manager means spending too much time on non-billable work.
– BSMP
Oct 1 '15 at 21:00
suggest improvements |Â
up vote
2
down vote
If you have specific questions and the time for the client to answer them, just ask. You will never get perfect specs. One technique I've used is to do a very small sample of a project and send it to the client. They usually have a better idea of what they want when they have something in their hands and can say, "I like this, I don't like that and add some other thing."
Also, this all needs to be done in the context of when they want it finished. Everyone needs to have an understanding of how much time and energy they can put into something. If the specs are vague and the time is short, they're just going to have to accept my professional judgement and doing the best I can.
suggest improvements |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
14
down vote
accepted
You ask questions. You don't start the work until you understand what the work is, and you find that out by asking questions. If you are given the assignment in person, don't end the meeting until you have asked enough questions. If you are given the assignment in email, reply with your questions or with an email asking for a phone call or meeting to ask questions.
Yes, it's frustrating to have to interview requirements out of people. We have a saying in my company: some clients really need consultants. If they knew precisely what they wanted we would just be typing, right?
So, in your case "I want an excel file showing the comparison between two different softwares" you might ask
- have you chosen the two software packages or is my first step to research and find what packages to consider?
- is this spreadsheet going to be one column for each software package, and then rows with the price, features, and so on? [I would expect a yes here, but it doesn't hurt to ask.]
- have you made a list already of the features you care about, or should I research what the features are?
- when do you need this by?
- if I can't find out some of the information, should I give you the partial spreadsheet, or let you know it will be late?
As time goes by, you may need to ask less questions because you may realize that your boss wants you to figure out how to do these things. Or you may ask less questions because your boss realizes that it's important to give you more detailed instructions. But in the short term, the only fix for incomplete requirements is to ask short, crisp questions (not "I don't understand, can you give me more details" or "I need more requirements than that") until you have the requirements you need.
answered Oct 1 '15 at 12:44
Kate Gregory
104k40230332
2
Totally agree, I have found that one of the biggest differences between senior devs and junior ones is that we don't just accept what was given us as the requirement. We ask detailed questions, send it back if is is incomplete, etc. I can't tell how many times I have seen something fail in QA and the dev say well I just assumed it meant... instead of having asked a clarifying question.
– HLGEM
Oct 1 '15 at 21:14
1
Sometimes I also offer alternative scenarios, Did you want this or this and get him to choose. In the case of the spreadsheet that is undefined, I might offer a set of fields I think might be on it and ask him if anything is missing or did he want to get rd of some of the suggested fields. Understanding your business domain helps tremendously in this.
– HLGEM
Oct 1 '15 at 21:17
5
Please allow me to introduce a note of grace. Many people are Writers and go into programming because they are comfortable with written communication. This manager could well be a Listener, and the only way to get the requirements may be through a conversation. I have worked with several people who literally didn't know what they wanted until I asked them and the words came out of their mouths. You need to work with the clients you have, not the clients you wish you had. Treat Listeners as Listeners.
– Thomas Cox
Oct 1 '15 at 21:19
suggest improvements |Â
up vote
14
down vote
accepted
You ask questions. You don't start the work until you understand what the work is, and you find that out by asking questions. If you are given the assignment in person, don't end the meeting until you have asked enough questions. If you are given the assignment in email, reply with your questions or with an email asking for a phone call or meeting to ask questions.
Yes, it's frustrating to have to interview requirements out of people. We have a saying in my company: some clients really need consultants. If they knew precisely what they wanted we would just be typing, right?
So, in your case "I want an excel file showing the comparison between two different softwares" you might ask
- have you chosen the two software packages or is my first step to research and find what packages to consider?
- is this spreadsheet going to be one column for each software package, and then rows with the price, features, and so on? [I would expect a yes here, but it doesn't hurt to ask.]
- have you made a list already of the features you care about, or should I research what the features are?
- when do you need this by?
- if I can't find out some of the information, should I give you the partial spreadsheet, or let you know it will be late?
As time goes by, you may need to ask less questions because you may realize that your boss wants you to figure out how to do these things. Or you may ask less questions because your boss realizes that it's important to give you more detailed instructions. But in the short term, the only fix for incomplete requirements is to ask short, crisp questions (not "I don't understand, can you give me more details" or "I need more requirements than that") until you have the requirements you need.
answered Oct 1 '15 at 12:44
Kate Gregory
104k40230332
2
Totally agree, I have found that one of the biggest differences between senior devs and junior ones is that we don't just accept what was given us as the requirement. We ask detailed questions, send it back if is is incomplete, etc. I can't tell how many times I have seen something fail in QA and the dev say well I just assumed it meant... instead of having asked a clarifying question.
– HLGEM
Oct 1 '15 at 21:14
1
Sometimes I also offer alternative scenarios, Did you want this or this and get him to choose. In the case of the spreadsheet that is undefined, I might offer a set of fields I think might be on it and ask him if anything is missing or did he want to get rd of some of the suggested fields. Understanding your business domain helps tremendously in this.
– HLGEM
Oct 1 '15 at 21:17
5
Please allow me to introduce a note of grace. Many people are Writers and go into programming because they are comfortable with written communication. This manager could well be a Listener, and the only way to get the requirements may be through a conversation. I have worked with several people who literally didn't know what they wanted until I asked them and the words came out of their mouths. You need to work with the clients you have, not the clients you wish you had. Treat Listeners as Listeners.
– Thomas Cox
Oct 1 '15 at 21:19
suggest improvements |Â
up vote
14
down vote
accepted
up vote
14
down vote
accepted
You ask questions. You don't start the work until you understand what the work is, and you find that out by asking questions. If you are given the assignment in person, don't end the meeting until you have asked enough questions. If you are given the assignment in email, reply with your questions or with an email asking for a phone call or meeting to ask questions.
Yes, it's frustrating to have to interview requirements out of people. We have a saying in my company: some clients really need consultants. If they knew precisely what they wanted we would just be typing, right?
So, in your case "I want an excel file showing the comparison between two different softwares" you might ask
- have you chosen the two software packages or is my first step to research and find what packages to consider?
- is this spreadsheet going to be one column for each software package, and then rows with the price, features, and so on? [I would expect a yes here, but it doesn't hurt to ask.]
- have you made a list already of the features you care about, or should I research what the features are?
- when do you need this by?
- if I can't find out some of the information, should I give you the partial spreadsheet, or let you know it will be late?
As time goes by, you may need to ask less questions because you may realize that your boss wants you to figure out how to do these things. Or you may ask less questions because your boss realizes that it's important to give you more detailed instructions. But in the short term, the only fix for incomplete requirements is to ask short, crisp questions (not "I don't understand, can you give me more details" or "I need more requirements than that") until you have the requirements you need.
answered Oct 1 '15 at 12:44
Kate Gregory
104k40230332
You ask questions. You don't start the work until you understand what the work is, and you find that out by asking questions. If you are given the assignment in person, don't end the meeting until you have asked enough questions. If you are given the assignment in email, reply with your questions or with an email asking for a phone call or meeting to ask questions.
Yes, it's frustrating to have to interview requirements out of people. We have a saying in my company: some clients really need consultants. If they knew precisely what they wanted we would just be typing, right?
So, in your case "I want an excel file showing the comparison between two different softwares" you might ask
- have you chosen the two software packages or is my first step to research and find what packages to consider?
- is this spreadsheet going to be one column for each software package, and then rows with the price, features, and so on? [I would expect a yes here, but it doesn't hurt to ask.]
- have you made a list already of the features you care about, or should I research what the features are?
- when do you need this by?
- if I can't find out some of the information, should I give you the partial spreadsheet, or let you know it will be late?
As time goes by, you may need to ask less questions because you may realize that your boss wants you to figure out how to do these things. Or you may ask less questions because your boss realizes that it's important to give you more detailed instructions. But in the short term, the only fix for incomplete requirements is to ask short, crisp questions (not "I don't understand, can you give me more details" or "I need more requirements than that") until you have the requirements you need.
answered Oct 1 '15 at 12:44
Kate Gregory
104k40230332
answered Oct 1 '15 at 12:44
Kate Gregory
104k40230332
answered Oct 1 '15 at 12:44
Kate Gregory
104k40230332
answered Oct 1 '15 at 12:44
Kate Gregory
104k40230332
104k40230332
2
Totally agree, I have found that one of the biggest differences between senior devs and junior ones is that we don't just accept what was given us as the requirement. We ask detailed questions, send it back if is is incomplete, etc. I can't tell how many times I have seen something fail in QA and the dev say well I just assumed it meant... instead of having asked a clarifying question.
– HLGEM
Oct 1 '15 at 21:14
1
Sometimes I also offer alternative scenarios, Did you want this or this and get him to choose. In the case of the spreadsheet that is undefined, I might offer a set of fields I think might be on it and ask him if anything is missing or did he want to get rd of some of the suggested fields. Understanding your business domain helps tremendously in this.
– HLGEM
Oct 1 '15 at 21:17
5
Please allow me to introduce a note of grace. Many people are Writers and go into programming because they are comfortable with written communication. This manager could well be a Listener, and the only way to get the requirements may be through a conversation. I have worked with several people who literally didn't know what they wanted until I asked them and the words came out of their mouths. You need to work with the clients you have, not the clients you wish you had. Treat Listeners as Listeners.
– Thomas Cox
Oct 1 '15 at 21:19
suggest improvements |Â
2
Totally agree, I have found that one of the biggest differences between senior devs and junior ones is that we don't just accept what was given us as the requirement. We ask detailed questions, send it back if is is incomplete, etc. I can't tell how many times I have seen something fail in QA and the dev say well I just assumed it meant... instead of having asked a clarifying question.
– HLGEM
Oct 1 '15 at 21:14
1
Sometimes I also offer alternative scenarios, Did you want this or this and get him to choose. In the case of the spreadsheet that is undefined, I might offer a set of fields I think might be on it and ask him if anything is missing or did he want to get rd of some of the suggested fields. Understanding your business domain helps tremendously in this.
– HLGEM
Oct 1 '15 at 21:17
5
Please allow me to introduce a note of grace. Many people are Writers and go into programming because they are comfortable with written communication. This manager could well be a Listener, and the only way to get the requirements may be through a conversation. I have worked with several people who literally didn't know what they wanted until I asked them and the words came out of their mouths. You need to work with the clients you have, not the clients you wish you had. Treat Listeners as Listeners.
– Thomas Cox
Oct 1 '15 at 21:19
2
2
Totally agree, I have found that one of the biggest differences between senior devs and junior ones is that we don't just accept what was given us as the requirement. We ask detailed questions, send it back if is is incomplete, etc. I can't tell how many times I have seen something fail in QA and the dev say well I just assumed it meant... instead of having asked a clarifying question.
– HLGEM
Oct 1 '15 at 21:14
Totally agree, I have found that one of the biggest differences between senior devs and junior ones is that we don't just accept what was given us as the requirement. We ask detailed questions, send it back if is is incomplete, etc. I can't tell how many times I have seen something fail in QA and the dev say well I just assumed it meant... instead of having asked a clarifying question.
– HLGEM
Oct 1 '15 at 21:14
1
1
Sometimes I also offer alternative scenarios, Did you want this or this and get him to choose. In the case of the spreadsheet that is undefined, I might offer a set of fields I think might be on it and ask him if anything is missing or did he want to get rd of some of the suggested fields. Understanding your business domain helps tremendously in this.
– HLGEM
Oct 1 '15 at 21:17
Sometimes I also offer alternative scenarios, Did you want this or this and get him to choose. In the case of the spreadsheet that is undefined, I might offer a set of fields I think might be on it and ask him if anything is missing or did he want to get rd of some of the suggested fields. Understanding your business domain helps tremendously in this.
– HLGEM
Oct 1 '15 at 21:17
5
5
Please allow me to introduce a note of grace. Many people are Writers and go into programming because they are comfortable with written communication. This manager could well be a Listener, and the only way to get the requirements may be through a conversation. I have worked with several people who literally didn't know what they wanted until I asked them and the words came out of their mouths. You need to work with the clients you have, not the clients you wish you had. Treat Listeners as Listeners.
– Thomas Cox
Oct 1 '15 at 21:19
Please allow me to introduce a note of grace. Many people are Writers and go into programming because they are comfortable with written communication. This manager could well be a Listener, and the only way to get the requirements may be through a conversation. I have worked with several people who literally didn't know what they wanted until I asked them and the words came out of their mouths. You need to work with the clients you have, not the clients you wish you had. Treat Listeners as Listeners.
– Thomas Cox
Oct 1 '15 at 21:19
suggest improvements |Â
up vote
2
down vote
I would propose an explanation along the path of: "a well defined requirement will give you a more precise result".
You could use an analogy if he does not understand. For instance: "If you experience that your car doesn't stop when you hit the brake, and just say to the mechanic "my car doesn't work" - he may just top off the oil, or start looking at the motor/starter, and never get to the brakes.
If you expect a specific result you have to be able to define your requirements. The hard part is to ask the requester to be more specific, especially when it is a manager doing the asking.
Also: you have to remember that the higher you go in the management hierarchy, the more of a bird's eye perspective they tend to have, especially if their background is purely managerial, and no hands-on experience. The connection between a detailed report and a quick overview pie chart or other isn't always obvious to them.
edited Oct 1 '15 at 11:40
Joe Strazzere
223k104653921
answered Oct 1 '15 at 10:46
JoSSte
1293
2
As a boss, I would find that patronizing. Perhaps I expect you to go figure that stuff out. Lecturing me that I need to give you missing information will work out poorly in that case. Further, asking vague people to "be more specific" rarely works because they don't know how to. You have to ask questions that help them do what you want, not just prod them to do what you want.
– Kate Gregory
Oct 1 '15 at 14:27
1
Depending on the person and setting, i would take a different approach, for example, I don't mind appearing stupid, if it gets me the information needed, without escalating the situation. In my specific situation, I have a very informal dialogue with my managers, and clients, and that gives the liberty to be straightforward. I also have no qualms about turning down assignments based on lacking requirement specifications. It's a business risk, and my job description directly states that I have to identify and resolve them.
– JoSSte
Oct 1 '15 at 14:31
suggest improvements |Â
up vote
2
down vote
I would propose an explanation along the path of: "a well defined requirement will give you a more precise result".
You could use an analogy if he does not understand. For instance: "If you experience that your car doesn't stop when you hit the brake, and just say to the mechanic "my car doesn't work" - he may just top off the oil, or start looking at the motor/starter, and never get to the brakes.
If you expect a specific result you have to be able to define your requirements. The hard part is to ask the requester to be more specific, especially when it is a manager doing the asking.
Also: you have to remember that the higher you go in the management hierarchy, the more of a bird's eye perspective they tend to have, especially if their background is purely managerial, and no hands-on experience. The connection between a detailed report and a quick overview pie chart or other isn't always obvious to them.
edited Oct 1 '15 at 11:40
Joe Strazzere
223k104653921
answered Oct 1 '15 at 10:46
JoSSte
1293
2
As a boss, I would find that patronizing. Perhaps I expect you to go figure that stuff out. Lecturing me that I need to give you missing information will work out poorly in that case. Further, asking vague people to "be more specific" rarely works because they don't know how to. You have to ask questions that help them do what you want, not just prod them to do what you want.
– Kate Gregory
Oct 1 '15 at 14:27
1
Depending on the person and setting, i would take a different approach, for example, I don't mind appearing stupid, if it gets me the information needed, without escalating the situation. In my specific situation, I have a very informal dialogue with my managers, and clients, and that gives the liberty to be straightforward. I also have no qualms about turning down assignments based on lacking requirement specifications. It's a business risk, and my job description directly states that I have to identify and resolve them.
– JoSSte
Oct 1 '15 at 14:31
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
I would propose an explanation along the path of: "a well defined requirement will give you a more precise result".
You could use an analogy if he does not understand. For instance: "If you experience that your car doesn't stop when you hit the brake, and just say to the mechanic "my car doesn't work" - he may just top off the oil, or start looking at the motor/starter, and never get to the brakes.
If you expect a specific result you have to be able to define your requirements. The hard part is to ask the requester to be more specific, especially when it is a manager doing the asking.
Also: you have to remember that the higher you go in the management hierarchy, the more of a bird's eye perspective they tend to have, especially if their background is purely managerial, and no hands-on experience. The connection between a detailed report and a quick overview pie chart or other isn't always obvious to them.
edited Oct 1 '15 at 11:40
Joe Strazzere
223k104653921
answered Oct 1 '15 at 10:46
JoSSte
1293
I would propose an explanation along the path of: "a well defined requirement will give you a more precise result".
You could use an analogy if he does not understand. For instance: "If you experience that your car doesn't stop when you hit the brake, and just say to the mechanic "my car doesn't work" - he may just top off the oil, or start looking at the motor/starter, and never get to the brakes.
If you expect a specific result you have to be able to define your requirements. The hard part is to ask the requester to be more specific, especially when it is a manager doing the asking.
Also: you have to remember that the higher you go in the management hierarchy, the more of a bird's eye perspective they tend to have, especially if their background is purely managerial, and no hands-on experience. The connection between a detailed report and a quick overview pie chart or other isn't always obvious to them.
edited Oct 1 '15 at 11:40
Joe Strazzere
223k104653921
answered Oct 1 '15 at 10:46
JoSSte
1293
edited Oct 1 '15 at 11:40
Joe Strazzere
223k104653921
edited Oct 1 '15 at 11:40
Joe Strazzere
223k104653921
edited Oct 1 '15 at 11:40
Joe Strazzere
223k104653921
223k104653921
answered Oct 1 '15 at 10:46
JoSSte
1293
answered Oct 1 '15 at 10:46
JoSSte
1293
answered Oct 1 '15 at 10:46
JoSSte
1293
1293
2
As a boss, I would find that patronizing. Perhaps I expect you to go figure that stuff out. Lecturing me that I need to give you missing information will work out poorly in that case. Further, asking vague people to "be more specific" rarely works because they don't know how to. You have to ask questions that help them do what you want, not just prod them to do what you want.
– Kate Gregory
Oct 1 '15 at 14:27
1
Depending on the person and setting, i would take a different approach, for example, I don't mind appearing stupid, if it gets me the information needed, without escalating the situation. In my specific situation, I have a very informal dialogue with my managers, and clients, and that gives the liberty to be straightforward. I also have no qualms about turning down assignments based on lacking requirement specifications. It's a business risk, and my job description directly states that I have to identify and resolve them.
– JoSSte
Oct 1 '15 at 14:31
suggest improvements |Â
2
As a boss, I would find that patronizing. Perhaps I expect you to go figure that stuff out. Lecturing me that I need to give you missing information will work out poorly in that case. Further, asking vague people to "be more specific" rarely works because they don't know how to. You have to ask questions that help them do what you want, not just prod them to do what you want.
– Kate Gregory
Oct 1 '15 at 14:27
1
Depending on the person and setting, i would take a different approach, for example, I don't mind appearing stupid, if it gets me the information needed, without escalating the situation. In my specific situation, I have a very informal dialogue with my managers, and clients, and that gives the liberty to be straightforward. I also have no qualms about turning down assignments based on lacking requirement specifications. It's a business risk, and my job description directly states that I have to identify and resolve them.
– JoSSte
Oct 1 '15 at 14:31
2
2
As a boss, I would find that patronizing. Perhaps I expect you to go figure that stuff out. Lecturing me that I need to give you missing information will work out poorly in that case. Further, asking vague people to "be more specific" rarely works because they don't know how to. You have to ask questions that help them do what you want, not just prod them to do what you want.
– Kate Gregory
Oct 1 '15 at 14:27
As a boss, I would find that patronizing. Perhaps I expect you to go figure that stuff out. Lecturing me that I need to give you missing information will work out poorly in that case. Further, asking vague people to "be more specific" rarely works because they don't know how to. You have to ask questions that help them do what you want, not just prod them to do what you want.
– Kate Gregory
Oct 1 '15 at 14:27
1
1
Depending on the person and setting, i would take a different approach, for example, I don't mind appearing stupid, if it gets me the information needed, without escalating the situation. In my specific situation, I have a very informal dialogue with my managers, and clients, and that gives the liberty to be straightforward. I also have no qualms about turning down assignments based on lacking requirement specifications. It's a business risk, and my job description directly states that I have to identify and resolve them.
– JoSSte
Oct 1 '15 at 14:31
Depending on the person and setting, i would take a different approach, for example, I don't mind appearing stupid, if it gets me the information needed, without escalating the situation. In my specific situation, I have a very informal dialogue with my managers, and clients, and that gives the liberty to be straightforward. I also have no qualms about turning down assignments based on lacking requirement specifications. It's a business risk, and my job description directly states that I have to identify and resolve them.
– JoSSte
Oct 1 '15 at 14:31
suggest improvements |Â
up vote
2
down vote
Your question is regarding a client who does not communicate well, therefore time is spent unnecessarily clarifying and tweaking things.
I don't see whats wrong here, surely the hours spent solving the clients problems are billable? Just bill them for it, and in your bill itemise things like that which could have been avoided.
Either they have so much money they don't care (which is fine)
Or they'll have a hard look at the info they're giving you to save some $$ next time.
In any case usually they wouldn't be giving you work direct, it should go through your manager first. So any issues you have should be taken up with your own manager.
answered Oct 1 '15 at 19:51
Kilisi
94.7k50216377
1
It's not clear from the question whether the Old Manager still works for the same organization or not. Some organizations and teams will refer to co-workers they do work for as internal clients. So it's not necessarily the case that the Old Manager is an external client they can bill.
– BSMP
Oct 1 '15 at 20:21
1
good point, but even internal jobs are usually billed internally aren't they? Everywhere I have worked people need to account for their time usually on some sort of job tracking. Makes no difference if it's time gathering info, or time spent more productively. The manager then looks at the job tracking and analyses it from there, not the worker...
– Kilisi
Oct 1 '15 at 20:35
2
but even internal jobs are usually billed internally aren't they? - Yes, though where I've worked it's referred to as non-billable time and you're supposed to make sure at least X% of your time is spent on billable work. I think your edit addresses this though. The OP should go to their manager if doing tasks for Old Manager means spending too much time on non-billable work.
– BSMP
Oct 1 '15 at 21:00
suggest improvements |Â
up vote
2
down vote
Your question is regarding a client who does not communicate well, therefore time is spent unnecessarily clarifying and tweaking things.
I don't see whats wrong here, surely the hours spent solving the clients problems are billable? Just bill them for it, and in your bill itemise things like that which could have been avoided.
Either they have so much money they don't care (which is fine)
Or they'll have a hard look at the info they're giving you to save some $$ next time.
In any case usually they wouldn't be giving you work direct, it should go through your manager first. So any issues you have should be taken up with your own manager.
answered Oct 1 '15 at 19:51
Kilisi
94.7k50216377
1
It's not clear from the question whether the Old Manager still works for the same organization or not. Some organizations and teams will refer to co-workers they do work for as internal clients. So it's not necessarily the case that the Old Manager is an external client they can bill.
– BSMP
Oct 1 '15 at 20:21
1
good point, but even internal jobs are usually billed internally aren't they? Everywhere I have worked people need to account for their time usually on some sort of job tracking. Makes no difference if it's time gathering info, or time spent more productively. The manager then looks at the job tracking and analyses it from there, not the worker...
– Kilisi
Oct 1 '15 at 20:35
2
but even internal jobs are usually billed internally aren't they? - Yes, though where I've worked it's referred to as non-billable time and you're supposed to make sure at least X% of your time is spent on billable work. I think your edit addresses this though. The OP should go to their manager if doing tasks for Old Manager means spending too much time on non-billable work.
– BSMP
Oct 1 '15 at 21:00
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
Your question is regarding a client who does not communicate well, therefore time is spent unnecessarily clarifying and tweaking things.
I don't see whats wrong here, surely the hours spent solving the clients problems are billable? Just bill them for it, and in your bill itemise things like that which could have been avoided.
Either they have so much money they don't care (which is fine)
Or they'll have a hard look at the info they're giving you to save some $$ next time.
In any case usually they wouldn't be giving you work direct, it should go through your manager first. So any issues you have should be taken up with your own manager.
answered Oct 1 '15 at 19:51
Kilisi
94.7k50216377
Your question is regarding a client who does not communicate well, therefore time is spent unnecessarily clarifying and tweaking things.
I don't see whats wrong here, surely the hours spent solving the clients problems are billable? Just bill them for it, and in your bill itemise things like that which could have been avoided.
Either they have so much money they don't care (which is fine)
Or they'll have a hard look at the info they're giving you to save some $$ next time.
In any case usually they wouldn't be giving you work direct, it should go through your manager first. So any issues you have should be taken up with your own manager.
answered Oct 1 '15 at 19:51
Kilisi
94.7k50216377
edited Oct 1 '15 at 20:56
answered Oct 1 '15 at 19:51
Kilisi
94.7k50216377
answered Oct 1 '15 at 19:51
Kilisi
94.7k50216377
answered Oct 1 '15 at 19:51
Kilisi
94.7k50216377
94.7k50216377
1
It's not clear from the question whether the Old Manager still works for the same organization or not. Some organizations and teams will refer to co-workers they do work for as internal clients. So it's not necessarily the case that the Old Manager is an external client they can bill.
– BSMP
Oct 1 '15 at 20:21
1
good point, but even internal jobs are usually billed internally aren't they? Everywhere I have worked people need to account for their time usually on some sort of job tracking. Makes no difference if it's time gathering info, or time spent more productively. The manager then looks at the job tracking and analyses it from there, not the worker...
– Kilisi
Oct 1 '15 at 20:35
2
but even internal jobs are usually billed internally aren't they? - Yes, though where I've worked it's referred to as non-billable time and you're supposed to make sure at least X% of your time is spent on billable work. I think your edit addresses this though. The OP should go to their manager if doing tasks for Old Manager means spending too much time on non-billable work.
– BSMP
Oct 1 '15 at 21:00
suggest improvements |Â
1
It's not clear from the question whether the Old Manager still works for the same organization or not. Some organizations and teams will refer to co-workers they do work for as internal clients. So it's not necessarily the case that the Old Manager is an external client they can bill.
– BSMP
Oct 1 '15 at 20:21
1
good point, but even internal jobs are usually billed internally aren't they? Everywhere I have worked people need to account for their time usually on some sort of job tracking. Makes no difference if it's time gathering info, or time spent more productively. The manager then looks at the job tracking and analyses it from there, not the worker...
– Kilisi
Oct 1 '15 at 20:35
2
but even internal jobs are usually billed internally aren't they? - Yes, though where I've worked it's referred to as non-billable time and you're supposed to make sure at least X% of your time is spent on billable work. I think your edit addresses this though. The OP should go to their manager if doing tasks for Old Manager means spending too much time on non-billable work.
– BSMP
Oct 1 '15 at 21:00
1
1
It's not clear from the question whether the Old Manager still works for the same organization or not. Some organizations and teams will refer to co-workers they do work for as internal clients. So it's not necessarily the case that the Old Manager is an external client they can bill.
– BSMP
Oct 1 '15 at 20:21
It's not clear from the question whether the Old Manager still works for the same organization or not. Some organizations and teams will refer to co-workers they do work for as internal clients. So it's not necessarily the case that the Old Manager is an external client they can bill.
– BSMP
Oct 1 '15 at 20:21
1
1
good point, but even internal jobs are usually billed internally aren't they? Everywhere I have worked people need to account for their time usually on some sort of job tracking. Makes no difference if it's time gathering info, or time spent more productively. The manager then looks at the job tracking and analyses it from there, not the worker...
– Kilisi
Oct 1 '15 at 20:35
good point, but even internal jobs are usually billed internally aren't they? Everywhere I have worked people need to account for their time usually on some sort of job tracking. Makes no difference if it's time gathering info, or time spent more productively. The manager then looks at the job tracking and analyses it from there, not the worker...
– Kilisi
Oct 1 '15 at 20:35
2
2
but even internal jobs are usually billed internally aren't they? - Yes, though where I've worked it's referred to as non-billable time and you're supposed to make sure at least X% of your time is spent on billable work. I think your edit addresses this though. The OP should go to their manager if doing tasks for Old Manager means spending too much time on non-billable work.
– BSMP
Oct 1 '15 at 21:00
but even internal jobs are usually billed internally aren't they? - Yes, though where I've worked it's referred to as non-billable time and you're supposed to make sure at least X% of your time is spent on billable work. I think your edit addresses this though. The OP should go to their manager if doing tasks for Old Manager means spending too much time on non-billable work.
– BSMP
Oct 1 '15 at 21:00
suggest improvements |Â
up vote
2
down vote
If you have specific questions and the time for the client to answer them, just ask. You will never get perfect specs. One technique I've used is to do a very small sample of a project and send it to the client. They usually have a better idea of what they want when they have something in their hands and can say, "I like this, I don't like that and add some other thing."
Also, this all needs to be done in the context of when they want it finished. Everyone needs to have an understanding of how much time and energy they can put into something. If the specs are vague and the time is short, they're just going to have to accept my professional judgement and doing the best I can.
suggest improvements |Â
up vote
2
down vote
If you have specific questions and the time for the client to answer them, just ask. You will never get perfect specs. One technique I've used is to do a very small sample of a project and send it to the client. They usually have a better idea of what they want when they have something in their hands and can say, "I like this, I don't like that and add some other thing."
Also, this all needs to be done in the context of when they want it finished. Everyone needs to have an understanding of how much time and energy they can put into something. If the specs are vague and the time is short, they're just going to have to accept my professional judgement and doing the best I can.
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
If you have specific questions and the time for the client to answer them, just ask. You will never get perfect specs. One technique I've used is to do a very small sample of a project and send it to the client. They usually have a better idea of what they want when they have something in their hands and can say, "I like this, I don't like that and add some other thing."
Also, this all needs to be done in the context of when they want it finished. Everyone needs to have an understanding of how much time and energy they can put into something. If the specs are vague and the time is short, they're just going to have to accept my professional judgement and doing the best I can.
If you have specific questions and the time for the client to answer them, just ask. You will never get perfect specs. One technique I've used is to do a very small sample of a project and send it to the client. They usually have a better idea of what they want when they have something in their hands and can say, "I like this, I don't like that and add some other thing."
Also, this all needs to be done in the context of when they want it finished. Everyone needs to have an understanding of how much time and energy they can put into something. If the specs are vague and the time is short, they're just going to have to accept my professional judgement and doing the best I can.
answered Oct 2 '15 at 13:54
user8365
suggest improvements |Â
suggest improvements |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f55265%2fhow-to-handle-communication-with-client-who-cannot-convey-requirements-well%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
10
I don't think "mentally challenged" is a good description here, that makes it sounds like he's handicapped, which does not seem to be the case.
– Erik
Oct 1 '15 at 10:32
He does have difficulty writing in correct English and he is not able to grasp basic concepts of his field of expertise... but I will edit the question. Oh. Thanks for editing!
– Monoandale
Oct 1 '15 at 10:57
5
There is nothing unprofessional about asking a client to be more specific in the request, with the goal of providing the correct answer/product in the first go.
– JoSSte
Oct 1 '15 at 11:00
2
One thing to note - you're saying he can't provide requirements well, then talk about his unclear specifications. You may find that you get better results by forgetting specifications if he's inexperienced, and instead focus on finding out what he actually wants to achieve. You will get far more kudos for really drilling down into what the stakeholder wants the end result to be and then producing that, rather than trying to force them to produce specs and then blindly following them. Ask questions lots of questions, and don't leave until you understand the problem.
– Jon Story
Oct 2 '15 at 14:02