Mixing
How to explain business people that their feature request is infeasible [closed]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
12
down vote
favorite
In my role some time I sit with business & operations people (people those directly connect with customers) to discuss new feature or some modifications, these people are mostly non technical and don’t know anything about the system and its internal process.
Some time they give very valuable suggestion and their insight about the system but some time they request for very odd feature which I think is having very little use to end user and is very hard to implement.
I cannot explain my technical difficulty because they are not going to understand it.
how can I convince them there request are infeasible?
software-industry professionalism communication
asked Nov 27 '12 at 5:38
Buzz
24238
closed as off topic by IDrinkandIKnowThings, bethlakshmi, yoozer8, squeemish, user1220 Nov 27 '12 at 20:59
Questions on The Workplace Stack Exchange are expected to relate to the workplace within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here. If this question can be reworded to fit the rules in the help center, please edit the question.
 |Â
show 7 more comments
up vote
12
down vote
favorite
In my role some time I sit with business & operations people (people those directly connect with customers) to discuss new feature or some modifications, these people are mostly non technical and don’t know anything about the system and its internal process.
Some time they give very valuable suggestion and their insight about the system but some time they request for very odd feature which I think is having very little use to end user and is very hard to implement.
I cannot explain my technical difficulty because they are not going to understand it.
how can I convince them there request are infeasible?
software-industry professionalism communication
asked Nov 27 '12 at 5:38
Buzz
24238
closed as off topic by IDrinkandIKnowThings, bethlakshmi, yoozer8, squeemish, user1220 Nov 27 '12 at 20:59
Questions on The Workplace Stack Exchange are expected to relate to the workplace within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here. If this question can be reworded to fit the rules in the help center, please edit the question.
3
I'd recommend this for moderator migration - user experience or stack overflow might work - but I second @Chad - this is a standard problem in computer science, not a workplace question.
– bethlakshmi
Nov 27 '12 at 15:32
3
"...I think is having very little use to end user..." - If they are the end user, they know better than you. You should just look at all their requests and provide appropriate estimates (even if they are crazy amounts of work), then let them decide what's worth keeping and what's not.
– MrFox
Nov 27 '12 at 16:53
1
i m confused why this is offtopic?,if does not belong here them may be fit at programmers.stackexchange.com
– Buzz
Nov 28 '12 at 4:30
1
@With editing, this could be made into a generic question faced by many people in the workplace; how to manage "outside" suggestions for 'obvious, simple' changes to a system, process, tool - that, because the outside person lacks the full picture, have huge hidden cost/time/priority implications.
– GuyM
Nov 29 '12 at 19:05
2
This is an issue about workplace communications. It's on-topic.
– Euan M
Nov 30 '15 at 19:07
 |Â
show 7 more comments
up vote
12
down vote
favorite
up vote
12
down vote
favorite
In my role some time I sit with business & operations people (people those directly connect with customers) to discuss new feature or some modifications, these people are mostly non technical and don’t know anything about the system and its internal process.
Some time they give very valuable suggestion and their insight about the system but some time they request for very odd feature which I think is having very little use to end user and is very hard to implement.
I cannot explain my technical difficulty because they are not going to understand it.
how can I convince them there request are infeasible?
software-industry professionalism communication
asked Nov 27 '12 at 5:38
Buzz
24238
In my role some time I sit with business & operations people (people those directly connect with customers) to discuss new feature or some modifications, these people are mostly non technical and don’t know anything about the system and its internal process.
Some time they give very valuable suggestion and their insight about the system but some time they request for very odd feature which I think is having very little use to end user and is very hard to implement.
I cannot explain my technical difficulty because they are not going to understand it.
how can I convince them there request are infeasible?
software-industry professionalism communication
asked Nov 27 '12 at 5:38
Buzz
24238
asked Nov 27 '12 at 5:38
Buzz
24238
asked Nov 27 '12 at 5:38
Buzz
24238
asked Nov 27 '12 at 5:38
Buzz
24238
24238
closed as off topic by IDrinkandIKnowThings, bethlakshmi, yoozer8, squeemish, user1220 Nov 27 '12 at 20:59
Questions on The Workplace Stack Exchange are expected to relate to the workplace within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as off topic by IDrinkandIKnowThings, bethlakshmi, yoozer8, squeemish, user1220 Nov 27 '12 at 20:59
Questions on The Workplace Stack Exchange are expected to relate to the workplace within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here. If this question can be reworded to fit the rules in the help center, please edit the question.
3
I'd recommend this for moderator migration - user experience or stack overflow might work - but I second @Chad - this is a standard problem in computer science, not a workplace question.
– bethlakshmi
Nov 27 '12 at 15:32
3
"...I think is having very little use to end user..." - If they are the end user, they know better than you. You should just look at all their requests and provide appropriate estimates (even if they are crazy amounts of work), then let them decide what's worth keeping and what's not.
– MrFox
Nov 27 '12 at 16:53
1
i m confused why this is offtopic?,if does not belong here them may be fit at programmers.stackexchange.com
– Buzz
Nov 28 '12 at 4:30
1
@With editing, this could be made into a generic question faced by many people in the workplace; how to manage "outside" suggestions for 'obvious, simple' changes to a system, process, tool - that, because the outside person lacks the full picture, have huge hidden cost/time/priority implications.
– GuyM
Nov 29 '12 at 19:05
2
This is an issue about workplace communications. It's on-topic.
– Euan M
Nov 30 '15 at 19:07
 |Â
show 7 more comments
3
I'd recommend this for moderator migration - user experience or stack overflow might work - but I second @Chad - this is a standard problem in computer science, not a workplace question.
– bethlakshmi
Nov 27 '12 at 15:32
3
"...I think is having very little use to end user..." - If they are the end user, they know better than you. You should just look at all their requests and provide appropriate estimates (even if they are crazy amounts of work), then let them decide what's worth keeping and what's not.
– MrFox
Nov 27 '12 at 16:53
1
i m confused why this is offtopic?,if does not belong here them may be fit at programmers.stackexchange.com
– Buzz
Nov 28 '12 at 4:30
1
@With editing, this could be made into a generic question faced by many people in the workplace; how to manage "outside" suggestions for 'obvious, simple' changes to a system, process, tool - that, because the outside person lacks the full picture, have huge hidden cost/time/priority implications.
– GuyM
Nov 29 '12 at 19:05
2
This is an issue about workplace communications. It's on-topic.
– Euan M
Nov 30 '15 at 19:07
3
3
I'd recommend this for moderator migration - user experience or stack overflow might work - but I second @Chad - this is a standard problem in computer science, not a workplace question.
– bethlakshmi
Nov 27 '12 at 15:32
I'd recommend this for moderator migration - user experience or stack overflow might work - but I second @Chad - this is a standard problem in computer science, not a workplace question.
– bethlakshmi
Nov 27 '12 at 15:32
3
3
"...I think is having very little use to end user..." - If they are the end user, they know better than you. You should just look at all their requests and provide appropriate estimates (even if they are crazy amounts of work), then let them decide what's worth keeping and what's not.
– MrFox
Nov 27 '12 at 16:53
"...I think is having very little use to end user..." - If they are the end user, they know better than you. You should just look at all their requests and provide appropriate estimates (even if they are crazy amounts of work), then let them decide what's worth keeping and what's not.
– MrFox
Nov 27 '12 at 16:53
1
1
i m confused why this is offtopic?,if does not belong here them may be fit at programmers.stackexchange.com
– Buzz
Nov 28 '12 at 4:30
i m confused why this is offtopic?,if does not belong here them may be fit at programmers.stackexchange.com
– Buzz
Nov 28 '12 at 4:30
1
1
@With editing, this could be made into a generic question faced by many people in the workplace; how to manage "outside" suggestions for 'obvious, simple' changes to a system, process, tool - that, because the outside person lacks the full picture, have huge hidden cost/time/priority implications.
– GuyM
Nov 29 '12 at 19:05
@With editing, this could be made into a generic question faced by many people in the workplace; how to manage "outside" suggestions for 'obvious, simple' changes to a system, process, tool - that, because the outside person lacks the full picture, have huge hidden cost/time/priority implications.
– GuyM
Nov 29 '12 at 19:05
2
2
This is an issue about workplace communications. It's on-topic.
– Euan M
Nov 30 '15 at 19:07
This is an issue about workplace communications. It's on-topic.
– Euan M
Nov 30 '15 at 19:07
 |Â
show 7 more comments
6 Answers
6
active
oldest
votes
up vote
25
down vote
accepted
You may want to start the conversation by asking clarifications on the requirements in order to better understand them. This will help put the business person at ease rather than appear confrontational. Asking why they need the requirement in the first place shows interest and willingness to satisfy the needs of the end user.
Then, you can explain that nothing is really unfeasible as long as you apply enough time and resources to the problem. Therefore, you can provide an exploratory estimate of how long it would take for you to implement the requirements. They, in turn, will ask questions about the estimates and why they are so high.
You can also ask the business person, what part of the requirements they would like to implement first. This will help them, and you, understand what is the most important piece and that part may end up being feasible.
In general I try to stay unemotional and focus my attention on understanding the need, decomposing in different parts, and estimating the time it will take to implement each part.
answered Nov 27 '12 at 6:58
David S.
3,9902441
11
+1 Let them make the decision as to how much they want to pay for a feature - it's a business decision, not a developer decision.
– Phil
Nov 27 '12 at 14:43
good points David
– Buzz
Nov 28 '12 at 4:32
1
"...nothing is really unfeasible as long as you apply enough time and resources to the problem." In addition to being false, this is dangerous, as you put yourself in a situation where the client may ask for something that really is technically unrealistic after you've given them the impression that you can do anything given enough time/money/etc. It's hard to explain technical limitations to non-technical people, but that doesn't mean you should be dishonest when a client requests something that simply isn't possible.
– kungphu
Nov 8 '16 at 2:15
add a comment |Â
up vote
15
down vote
You don't have to explain the technical details to them, but you do need to give them an understanding as to the challenges you will face in trying to implement it. One thing you always need to keep in mind (and I've been a developer for almost 30 years) is that the business and operations people are experts in their business and the company operations. I've come across too many technical people in my travels who lose sight of the fact that, although the people they have deal with on a daily basis know very little about computers and software development, they know far more about business and corporate operations than they do. The developer has to approach the problem with the eye of a person who wants to solve their problem, not criticize their approach.
That being said, engage them in a discussion which will allow them to show you exactly what they need. Go as basic as you need to go, because the better you understand the problem, the easier it will be for you to suggest an alternative path that could give them most, if not all, of what they are looking for without overly taxing your development schedule. They are coming to you for assistance, and if you take the time to listen to their needs and fully understand the problem they are trying to solve, you will not only have the gratitude of a desperate group of people, you will also have a quality solution which will only make you look good to everyone it impacts.
answered Nov 27 '12 at 6:29
Neil T.
5,01711826
add a comment |Â
up vote
6
down vote
In this kind of situation I find the "yes of course... however" technique is useful.
"Yes of course we can implement feature X, however the way that the code is currently engineered this would mean what we call a "coding epic"; without a detailed analysis with the team its hard to say for sure, but it could take about 16 weeks to implement if we dropped all other tasks, pushed back the next release and just focussed on this."
The advantage here is that if you have misunderstood the importance of the request - which given you are not directly talking to the end-user is always possible - if it is the most important thing in the universe, it can be addressed.
answered Nov 27 '12 at 7:30
GuyM
8,4332743
add a comment |Â
up vote
6
down vote
I think what you might be facing is really a requirements capture problem.
You are getting a feature-request that doesn't make sense. This could mean that the business team doesn't know what their talking about, but it is much more likely that there is a mis-match between what you think they're asking for and what they really require.
Requirements capture is all about determining what the customers require and NOT what they're literally asking for. The customers might not be able to frame their problem/request into a form that makes sense for someone to design and implement. It is up to the other side to do the work to understand what outcomes are desired and then devise a plan to reach those outcomes. In other words, effective requirements capture isn't a one-way transfer of requests from the customer to the implementer, it is a dialectical process where some amount of back-and-forth outputs the real requirements in rhetoric that the implementer can work with.
answered Nov 27 '12 at 15:12
Angelo
6,15621631
add a comment |Â
up vote
3
down vote
Regardless of how you work to tell them "Well, the way we have our core code setup currently this wouldn't work" or "This would give little value, technically, to our customers."
Instead, talk business with them.
These people know money and they know charts. When giving a feasibility assessment at my workplace my development department always makes sure that a quote is included, and that this quote not only factors in the monetary value of what it would cost time and resource wise - but sanity wise as well. If the project is not likely to give any value or be too problematic to try and fill then the quote is upped.
Pricing for the work, and possible showing of Return on Investment is going to be the easiest way to get through their head to show them that it's a bad project idea, from their point of view. If you're unable to do so with either of these, then it's probably not an infeasible or bad idea.
answered Nov 27 '12 at 13:10
cloyd800
548213
add a comment |Â
up vote
3
down vote
Have a proper flow. Do not allow business people to make direct request to developers. Change request must get filed using issue tracking software. And then they wouldn't go directly to developers, but to a product manager, who would prioritize them based on business value and also on your estimation of the work involved.
Obviously suggestions with low business value and lot of developer work will be either rejected. Or as it's practiced in some organizations, put on the very bottom of backlog (where most likely they'll stay forever).
answered Nov 27 '12 at 11:52
vartec
764512
add a comment |Â
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
25
down vote
accepted
You may want to start the conversation by asking clarifications on the requirements in order to better understand them. This will help put the business person at ease rather than appear confrontational. Asking why they need the requirement in the first place shows interest and willingness to satisfy the needs of the end user.
Then, you can explain that nothing is really unfeasible as long as you apply enough time and resources to the problem. Therefore, you can provide an exploratory estimate of how long it would take for you to implement the requirements. They, in turn, will ask questions about the estimates and why they are so high.
You can also ask the business person, what part of the requirements they would like to implement first. This will help them, and you, understand what is the most important piece and that part may end up being feasible.
In general I try to stay unemotional and focus my attention on understanding the need, decomposing in different parts, and estimating the time it will take to implement each part.
answered Nov 27 '12 at 6:58
David S.
3,9902441
11
+1 Let them make the decision as to how much they want to pay for a feature - it's a business decision, not a developer decision.
– Phil
Nov 27 '12 at 14:43
good points David
– Buzz
Nov 28 '12 at 4:32
1
"...nothing is really unfeasible as long as you apply enough time and resources to the problem." In addition to being false, this is dangerous, as you put yourself in a situation where the client may ask for something that really is technically unrealistic after you've given them the impression that you can do anything given enough time/money/etc. It's hard to explain technical limitations to non-technical people, but that doesn't mean you should be dishonest when a client requests something that simply isn't possible.
– kungphu
Nov 8 '16 at 2:15
add a comment |Â
up vote
25
down vote
accepted
You may want to start the conversation by asking clarifications on the requirements in order to better understand them. This will help put the business person at ease rather than appear confrontational. Asking why they need the requirement in the first place shows interest and willingness to satisfy the needs of the end user.
Then, you can explain that nothing is really unfeasible as long as you apply enough time and resources to the problem. Therefore, you can provide an exploratory estimate of how long it would take for you to implement the requirements. They, in turn, will ask questions about the estimates and why they are so high.
You can also ask the business person, what part of the requirements they would like to implement first. This will help them, and you, understand what is the most important piece and that part may end up being feasible.
In general I try to stay unemotional and focus my attention on understanding the need, decomposing in different parts, and estimating the time it will take to implement each part.
answered Nov 27 '12 at 6:58
David S.
3,9902441
11
+1 Let them make the decision as to how much they want to pay for a feature - it's a business decision, not a developer decision.
– Phil
Nov 27 '12 at 14:43
good points David
– Buzz
Nov 28 '12 at 4:32
1
"...nothing is really unfeasible as long as you apply enough time and resources to the problem." In addition to being false, this is dangerous, as you put yourself in a situation where the client may ask for something that really is technically unrealistic after you've given them the impression that you can do anything given enough time/money/etc. It's hard to explain technical limitations to non-technical people, but that doesn't mean you should be dishonest when a client requests something that simply isn't possible.
– kungphu
Nov 8 '16 at 2:15
add a comment |Â
up vote
25
down vote
accepted
up vote
25
down vote
accepted
You may want to start the conversation by asking clarifications on the requirements in order to better understand them. This will help put the business person at ease rather than appear confrontational. Asking why they need the requirement in the first place shows interest and willingness to satisfy the needs of the end user.
Then, you can explain that nothing is really unfeasible as long as you apply enough time and resources to the problem. Therefore, you can provide an exploratory estimate of how long it would take for you to implement the requirements. They, in turn, will ask questions about the estimates and why they are so high.
You can also ask the business person, what part of the requirements they would like to implement first. This will help them, and you, understand what is the most important piece and that part may end up being feasible.
In general I try to stay unemotional and focus my attention on understanding the need, decomposing in different parts, and estimating the time it will take to implement each part.
answered Nov 27 '12 at 6:58
David S.
3,9902441
You may want to start the conversation by asking clarifications on the requirements in order to better understand them. This will help put the business person at ease rather than appear confrontational. Asking why they need the requirement in the first place shows interest and willingness to satisfy the needs of the end user.
Then, you can explain that nothing is really unfeasible as long as you apply enough time and resources to the problem. Therefore, you can provide an exploratory estimate of how long it would take for you to implement the requirements. They, in turn, will ask questions about the estimates and why they are so high.
You can also ask the business person, what part of the requirements they would like to implement first. This will help them, and you, understand what is the most important piece and that part may end up being feasible.
In general I try to stay unemotional and focus my attention on understanding the need, decomposing in different parts, and estimating the time it will take to implement each part.
answered Nov 27 '12 at 6:58
David S.
3,9902441
edited Mar 5 '15 at 13:00
answered Nov 27 '12 at 6:58
David S.
3,9902441
answered Nov 27 '12 at 6:58
David S.
3,9902441
answered Nov 27 '12 at 6:58
David S.
3,9902441
3,9902441
11
+1 Let them make the decision as to how much they want to pay for a feature - it's a business decision, not a developer decision.
– Phil
Nov 27 '12 at 14:43
good points David
– Buzz
Nov 28 '12 at 4:32
1
"...nothing is really unfeasible as long as you apply enough time and resources to the problem." In addition to being false, this is dangerous, as you put yourself in a situation where the client may ask for something that really is technically unrealistic after you've given them the impression that you can do anything given enough time/money/etc. It's hard to explain technical limitations to non-technical people, but that doesn't mean you should be dishonest when a client requests something that simply isn't possible.
– kungphu
Nov 8 '16 at 2:15
add a comment |Â
11
+1 Let them make the decision as to how much they want to pay for a feature - it's a business decision, not a developer decision.
– Phil
Nov 27 '12 at 14:43
good points David
– Buzz
Nov 28 '12 at 4:32
1
"...nothing is really unfeasible as long as you apply enough time and resources to the problem." In addition to being false, this is dangerous, as you put yourself in a situation where the client may ask for something that really is technically unrealistic after you've given them the impression that you can do anything given enough time/money/etc. It's hard to explain technical limitations to non-technical people, but that doesn't mean you should be dishonest when a client requests something that simply isn't possible.
– kungphu
Nov 8 '16 at 2:15
11
11
+1 Let them make the decision as to how much they want to pay for a feature - it's a business decision, not a developer decision.
– Phil
Nov 27 '12 at 14:43
+1 Let them make the decision as to how much they want to pay for a feature - it's a business decision, not a developer decision.
– Phil
Nov 27 '12 at 14:43
good points David
– Buzz
Nov 28 '12 at 4:32
good points David
– Buzz
Nov 28 '12 at 4:32
1
1
"...nothing is really unfeasible as long as you apply enough time and resources to the problem." In addition to being false, this is dangerous, as you put yourself in a situation where the client may ask for something that really is technically unrealistic after you've given them the impression that you can do anything given enough time/money/etc. It's hard to explain technical limitations to non-technical people, but that doesn't mean you should be dishonest when a client requests something that simply isn't possible.
– kungphu
Nov 8 '16 at 2:15
"...nothing is really unfeasible as long as you apply enough time and resources to the problem." In addition to being false, this is dangerous, as you put yourself in a situation where the client may ask for something that really is technically unrealistic after you've given them the impression that you can do anything given enough time/money/etc. It's hard to explain technical limitations to non-technical people, but that doesn't mean you should be dishonest when a client requests something that simply isn't possible.
– kungphu
Nov 8 '16 at 2:15
add a comment |Â
up vote
15
down vote
You don't have to explain the technical details to them, but you do need to give them an understanding as to the challenges you will face in trying to implement it. One thing you always need to keep in mind (and I've been a developer for almost 30 years) is that the business and operations people are experts in their business and the company operations. I've come across too many technical people in my travels who lose sight of the fact that, although the people they have deal with on a daily basis know very little about computers and software development, they know far more about business and corporate operations than they do. The developer has to approach the problem with the eye of a person who wants to solve their problem, not criticize their approach.
That being said, engage them in a discussion which will allow them to show you exactly what they need. Go as basic as you need to go, because the better you understand the problem, the easier it will be for you to suggest an alternative path that could give them most, if not all, of what they are looking for without overly taxing your development schedule. They are coming to you for assistance, and if you take the time to listen to their needs and fully understand the problem they are trying to solve, you will not only have the gratitude of a desperate group of people, you will also have a quality solution which will only make you look good to everyone it impacts.
answered Nov 27 '12 at 6:29
Neil T.
5,01711826
add a comment |Â
up vote
15
down vote
You don't have to explain the technical details to them, but you do need to give them an understanding as to the challenges you will face in trying to implement it. One thing you always need to keep in mind (and I've been a developer for almost 30 years) is that the business and operations people are experts in their business and the company operations. I've come across too many technical people in my travels who lose sight of the fact that, although the people they have deal with on a daily basis know very little about computers and software development, they know far more about business and corporate operations than they do. The developer has to approach the problem with the eye of a person who wants to solve their problem, not criticize their approach.
That being said, engage them in a discussion which will allow them to show you exactly what they need. Go as basic as you need to go, because the better you understand the problem, the easier it will be for you to suggest an alternative path that could give them most, if not all, of what they are looking for without overly taxing your development schedule. They are coming to you for assistance, and if you take the time to listen to their needs and fully understand the problem they are trying to solve, you will not only have the gratitude of a desperate group of people, you will also have a quality solution which will only make you look good to everyone it impacts.
answered Nov 27 '12 at 6:29
Neil T.
5,01711826
add a comment |Â
up vote
15
down vote
up vote
15
down vote
You don't have to explain the technical details to them, but you do need to give them an understanding as to the challenges you will face in trying to implement it. One thing you always need to keep in mind (and I've been a developer for almost 30 years) is that the business and operations people are experts in their business and the company operations. I've come across too many technical people in my travels who lose sight of the fact that, although the people they have deal with on a daily basis know very little about computers and software development, they know far more about business and corporate operations than they do. The developer has to approach the problem with the eye of a person who wants to solve their problem, not criticize their approach.
That being said, engage them in a discussion which will allow them to show you exactly what they need. Go as basic as you need to go, because the better you understand the problem, the easier it will be for you to suggest an alternative path that could give them most, if not all, of what they are looking for without overly taxing your development schedule. They are coming to you for assistance, and if you take the time to listen to their needs and fully understand the problem they are trying to solve, you will not only have the gratitude of a desperate group of people, you will also have a quality solution which will only make you look good to everyone it impacts.
answered Nov 27 '12 at 6:29
Neil T.
5,01711826
You don't have to explain the technical details to them, but you do need to give them an understanding as to the challenges you will face in trying to implement it. One thing you always need to keep in mind (and I've been a developer for almost 30 years) is that the business and operations people are experts in their business and the company operations. I've come across too many technical people in my travels who lose sight of the fact that, although the people they have deal with on a daily basis know very little about computers and software development, they know far more about business and corporate operations than they do. The developer has to approach the problem with the eye of a person who wants to solve their problem, not criticize their approach.
That being said, engage them in a discussion which will allow them to show you exactly what they need. Go as basic as you need to go, because the better you understand the problem, the easier it will be for you to suggest an alternative path that could give them most, if not all, of what they are looking for without overly taxing your development schedule. They are coming to you for assistance, and if you take the time to listen to their needs and fully understand the problem they are trying to solve, you will not only have the gratitude of a desperate group of people, you will also have a quality solution which will only make you look good to everyone it impacts.
answered Nov 27 '12 at 6:29
Neil T.
5,01711826
answered Nov 27 '12 at 6:29
Neil T.
5,01711826
answered Nov 27 '12 at 6:29
Neil T.
5,01711826
answered Nov 27 '12 at 6:29
Neil T.
5,01711826
5,01711826
add a comment |Â
add a comment |Â
up vote
6
down vote
In this kind of situation I find the "yes of course... however" technique is useful.
"Yes of course we can implement feature X, however the way that the code is currently engineered this would mean what we call a "coding epic"; without a detailed analysis with the team its hard to say for sure, but it could take about 16 weeks to implement if we dropped all other tasks, pushed back the next release and just focussed on this."
The advantage here is that if you have misunderstood the importance of the request - which given you are not directly talking to the end-user is always possible - if it is the most important thing in the universe, it can be addressed.
answered Nov 27 '12 at 7:30
GuyM
8,4332743
add a comment |Â
up vote
6
down vote
In this kind of situation I find the "yes of course... however" technique is useful.
"Yes of course we can implement feature X, however the way that the code is currently engineered this would mean what we call a "coding epic"; without a detailed analysis with the team its hard to say for sure, but it could take about 16 weeks to implement if we dropped all other tasks, pushed back the next release and just focussed on this."
The advantage here is that if you have misunderstood the importance of the request - which given you are not directly talking to the end-user is always possible - if it is the most important thing in the universe, it can be addressed.
answered Nov 27 '12 at 7:30
GuyM
8,4332743
add a comment |Â
up vote
6
down vote
up vote
6
down vote
In this kind of situation I find the "yes of course... however" technique is useful.
"Yes of course we can implement feature X, however the way that the code is currently engineered this would mean what we call a "coding epic"; without a detailed analysis with the team its hard to say for sure, but it could take about 16 weeks to implement if we dropped all other tasks, pushed back the next release and just focussed on this."
The advantage here is that if you have misunderstood the importance of the request - which given you are not directly talking to the end-user is always possible - if it is the most important thing in the universe, it can be addressed.
answered Nov 27 '12 at 7:30
GuyM
8,4332743
In this kind of situation I find the "yes of course... however" technique is useful.
"Yes of course we can implement feature X, however the way that the code is currently engineered this would mean what we call a "coding epic"; without a detailed analysis with the team its hard to say for sure, but it could take about 16 weeks to implement if we dropped all other tasks, pushed back the next release and just focussed on this."
The advantage here is that if you have misunderstood the importance of the request - which given you are not directly talking to the end-user is always possible - if it is the most important thing in the universe, it can be addressed.
answered Nov 27 '12 at 7:30
GuyM
8,4332743
answered Nov 27 '12 at 7:30
GuyM
8,4332743
answered Nov 27 '12 at 7:30
GuyM
8,4332743
answered Nov 27 '12 at 7:30
GuyM
8,4332743
8,4332743
add a comment |Â
add a comment |Â
up vote
6
down vote
I think what you might be facing is really a requirements capture problem.
You are getting a feature-request that doesn't make sense. This could mean that the business team doesn't know what their talking about, but it is much more likely that there is a mis-match between what you think they're asking for and what they really require.
Requirements capture is all about determining what the customers require and NOT what they're literally asking for. The customers might not be able to frame their problem/request into a form that makes sense for someone to design and implement. It is up to the other side to do the work to understand what outcomes are desired and then devise a plan to reach those outcomes. In other words, effective requirements capture isn't a one-way transfer of requests from the customer to the implementer, it is a dialectical process where some amount of back-and-forth outputs the real requirements in rhetoric that the implementer can work with.
answered Nov 27 '12 at 15:12
Angelo
6,15621631
add a comment |Â
up vote
6
down vote
I think what you might be facing is really a requirements capture problem.
You are getting a feature-request that doesn't make sense. This could mean that the business team doesn't know what their talking about, but it is much more likely that there is a mis-match between what you think they're asking for and what they really require.
Requirements capture is all about determining what the customers require and NOT what they're literally asking for. The customers might not be able to frame their problem/request into a form that makes sense for someone to design and implement. It is up to the other side to do the work to understand what outcomes are desired and then devise a plan to reach those outcomes. In other words, effective requirements capture isn't a one-way transfer of requests from the customer to the implementer, it is a dialectical process where some amount of back-and-forth outputs the real requirements in rhetoric that the implementer can work with.
answered Nov 27 '12 at 15:12
Angelo
6,15621631
add a comment |Â
up vote
6
down vote
up vote
6
down vote
I think what you might be facing is really a requirements capture problem.
You are getting a feature-request that doesn't make sense. This could mean that the business team doesn't know what their talking about, but it is much more likely that there is a mis-match between what you think they're asking for and what they really require.
Requirements capture is all about determining what the customers require and NOT what they're literally asking for. The customers might not be able to frame their problem/request into a form that makes sense for someone to design and implement. It is up to the other side to do the work to understand what outcomes are desired and then devise a plan to reach those outcomes. In other words, effective requirements capture isn't a one-way transfer of requests from the customer to the implementer, it is a dialectical process where some amount of back-and-forth outputs the real requirements in rhetoric that the implementer can work with.
answered Nov 27 '12 at 15:12
Angelo
6,15621631
I think what you might be facing is really a requirements capture problem.
You are getting a feature-request that doesn't make sense. This could mean that the business team doesn't know what their talking about, but it is much more likely that there is a mis-match between what you think they're asking for and what they really require.
Requirements capture is all about determining what the customers require and NOT what they're literally asking for. The customers might not be able to frame their problem/request into a form that makes sense for someone to design and implement. It is up to the other side to do the work to understand what outcomes are desired and then devise a plan to reach those outcomes. In other words, effective requirements capture isn't a one-way transfer of requests from the customer to the implementer, it is a dialectical process where some amount of back-and-forth outputs the real requirements in rhetoric that the implementer can work with.
answered Nov 27 '12 at 15:12
Angelo
6,15621631
answered Nov 27 '12 at 15:12
Angelo
6,15621631
answered Nov 27 '12 at 15:12
Angelo
6,15621631
answered Nov 27 '12 at 15:12
Angelo
6,15621631
6,15621631
add a comment |Â
add a comment |Â
up vote
3
down vote
Regardless of how you work to tell them "Well, the way we have our core code setup currently this wouldn't work" or "This would give little value, technically, to our customers."
Instead, talk business with them.
These people know money and they know charts. When giving a feasibility assessment at my workplace my development department always makes sure that a quote is included, and that this quote not only factors in the monetary value of what it would cost time and resource wise - but sanity wise as well. If the project is not likely to give any value or be too problematic to try and fill then the quote is upped.
Pricing for the work, and possible showing of Return on Investment is going to be the easiest way to get through their head to show them that it's a bad project idea, from their point of view. If you're unable to do so with either of these, then it's probably not an infeasible or bad idea.
answered Nov 27 '12 at 13:10
cloyd800
548213
add a comment |Â
up vote
3
down vote
Regardless of how you work to tell them "Well, the way we have our core code setup currently this wouldn't work" or "This would give little value, technically, to our customers."
Instead, talk business with them.
These people know money and they know charts. When giving a feasibility assessment at my workplace my development department always makes sure that a quote is included, and that this quote not only factors in the monetary value of what it would cost time and resource wise - but sanity wise as well. If the project is not likely to give any value or be too problematic to try and fill then the quote is upped.
Pricing for the work, and possible showing of Return on Investment is going to be the easiest way to get through their head to show them that it's a bad project idea, from their point of view. If you're unable to do so with either of these, then it's probably not an infeasible or bad idea.
answered Nov 27 '12 at 13:10
cloyd800
548213
add a comment |Â
up vote
3
down vote
up vote
3
down vote
Regardless of how you work to tell them "Well, the way we have our core code setup currently this wouldn't work" or "This would give little value, technically, to our customers."
Instead, talk business with them.
These people know money and they know charts. When giving a feasibility assessment at my workplace my development department always makes sure that a quote is included, and that this quote not only factors in the monetary value of what it would cost time and resource wise - but sanity wise as well. If the project is not likely to give any value or be too problematic to try and fill then the quote is upped.
Pricing for the work, and possible showing of Return on Investment is going to be the easiest way to get through their head to show them that it's a bad project idea, from their point of view. If you're unable to do so with either of these, then it's probably not an infeasible or bad idea.
answered Nov 27 '12 at 13:10
cloyd800
548213
Regardless of how you work to tell them "Well, the way we have our core code setup currently this wouldn't work" or "This would give little value, technically, to our customers."
Instead, talk business with them.
These people know money and they know charts. When giving a feasibility assessment at my workplace my development department always makes sure that a quote is included, and that this quote not only factors in the monetary value of what it would cost time and resource wise - but sanity wise as well. If the project is not likely to give any value or be too problematic to try and fill then the quote is upped.
Pricing for the work, and possible showing of Return on Investment is going to be the easiest way to get through their head to show them that it's a bad project idea, from their point of view. If you're unable to do so with either of these, then it's probably not an infeasible or bad idea.
answered Nov 27 '12 at 13:10
cloyd800
548213
answered Nov 27 '12 at 13:10
cloyd800
548213
answered Nov 27 '12 at 13:10
cloyd800
548213
answered Nov 27 '12 at 13:10
cloyd800
548213
548213
add a comment |Â
add a comment |Â
up vote
3
down vote
Have a proper flow. Do not allow business people to make direct request to developers. Change request must get filed using issue tracking software. And then they wouldn't go directly to developers, but to a product manager, who would prioritize them based on business value and also on your estimation of the work involved.
Obviously suggestions with low business value and lot of developer work will be either rejected. Or as it's practiced in some organizations, put on the very bottom of backlog (where most likely they'll stay forever).
answered Nov 27 '12 at 11:52
vartec
764512
add a comment |Â
up vote
3
down vote
Have a proper flow. Do not allow business people to make direct request to developers. Change request must get filed using issue tracking software. And then they wouldn't go directly to developers, but to a product manager, who would prioritize them based on business value and also on your estimation of the work involved.
Obviously suggestions with low business value and lot of developer work will be either rejected. Or as it's practiced in some organizations, put on the very bottom of backlog (where most likely they'll stay forever).
answered Nov 27 '12 at 11:52
vartec
764512
add a comment |Â
up vote
3
down vote
up vote
3
down vote
Have a proper flow. Do not allow business people to make direct request to developers. Change request must get filed using issue tracking software. And then they wouldn't go directly to developers, but to a product manager, who would prioritize them based on business value and also on your estimation of the work involved.
Obviously suggestions with low business value and lot of developer work will be either rejected. Or as it's practiced in some organizations, put on the very bottom of backlog (where most likely they'll stay forever).
answered Nov 27 '12 at 11:52
vartec
764512
Have a proper flow. Do not allow business people to make direct request to developers. Change request must get filed using issue tracking software. And then they wouldn't go directly to developers, but to a product manager, who would prioritize them based on business value and also on your estimation of the work involved.
Obviously suggestions with low business value and lot of developer work will be either rejected. Or as it's practiced in some organizations, put on the very bottom of backlog (where most likely they'll stay forever).
answered Nov 27 '12 at 11:52
vartec
764512
edited Nov 29 '12 at 17:27
answered Nov 27 '12 at 11:52
vartec
764512
answered Nov 27 '12 at 11:52
vartec
764512
answered Nov 27 '12 at 11:52
vartec
764512
764512
add a comment |Â
add a comment |Â
3
I'd recommend this for moderator migration - user experience or stack overflow might work - but I second @Chad - this is a standard problem in computer science, not a workplace question.
– bethlakshmi
Nov 27 '12 at 15:32
3
"...I think is having very little use to end user..." - If they are the end user, they know better than you. You should just look at all their requests and provide appropriate estimates (even if they are crazy amounts of work), then let them decide what's worth keeping and what's not.
– MrFox
Nov 27 '12 at 16:53
1
i m confused why this is offtopic?,if does not belong here them may be fit at programmers.stackexchange.com
– Buzz
Nov 28 '12 at 4:30
1
@With editing, this could be made into a generic question faced by many people in the workplace; how to manage "outside" suggestions for 'obvious, simple' changes to a system, process, tool - that, because the outside person lacks the full picture, have huge hidden cost/time/priority implications.
– GuyM
Nov 29 '12 at 19:05
2
This is an issue about workplace communications. It's on-topic.
– Euan M
Nov 30 '15 at 19:07