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 antagonistic.
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 negotiating …)
- 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) estimates 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 roadblock!