When I look back at yesterday's comments about defining the problem, I can find many instances in my career where, if I had stopped and examined the problem in more detail, I would have made different decisions and different recommendations.
With regard to technology decisions, I've usually made the right recommendation at the right time based on the information I was given. I was asked to solve a specific problem, within specific parameters, and I came up with a solution for that problem. The problem lies in the fuzzier "direction" requests and anything else that involved other people making decisions. You see, I am really bad at guessing at what other people think. I just can't do it, mainly because everyone else thinks illogically. (Either that or I am insane.)
When dealing with other people, however, it is more important than ever to sit back and really understand what the problem is, not just your solution to the problem. Everyone has a different perspective on the issue and everyone is going to have a different answer to the problem. If we can agree on what the real problem is, however, we can more readily agree on an overall solution that fits in with everyone's perception of the problem.
Whether the problem is with regard to a complex business issue or a procedural flaw in a process, the underlying problem needs to be identified and agreed upon by the different parties. You may discover that what you are trying to solve isn't really a problem, but a symptom of a completely different problem that is not going to be resolved by your solution. Implementing your solution would do nothing to fix the problem, which in itself is a problem, just not the one that needed solving when you started.
No comments:
Post a Comment