Answering questions with questions is a quick path towards
Why do some folks insist on answering questions with questions?
Or, answering questions with roadblocks? It's not surprising when you
hear IT complain about their inability to connect with the business, of
not being included, etc. - and then demonstrate a style of investigation
/ requirements gathering / support / feedback that is a bit
Business: How long would it take you to do X?
IT: Why X? Why not Y?
... or IT: Why X? What are the benefits?
... or IT: Doesn't matter ... we don't have
time/resources for that.
Major tactical errors - just put yourself in their place, and
listen. It sounds like you are questioning their competence as business
people (Are you suggesting I don't understand my own problem?
That I don't know / didn't compute a cost / benefit?)
It doesn't matter that you may be right (and no, I'm not implying
that you should humor the incompetent). Folks may not know of the
existence of alternate solutions. It's possible they may not be aware of
competing requirements / demands on your time. When the conversation
starts, it's really not about the facts at all. By refusing to answer
their question, you invalidate any and all thinking work they may have
put into this, and that would put anyone off.
The best approach is to answer the question as completely as
possible, given whatever information you may or may not have. Simple
program changes? 2 days. Basic reports? 5-10 days. Whatever - just
provide a reasonable answer - and then ask the follow-up questions on
specific requirements or alternatives. (... now, we're
- Requirements include level of detail - don't assume the
correct answer to a reporting / information inquiry is the 100%
solution. Remember, we work in a fast-moving business climate, and
often the 80%, throwaway solution is good enough. By digging into the
requirements, you can help them cut the time / resource requirements
down, and get something that's "good enough" delivered faster.
- When someone asks how long it would take, they typically need
a good estimate, but not a scientific one. "Rough Order of Magnitude"
(ROM) estmiates are terrific - and you can tell them that. This
is a rough estimate; we could be done in two months, give or take a few
weeks (expect +/- 50% accuracy). Note that the key answer they are
looking for is that it's not one week and it's not one year - but if
they "need" something in one week, we can look into alternatives.
- Please, do not tell me that the business will assume you mean
delivered in two months, and hold you to that forever. Yes,
most business folks don't immediately understand the difference
between effort time and calendar time, but if they walk away from the
conversation thinking "done by Xmas", and that belief never
changes - whose fault is that? (I want you to say yours -
take responsibility for the communications!!
- "Time to value" and "total cost to implement" can be the
driver - so we should consider taking advantage of standard product (as
opposed to customization). Now, your IT strategic direction becomes the
means, not the end, because it's the business results we should be
driving towards, not the IT platitudes.
- Resource constrained? Well, if there is business benefit
there, then we can cost-justify incremental / over the budget spend
(your budget or mine makes little difference - but the benefits now
must be hard and quantified).
It's completely OK to push back on requests for work, but
typically there is no need to make it a shoving match. Give them what
they ask for - an estimate - and then help them understand how likely
that outcome is. You've just become a major help to them, not a