I am involved in a lot of conversations where companies and people are trying to solve a business challenge with software. Communication is so compressed nowadays, people’s time is limited, and we are almost always communicating across multiple time zones and frequently across cultures. This makes a common understanding difficult and opens up lots of opportunity for confusion.

Normally I would agree that talking about solutions is a very good thing. Here’s what happens in almost every one of these conversations. We fail to actually define the problem, because we’re so anxious to offer our solution. Generally there isn’t a description of the challenge at all, typically we hear a proposed solution (not a problem) and are asked to comment on how to execute on it. So many IT projects are based on this flawed foundation and the results are a lot of wasted time and money.

Why is defining the challenge so important?

There are always multiple ways to solve a problem. Normally the best approach requires a combination of expertise (context over the business process, technical expertise of the systems involved, good critical thinking skills, understanding of the users involved, and knowledge of how software works in general). No one person holds all this knowledge. You have to describe the challenge to the group that can collectively come up with the best solution.

On a recent call, we were talking about integration. The customer started the conversation with how they would provide a data file out of their system for us to pick up and integrate into another system. For some time the conversation dove deep into the details of how this proposed solution would work. I then asked the question, why are you exporting to a file? The answer was “it’s just what I thought we needed to do.” This is a great example. We didn’t define the challenge; we just started discussing a potential solution offered by one person with limited context and expertise. The customer wanted bi-directional, real-time integration – exporting to a file as an intermediary step would prevent the desired results of this project, yet we spent lots of time talking about this potential solution because we didn’t take the time to define the challenge clearly.

So next time you’re getting into a conversation about how to solve a business challenge with software, hold up on the solutions and ask clarifying questions about the challenge. Test yourself, do I understand what the challenge is completely, before you start trying to solve it. Often the little details you get from asking clarifying questions will greatly influence your solution thinking and often they provide the spark to solve the challenge more elegantly.

For example:

1. Can someone describe the business challenge you want to solve?
2. What are the desired BUSINESS results?
3. What are all the systems involved?
4. Describe the users of this system?
5. What is the scale of challenge?
6. What is the timeframe the solution is needed in?

Does everyone involved understand the problem? It’s really easy to make assumptions here and plough forward without validating that everyone is on the same page. I’ve seen “early assumptions” cost hundreds of thousands of dollars and months of labor downstream.

Take the time to define the challenge, if nobody asks any clarifying questions – you’re probably making assumptions, rather than verifying understanding. Being smart isn’t about proposing the first potential solution, being smart is about asking the right question that expands everyone understands.